DC-2 Walkthrough
Hello World! As I once again gear up for my OSCP, I decided to continue with my walkthrough series to blog journey to finally passing the OSCP. I took a little time off due to changes that were occurring in my life. Because of this, I decided to start back with one of the first boxes I “hacked,” DC2 found on Offensive Security Play Ground. Lets begin!
One trick to save me time, I will always create an environment variable for the IP. This can be seen in the screenshot below. Instead of having to add the IP address to every scan, I can just use the variable $ip.
My methodology begins with assessing every single open port on the node. One of the most important aspects of any CTF challenge and real life penetration testing is note keeping. Its critical to keep a copy of every single scan you perform. The last thing you want to do is rerun a scan you already performed because you did not keep proper notes. Because of this, after every scan I perform, I pipe all the output to a text file using tee.
We have 2 ports open on DC2, port 80 and port 7744. Now that I know which ports are open, I run a more detailed scan of those ports to know exactly what services are running on those ports. From the screenshot below, we can see we have a web service running on port 80 and SSH running on port 7744.
Ill begin my assessment by exploring the website hosted on this server. When I entered the IP address into my web browser, i was given a error message that dc-2 could not be found. From the nmap output above, we can see that the IP address redirects you to the URL http://dc-2/. Due to this, i updated my /etc/hosts file to map the IP address of the server to dc-2.
Once this was completed, I refreshed my browser and was redirected to a Wordpress website. With any Wordpress site, I always begin my assessment with running scans on the site using wpscan. The goal is to collect users from the site and any potentially vulnerable plugins.
While this runs, I will explore the website for any information I can use to exploit the machine. One the site, we can see a tab called Flag. This flag hints that a normal wordlist would not work for any brute forcing.
One feature of wpscan is the ability to perform a password brute force attack to log into the backend of a Wordpress site. With a valid user list and password file, Wpscan can brute force the site to identify valid username and password combos.
My scan was completed for the user enumeration and we identified 3 users, admin, jerry and tom. I added those names to a username.txt file for later use. Given the flag hinted at creating a custom wordlist, I then used cewl to create a password wordlist from the site. Cewl will grab all the words found on a webpage and create a wordlist with everything found on the site.
Using wpscan, we were able to find successful credentials for the site.
Since we have SSH open on port 7744, i wanted to test these credentials to see if i can access the server. Success! Using the credentials for the website, we were able to login to the server using SSH.
The next obstacle to climb over is rbash. The user tom has a restricted shell which limits the commands we have available to us. This does make our job a bit more difficult, but nothing is impossible with the right amount of research. To view what commands we have available to us, run the command “ls /home/tom/usr/bin.”
The Vi binary gives us the opportunity to escape the restricted shell. Once you open Vi, use the commands below:
:set shell=/bin/bash
:shellAfter this, I set the environment variables to bash to run all commands properly.
The flag found in the user tom home directory hinted and changing into the user jerry for our next step in privilege escalation. Give that we already have the password for Jerry, all we have to do is run su jerry and enter password to switch users. Below we can see that I have successfully switched to the user Jerry.
Since we have the password for the user jerry, I start my priviege escalation by running the command sudo -l. This will let us see what commands the user can run with root level privileges. In this case, Jerry has the ability to run /usr/bin/git with root level privileges without needing the root password.
For our final stage, we will leverage Git to spawn a root level shell on the host. In order to do this, we first run the command, “sudo git help config”
From the help menu, we then run “!/bin/sh.” After pressing enter, you will be rewarded with a root level shell!
