Kvasir CTF - Writeup

Man. I played few CTFs in my life. But this one, to be honest, was one of the best I’ve ever tried…;) Have fun.

Let’s start from the beginning. I’ve already mentioned about this CTF in one of my posts few months(yep;)) ago… I was able to sit down to the game again, and check this CTF from the ‘new perspective’ (let’s say… ;)). Few results(/ideas/notes/you-name-it) you will find below.

Environment

Get your fresh copy of Kvasir CTF and remember to send some thanks/feedback/beers;) to the author. Prepare your environment ‘as you with’: VirtualBox/Vmware – your choice. Whatever will work for you.

P.S. – “attackers box” of course. So in my case it was Kali2.0 (installed on VirtualBox) with some updates (related to “few exercises with OpenVAS” from small ‘write-up’ posted last time). Anyway, your (default) installation of Kali 2.0 should work as well.

Let’s get to work

For this CTF, my IP was set to 192.168.56.66. I used netdiscover –r 192.168.56.0 to find out if there are any other hosts than mine (“dhcp’ed”) in the same “LAN”:

So far so good, we’ve found 2 new IP’s: .101 and .100.

First of all I found that on .101-IP we will have HTTP (at port 80):

I was wondering, maybe panel will be vulnerable for SQL injection. To check it, I grabbed the login-request (like below). I modified original request to send not-printable characters (maybe there will be a bug in some kind of parser I thought…):

Sample error response:

So, seems to be vulnerable:

...after a while… I decided that I will not be able to inject “my code” this way here. I decided to switch to another form in the page, which was ‘register’ form:

Performing similar steps like before (Burp+some strings for Intruder) but this time for register.php I found that the idea of the form (prepared to send to DB?) was something like:

Why:

Ok… So I was wondering maybe this or maybe that, trying different possibilities…

The key was the ‘schema’ of injection done like this:

Let’s try it out:

Of course, we’re in. Next page we’ll see is an admin.php page. Check it out:

What you can assume here? ;) You can assume, that you already have a PHPSESSID value. ;D So:

(Hint: yes, target IP has changed. This is because during the CTF I was restarting and resetting the whole VM again and again couple of times… You’ll get use to it. ;))

And why the poc like this, because of the RCE bug inside the form:

As you can see, you can automate it a little bit:

 

 

Let’s do some basic overview of the system and files:

Nice, so we can see that there is a remote code exec bug in the source, as well as some other vulnerabilities. Studying the code, we will find the login and password for another host, which will be 192.168.2.200 – “DataBase” server this time. J Let’s do it, back to the source:

As you can probably assume now I was wondering if I will be able to run some kind of reverse-shell here. My first choice was PentestMonkey reverse-shell:

Some basic configurations…

…and we’re in:

First of all I tried to root this box but unfortunately I wasn’t able to do it (“in a few minutes”)…

…so I decide to stop, and just look around to see, maybe I’ll find something else also interesting. I rewrited reverse-shell a little bit, so now I was able to type commands in a ‘more interactive way’. I wasn’t able to use nmap (not installed AFAIK), so I decide to use netcat to perform a simple port scanning for found hosts (“reachable” from WWW-target-host):

Ok, let’s check our new credentials:

Looks like we have an access to the DB (server). Great. ;)

Let’s pause here for a moment. Quick “do-it-for-your-self”: check few things in available (remote) DB. Check permissions, grants, default files locations, etc. You will see that the DB:

• allows to create tabes
• (so) allows to read files (anyway <- it is blocked via load_file() afaik)
• write to files
• write to DB files (“this is our guy”)
• use hex()/unhex() <link:2:both>

After comparing and mixing all of the above, you’ll get…

How I meet your raptor2 in 2017

 

First of all:

It was easy to get the password. Google it or crack it with rockyou.txt<link>.

Working?

Good. Now.

Summary: you have a root@DB. You have a “raptor” file (“almost” prepared ;)). Ok. Check this out:

Everything looks alright here but this is not true. ;] It took me a while to figure it out. See the results from file raptor.so command? Look at it, it is data…

