Temple of Doom: 1 Boot to Root VM Walkthrough

Introduction

Today we’re going to thoroughly pwn the Temple of Doom: 1 VM from Vulnhub, created byΒ 0katz. This box was fun and had some swish ASCII art to boot, I learned a tonne from it and I hope that you learn something from this write up!

Let’s get to it.

Host Identification and nmap-ing

First up we check where our VM is using netdiscover (netdiscover -i INTERFACE -r 192.168.56.0/24)

Cool, box is at 192.168.56.101.

Next up we find out what ports are open on the box with the ever useful nmap –

So the box has a very limited attack surface. Just SSH on port 22 and what appears to be a Node JS web server on port 666 (D00M!)

Next we check out that port in a browser to see whether it actually is a webserver or not.

Port 666 – The Number of the Beast

Navigating to the webserver gives us a HUGELY anticlimactic “Under Construction, Come Back Later!” message.. So now we run the usual enumeration steps.

Check for robots.txt

“Cannot GET /robots.txt”

Run dirb against it

Nope. Nothing found with 4 different word lists.

Run nikto against it

Nope. Even with the “-Tuning d” flag to tell it that the remote end is a webservice!

The A-ha! Moment

In desp(acito)eration I went back to the browser and hit refresh and ‘lo and behold now there is a random error message:

Interesting right? The only difference between this request and the last one is that a “profile” cookie has now been set.. Let’s dig into it.

The stock cookie looks like this:

 

which base64 decodes to this:

{“username”:”Admin”,”csrftoken”:”u32t4o3tb3gg431fs34ggdgchjwnza0l=”,”Expires=”:Friday, 13 Oct 2018 00:00:00 GMT”}

… Username admin? wut? Anyway. The error above is whinging about “unexpected token F in JSON at position 79” which happens to correspond with the “Expires” field. Maybe we could remove that equals sign and get it to work?

After setting my new profile cookie in Firefox we’re greeted with a rather terse “Hello Admin” message. One step further anyway!

Supplying this cookie value to Nikto yielded nothing extra, ditto Dirb..

After a bit of Googling for Node app pentesting I came across this beautiful articleΒ which we discusses how dangerous “unserialize” can be.. Notice the first line in the error output above? uh-oh!

Unserialize-pwnage

Taking the sterling example offered by the chaps above, I used the following input:

Which should kill the Node server. ‘lo and behold:

Completely trashed the process πŸ™‚ Now we just need to bounce the VM and weaponize the exploit.

  • First up, use this excellent script to generate a reverse JS shell using eval and charcodes:
  • Next, insert the output of that script into my profile cookie:

  • Next, base64 it and set it as my cookie
  • Next start a netcat listener on port 6666 (see what I did there..)
  • Next refresh the browser
  • ???
  • Profit

And we have our basic shell πŸ™‚ *claps*

Better Shell and Privesc

First things first, get a more persistent and less flaky shell. A la meterpreter!

I’m not going to labour the point here as you can read many of my other blogs to find out how to spin up a meterpreter shell etc. What I WILL say though is that I got my meterpreter shell and executed “mkdir .ssh” from within my shell, then backgrounded the shell and ran “run post/linux/manage/sshkey_persistence” which installed a valid private key file on my box so that I can SSH to the target. This is aΒ much better form of persistence and less flaky than reverse shells etc.

Now for PrivEsc.

As always, the stuff leading up to this part was (comparitively..) easy. This was the hard part! I spent ages running the usual gamut of Unix-Privesc-Checker etc. but nothing useful popped out (there are a load of kernel exploits for the box, but GCC’s not installed and all of my attempts to cross compile failed!)

Eventually I ran “ps aux | grep -i fireman” (the other use on the box) and spotted that he’s running something called “ss-manager”, a bit of research online shows that the version installed is vulnerable to a command execution vulnerability! Wahoo this will let us escalate from nodeadmin to fireman πŸ™‚

So first things first, use the exploit to find out what fireman can run as root:

Which pops out with:

All of that is interesting, but the “tcpdump” line is particularly of interest as it can be used for privesc to root..

The set up is as follows:

  • make a script in /tmp/ which simply echos a new user to the passwd file (echo “toor1:aaKNIEDOaueR6:0:0:toor:/root:/bin/bash” >> /etc/passwd)
  • Use the ss-manager vulnerability to run “add: {“server_port”:8005, “password”:”test”, “method”:”||sudo tcpdump -ln -i eth0 -w /dev/null -W 1 -G 1 -z /tmp/test -Z root||”}

Step 1 seems to have worked, let’s check /etc/passwd to confirm:

Great, it worked. That hashed password corresponds with “foo” so let’s try and log in.

Woot! And the flag –

Bingo!

Conclusion

This was a great box. Really unique set of challenges and my first ever NodeJS pentest! As mentioned above I found the most challenging part to be the privesc, because I’m so used to going from limited user -> root, rather than limited user -> intermediate user -> root.

Cheers 0katz πŸ™‚

2 Comments

Add a Comment

Your email address will not be published. Required fields are marked *