MyFirstBlog
Challenge Data
| Field | Value |
|---|---|
| CTF | Batman's Kitchen CTF |
| Challenge | MyFirstBlog |
| Category | Web |
| Flag | bkctf{k3ys_in_th3_l0ck5} |
Challenge Description
It was a simple personal blog. A deleted post was still accessible and there was an attachment endpoint that received file names as a parameter. The solve came from combining those two clues.
Reconnaissance
On the front page there were links to /blog/1, /blog/2, and /blog/4, so the first thing to try was the missing route. At /blog/3 there was a post marked as deleted, but the HTML still exposed useful information.
Two details mattered there.
- A comment explained that documents inside the
otherfolder required an API key. - An
<object>loaded a PDF with that key directly in the URL.
/attachment?file=resume.pdf&apiKey=906392d25b3bd7d3af491799f89f6620
On top of that, the site was already using /attachment?file=... to serve static resources, so the file parameter was the most natural place to test path traversal.
Analysis
Without the API key, requests such as file=/flag.txt or file=../../../flag.txt returned 403. But once the key was known, the behavior changed. The server did allow access to files from the other folder and the file value was not properly restricted.
If the backend resolved paths starting from other/<file> without sanitizing ../, it was possible to escape the expected directory and end up reading /flag.txt.
The deleted post was not only leftover content. It was also exposing the credential needed to use the vulnerable endpoint.
Solution
With the exposed API key, the endpoint could be requested like this.
curl -s "http://34.186.135.240:30000/attachment?file=../../../flag.txt&apiKey=906392d25b3bd7d3af491799f89f6620"
The response returned the flag directly.
Flag
bkctf{k3ys_in_th3_l0ck5}