… which from our (udf attack’s) perspective is useless. ;] What we will need to do is to find a SO-file (of raptor; probably you can find it located by default on Kali 2 or in sqlmap-repos), and check if the file will be a real ELF or simple data (in case if data – raptor will not work).

(…) not working (again? ;D) Try again. ;]

... and again:

Still want this? ;]

Don’t worry. “ELF is in incorrect format” or something like that when you will try to use it… ;) Again…!

How I finally solved it - by preparing SQL_file with a hex-string.

Hex-string is your raptor.so/ELF-file converted by xxd<link>. Now you need to create one-line-string from the output from xxd. Now the output, should be prepared on your Kali (in /var/www/) like this:

mysql -h 192.168.2.200 -u root -pcoolwater -e "select  unhex('7f45(...)0000000000000') into dumpfile '/usr/lib/mysql/plugin/lib_mysqludf_sys.so';"

Check yours (and mine) first-hex-values for unhex<link:mysql> function. Should be the same to work I think...

Now. You still have an access to www-data@web server. Let’s use GET<link> again to grab sql-file with prepared hex-raptor-bash-file. Detailed commands you will find below:

Looks better? ;) To automate it a little bit more, I created a small wrapper to all of those messy commands:

(I moved py.py to py to save some time.) Let’s check it out now:

Looks promising:

More:

More:

Hehe. Ok. Let’s try something else. Little info-gathering:

Next. 

Next:

Ok, so 2 new IPs: 192.168.3.40 and 192.168.3.50.

Jump around

At this stage I decided that I need to sit back again with Kali-shell and prepare some other “reverse-shell” than that one used before (with netcat and revshell). 

I decide to work with Metasploit. I found few cool tricks on this page...;> and I decided to use it for my case:

  

handler prepared, so let’s create our payload:

 Running it:

Unfortunately (with meterpreter prepared for php) I couldn’t setup a working session. I decided to switch to other payload:

And this is what we’re looking for – working session:

Now I was able to connect to the system again (via msf), check it out:

Looks like this is not a bash, but kind of a python-shell. Good. ;]

Let’s find some basic info, maybe box is vulnerable to some known root-sploit:

Ok, we will get back to it later (maybe;P).

In the middle of time I was wondering if I will be able to grab some ‘www source’ from this server, to try it out with my new script (mentioned also here<link:testlink>). We’ll see, maybe one time. Anyway, I grabbed the source:

After that, I was able to download and read the source (later):

Ok, let’s try it as a little break;)

Yes, I know. “Extremely advance” technique… anyway. ;) Let’s go back to our meterpreter session.

I was finally able to re-run meterpreter when using it with python payload (generated by msfvenom):

Here we go again, to add route:

Let’s get to work:

Little port-forwarding, and you are able to log in directly to MySQL located at 192.168.2.200:

Now. Remember me? ;]

I was curious how can I access some ssh account(s). Because I was able to access DB-server ‘as root’, I decided to read /etc/ssh/sshd_config to see how SSH server is configured. This is what I found:

Now:

Ok, let’s read it:

(Looks like the one I added yesterday ;D But I tried it so many times, that maybe I’m missing something. Nevermind ;))

I decided to erase the whole content of DB-root’s authorized_keys, regenerate my own (on Kali) and put it again to original root’s (keys) file:

Here we go again:

Just to verify that everything is ok and root’s file is updated:

Looks good. Next, we will try to log from our box (Kali) to DB-server (192.168.2.200).

(After some time… ;]) I was not able to log in via ssh. I even found some writeup’s on VulnHub describing how it can be achieved but it did not worked for me.

After few hours ;) I figured out another way. This one worked for me, maybe you will find it useful too:

So now we have 2 sessions in MSF: first one with meterpreter and second one with ‘normal shell’. Because I wasn’t able to connect via SSH, I decided to use raptorto create a “netcat-backdoor” on DB-server:

Now, we will run back.sh (via raptor) and from our (Kali) ‘normal shell’ (2^nd session in Metasploit) we will connect to DB-box on port 9999:

