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
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.
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.
nmap scan, we can note the following:
nginx 1.15.10, OpenSSH 7.4p1 Debian
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 served a login form.
The source code of the login page tells us that credentials are sent to
POST. Other than that, there’s nothing out of the ordinary.
nginx version in use is
1.5.10 and a Google search gave some interesting information.
v1.5.10 had an arbitrary code execution vulnerability in it.
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 is a nice web server scanner. Let’s see if it has anything for us.
I guess not.
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
Medusa to give lots of false positives, rendering them useless in this scenario.
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
Hydra and it will give you
jim user’s password within a minute!
Switch user to
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
Nice! We now have
charles user password. SSH in with
Now that we’re
charles user, let’s check what commands we can execute as another user.
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
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/