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....