(By the way: later on that day I was reading this small article, to check my notes for what else can be done or what I can not “see” – this is how I found that probably to access SSH I will need keys from backup ;) But I will check it maybe later, just to verify…;)) 

So, we are root on DB. We can now go back to those 2 found new machines.

Let’s import pty from python to run /bin/bash:

Cool. Looking for some configs and files inside the box:

Let’s see connections:

Hm. Some FTP and some connections between ‘my host’ (DB) and 192.168.3.40. In the middle of looking what’s inside the server, I started sniffing packets:

Wait, what?

 

Checking…

Looks like an alive user, cool:

“We’ve got it” ;]

Ok. After I sniffed the password I decided to try to log in on remote host (unfortunately because during tcpdump session I typed ctr+c, my session was lost and I needed to reconnect it again…so here we go again… ;)):

And we are here:

Let’s “beautify” it (with python’s pty module):

Let’s check those hosts

 Ok.

Status for 192.168.3.40: 22/tcp available. Status for 192.168.3.50: 22/tcp and 4444/tcp (my metasploit/nc? ;)) – available too. Let’s check it. First of all find credentials in your pcap file, we will use them: celes:im22BF4HXn01.

Trying...

;]

What’s next? Searching for some interesting files/info again…

Next:

Ok, who knows stepic? ;) Me too, so…

Let’s find out what’s going on with those files. 

(hehe, this one is nice ;)

Ok, stepic.)

…but before that, let’s check what’s on 4444/tcp on 192.168.3.50:

(We need to get back to .words.txt file I think…Later.) Checking getLogs.py script we will find another box – 192.168.3.200 – with some ‘ftp account’. Let’s check it too:

Ok, let’s scan it (with nc):

Let’s try to connect to the same credentials (to SSH) as we tried to FTP – (spoiler: not working;)). Ok, so we can now go back to our celes-directory, to check next file, this time kvasir.png.

When I finally downloaded this PNG, I saw an UFO… ;)

Ok, so let’s check that stepic tool:

Ok. Downloading stepic to my Kali-box, and learning –help to proceed with decoding… Also you will see that to decode found string, I used Decoder tab available in BurpSuite:

So it looks like we have a PNG in PNG. Verifying…

Ok, let’s open it:

Uh. Barcode? QR-code? Ok. Few minutes with Google and I found what should be done next:

Now it looks like a password in my opinion, but we will check it later(todo:note it as usual;)). For now we know that inside the new photo file we’ll found string: Nk9yY31hva8q.

Next. It’s time to solve some puzzles… Our next target will be that 4444/tcp port on terra-box (which I broke with ctrl+c last time ;\ ). To solve this, we need to play a little bit with file located at DB-srv - .words.txt in (you will find it in /root directory):

To understand what should be done here, I created “my own small script” on Kali and I started it with .words.txt file as an input. After a while I assumed, that real job to do here is to get words from .words.txt file, sort them and solve the anagram. And yeah, ‘your try’ should be sent to 192.168.3.50 to port 4444 of course. ;) So?

Let’s get to work (Ok I lied here a little bit ;P to real solve this case I visited 3 links: google with ‘anagrams’, and stackOverflow). Now after mixing all of those 3, I was able to prepare my super-cool-script.py and solve the challenge ;)

(By the way, here you will find cool page. You can use it to compare ‘your’ results (or from your script) with those, working for solve-me on port 4444. For example:

You can also find some ‘online anagram solver’ – your choice ;)

Ok. Let’s go – some ‘manual testing’):

Hahahaha ;D Again Neo! ;)

After I understood the whole idea of this case (and python code found on StackOverflow), similar skeleton(s) you can of course find at VulnHub, on section with writeup’s for Kvasir.

Final results below:

Running again against 192.168.3.50:

(Last time I closed session again, so after I was reconnected again, this time I sent python’s output to log file to check it later.)

First idea – base64, so checking:

Cool. I hope it will help me now to go a little bit deeper. Maybe last found password will be helpful here. Let’s check it:

As you can see on the screen above – remember to set proper perms for your new-key-file. Then you’ll be able to connect to dev2-server as terra. Searching for interesting files/info:

