The objective is the same as the previous one, get root and read key.txt
Recon
Again, this will be a web hacking mission, only web server is available.
There was nothing in the source code, no suspicious headers, no sql injection in the login. I ran OpenVAS, Dirbuster and Nikto on the target, but nothing more was uncovered other than a Phpmyadmin interface, which kept giving me “unable to connect to MySQL server” errors no matter what I did. I assumed that maybe the web server is a false front and that might be something else hidden on the machine, so I ran a UDP scan next, which revealed an additional port:
123
nmap -sU -F -n -T4 192.168.80.166
PORT STATE SERVICE REASON
5353/udp open zeroconf udp-response ttl 255
Further internet research and a version scan implied that this was the Multicast DNS protocol. I couldn’t find anything to exploit it, though. But it made me want to take a closer look at Nmap’s results again, so I ran another scan:
123456789
nmap -p- 192.168.80.166
Starting Nmap 6.49BETA5 ( https://nmap.org ) at 2016-07-21 08:14 EDT
Nmap scan report for 192.168.80.166
Host is up, received arp-response (0.00024s latency).
Not shown: 65533 closed ports, 1 filtered port
Reason: 65533 resets and 1 port-unreach
PORT STATE SERVICE REASON
80/tcp open http syn-ack ttl 64
This time I read it more carefully and I noticed it reported a filtered port. I ran Nmap again with the verbose flags and —packet-trace option and this time it returned a new port:
123
PORT STATE SERVICE REASON
80/tcp open http syn-ack ttl 64
666/tcp open doom syn-ack ttl 64
This must have been the previously reported as filtered port. Version scanning revealed that this was actually another web server!
1
666/tcp open http syn-ack ttl 64 Apache httpd 2.2.14 ((Ubuntu))
Before continuing, I am taking a detour here because it seems I had bypassed a secion of the challenge. When I came back to resume working on this VM, I couldn’t get the 666 port to open, and I had no idea what triggered it. I looked at g0tmi1lk’s video and it turns out there is a SQLi string that you can insert into the password field of the first web server that gives you a different response. The string is ‘ or 1=1—’. I previously tested this parameter with sqlmap and also inserting another variation of this string, with no satisfactory answer. I assumed maybe it’s hardcoded, because the slightest change, as in putting a space after the comment character invalidates it. Anyway, with this injection attempt you are taken to a page that says “Ok, nice shot……but, you are looking in a wrong place bro! ;–)”. In the source, there was a URL encoded string:
Alright, this is a reference to port knocking. I further decoded the binary data to ascii by using this site and got the string 1001:1101:1011:1001. So I assumed this string will need to be given to the host in order to open up the port.
12345
#!/bin/bash
for i in 1001 1101 1011 1001
do
nc 192.168.80.167 80 $i
done
Indeed, now the 666 port was opened. Not sure how I previously got to it without going through the sequence
Ok, back to hacking! First thing I noticed was a really old Joomla version, so I fired up joomscan and among the 4 vulnerabilities found, I show here one that seemed more interesting:
12345
Info -> CorePlugin: TinyMCE TinyBrowser addon multiple vulnerabilities
Versions effected: Joomla! 1.5.12
Check: /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/
Exploit: While Joomla! team announced only File Upload vulnerability, in fact there are many. See: http://www.milw0rm.com/exploits/9296
Vulnerable? Yes
Ok, let’s keep this in mind and continue looking. I ran Nikto against this new web server and it reported entries in robots.txt!
I visited those directories but there was nothing interesting. The administrator one contained a message stating that I am not the real administrator. So I went back to testing for SQLi in the login page and in the URL parameters. In particular, I was interested by the Itemid parameter. When I tampered with it, I got messages that I need to login to view that area of the site. I used sqlmap but no vulnerability found. Seeing so many parameters in the URL, I decided to test each one of them by visiting every page and trying a single quote in every parameter. And the jackpot was found at the letter parameter in the List contents page:
12345
http://192.168.80.166:666/index.php?option=com_abc&view=abc&letter=%27&Itemid=3
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%' GROUP BY title ORDER BY title' at line 1 SQL=SELECT id, title FROM jos_content WHERE state = 1 AND UPPER(title) LIKE ''%' GROUP BY title ORDER BY title
'
With this information, I pointed sqlmap to the vulnerable parameter and retrieved the jos_users table of the joomla database, where among others, there were usernames and password hashes
Well, these hashes won’t help much, as a quick search didn’t give me any way to crack them fast and easy. I did research a bit on the internet and found out that these are salted hashes, stored in the format md5 hash:salt. I also found there is a Perl script that can help with cracking such hashes, called joomlacrack.pl. But I thought I might not need to crack them if I could use sqlmap to execute commands on the server and write a PHP backdoor there. So that’s what I tried next. Passing pwd to —os-cmd gave me the location of the current directory, which is /var/www. I tried writing a shell directly in this location but I failed. So next I listed the contents of the present directory and noticed a configuration.php file that I read, and inside there were credentials for the database:
1234567
/* Database Settings */
var $dbtype = 'mysql';
var $host = 'localhost';
var $user = 'root';
var $password = 'yUtJklM97W';
var $db = 'joomla';
var $dbprefix = 'jos_';
I went to the phpmyadmin interface and logged in as root. Then I was able to use SQL to create a rudimentary shell:
After uploading this shell, I used to download the reverse PHP shell that I hosted with Python’s SimpleHTTPServer. And then I navigated to it and received the connection on my Netcat listener:
12345
Linux HackademicRTB2 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
15:14:37 up 4:02, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: can't access tty; job control turned off
The local exploit that worked was the same one I used in the previous Hackademic challenge, the RDS Protocol Local Privilege Escalation exploit. Again, I used wget to download it from my machine and ran it:
1234567
[snipped]
[*] Restoring function pointer...
id
uid=0(root) gid=0(root)
ls /root/
Desktop
Key.txt
Trying to read the key gave a huge base64 encoded string, so I copied it to the web server directory, gave it permissions for everyone, and then I downloaded it on my machine, where I could decode it:
So it’s an image! (when I tried reading it there was binary garbage, so I assumed it must be another type of file than a text one). I used this base64 to image converter to see the image:
Debriefing
This host implemented a sneaky defense of port knocking in order to serve the second web server. It was a bit unrealistic to require a hardcoded value for the password parameter on the first web server in my opinion. The second server was vulnerable to real SQL injection that could read files on the system and execute commands. Having the database root credentials readily available allowed me to gain a foothold on the machine, from which the only step left was finding an exploit that would give me root.
12345678
/ You are only young once, but you can \
\ stay immature indefinitely. /
--------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||