Lord Of The Root - CTF

First of all: big thanks for the author for preparing this CTF. Man, I had no idea that Frodo is a hipster! ;D

…but first things first. ;) I started this CTF as usual: scanning the target’s IP:

What I’ve found surprised me a little bit, so I decide to scan the machine again:

Ok… So which way should I go? The goal here is to “take the ring into Mordor” (and grab the flag). So any 0days for ssh6.6.p1 for Ubuntu? :> Maybe a little bruteforce? So let’s try to connect to it first:

Ok, should be easy as one-two-three. I remember one “section” of wargame on SCS in Poland related to this case: port knocking (beside that: ‘knock friend to enter’). 3-2-1… nmap again:

Looks like after that, we will see a 1337le diff:

What’s going on? Machine is definitely ready for port knocking. Let’s find out what’s running on port 1337:

Nice, looks like a HTTP server. Let’s try to dig a little bit deeper and let’s send a GET to this server:

Ok, we can see some (let’s say;)) “normal” Apache response (headers) and some source of the web page. I decide to download the photo from /images/iwilldoit.jpg and put it on my WWW (in my small lab machine) to check if this is a real pic or not. And I found this:

Now I knew that we need that pony! ;) I was wondering where is it and that’s how I decide to run a few instances of dirb (with few different dictionaries). So now I had few minutes to poke a server more manually. Few quick checks for default locations of files possible to find during webapp pentests and I found that robots.txt is accessible on a weird way:  

What do you see here? I see some base64<link>. Let’s decode it, but before that – there is also a link to another JPG. When I saw this…

Frodo is a hipster! ;D This is what I did not expect during a CTF – lesson from that one: expect everything. ;) Ok. Let’s decode that mentioned base64 now:

Ok, cool. Seems that we’re closer… Another base64?

… and closer… ;) Ok. What we’ve found here:

Some kind of a panel? If so, we should be able to send a POST or GET there. So we need a 3 params: username, password and submit with “ Login “ value. We can do it via Burp or via console – your choice. I decided to continue in console (I just like it, it’s really your choice):

As you can see, the huge different in the response is that we now can see that there is some interaction with that web page. “Username or Password is invalid”. Ok, so I see two ways: bruteforce, but it’s (in the most cases) boring ;) or we can try, maybe this panel is vulnerable to some injection attacks.

I used sqlmap here with request similar to the one I used before with curl:

Type ‘y’ and next I saw:

Ok, so it’s probably “working” somehow… We need to understand what and where. My mistake was to type yes also for redirection (last question from the screen). Don’t do it. Type no and go deeper:

Nice. I like to play with shells so I decide to re-run sqlmap with --sql-shell parameter:

Nice, so we’re able to connects to the database and grab some info. I was wondering if we can also grab some files (maybe there is a config.php.inc.blah file and we can escalate privs because of some found passwords or something other interesting like configs, etc…):

 

Oh yes. J And it was cool when I was reading one-line files. I decide to grab a content of those PHP files I found before. Believe me or not, during time-based SQLinjections… it’s a nightmare, even in ‘your localhost’ ;) Anyway… after a while I had some new infos:

Yes yes, there is a Legolas ;) I decide to grab a login.php file to check maybe there is a config.php.etc…

Oh yes, the last line ;] I decide to check it asap:

Hehe, nice try. ;] Ok. I thought I will not find anything more interesting than that in the code, so I switched to sqlmap again (to grab more data from DB). And that’s how I found Users table. After few more queries I’ve got a usernames and passwords in a clear text. Let’s try the first one: Frodo (the hipster ;])

Nope. So maybe next one:

Excellent! We are in. The obvious now is to get (The Lord of The) Root and uid = 0. ;)

Quick review to check what’s inside our /home/ directory and what’s inside wwwroot:

Ok, what’s there on the / folder? Our little SECRET with some (suid) files. I decide to analyze them a little bit more … J So - first idea was: let’s try to exploit the binary.  

Yeah, ok. We saw that before… But after a while I asked myself: what am I missing?

So, yeah. sigsegv, sigsegv, and “/file’ has changed; re-reading symbols”. Say what? ;] The same thing happened with other 2 bins (door2 and door3). I thought I will need to read LotR again but …

I decided to start it again after a while. This time after I started gdb I decided to log all session to a file. I typed (see door1): 

$ gdb –q ./file

$ break main

$ set logging file /tmp/gdball.log # because if we’ll start a session in current directory, we will not have permissions to continue.

Now start the program with commands from the screen before. Let’s start from:

<gdb> r `perl –e ‘print “A”x180 . “B”x4’`

Ok, so SIGSEGV is possible but I was still wondering why I can not exploit that binary. I decide to check other's solusions and that's how I found an excellent writeup by g0blin - thanks!

g0blin wrote that there is an ASLR (I missed that), so now exploitation should be easier. Rewriting his exploit to smaller one and run as smeagol in for() loop, will result like this:

smeagol@LordOfTheRoot:~$ for i in `seq 1 2100`; do python ap.py; done
Segmentation fault (core dumped)
Segmentation fault (core dumped)
Segmentation fault (core dumped)
(...)

Segmentation fault (core dumped)

# id

And your EUID should be 0. You should be able to find the flag now. ;)

Big thanks goes to: KookSec for preparing such a cool CTF, g0blin thanks for the hint with ASLR (as well as other cool writeups) and for VulnHub for hosting those games. Thank you guys :)

Cheers