In the last article, we rooted a VulnHub machine – DC-2. I wanted to write about DC-3 next, but for some weird reason its NIC was not coming up. So, I’m skipping DC-3 and moving on to the next machine in the series – DC-4. The machine is available here.
Note: The methodologies and tools that you learn from pentesting have real world applications. Do not attempt to try and hack into machines you’re not authorized to. I will not be held responsible for your actions.
Finding the IP Address of DC-4
After powering up the machine in Workstation, the first step is to determine its IP address. We’ll need the IP address for all communications with DC-4. My personal choice is netdiscover.
The IP address of DC-4 turned out to be 192.168.248.142. Let’s modify our /etc/hosts file on Kali to reflect this.
Deep Nmap Scan
Now that we know the IP address of DC-4, we’ll scan it more deeply to get more information out of it. I have written a port scan bash script which is basically two nmap scans. The first scan determines open ports and the second scan uses the -A flag on those ports.
From the nmap scan, we can note the following:
- Software:
nginx 1.15.10, OpenSSH 7.4p1 Debian - OS:
Linux 3.X|4.X
There’s not much to go on. OpenSSH 7.4p1 is fairly recent and is likely to be not vulnerable. So, the first port of interest is port 80.
Port 80
Port 80 served a login form.
The source code of the login page tells us that credentials are sent to login.php through POST. Other than that, there’s nothing out of the ordinary.
nginx
The nginx version in use is 1.5.10 and a Google search gave some interesting information.
Looks like v1.5.10 had an arbitrary code execution vulnerability in it.
Dirbuster
Let’s use a website directory enumeration tool like dirbuster to find the URI of various web directories that are not visible to us right now. My standard dirbuster search configuration for nginx web server is:
dirbuster did not find anything that I found interesting. I thought command.php would be interesting, but no.
Nikto
Nikto is a nice web server scanner. Let’s see if it has anything for us.
I guess not.
Brute Force
So far, we did not find anything that indicates a vulnerability. So, my last option is to brute force the login form we found. There doesn’t appear to be any lockout policy on the form, so a brute is safe. I’ll use Burp Suite Community for this purpose.
It takes an insanely long time to brute force with Burp Suite Community edition. It tells us that attacks are time throttled, but that’s an understatement. Its effects cause the total time to brute force to run into hours instead of half hour. But the community edition is what I got. For purposes of this article, I’ve moved up the correct password to the top of the wordlist.
Notice that after checking the credentials root:happy, the login form responds with 200 OK for all other credentials as well. Also, the login form doesn’t provide a suitable response on incorrect login. This causes brute-forcing tools like Hydra and Medusa to give lots of false positives, rendering them useless in this scenario.
Command Injection
The web application allows the root user to execute shell commands on the target system.
We should be able to intercept this request and modify the command to give us a reverse shell instead. Burp Suite Proxy to the rescue!
Nice! We have a www-data user shell. Next step is to escalate privileges!
Lateral Movement 1
I found some old used passwords under /home/jim/backups directory and I transferred to my Kali. Run a md5sum on the received file to verify file integrity. These will be useful for brute-forcing SSH for the other users on the target.
Start brute forcing SSH with Hydra and it will give you jim user’s password within a minute!
Switch user to jim.
Lateral Movement 2
Transfer and execute LinEnum.sh on DC-4 to check for privilege escalation hints. These are some of the notes I made:
Linux dc-4 4.9.0-3-686 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) i686 GNU/Linux/var/mail/jim
Nice! We now have charles user password. SSH in with charles.
Privilege Escalation
Now that we’re charles user, let’s check what commands we can execute as another user.
The program teehee is probably custom-built, but it looks very similar to the program tee. This can be verified by comparing the help outputs of the two programs.
We can see in GTFOBins that tee can be used to write to a file when running in sudo context. Let’s append the data charles ALL=(ALL:ALL) ALL to /etc/sudoers to allow charles to sudo su root with his own password.
Root privileges! Nice! We have root shell and we have successfully compromised the DC-4 machine!
Thank you for reading!
In this article, we brute forced the web login form to authenticate ourselves, used command injection to get a foothold on DC-4, disclosed credential information by getting our hands on a file containing old passwords and reading user mail. Finally, we exploited the teehee program to gain root privileges on DC-4.
Thank you for reading! I hope you learnt something new from this article! If you have any questions, leave them in the comments section below and I’ll get back to you as soon as I can!
Feature image credit: https://www.360logica.com/blog/different-methodologies-penetration-testing/