Proving Grounds - Amaterasu Walkthrough

Initial Compromise

If you want to follow along be sure to first get access to this lab by going to OffSec. We start off by running a basic NMAP scan as root to determine what ports are open on the machine and their service versions. Let’s throw in the -A flag to get an understanding of what operating system we’re working with.

nmap -sV -sT -A -p- 192.168.224.249

Sometimes nmap scans can take a while, so I like to pipe the output into a text file to reference the scan later. You can use the following command to do so:

nmap -sV -sT -A -p- 192.168.224.249 >> nmap_scan.txt

Taking a look at our nmap results, we can see there’s various open ports. We see the web server is running a Unix distribution. Let’s start poking at each port. Starting at port 21, we see that the ftp service allows anonymous connections. To connect to it, we can use the ftp command.

ftp 192.168.224.249

When prompted for a username we just have to input “anonymous” and we have a valid connection. From here we can try to enumerate files on the system, but unfortunately many commands won’t work, so this avenue won’t get us anywhere. So let’s pivot to http enumeration.

Let’s try enumerating the http ports, 40080 and 33414. Upon navigating to 33414 in a web browser we don’t get anything useful. Let’s try 40080. We get a fancy looking page, but nothing too useful. Time to do some brute forcing. We’re going to fuzz potential directory endpoints using gobuster.

gobuster dir -u 192.168.224.249:40080 -w /usr/share/SecLists/Discovery/Web-Content/directory-list-2.3-big.txt

Nothing super interesting from our gobuster fuzzing. Let’s try port 33414.

Gobuster dir -u 192.168.224.249:33414 -w /usr/share/SecList/Discovery/Web-Content/directory-list-2.3-big.txt

This yields some more promising endpoints. We see a /info and /help endpoint that we can navigate to and see what lives there.

We see that the help endpoint lists the /file-list?dir=/tmp and a /file-upload endpoint. That’s interesting, an endpoint that presumably allows us to enumerate files hosted on the web server. Let’s see what we can find, and figure out if we can find a user associated with the system. Users show up in the /home directory on linux & unix systems. Let’s see who we find if we try and hit the home directory.

Looks like there’s a user named alfredo. Let’s take a look at his home directory.

Looks like there’s a .ssh folder, along with the first half of our flag that lives in local.txt. However, we can’t execute other commands through this endpoint. We can attempt to crack Alfredo’s password using hydra and attempting to brute force login through ssh, but remember that file upload endpoint we found earlier? Let’s see if we can upload a test file to the web server. Let’s take a look at that endpoint. We can gather some info on the file-upload function through the /info endpoint.

After some research, we can craft a curl command and upload a simple test.txt file to the web server and see if it works.

curl -i -L -X POST -H "Content-Type: multipart/form-data" -F file="@//home/user/Documents/OffSec/Proving_Grounds/Play/Amaterasu/text.txt" -F filename=”/tmp/test.txt”

Sure enough, we get a 200 OK from the server and we can use the /file-list endpoint to validate whether our test file lives on the server.

Success! Our test file now lives in the /tmp folder on the server. Now that we know we can upload files to the server, let’s see if we can overwrite alfredo’s ssh keys.

We can generate new keys using ssh-keygen and then upload those keys to the .ssh folder using the file-upload function.

Once we have the id_rsa files, we can upload the .pub file to the web server using the same curl command, but this time pointing to alfredo’s .ssh directory

Looks like the server only accepts certain file types. Although a small hiccup, we have a neat trick to bypass this. We can move the .pub file into a .txt file using the mv command in linux.

mv id_rsa.pub id_rsa.txt

Once we retry uploading the id_rsa.txt file to the .ssh directory, we get a successful response from the web server. Now we can try logging in as alfredo using the basic ssh function and passing the id_rsa file on our local machine. If we reference back to our initial port scan, the normal ssh port, 22, is not an open port. However, there’s an OpenSSH service running on port 25022, so we’ll need to use the -p flag to specify the correct port.

ssh -p 25022 alfredo@192.168.224.249 -i id_rsa

Success! We’re now logged in as alfredo and can get the first part of the flag.

Privilege Escalation

Now that we’ve got access to the web server, we need to escalate our privileges to root. Let’s take a look at the cronjobs on the syste by viewing the /etc/contab file.

cat  /etc/crontab

We can see a backup-flask.sh script that runs every minute. After doing some research, I was able to find the wildcare being used leads to privilege escalation using tar. We can do this by running the following commands in the restapi directory: