Overview

The goal of this activity was to work with the processes, procedures, and resources utilized in ethical hacking.

Useful Commands and Instructions

1. Determining the versions of the two services exposed by cupcake

The screenshot above depicts the usage of nmap to scan the target host on common ports. Below, both ports are focused on with the -sV flag to detail the service and version number.

2. Parsing nmap result with nmaptocsv

Now I've run nmap with the -sT and -sV flags to specify a TCP port scan and detail the service and version for the top 100 ports. -Pn disabled host discovery and only does port scan. -oG outputs the results of the scan to a file. The nmaptocsv command below formats the output into a .csv format, which makes for an easy copy/paste into a spreadsheet application.

Once the output is provided in the console, you can simply copy/paste it into a spreadsheet. When you open a new sheet, there's an option to split the content into cells so that it's formatted as expected. You'll end up with something similar to the screenshot below:

3. The techniques you used to invoke remote code execution

Because we know that the IP is running port 80, it was worth checking for a public-facing web server. Below is the publicly available content from the web browsing session:

If we run the shellshock vulnerability against the webserver, we can get the kernel information and use this to find even more vulnerabilities:

The bulk of the remote code execution in this lab follows the following format, with slight adjustments--these are used to obtain the /etc/passwd file, the HTML behind the webpage, and some networking information. We'll revisit the /etc/passwd file later for the purposes of brute-forcing and privilege escalation.

4. The generation of a list of passwords and subsequent ssh bruteforce

When we examine the /etc/passwd file, we notice only one irregularity--the non-root user called "samwise". Following the LOTR theme in this class, we know that this is our next step in obtaining access.

In the /usr/share/wordlists directory, we were pointed to a wordlist file that we needed to sort out potential passwords from--so I grep'd the potentially relevant content:

From here, the output was directed into another file and parsed into hydra, a built-in password-cracking tool. These potentially relevant words will be utilized against the "samwise" user to attempt a brute-force--we were then able to use valid credentials to SSH into the "samwise" account, a non-root user.

5. Transfer of files using python and wget or any other mechanism you chose

The screenshot below details the utilization of searchsploit, and the -m and the exploit number together end up copying the exploit to a local directory (see the right side of the capture). Now that it's saved to the device, we used python to set up a webserver on a nonstandard port (see bottom right). Once this was running, the target host (bottom left side) was utilized: I created a new unique directory (since this was a shared target), and from there I used wget to browse to the attacking box at the nonstandard port and redirected to the exploit. This, in turn, saves the exploit to the device.

6. Compiling and running a privilege escalation exploit (It can be different than the demo!)

Now that the exploit is saved locally on the victim box, it can be compiled with gcc and the -o specifies the output, in this case my name. Errors were handled with -l immediately followed by the variable, since they needed to be linked. Note the resulting permissions at the bottom of the screenshot:

Now that the exploit is compiled, it can be run--you'll be prompted to enter a new "root" password (this takes a couple of minutes to run):

You'll notice if you cat /etc/passwd that the file has been modified and the root user has been modified to "firefart".

By using su and changing users to "firefart" (and entering the password you generated earlier) you'll effectively be root--try running id and you'll see that your group ID is set to zero.

To revert your work, simply copy the tmp file to /etc/passwd and allow overwrite.

Issues and Troubleshooting

My main issue in this lab was displaying the contents of /etc/passwd--when I was working on the lab, the environment was not reset and therefore I was unable to see the content properly. The only remedy for this was to wait, and a couple of days later, the issue was fixed and my command worked as expected. This was a unique situation since the target existed within a shared environment. This limitation wouldn't likely exist within a realistic scenario.

Questions/Reflection

This lab as a whole was very unique for me--I've never dealt with a network that involved lateral movement and open-source research in a dynamic environment. The context within this lab was especially new, and the techniques were foreign. I hope to become more comfortable with this content as we progress through future labs. I appreciated the ways that we utilized Kali tools and leveraged existing infrastructure through "living off the land". I struggled with some of the more specific syntax, which required googling, asking for assistance, and certain degrees of trial and error.