VulnHub – DC-5

 

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.

1. Nmap output

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

2. Website on port 80

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

3. Contact form on website

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.

4. Thankyou.php

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.

6. Fuzzing for the correct parameter

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.

7. Ignoring false positive results

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.

9. Verifying LFI in browser

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.

10. Testing for possible log injection

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.

11. Injecting PHP code

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

12. Incoming connection

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.

13. Output of LinPEAS

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.

15. Execution of the exploit aborts.

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.

16. Content of exploit code

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

17. Triggering execution of exploit and getting root privileges