searchsploit – Offensive IT

October 31, 2020

VulnHub – DC-6

Machine: DC-6
Target IP: 10.1.1.4
Attacker IP: 10.1.1.5
Difficulty: Easy
Goal: Get /root/theflag.txt
Link: https://www.vulnhub.com/entry/dc-6,315/
VM-Creator: https://twitter.com/dcau7

The first thing we do is to follow the advice of the vm creator to edit our hosts file in the following way, as shown in figure 1. To do so we use the command:

sudo vi /etc/hosts

1. Adding the host “wordy” into /etc/hosts

We then use Nmap to find the target system’s open ports.

Since we identified a web service on port 80 we use a browser of our choice to browse the website. As shown in figure 3 we see that the web server is hosting a WordPress site.

The text on the website might be a hint to have a look at the installed plugins. To do so we use a tool call WPScan. Please note, that we might have to provide an API-token, which is free available at https://wpvulndb.com/users/sign_up.

sudo wpscan –url http://wordy/ -e vp –api-token **censored**

As a result we get a big list of 24 identified vulnerabilities, but most of them are XSS and wont give us direct access to the administrative backend or the underlying target system.
When we take a look at the clue that the vm creator provided we see that we should create a smaller subset of a larger password dictionary (rockyou).

cat /usr/share/wordlists/rockyou.txt | grep k01 > passwords.txt

We do so and as a result we get a list of 2668 possible passwords. The next step is to identify possible usernames by using WPScan once more.

sudo wpscan –url http://wordy/ -e u –api-token **censored**

The next step is to use WPScan to perform a dictionary attack with the identified users and our shortened password list.

sudo wpscan –url http://wordy/ -U users.txt -P passwords.txt –api-token **censored**

5. WPScan password attack

Using the username and password combination from figure 5 we are able to login to the administrative backend. There we do not have full administrative privileges, but we have access to a plugin called “Activity monitor” as shown below.

Since we wanted to identify a vulnerable plugin in the first place but haven’t been able to identify one yet, we take a closer look at the new identified plugin. We try to find any version information about the plugin and are able to find something in the source code of the plugin page as shown in figure 7.

Doing a quick search for exploits we are able to find an exploit for the exact same version of the plugin. This just has to be the match we were looking for.

We take a close look at the proof-of-concept (poc) code and edit it to create a reverse connection to our attacking system.

Since the code is going to be triggered via CSRF we need to host the HTML file on our own and trigger it manually, while being logged into the target WordPress backend. To host the HTML code we use a simple Python HTTP server as shown in figure 10.

When we access the HTML file on our HTTP server we are presented with a submit button which executes the poc code.

11. Button to execute code via CSRF while being logged into the WordPress backend

Before executing the code by clicking the Submit request button we start a Netcat listener on port 443 on our attacking machine to handle the incoming connection.

12. Incoming connection from target system after RCE over CSRF

Once we are on the machine we search the home directory of the local users. Inside the directory /home/mark we find a file called things-to-do.txt which contains credentials for another user called Graham.

We use these credentials to connect to the system as user Graham via SSH. Once we are on the target system as user Graham, we check our sudo privileges and find an interesting script called backups.sh.

14. Finding an writeable, sudo executable script

Checking our own privileges shows, that we have permission to edit the script as shown in figure 14. After editing the script and executing it as user Jens we are able to escalate our privileges as shown in figure 15.

Furthermore figure 15 shows, that user Jens is able to execute Nmap with root privileges without a password. A quick look at GTFO bins shows us, how to exploit this misconfiguration. Important to know is, which version of Nmap is going to be targeted, since there was an interactive mode that could be used up to version 5.21. Once we created a Nmap script that opens a shell we execute it as user root to escalate our privileges once more and are able to access the flag.

February 15, 2020

VulnHub – DC-3

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.