Two ifaces, so here we go again ;] Checking new host for open ports:

Looks like this is our python-server:

After a while on looking for some interesting files/configs I found some hints in /mail directory:

Can you see it? ;]

Better now? Yep, we have another box. ;] Ok, scanning both:

Better now? Yep, we have another box. ;] Ok, scanning both:

But locke said something about port-knocking. I remember that it was used during some other CTF I played while ago, so I decided to check if it will help me to figure out what should be done. First of all, rescan:

And surprisingly(?) we can some new ports open. Checking again with some ideas from other CTF’s:

Now we can see new port – 1111/tcp. Checking:

It’s echo-server or am I missing something?

(Restart and) … reconnect again… ;] And now we have some better results:

Good.

So what do we have here:

LittleShell found here:

Looking for the /home directory, 2 users found (kefka and locke), checking locke’s $HOME:

It looks like we need to get that disk image and look what’s inside… Now we’re here:

I decided that maybe it will be easier to use portfwd to forward DB’s port (7676 with netcat) to my local-kali:

Next, as you will see below, I decided to download the image (probably) in a hard-way (“probably”, because I think that there is a lot easier way to do it), anyway… ;)

So diskimage.tar.gz is now on dev2-box. We need to get it to our Kali. Now we are here:

Almost finished…

 

Yep, definitely the hard-way ;D

Got it:

After a while with google, I mounted the file to check what’s inside:

Another stage seems to be to crack somehow this password… I “opened” this file (image) also in other tools (like hexdump for example), below some findings to think about it:

What should we try here? g0tm1lk<link>? ;] Or funky.wav? Let’s try to extract it:

Could it be another file on that disk? Let’s verify it. While we’re mounting the disk, we can see only Secret.rar file. Now we will try to recover funky WAV-file. Few seconds with Google and we’re here:

Let’s try it. Next thing: man dd, because you want to ‘read’ only some part of the disk. We will not convert the whole image file. In manual you will find sections describing: skip, count and bs. After counting the proper “offset”, you will be able to extract the wav-file. (You can also find and use tool called foremost

…described on knapsy’s blog.) During playing (with) the file I found that page contains:

(As I did not have any good results with DeepSound and Audacity, I decided to check SonicVisualizer), so:

Now, open your WAV file, see the spectrogram?

Looks like we’ve got another password: OrcWQi5VhfCo. Cool. Checking if it will work for Secret.rar:

Content of MyPassword.txt looks like this:

So, it should be a password for kefka at 192.168.4.100, checking (5224XbG5ki2C):

Good ;] Looking around…

After a while, we’re in /opt directory, looking for 2 files:

Ok, let’s run it:

Looking for open ports again:

Good, we have a new port opened. Let’s check it:

Ok, checking (small) ‘v’:

Ups… ;] Again.

OK, now we can proceed:

Ok, for each time we will receive another ‘key’:’value’ pair. What’s that pair… I tried at Wiki (with some lengths of encrypted string), and this is what I found:

Checking…

By the way, you can also check here and here. After reading about the possible way of exploiting that case, I found greatdescription of how we should learn (about the bug) here, and how to exploit it. Using the script prepared by leonizja we will be able to crack the cipher.

Let’s now use new grabbed “password” to access hidden shell. We will be able to create our door to root shell:

New connect via nc from DB-server and we’re here:

Running mishell (but the trick with importing pty to terminal is not working here, so we need to stay with first shell ;)):

Let’s go back:

;] Nice, but I don’t know that language…

Googling for a first word in flag-message…

Ok, so let’s try rot13:

Seems like this is the last flag and the game is “over” right now. ;]

(In my opinion we can always try to root the rest of the IP’s we’ve found during the game, anyway I will leave it for you as an exercise ;) If you want to talk about it or need any help, feel free to mail me.)

Big thanks for the author for preparing such amazing game. This CTF was one of the best I’ve ever played. You will learn & practice a lot here.

More CTF’s you will find here.

Cheers!

P.S.
For all of you who want that root on those Debian's7:

;]