code16: OwlNest

During last few days I tried to solve another CTF from VulnHub. This time I decided to try OwlNest prepared by Swappage . Below you will find few notes about the game. Let's play...

When your machine is ready, let's try to scan it. Below you will find few results:

Ok, nice. We can see few TCP port. Let's start from the HTTP port - 80/tcp:

When I was investigating the page with Burp I saw that there is an interesting message in one of the responses. See below:

I assumed that it will be a good indicator that there is something wrong... Next thing I decided to do was creating my own user in the application:

In the registration form you will see that the username/login field is only able to hold 16-characters. It reminds me the bug from Wordpress (described by Sucuri) when after posting 'long' comment you will add XSS...

Let's check what will happen when we will set login-name longer then that (note that I used %20 as a space-character and then 17th character will do the job):

Checking if we can register as an 'admin':

Too bad. Checking if we can register as 'admin %0a' (to do that, grab a request in Burp and change it like below ;))

Response:

This is not what I was looking for... but let's try to log in:

Ok, checking:

Great, now we have an access to the upload form:

Checking if we can upload the file:

I spent some time with Burp and this form to try if there is 'any kind of bug'... after a while I found that we can upload a PHP file (time for the backdoor.php?):

It should be probably game-over now, but I saw some 'other' message from the author:

:]

Let's try harder.

What's this...?

Orly? ;] Verifying:

So now it should be easier to read (our uploaded) file(s). Let's check some more...

...so I'm doing something wrong... again:

Next, I decided that it will be easier to grab the file directly to my Kali-box. To do that I copied the PHPSESSID (from DataTamper) and use it like below:

So now we've got:

Response in the file below:

Let's de-base64 the response (file) now:

Looks interesting. Let's go deeper... Checking the binary:

(During the gdb session we can see some nice call's, for example:

)

Let's run the binary:

:Z

Ok, again. Let's analyze that webapp, checking results from dirb:

This looks pretty ready to be our new input for php://filter ;]

Checking:

...just in case... ;)

Unfortunately this was not the way. Owl is still watching me ;S

I decided to get back to the binary again. I found something (I remember from the long past when I was learning C for the first time ;> ) - CGI:

Few minutes with Google, and you should be here (but the link is dead afaik, so try to google it or grab a copy from archive.org):

After you'll read it... ;]

...and after you will 'read' the validateEmail function...

...you should already know that...

...so... ;]

After reading some files from webroot, we can assume how the apps is working. Check this out:

(of course the screen with the source is already de-base64'd but I believe you will get to that point at home ;])

(we will need it to prepare the request to ('run') our upload-CGI binary) how ? should be also easy to google:

(First I though that this is the binary responsible for the 31337/tcp port... that's why the name is elite.bin - but it was not ;])

Again...

I created the directory in /var/www to 'prepare' environment similar to the one available on the target-machine:

So now, we need to get a proper request to the app (on original remote target). Let's do that (using Burp):

Response looks good:

Checking /images/:

Our testfile is there so, it's good. (In the middle of fuzzing-with-Burp... ;]

) Interesting. ;] Let's try to do the similar 'request' from the Kali-console:

Oh, cool. ;]

What's next?

Ok, nice. Let's check that binary more carefully...

Yep ;]

...but the real shellcode I used was grabbed from this >tutorial< ;]

Calling pizza...

So now we need to get the offset lenght:

...and fix our payload to check if the result will be similar to the one we want to achieve:

Preparing new shellcode with Metasploit...

Checking

Illegal instruction - so good (let's say;)) , but I missed something ;] recheck...

Nope.

After a while I decided to take a break and start the VM again from the beginning.

The reason I wasn't able to exploit that program was probably wrong shellcode or some error in the whole payload. This time I tried to achieve 'the same' results using gdb-peda:

According to the previous research, we should be here:

To get the proper names of fields I used Burp proxy (I'm logged-in as the new 'admin+11chars' user):

As you can see, program crashed at 0x42424242. Now we will open the program in gdb (with gdb-peda) using -c to add generated core file:

When the program is ready in gdb, first I created breakpoint to the main() function. Then I used 'r' to run the program:

gdb will break, so I used gdb-peda to find JMP ESP instruction and to generate a reverse-shellcode to my Kali Linux (.1.183):

(First I used 'call esp' but It wasn't good idea :]) To prepare a new query I used query2.txt file and notepad.exe to copy/paste some notes/addresses, see below:

Since my 'call esp' did not worked as I believed it will be, I decided to use 'jmp esp' (to do 'jmp to esp' ;] ...yeah I know.) - anyway:

Checking:

Great! It's working (but still on Kali machine!), now we need to check if the same payload can be used to attach OwlVM:

Ok, looks stable. Checking:

'Unable to open file' :|

There was only 1 reason I wasn't able to reach the shell - wrong values of parameters. :]

So after I fixed filenames - this is what I found: