Amaterasu CTF Write-up

Phase 1: Recon

I started this CTF by running an nmap scan. It returned 4 open ports, on which I ran a second and more detailed scan.

I began investigating the FTP server, but it had a strange error which I did not know how to fix.

I did some research, but it didn’t seem like something that could be fixed on the user end, so I moved past it.

The HTTP server on port 40080 was open, but seemed like another dead end. Nothing was executable or interactive. It was all static.

I didn’t bother with SSH. A simple google search didn’t reveal anything, and the protocol is known for being secure. I moved on to the HTTP server on port 33414.

Initially I was sent to a Not Found page.

Gobuster found the /info page though, which led me to /help. This revealed that this was an API.

/help listed all the available routes for the API. Listing directories allowed me to find a user: ‘alfredo’.

His home directory had a .ssh folder with both a public and private key. I got excited but realized that we could only list directories, not read files.

Moving on from directory listings, I explored the file upload section. This took a bit of analyzing the errors in order to form a proper Curl request.

Finally a test file was able to be uploaded!

The file listing allowed me to see that the upload was successful.

Phase 2: Access

The vector I used to gain access to the machine was to write my SSH public key into alfredo’s .ssh directory. It took me a while to figure out how to do this though.

At first I tried to overwrite the public and private keys in .ssh. This didn’t do anything. I remembered that SSH keys need to be included in .ssh/authorized_keys to be used for log in.

I tried many different ways to upload a directory, or to write the public key to a file called “authorized_keys/id_rsa.pub”, but with no luck.

Finally, I simply wrote the public key to a file called “authorized_keys”.

With that, I was able to finally log in to the machine. Hooray!

Phase 3: Escalation

After checking the low hanging fruit of

sudo -l

and

find / -perm -4000 2>/dev/null

and finding nothing useful, I looked at the cron services running.

Crontab revealed an unusual script being run every minute.

Investigating it, I began to think of how it could be exploited.

Every minute, this script would set the primary path to be ‘/home/alfredo/restapi’, which is a writeable directory. The script would then go to that directory and run a tar command on every file in that directory.

Unfortunately for the admins and fortunately for us, when tar is called, it is called using a relative path. Moreover, our path environment variable is set to look at /home/alfredo/restapi/ before anywhere else.

Putting these facts together, we can craft a malicious script called ‘tar’, which will be saved in ‘restapi’. This ‘tar’ will open a shell can connect to my attacker machine on port 21.

A note on why we are connecting to port 21: it seemed that the target machine had a firewall blocking connections to any attacker port not also open on the target machine. Port 80, for example, would not connect.

Within a minute, the listener had spawned a shell as none other than root.

The box has been pwned!