Saturday, November 26, 2016

VulnHub - Lord of the Root Writeup















Tags: password reuse; improper input validation; un-patched server; SQLi

Lord of the Root is an intentionally vulnerable Ubuntu 14.04 virtual machine (VM) created by KookSec and hosted on vulnhub.com.  

I downloaded and imported the .ova into my virtual lab without issues using VMWare Fusion(Professional Version 8.5.2).  The VM started up and presented the following desktop:


The desktop revealed a likely user account on the machine.  Smeagol is a character in the Lord of the Rings anthology.  I added 'smeagol' and other likely LOTR characters to my username list for later.

On my attacking Kali Linux VM I ran netdiscover to determine the target's IP address:


I ran some nmap scans:



Looks like the target is running SSH on port 22.



The remote SSH session attempt revealed the SSH splash screen that included the the word 'knock' and 'Easy as 1,2,3' (a port knocking clue).

Before I attempted port knocking, I did a quick SSH brute force attempt.

I used hydra to test user smeagol for easy passwords (barnett_top500.txt) and was unsuccessful. Then used cewl to create a password list of Lord of the Rings words and tried hydra again.

#cewl http://www.imdb.com/title/tt0120737/trivia?ref_=tt_ql_2 -d 0 -w /root/lordroot/imdb_words2.txt -m 8


OK, so no trivial brute force  for user smeagol.

I began port knocking.  I tried a bunch of different ways, but here is the method that opened up a new port:


This port knocking method opened up a new port, port 1337.


Interesting...port 1337...for fun I browsed to the port:


OK...I examined the source code of the page.


The source code revealed a sub-directory of the web root.  I browsed to it and found this...


OK, an image directory.  I downloaded and examined each image in binwalk.


I found nothing interesting in the three images.  I also examined each images' metadata in Exiftool and found nothing interesting either.

For fun, I browsed for a robot.txt file on the web root...


The robots.txt page had one of the three images in it and did not have the usual file directory presentation.  I examined the page's source code.


The source code had some syntax-incorrect html code that contained a likely encoded string.  I tried various ways to decode this string.  I eventually discovered that is was a double-Base64 encoded string.


I used Kali Linux's base64 decoding method.  Was rewarded after the first decode with a note of encouragement ('Closer!').


The second decode revealed what was most likely a new directory off the web root.  Now, we are getting somewhere!

I browsed to the newly-disovered directory.


Aaand, it is a page with form-based authentication.  

I ran the page through Burp Suite Pro and discovered a possible SQLi vulnerability.


SQL Injection Vulnerability

I prepared to attack the possible SQLi vulnerability by crafting a post request as per below.  Then, I ran it through SQLMap.

request.txt

POST /978345210/index.php HTTP/1.1
Host: 192.168.188.244:1337
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Iceweasel/43.0.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=9lr00pcvfm2ne5k7lbqe3ol156
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 40

username=aaa*&password=bbb*&submit=+Login+



Ran the following command with SQLMap:

#sqlmap -r /root/request.txt --risk=3 --level=5


SQLMap indicated that the username parameter was likely vulnerable to a time-based blind SQL Injection and that the web application database was MySQL version 5.0.12.

I attempted to enumerate the name of the web applications database:


#sqlmap -r /root/request.txt --dbms=MYSQL --risk=3 --level=5 –current-db


Discovered that the web app database name was (ironically) 'Webapp'.  I then attempted to discover the tables in the 'Webapp' database:

#sqlmap -r /root/request.txt --dbms=MYSQL --risk=3 --level=5 -D Webapp --tables


Looks like just one table 'Users'...

Next, I enumerated the columns in the Users table...

#sqlmap -r /root/request.txt --dbms=MYSQL --risk=3 --level=5 -D Webapp -T Users –columns


Looks like three columns...including the password and username columns...

I then attempted to dump the contents of all three columns in the Users table...

#sqlmap -r /root/request.txt --dbms=MYSQL --risk=3 --level=5 -D Webapp -T Users --dump


Aaaand, it worked. I noted all five web app credentials for my notes.

For fun, I attempted to login to SSH as user smeagol with the web app password....

#ssh smeagol@192.168.188.244
(password:MyPreciousR00t)


And it worked.  I gained user smeagol access remotely via SSH.

Privilege Escalation

Since the target has an Ubuntu 14.04 kernel, I first considered the 'overlayfs
(Linux Kernel 4.3.3 (Ubuntu 14.04/15.10) - 'overlayfs' Privilege Escalation (1) – 39166.c) local exploit.

I put 39166.c on my attacking Kali Linux machine's web root, started the apache server on it, and from the remote SSH user session on the target used wget to bring the script on the target. 


I made it executable, compiled it locally, and then executed it.  



It worked!; I got root privileges on the target. I then found the proof flag.


This completed the Lord of the Root challenge.


Recap:
The SSH splash page gave a port knocking clue; used port knocking to open up a new port (1337). I browsed to that port, inspected source code to find a double Base64 encoded directory. In that directory there was a form-authentication page. Used Burp Suite Pro to discover a possible SQLi vulnerability. Confirmed the vulnerability in SQLMap and dumped web application credentials (improper user input validation). Used one of the credentials to log in as user on SSH (password re-use). Used a local kernel exploit to escalate privileges to root (unpatched server).

Acknowledgements:
Thanks to KookSec for creating the Lord of the Root challenge. Thanks to g0tmi1k for hosting and maintaining the vulnhub.com site.  Also to the vulnhub folks who test each VM so thoroughly before releasing.

No comments:

Post a Comment