injection – Offensive IT

Machine: DC-3
Target IP: 10.0.2.11
Attacker IP: 10.0.2.15
Difficulty: Easy
Goal: Get /root/the-flag.txt
Link: https://www.vulnhub.com/entry/dc-3,312/
VM-Creator: https://twitter.com/dcau7

For initial reconnaissance we use Nmap to scan the system for open ports. Interestingly, even when we use the option -p- to scan all 65535 ports (TCP) Nmap identifies only one open port as shown in figure 1.

When browsing the root webpage on port 80 we are presented with some information about the boot2root challenge but nothing too interesting. To gather more information about the HTTP service we use the tool Gobuster to search for further directories as shown in figure 2.

2. Using Gobuster to search for hidden directories

When browsing the /administrator directory we find a login page for the CMS backend Joomla!.

3. Joomla! at http://10.0.2.11/administrator

To identify the version of Joomla! we can use a tool called Joomscan as shown in figure 4.

4. Joomscan to identify Joomla! version.

After identifying version 3.7.0 we use Searchsploit to look for any known exploits or vulnerabilities for the specific version. As figure 5 shows we are in luck and there is an SQL-injection vulnerability for Joomla! Version 3.7.0.

5. Using Searchsploit to search for available exploits

With the command “searchsploit -x exploits/php/webapps/42033.txt” we can take a closer look at the exploit and see that there is already a prepared Sqlmap call as proof of concept.

6. Joomla! SQL-Injection exploit description

When we run the Sqlmap statement and replace the target address we can verify that the SQL-injection is working and pull the names from the existing databases from the target as shown in figure 7.

Afterwards we dump the Joomla! Database with the following command and receive the username and hash for the administrator of the backend.

Sqlmap -u “http://10.0.2.11/index.php?option=com_fields&view=fields&layout=modal&list[fullordering]=updatexml” –risk=3 –level=5 –random-agent –dump -D joomladb -p list[fullordering]

8. Sqlmap dumps user table from joomladb

To crack the hash with a dictionary attack we need to know what hashing algorithm to use. To identify the algorithm, we can use a tool called Hashid as shown in figure 9.

9. Using Hashid to identify hashing algorithm

The next step is to use Hashcat to perform the dictionary attack. But before we can do that, we use the Hashcat help function to search for the corresponding algorithm to know which parameters to use.

10. Searching for correct Hashcat mode

With the following command we are able to execute a dictionary attack and crack the hash to receive the cleartext password as shown in figure 11.

hashcat -a 0 -m 3200 hash.hash /usr/share/wordlists/rockyou.txt –force

With the username “admin” and the password “snoopy” we have administrative access to the Joomla! backend. We can use this to edit an existing template to place a PHP reverse shell (LINK).

12. Replacing PHP-Template code with reverse shell

After placing the reverse shell code we start a Netcat listener on port 443 for handling an incoming connection. To execute the PHP code we browse the webpage of the modified template at:

http://10.0.2.11/templates/protostar/error.php

As figure 13 shows this allows us to receive a reverse connection to the target system.

From there on we need to escalate our privileges on the target system. After checking some initial stuff like home directories for interesting information and cron jobs we download and execute Linpease (LINK) on the target machine.
Linpease reveals an old kernel exploit and marks it as 99% change for privilege escalation as shown in figure 14.

Next up we use Searchsploit to check the kernel version 4.4.0-21-generic and we find one that is 32-bit system compatible (Linux Kernel 4.4.x (Ubuntu 16.04) – ‘double-fdput()’ bpf(BPF_PROG_LOAD) Privilege Escalation).

15. Using Searchsploit to find kernel exploit

When checking the description for the kernel exploit with the following command we find a download mirror on Github.

searchsploit -x exploits/linux_x86-64/local/39772.txt

We download it to our attacking machine and host the needed files with an Python simple web server. Afterwards we download the exploit to the target system as shown in figure 16.

16. Downloading Exploit to target machine

