The Planets: Earth

Can you root this machine?

today i am solving playing The Planets: Earth machine from Vulnhub CTF.

1. Host Discovery & Reconnaissance

So, i start with finding the ip of machine with this command.

So, the ip of targeted machine is 192.168.226.152 and Now I have to run nmap on this machine to find the open ports

Open ports are as follows;

2. Web Enumeration & Virtual Host Discovery

I got my result that these ports are open, let me open port 80 and 443 on browser.

So next i have a thought to check robots.txt but nothing found as you can see below.

i run dirb tool to find hidden directories and folders on website’s ip.

it gives nothing important, then again, I checked nmap results there I saw two dns names.

i add these dns names in my /etc/hosts file.

I got two sites with same content with on different ports i.e 80,443. So, I again ran dirb tool on these sites.

And got some working and non-working links

Well, this time robots.txt is shown and /testingnotes.* looks different so I open that.

Three critical facts dropped here: the messaging app uses XOR “encryption”, a file called testdata.txt was used to test it, and the admin portal username is terra.

Grabbed the referenced test file:

Guess what? this is our encryption key

3. Breaking the XOR Encryption

The earth.local messaging page stores a history of previously sent, XORencrypted messages (as hex). Because testdata.txt was encrypted through the exact same system with the exact same key, XOR-ing its known plaintext against its own ciphertext (and sliding it across the other stored ciphertexts) recovers fragments of the repeating key, a classic known-plaintext / cribdragging attack against reused-key XOR.

Get Khalid Abdullahi’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Used CyberChef (From Hex → XOR) to do this interactively:

The output repeats a readable fragment across multiple blocks ,the tell-tale sign of a correctly-aligned key in a reused-key XOR cipher. Extending and cleaning up that recovered key made it possible to decrypt the admin’s stored messages, which contained the actual admin portal password.

Logged into earth.local/admin as terra with the recovered credentials

A direct reverse shell one-liner was blocked by an outbound filter:

Worked around the filter by base64-encoding the payload and decoding/executing it server-side with base64 -d | bash, which doesn’t match the blocked pattern:

Caught the callback on a listener:

Shell landed as apache on host earth. The Django project directory under /var/earth_web held the first flag:

5. Privilege Escalation

Now I have escalate the privilege on this machine, before that I spawn the python shell for better and strong connection.

All this just to upgrade my shell.

Upgraded the dumb shell to a proper interactive TTY before doing anything further (needed for su and cleaner tooling):

As a ctf player the word reset root attracted me to much so i went ahead and opened it

it talks about reset triggers are not present, now i have see what are the triggers name. For that i import this file to my main machine.

I set up a listener

After so many tries I successfully able to export this file in my main system.

Let’s check with ltrace tool because its a binary file and i cannot read with cat command.

So, this tells me to make some folders with these names, let me make these folders.

I got the root user password let’s try this and read root flag.

I successfully complete this machine.

i demonstrated

• Host & service discovery (arp-scan, nmap) and reading SSL certificate metadata for recon (SAN field leaking internal hostnames)
• Virtual host enumeration & brute-forcing content per-hostname instead of per-IP
• Source-hunting via robots.txt and developer-note disclosure
• Known-plaintext / crib-dragging attack against reused-key XOR encryption using CyberChef
• Filter evasion via base64-encoded payload execution
• Linux privilege escalation via SUID binary reverse engineering (ltrace) rather than guesswork
• Cross-host file transfer techniques and troubleshooting when standard methods (e.g. /dev/tcp) aren’t available