Udhaifu za 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 Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Sehemu ya chapisho hili inategemea chapisho nzuri: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
Mwandishi wa zana nzuri za pentest JWTs https://github.com/ticarpi/jwt_tool

Faida za Haraka

Endesha jwt_tool kwa mode All Tests! na subiri mistari ya kijani

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, zana itagundua baadhi ya kesi ambapo programu ya wavuti inakagua JWT kwa njia isiyofaa:

Kisha, unaweza kutafuta ombi hilo kwenye proxy yako au dump JWT iliyotumika kwa ombi hilo ukitumia jwt_ tool:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

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

Tamper data without modifying anything

You can just tamper with the data leaving the signature as is and check if the server is checking the signature. Try to change your username to “admin” for example.

Is the token checked?

Ili kukagua ikiwa signature ya JWT inathibitishwa:

  • Ujumbe wa kosa unaonyesha uthibitisho unaendelea; mapitio ya taarifa nyeti katika maelezo ya kosa verbose yanapaswa kukaguliwa.
  • Mabadiliko kwenye ukurasa uliorudishwa pia yanaonyesha uthibitisho.
  • Hakuna mabadiliko inaonyesha hakuna uthibitisho; hapa ndipo unaweza kujaribu tampering ya payload claims.

Origin

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

  • Tokens first seen from the client side suggest the key might be exposed to client-side code, necessitating further investigation.
  • Tokens originating server-side indicate a secure process.

Duration

Angalia ikiwa token inadumu zaidi ya 24h… labda haijaexpira kabisa. Ikiwa kuna “exp” field, angalia ikiwa server inaishughulikia ipasavyo.

Brute-force HMAC secret

See this page.

Derive JWT secrets from leaked config + DB data

Iliarbitrary file read (au backup leak) ikaonyesha pamoja application encryption material na user records, unaweza wakati mwingine kuunda upya JWT signing secret na kutengeneza session cookies bila kujua plaintext passwords. Mfano wa muundo uliobainika katika 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 token iliyosainiwa kwenye cookie ya kikao (kwa mfano, n8n-auth) ili kujifanya kuwa mtumiaji/msimamizi hata kama hash ya nenosiri imeongezwa chumvi.

Modify the algorithm to None

Weka algorithm inayotumika kuwa “None” na ondoa sehemu ya saini.

Tumia Burp extension iitwayo “JSON Web Token” kujaribu tatizo hili na kubadilisha thamani tofauti ndani ya JWT (tuma request kwa Repeater na kwenye kichupo cha “JSON Web Token” unaweza kubadilisha thamani za token. Pia unaweza kuchagua kuweka thamani ya uwanja wa “Alg” kuwa “None”).

Change the algorithm RS256(asymmetric) to HS256(symmetric) (CVE-2016-5431/CVE-2016-10555)

Algorithm HS256 inatumia ufunguo wa siri kusaini na kuthibitisha kila ujumbe.
Algorithm RS256 inatumia ufunguo wa binafsi kusaini ujumbe na kutumia ufunguo wa umma kwa uthibitishaji.

Ikiwa utabadilisha algorithm kutoka RS256 hadi HS256, code ya back end itatumia public key kama secret key kisha itumie algorithm HS256 kuthibitisha saini.

Kisha, kwa kutumia public key na kubadilisha RS256 kuwa HS256 tunaweza kuunda saini halali. Unaweza kupata certificate ya web server kwa kutekeleza hii:

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

Ufunguo mpya (public key) ndani ya header

Mshambuliaji anaweka ufunguo mpya ndani ya header ya token na server inatumia ufunguo huu mpya kuthibitisha signature (CVE-2018-0114).

Hii inaweza kufanywa na “JSON Web Tokens” Burp extension.
(Send the request to the Repeater, inside the JSON Web Token tab select “CVE-2018-0114” and send the request).

JWKS Spoofing

Maelekezo yanaelezea mbinu ya kutathmini usalama wa JWT tokens, hasa zile zinazotumia dai la header “jku”. Dai hili linapaswa kuunga mkono faili ya JWKS (JSON Web Key Set) ambayo ina public key inayohitajika kwa uthibitisho wa token.

  • Assessing Tokens with “jku” Header:

  • Hakiki URL ya dai la “jku” ili kuhakikisha inaelekeza kwa faili sahihi ya JWKS.

  • Badilisha thamani ya “jku” ya token ili kuipeleka kwenye huduma ya wavuti unayodhibiti, kuruhusu uchunguzi wa trafiki.

  • Monitoring for HTTP Interaction:

  • Kuona maombi ya HTTP kwa URL uliyotaja kunaonyesha jaribio la server la kupata keys kutoka kwenye kiungo uliotoa.

  • Unapotumia jwt_tool kwa mchakato huu, ni muhimu kusasisha faili jwtconf.ini na eneo lako la JWKS ili kurahisisha upimaji.

  • Command for jwt_tool:

  • Execute the following command to simulate the scenario with jwt_tool:

python3 jwt_tool.py JWT_HERE -X s

Kid Issues Overview

Dai la header la hiari linalojulikana kama kid linatumiwa kutambua key maalum, jambo ambalo huwa muhimu hasa katika mazingira yenye key nyingi kwa ajili ya uhakiki wa saini ya token. Dai hili husaidia kuchagua key inayofaa kuthibitisha saini ya token.

Revealing Key through “kid”

Wakati dai la kid lipo kwenye header, inapendekezwa kutafuta kwenye saraka ya wavuti faili inayolingana au mabadiliko yake. Kwa mfano, ikiwa "kid":"key/12345" imeainishwa, tafuta faili /key/12345 na /key/12345.pem katika web root.

Path Traversal with “kid”

Dai la kid pia linaweza kutumika kuvinjari mfumo wa faili, kwa hivyo linaweza kuruhusu uteuzi wa faili yoyote. Inawezekana kujaribu muunganisho au kutekeleza mashambulizi ya SSRF kwa kubadili thamani ya kid ili kulenga faili maalum au huduma. Kugeuza JWT kubadilisha thamani ya kid huku ukihifadhi signature ya awali kunaweza kufanywa kwa kutumia bendera -T katika jwt_tool, kama inavyoonyeshwa hapa chini:

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

By targeting files with predictable content, it’s possible to forge a valid JWT. For instance, the /proc/sys/kernel/randomize_va_space file in Linux systems, known to contain the value 2, can be used in the kid parameter with 2 as the symmetric password for JWT generation.

SQL Injection kupitia “kid”

Ikiwa yaliyomo katika dai la kid yanatumika kuchukua nywila kutoka kwa database, SQL Injection inaweza kuwezeshwa kwa kubadilisha payload ya kid. Mfano wa payload unaotumia SQL Injection kubadilisha mchakato wa kusaini JWT ni:

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

Mabadiliko haya yanalazimisha matumizi ya secret key inayojulikana, ATTACKER, kwa kusaini JWT.

OS Injection kupitia “kid”

Senario ambako parameter ya kid inaonyesha njia ya faili inayotumiwa ndani ya muktadha wa utekelezaji wa amri inaweza kusababisha kwetsuamia za Remote Code Execution (RCE). Kwa kuingiza amri katika parameter kid, inawezekana kufichua private keys. Mfano wa payload ya kupata RCE na kufichua funguo ni:

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

x5u and jku

jku

jku stands for JWK Set URL.
Ikiwa token inatumia dai la “jku” katika Header basi angalia URL iliyotolewa. Hii inapaswa kuonyesha URL inayoonyesha faili la JWKS linalohifadhi Public Key kwa ajili ya kuthibitisha token. Badilisha token ili kuonyesha thamani ya jku kuelekea kwa web service unaweza kufuatilia traffic yake.

Kwanza unahitaji kuunda certificate mpya yenye private & 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

Kisha unaweza kutumia, kwa mfano, jwt.io kuunda JWT mpya ukiwa na created public and private keys na ukielekeza parameter jku kwenye certificate iliyoundwa. Ili kuunda jku certificate halali unaweza kupakua ile ya asili na kisha kubadilisha vigezo vinavyohitajika.

Unaweza kupata vigezo “e” na “n” kutoka kwa public certificate 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))

x5u

X.509 URL. URI inayoelekeza kwa seti ya vyeti vya umma vya X.509 (muundo wa cheti) vilivyokodishwa kwa PEM. Cheti cha kwanza katika seti lazima kiwe hicho kilichotumika kusaini JWT hii. Vyeti vinavyofuata vinasaini kile kilichotangulia, hivyo kukamilisha mnyororo wa vyeti. X.509 imefafanuliwa katika RFC 52807. Usalama wa usafirishaji unahitajika ili kuhamisha vyeti.

Jaribu kubadili header hii kwa URL chini ya udhibiti wako na angalia kama ombi lolote linapokelewa. Katika hali hiyo unaweza kuharibu JWT.

Ili kutengeneza token mpya kwa kutumia cheti unachodhibiti, unahitaji kuunda cheti na kutoa funguo za umma na za kibinafsi:

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

Kisha unaweza kutumia kwa mfano jwt.io kuunda JWT mpya ukiwa na created public and private keys na kuelekeza parameter x5u kwenye certificate .crt iliyotengenezwa.

Unaweza pia kuchukua faida ya vuln hizi zote mbili kwa SSRFs.

x5c

Parameter hii inaweza kuwa na certificate in base64:

Iwapo mshambulizi generates a self-signed certificate na kuunda forged token kwa kutumia corresponding private key na kubadilisha thamani ya parameter “x5c” na kuweka certificate mpya iliyotengenezwa pamoja na kurekebisha vigezo vingine, yaani n, e na x5t, basi kwa msingi token bandia 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 Uliojengwa Ndani (CVE-2018-0114)

Ikiwa JWT imejumuisha ufunguo wa umma kama katika tukio lifuatalo:

Kwa kutumia script ifuatayo ya nodejs, inawezekana kuzalisha 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 kuunda private/public key mpya, kuingiza public key mpya ndani ya token na kuitumia kutengeneza signature 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

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

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));

Mwisho, kwa kutumia ufunguo wa umma na ufunguo wa kibinafsi pamoja na thamani mpya za “n” na “e” unaweza kutumia jwt.io kutengeneza JWT mpya halali yenye taarifa yoyote.

ES256: Kufichua ufunguo wa kibinafsi kwa nonce ileile

Ikiwa baadhi ya maombi yanatumia ES256 na yanatumia nonce ileile kuunda JWTs mbili, ufunguo wa kibinafsi unaweza kurejeshwa.

Here is a example: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

Dai la JTI (JWT ID) linatoa kitambulisho cha kipekee kwa Token ya JWT. Linaweza kutumika kuzuia token kutumika tena (replay).
Hata hivyo, fikiria hali ambapo urefu wa juu wa ID ni 4 (0001-9999). Maombi 0001 na 10001 zitatumia ID ile ile. Kwa hivyo, ikiwa backend inaongeza ID kwa kila ombi unaweza kuchukua faida ya hili ili replay a request (itakuhitaji kutuma maombi 10000 kati ya kila replay iliyofanikiwa).

JWT Registered claims

JSON Web Token (JWT)

Mashambulizi mengine

Cross-service Relay Attacks

Imeonekana kwamba baadhi ya web applications zinategemea huduma ya kuaminika ya JWT kwa ajili ya uundaji na usimamizi wa token zao. Kuna matukio yaliyorekodiwa ambapo token iliyotengenezwa kwa mteja mmoja na huduma ya JWT ilikubaliwa na mteja mwingine wa huduma ile ile ya JWT. Ikiwa utolewaji au upya wa JWT kupitia huduma ya mtu wa tatu utaonekana, inapaswa kuchunguzwa uwezekano wa kujisajili kwa akaunti kwenye mteja mwingine wa huduma hiyo kwa kutumia jina la mtumiaji/barua pepe ile ile. Kisha jaribu replay token uliopata katika ombi kwa lengo kuona kama inakubaliwa.

  • Kukubaliwa kwa token yako kunaweza kuashiria tatizo kubwa, labda kuruhusu kuiga akaunti ya mtumiaji yeyote. Hata hivyo, inapaswa kutajwa kwamba ruhusa kwa upimaji mpana inaweza kuhitajika ikiwa unajiandikisha kwenye application ya mtu wa tatu, kwani hii inaweza kuingia katika eneo la kisheria lenye utata.

Expiry Check of Tokens

Muda wa kumalizika wa token unakaguliwa kwa kutumia dai la Payload la “exp”. Kwa kuwa JWTs mara nyingi hutumiwa bila taarifa za session, inahitaji kushughulikiwa kwa uangalifu. Katika matukio mengi, kukamata na replay JWT ya mtumiaji mwingine kunaweza kuruhusu kuiga utambulisho wa mtumiaji huyo. JWT RFC inapendekeza kupunguza JWT replay attacks kwa kutumia dai la “exp” kuweka muda wa kumalizika kwa token. Aidha, utekelezaji wa ukaguzi unaofaa na application ili kuhakikisha thamani hii inashughulikiwa na token zilizokwishakamilika zinakatwa ni muhimu. Ikiwa token ina dai la “exp” na mipaka ya muda ya upimaji inaruhusu, inashauriwa kuhifadhi token na kureplay baadaye baada ya muda wa kumalizika kupita. Yaliyomo ya token, ikijumuisha uchambuzi wa timestamp na ukaguzi wa kumalizika (timestamp kwa UTC), yanaweza kusomwa kwa kutumia jwt_tool’s -R flag.

  • Hatari ya usalama inaweza kuwepo ikiwa application bado inathibitisha token, kwani inaweza kubainisha kuwa token haiwezi kamwe kuisha.

Tools

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

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 Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks