After successful rooting of HackademicRTB1 which wasn’t very hard at all, here’s the second hackme, provided by GhostInTheLab, which is a bit more difficult as you will see. I’ve spent around 3 hours on solving this hackme, in comparison to HackademicRTB1 which took less than 1 hour to root.
The goal is to read the Key.txt in the root-directory. While working on this hackme I’ve encountered a nice technique called “Port Knocking”, which is very interesting at all. So let’s do not waste time.
Please notice: If you want to solve this by yourself, stop reading here!
After setting up a VM using VMware Workstation and running the downloaded Image, the first thing to do is: information gathering about the target. Nmap will help:
Nmap shows two different open ports on the target: Port 80 running an Apache v2.2.14, and a filtered Port 666 which cannot be accessed at this point. Looks like you have to find a vulnerability within a web-application, instead of simply exploiting some faulty services.
Let’s take a look at the webpage:
Looks ok so far. If you have a closer look at the webpage using a Nikto-scan:
There’s a phpMyAdmin installed and some directories with listing enabled. Let’s have a look at the phpMyAdmin installation and see if this basically could open a door to the entire system using the “phpmyadmin/changelog.php” file, which reveals that the installed version of phpMyAdmin is v184.108.40.206. Searching on Exploit-DB for some exploits:
But that one isn’t usable as you’ll find out by launching against the target. So let’s have a closer look at the entry-page. Start Burp Suite and set up a proxy for your favourite browser to see what’s happening when trying to login:
Let’s try to simply bypass the Login-Form using “admin” as a username and “ ‘ OR 1=1–’” as a password. This seems to work, now we’re transferred to a visually nearly blank, new page:
The page is scrollable and looks a bit too large. So check Burp again, what’s going on here:
There’s quite a long string hidden using the color “black” on a black background. Well…of course nobody would secure his website like this! This string looks a bit weird first, but if you have a closer look, you’ll discover that this seems to be hex-encoded. Convert it to ASCII:
Still looks a bit like a hex. Let’s convert it to ASCII again and et voila:
This is a message, isn’t it ?! By the way: Burp also has got a nice decoder integrated:
Right at this point I spent most of the time on this hackme, because I did not realize what the author wants to tell me :). Even after converting the binaries back to ASCII:
Uuhhm ?!?! I tried to google this sequence of bytes and ascii, I tried to use them as passwords for the phpMyAdmin - Page, I tried a lot of mathematical conversions with these bytes, but entirely I did not found anything which could help me :(
But after some desperate minutes of googling for the word “knock” in combination with “it security” the first result hit my eye: “port knocking”. Sounds like a good way to protect something. And after thinking about the filtered port 666, it clearly came to my mind: maybe the admin has protected something on port 666 using “port knocking”.
Wikipedia says about “Port knocking”:
In computer networking, port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specific port(s). A variant called Single Packet Authorization exists, where only a single “knock” is needed, consisting of an encrypted packet. The primary purpose of port knocking is to prevent an attacker from scanning a system for potentially exploitable services by doing a port scan, because unless the attacker sends the correct knock sequence, the protected ports will appear closed.
The found string “1001:1101:1011:1001” could be the sequence of ports you have to send a SYN to, to open the filtered port 666. Let’s give it a try using netcat:
after this sequence, let’s do a portscan using nmap again:
Great! The port knocking worked like a charm. Port 666 has been opened running another Apache. Browse to it:
Port 666 is running a Joomla installation. Maybe there are some vulnerable modules to get deeper into the system ? Let’s check that using the famous Joomla-vulnerability scanner “Joomscan”:
The results from Joomscan are not usable at all because the admin has configured some defensive mod_rewrite rules, which results in a lot false/positives. The next part is going to be time-consuming if doing this by hand: You have to check every link on the site for a SQL-Injection. Another way is using a web-vulnerability-scanner like “WebSecurity”. All in all there is a vulnerable parameter in the URL:
Using sqlmap you can quickly verify the SQL-Injection vulnerability:
Now you can enumerate the databases, using:
The user running the queries:
Well…this is the biggest mistake a web designer/coder/administrator can make: Running scripts using the root-user. This means we have full control over the whole MySQL-Database, resulting in fetching all MySQL-Users including their passwords:
Or all Joomla-related user tables:
Now you can either crack those password hashes, but this is probably the longest journey to your goal. Another simple way: The sitescript gets executed by the root-user. This means we have full control over the filesystem too! Using sqlmap’s file-read function, you can easily grab the Joomla-Config file which contains the MySQL-User-Credentials in plain text (by the way you can also read the “/root/Key.txt” the same way, but this is for the lazy ones! Instead I would like to have full shell-control!)
In the “configuration.php” file, you can find the MySQL-credentials used for Joomla:
Using the found credentials we can now easily access the hosted phpMyAdmin:
Next step: Uploading a phpshell to get access to a /bin/bash:
Create a tempdb and one table called “form” with one column and insert the following code:
dump this to the filesystem (obviously the www-directory, since we want to execute the shellscript):
create a second table called “upload” with one column and insert:
this small script, used by the upload-form moves the file to the correct directory. Dump it:
and brwose to the upload-form:
Now you can upload heavy shell-scripts like C99 or R57, but our minimalistic php-reverse-shell-script from the HackademicRTB1 solution is quite enough again. Configure a netcat to listen for incoming (reversed) connections:
Upload the php-reverse-shell and launch using your browser and et voila:
Apache is run by the user “www-data” who has not enough system-rights to read contents inside the /root/ directory. So again, we’re using the
Linux Kernel <= 2.6.36-rc8 RDS privilege escalation exploit
The rds_page_copy_user function in net/rds/page.c in the Reliable Datagram Sockets (RDS) protocol implementation in the Linux kernel before 2.6.36 does not properly validate addresses obtained from user space, which allows local users to gain privileges via crafted use of the sendmsg and recvmsg system calls.
to exploit the kernel and get root-privileges:
Download and compile the exploit:
and launch it:
Now we are able to read the contents of the “Key.txt”:
But hold on! That looks weird and not human-readable. At the end of the string you recognize the “=” which indicates that it’s probably base64 encoded. There are different ways of decrypting this, the easiest for now is using burp-suite. Move the file to a webserver directory:
Browse it using burp:
And if you have a look at the decoded values, you’ve probably recognized the “PNG” string which indicates that this is an image file. Save and view it :-):