We check the compile.sh script from the exploit and check if GCC is installed on the target to compile the exploit. Indeed GCC is installed on the target so we compile the exploit and run it afterwards to gain root privileges.

As usual we start with a Nmap scan to find open ports on the target system. As we can see in figure 1 we only detect port 22 for SSH and 80 for HTTP with a quick scan.

When we visit the website it says something about DOS-Protection by IP banning as shown in figure 2.

Since we do not want to get our IP banned at the first few minutes by starting any enumeration scan we take it slow. A nice way to gather some useful information is by searching for a sitemap or robots.txt.

The robots.txt contains a new directory called /writeup. By browsing the directory we see multiple blog entries, all writeups on Hack the Box challenges as shown in figure 4.

On the /writeup directory we see just 4 interactive links which lead to writeups on different hack the box machines. There is nothing interactive beside one parameter inside the URL which is ?page. We quickly try some local file inclusions and other things but nothing seems to work. By taking a look on the source code of the page we see a hint that the open source content management system CMS Made Simple is being used as shown in figure 5.

5. Checking source code to gather information about CMS

Searching on Google for “CMS Made Simple exploit” we find a blog entry on packetstormsecurity.com about a SQL injection vulnerability. We copy the exploit and run it and are able to pull the hashed password and username off the system as shown in figure 6.

python cmsSQLi.py -u http://10.10.10.138/writeup

The script offers to decrypt the hashed and slated password. But since running decryption on a single kernel inside a VM is not that efficient
we switch to a proper machine and use Hashcat. When we take a look inside the source code of the SQL-injection exploit script to see how the hashing algorithm works.

Inside the script we find a function for cracking the salted hashes by calculating a MD5 sum for the salt and password strings.
When we take a quick look on the example hashes for Hashcat and search for MD5 we see that the exact same mode is already implemented as hash-mode 20.

So we start Hashcat with the salted password and the rockyou.txt dictionary and get the password as shown in figure 8.

One important thing to know is that even if the hashed password is being hashed by the format salt:password we have to store the hash and salt in the format hash:salt for Hashcat being able to process the data.
Now we can use SSH to connect to the system and are able to access the user flag.

The next goal is to escalate our privileges. But since kernel is up to date, no cronjobs seem to be misconfigured or any other easy to guess things seem to be leaking information we enumerate further and find a note on /etc that informs us about a known security issue where users have more permission on files and directories as the should have.

So we check what privileges we have and search for all writeable directories to see if anything is unusual. We see that we are a member of the group staff which allows us to write inside /usr/local/bin which is part of the PATH variable.

11. Group membership and writeable directory

12. Directory /bin is affected by security flaw

One way on how to exploit this misconfiguration is by executing a PATH injection attack by finding any process that calls a file from a relative path and by replacing the intended file with a malicious file with the same name and put it inside a directory which is part of the PATH environment.
But to find such a process that uses a file with a relative path can be tricky.
One way of doing so us by using PSPY to monitor all processes executed by root.
Using PSPY we see that every time the SSHD process handles a new established connection a process calls for a file called 10-uname.
When we take a look inside that file we see that it is a bash script running uname -rnsom as shown in figure 13.

When we login to the system via SSH as we did earlier on figure 9, we can see that the output of that command gets printed as the message of the day / welcome message for the SSH connection.
Since we are able to override everything inside the /usr/local/bin we could potentially replace the uname binary with a malicious one which would get executed every time a successful connection via SSH gets established.
So we create a simple bash script that prints the root flag and call it uname.

14. Malicious uname file

Afterwards we place the file inside the /usr/local/bin directory. Afterwards we try to login to the system via SSH and as figure 15 shows the script gets executed and we obtained the root flag.

15. Root flag gets used as message of the day

So instead of only printing the root flag we could also replace the uname binary with a reverse TCP shell to get root access to the system as shown in figure 16.

Tag: injection

VulnHub – DC-3

Hack The Box – Writeup