Cordian – Page 3 – Offensive IT

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.

Machine: DC-5
Target IP: 10.0.2.12
Attacker IP: 10.0.2.16
Difficulty: Easy
Goal: Get /root/thisistheflag.txt
Link: https://www.vulnhub.com/entry/dc-5,314/
VM-Creator: https://twitter.com/dcau7

As always we start with an Nmap scan to see what ports the target system is offering. As figure 1 shows there is an Nginx web server on port 80 and RPC actively listening for connections. Interesting is, that there is no SSH, which means that we have to gain access over a reverse shell and do not need and try to find any SSH-keys or passwords.

When we take a look at the website we see that it is PHP based without any relevant information.

When we try to find anything that offers some sort of user interaction we only see a site called contact.php.

We try to do some basic injection but it seems like we are not getting any new knowledge. Furthermore we are not able to access our own contact information that we submitted. After submission we are only presented with a page that says “Thank You” but nothing else of interest.

After a very close look we could potentially see that the year provided on the footer for the Copyright information is different for the thankyou.php page than for the rest of the website (for comparison see figures 2 and 4).

When we take a closer look at the source code we see that there is a class called footer-wrapper. We try to access the footer by guessing the filename footer.php and are able to verify that it shows different annual figures for every access.

5. footer.php displays different annual figures on every reload

If the Copyright changes, but source code shows its a static content, it has to be some PHP include magic.
We need to find out how this PHP include works. It has to reference the footer.php file, which is why we need to search for the correct parameter. To do this we use a Fuzzer like Gobuster.

We see that most responses are 851 characters of length. We run the command again and exclude every response with 851 characters and are able to identify the parameter file as shown in figure 7.

And since we are including a file lets try some local file inclusion as shown in figure 8.

8. Identifying LFI over fuzzing — 8. Testing for LFI

We can verify the LFI vulnerability from figure 8 by using the browser as shown below.

Since there is no SSH there is no need to search for an password or SSH key. Another way to gain access to a system when having LFI is by log poisoning. To do so we need to be able to inject a payload into a logfile and then display the logfile via LFI to get the injected code executed.
From the Nmap scan we know that the web server is Nginx. This means that we know that the web server log should be on /var/log/nginx/access.log and error.log.

When we try to include error.log we see the actual content of the log file. So we try to verify if we are able to determine the content of that file by accessing

http://10.0.2.16/thankyou.php?file=henkel-security.com

which gives us no concrete result at first. But when we access

http://10.0.2.16/thankyou.php?file=/var/log/nginx/error.log

we see that our URL got into the error.log file.

So the next step is to inject a string that would be interpreted as a PHP file with command execution into the log file and execute it by displaying the log file via LFI.

Listening on port 445 gives us a reverse connection from the target system back to our machine as user www-data.

The next step is to escalate our privileges. To do so we use a handy tool called LinPEAS. The script shows us a possible privilege escalation by abusing screen version 4.5.0.

We find the exploit by using Searchsploit.

14. Using Searchsploit to get exploit for screen

Simply copying the exploit code to the target system and executing it does not work. As figure 15 shows, the exploit aborts after the first step.

We take a closer look at the exploit code and try to figure out what it is actually doing. The exploit writes two files to the /tmp directory and compiles them later on. We create those to files manually on our Kali-Linux and compile them. Afterwards we copy the created libhax.so and rootshell to the /tmp directory on the target system.

As last step we trigger the exploit by hand and gain root privileges as shown in figure 17.

Author: Cordian

VulnHub – DC-6

VulnHub – DC-5