Source Code Analysis The goal is to access the GET /flag endpoint which calls an executable that prints out the flag. It’s guarded by 2 checks: if session[:user] == "admin" if req.ip == "127.0.0.1" There’s also an interesting POST /download endpoint. It accepts any session but is also guarded by the if req.ip == "127.0.0.1" check. It serves a file based on filename from our request, which leads to LFI....
Initial Inspection After loading the page we’re greeted with an upload form for zip archives. We’re informed that after uploading we can access the files by appending a filename to a generated UUID. We inspect the code and learn that our uploaded archive will be unzipped using unzip. Zip With a Symlink We can use the zip command to create an archive that’ll preserve symlinks by using the -y option....
Source Code Analysis The aim of the challenge is to call the POST /feature which contains a command injection vulnerability. As we can see, we need a valid signed access_token that contains the string access_granted. There’s GET /release endpoint that’ll do exactly that if we pass the validate_server(...) check. Interestingly, if we set a query param debug=true, we can control the validation server address. The validate_server(validation_server) method does the following:...
Source Code Analysis At first glance, I thought the intended vulnerability was a race condition. However, upon closer examination I noticed a suspicious unset($_SESSION['username']); in logout.php. The correct answer for each question is random, but it’s generated in advance both at the beginning of the quiz and upon submitting an answer. The if (intval($answer) === $next_correct) {...} is the essential part of the challenge. Regardless if our answer is correct or wrong, it’ll call htmlspecialchars($_SESSION['username']), which will throw an exception if username is unset in the session....
Source Code Analysis Upon inspecting the code, we find that there’s /ai/run path that sounds like it could let us execute something. It’s “guarded” by middleware that inspects whether host in the uri or the request header ‘host’ starts with 127.0.01. Afterwards, the execution is passed to handle_cmd which can execute one of 6 commands. For us, the intereting ones are displaying env vars And running a .bat script with an argument passed by us....
Initial Inspection There’s no souce code provided for the challenge. The only thing we’re given to work with is a website that executes our input code presumably using Bun. After playing around with it for a bit we know that it’s Bun, since the Bun variable is available and allows us to call different methods. More Recon There are quite a few limitations to our code: Bun.spawnSync function appears to be overwritten with a WAF message, WAF blocks our input from the POST body if it’s too long (I didn’t count it, but it’s about ~30 chars give or take), We can’t call await directly, Even though we can call Bun....
Initial Code Analysis Upon inspecting the code, we discovered that the frontend application is running Next.js 14.1.0. This version is vulnerable to SSRF https://nvd.nist.gov/vuln/detail/CVE-2024-34351. We also notice the flag.txt file is copied to /usr/share/nginx/html/flag.txt in the backend app, meaning it’s exposed via backend/flag.txt inside the docker network. We’ll perform an SSRF to make the frontend application send a request to the backend application /flag.txt and send it back to us....
First Steps We analyze the code and notice the email page will only show emails addressed to test@email.htb. We create a user with the email test@email.htb and confirm the registration by visiting the link from an email. DNS Rebinding to Activate an Internal User Upon further code inspection, we found out that users who sign up with an email hosted at apexsurvive.htb will be marked as internal users. There’s an /external API endpoint that can be used for an open redirect....