JWT Vulnerabilities (Json Web Tokens)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
If you are interested in hacking career and hack the unhackable - we are hiring! (kuandika na kuzungumza kwa ufasaha kwa Kiholanzi kunahitajika).
Part of this post is based in the awesome post: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology Author of the great tool to pentest JWTs https://github.com/ticarpi/jwt_tool
Run jwt_tool with mode All Tests! and wait for green lines
Ikiwa una bahati, chombo kitapata kesi ambapo programu ya wavuti inakosea kuangalia JWT:
Kisha, unaweza kutafuta ombi katika proxy yako au kutupa JWT iliyotumika kwa ombi hilo ukitumia jwt_ tool:
You can also use the Burp Extension SignSaboteur to launch JWT attacks from Burp.
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.
To check if a JWT's signature is being verified:
An error message suggests ongoing verification; sensitive details in verbose errors should be reviewed.
A change in the returned page also indicates verification.
No change suggests no verification; this is when to experiment with tampering payload claims.
It's important to determine whether the token was generated server-side or client-side by examining the proxy's request history.
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.
Check if the token lasts more than 24h... maybe it never expires. If there is a "exp" filed, check if the server is correctly handling it.
Set the algorithm used as "None" and remove the signature part.
Use the Burp extension call "JSON Web Token" to try this vulnerability and to change different values inside the JWT (send the request to Repeater and in the "JSON Web Token" tab you can modify the values of the token. You can also select to put the value of the "Alg" field to "None").
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:
Mshambuliaji anaingiza funguo mpya kwenye kichwa cha token na seva inatumia funguo hii mpya kuthibitisha saini (CVE-2018-0114).
Hii inaweza kufanywa kwa kutumia "JSON Web Tokens" Burp extension. (Tuma ombi kwa Repeater, ndani ya tab ya JSON Web Token chagua "CVE-2018-0114" na tuma ombi).
Maagizo yanaelezea njia ya kutathmini usalama wa JWT tokens, hasa zile zinazotumia madai ya kichwa "jku". Dhamira hii inapaswa kuunganisha na faili ya JWKS (JSON Web Key Set) ambayo ina funguo ya umma inayohitajika kwa uthibitishaji wa token.
Kuthibitisha Tokens zenye Kichwa "jku":
Thibitisha URL ya dhamira "jku" ili kuhakikisha inapeleka kwenye faili sahihi ya JWKS.
Badilisha thamani ya "jku" ya token ili kuelekeza kwenye huduma ya wavuti inayodhibitiwa, kuruhusu ufuatiliaji wa trafiki.
Kufuatilia Maingiliano ya HTTP:
Kuangalia maombi ya HTTP kwenye URL yako iliyotolewa kunaonyesha juhudi za seva kupata funguo kutoka kiungo chako kilichotolewa.
Unapokuwa unatumia jwt_tool kwa mchakato huu, ni muhimu kuboresha faili ya jwtconf.ini na eneo lako la JWKS binafsi ili kuwezesha majaribio.
Amri kwa jwt_tool:
Tekeleza amri ifuatayo ili kuiga hali hiyo na jwt_tool:
Dhamira ya hiari inayojulikana kama kid inatumika kutambua funguo maalum, ambayo inakuwa muhimu hasa katika mazingira ambapo funguo nyingi zinapatikana kwa uthibitishaji wa saini ya token. Dhamira hii inasaidia katika kuchagua funguo sahihi kuthibitisha saini ya token.
Wakati dhamira ya kid inapatikana kwenye kichwa, inashauriwa kutafuta kwenye directory ya wavuti kwa faili inayolingana au tofauti zake. Kwa mfano, ikiwa "kid":"key/12345" imeainishwa, faili /key/12345 na /key/12345.pem zinapaswa kutafutwa kwenye mzizi wa wavuti.
Dhamira ya kid inaweza pia kutumika vibaya kuzunguka mfumo wa faili, ikiruhusu kuchagua faili yoyote. Inawezekana kujaribu kuunganishwa au kutekeleza mashambulizi ya Server-Side Request Forgery (SSRF) kwa kubadilisha thamani ya kid ili kulenga faili au huduma maalum. Kubadilisha JWT ili kubadilisha thamani ya kid huku ukihifadhi saini ya awali kunaweza kufanywa kwa kutumia bendera -T katika jwt_tool, kama inavyoonyeshwa hapa chini:
Kwa kulenga faili zenye maudhui yanayoweza kutabirika, inawezekana kutengeneza JWT halali. Kwa mfano, faili ya /proc/sys/kernel/randomize_va_space katika mifumo ya Linux, inayojulikana kuwa na thamani 2, inaweza kutumika katika parameter ya kid na 2 kama nenosiri la simetriki kwa ajili ya uzalishaji wa JWT.
Ikiwa maudhui ya dai la kid yanatumika kupata nenosiri kutoka kwenye hifadhidata, kuingilia kati kwa SQL kunaweza kuwezesha kwa kubadilisha payload ya kid. Mfano wa payload inayotumia SQL injection kubadilisha mchakato wa kusaini JWT ni:
non-existent-index' UNION SELECT 'ATTACKER';-- -
Mabadiliko haya yanawalazimisha kutumia funguo ya siri inayojulikana, ATTACKER, kwa ajili ya kusaini JWT.
Hali ambapo parameter ya kid inaelekeza kwenye njia ya faili inayotumika ndani ya muktadha wa utekelezaji wa amri inaweza kusababisha udhaifu wa Remote Code Execution (RCE). Kwa kuingiza amri kwenye parameter ya kid, inawezekana kufichua funguo za faragha. Mfano wa payload kwa ajili ya kufikia RCE na ufichuzi wa funguo ni:
/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&
jku inasimama kwa JWK Set URL. Ikiwa token inatumia dai la “jku” Header basi angalia URL iliyotolewa. Hii inapaswa kuelekeza kwenye URL inayoshikilia faili la JWKS ambalo lina Funguo ya Umma kwa ajili ya kuthibitisha token. Badilisha token ili kuelekeza thamani ya jku kwenye huduma ya wavuti ambayo unaweza kufuatilia trafiki yake.
Kwanza unahitaji kuunda cheti kipya chenye funguo mpya za faragha na za umma.
Kisha unaweza kutumia kwa mfano jwt.io kuunda JWT mpya na funguo za umma na za faragha zilizoundwa na kuelekeza parameter jku kwa cheti kilichoundwa. Ili kuunda cheti halali cha jku unaweza kupakua kile original na kubadilisha parameters zinazohitajika.
Unaweza kupata parameters "e" na "n" kutoka kwa cheti cha umma kwa kutumia:
X.509 URL. URI inayopointia seti ya X.509 (kiwango cha muundo wa cheti) vyeti vya umma vilivyoandikwa kwa mfumo wa PEM. Cheti cha kwanza katika seti lazima kiwe kile kinachotumika kusaini JWT hii. Vyeti vinavyofuata kila kimoja husaini kile kilichopita, hivyo kukamilisha mnyororo wa vyeti. X.509 imefafanuliwa katika RFC 52807. Usalama wa usafirishaji unahitajika kuhamasisha vyeti.
Jaribu kubadilisha kichwa hiki kuwa URL chini ya udhibiti wako na angalia kama ombi lolote linapokelewa. Katika hali hiyo, unaweza kubadilisha JWT.
Ili kutunga token mpya kwa kutumia cheti kinachodhibitiwa na wewe, unahitaji kuunda cheti na kutoa funguo za umma na za faragha:
Kisha unaweza kutumia kwa mfano jwt.io kuunda JWT mpya na funguo za umma na za faragha zilizoundwa na kuelekeza parameter x5u kwa cheti .crt kilichoundwa.
Pia unaweza kutumia udhaifu hizi kwa SSRFs.
Parameter hii inaweza kuwa na cheti katika base64:
Ikiwa mshambuliaji anazalisha cheti kilichojisaini mwenyewe na kuunda token iliyofanywa kwa kutumia funguo za faragha zinazohusiana na kubadilisha thamani ya parameter "x5c" na cheti kilichozalishwa upya na kubadilisha parameta zingine, yaani n, e na x5t basi kimsingi token iliyofanywa itakubaliwa na seva.
Ikiwa JWT ina funguo ya umma iliyojumuishwa kama katika hali ifuatayo:
Kwa kutumia skripti ifuatayo ya nodejs inawezekana kuzalisha funguo ya umma kutoka kwa data hiyo:
Ni possible kuunda funguo mpya za binafsi/za umma, kuingiza funguo mpya ya umma ndani ya token na kuitumia kuunda saini mpya:
Unaweza kupata "n" na "e" ukitumia hii nodejs script:
Finally, using the public and private key and the new "n" and "e" values you can use jwt.io to forge a new valid JWT with any information.
Ikiwa baadhi ya programu zinatumia ES256 na kutumia nonce sawa kutengeneza jwts mbili, funguo ya faragha inaweza kurejeshwa.
Here is a example: ECDSA: Kufichua funguo ya faragha, ikiwa nonce sawa inatumika (na SECP256k1)
The JTI (JWT ID) claim provides a unique identifier for a JWT Token. It can be used to prevent the token from being replayed. However, imagine a situation where the maximun length of the ID is 4 (0001-9999). The request 0001 and 10001 are going to use the same ID. So if the backend is incrementig the ID on each request you could abuse this to replay a request (needing to send 10000 request between each successful replay).
Cross-service Relay Attacks
Imekuwa ikionekana kwamba baadhi ya programu za wavuti zinategemea huduma ya JWT iliyoaminika kwa ajili ya kutengeneza na kusimamia token zao. Matukio yameandikwa ambapo token, iliyotengenezwa kwa mteja mmoja na huduma ya JWT, ilikubaliwa na mteja mwingine wa huduma hiyo hiyo ya JWT. Ikiwa utoaji au upya wa JWT kupitia huduma ya mtu wa tatu unashuhudiwa, uwezekano wa kujiandikisha kwa akaunti kwenye mteja mwingine wa huduma hiyo kwa kutumia jina la mtumiaji/barua pepe sawa unapaswa kuchunguzwa. Jaribio linapaswa kufanywa kujaribu token iliyopatikana katika ombi kwa lengo ili kuona ikiwa inakubaliwa.
Tatizo muhimu linaweza kuonyeshwa na kukubaliwa kwa token yako, ambayo inaweza kuruhusu udanganyifu wa akaunti ya mtumiaji yeyote. Hata hivyo, inapaswa kuzingatiwa kwamba ruhusa ya majaribio mapana inaweza kuhitajika ikiwa kujiandikisha kwenye programu ya mtu wa tatu, kwani hii inaweza kuingia katika eneo la sheria lenye kivuli.
Expiry Check of Tokens
The token's expiry is checked using the "exp" Payload claim. Given that JWTs are often employed without session information, careful handling is required. In many instances, capturing and replaying another user's JWT could enable impersonation of that user. The JWT RFC recommends mitigating JWT replay attacks by utilizing the "exp" claim to set an expiry time for the token. Furthermore, the implementation of relevant checks by the application to ensure the processing of this value and the rejection of expired tokens is crucial. If the token includes an "exp" claim and testing time limits allow, storing the token and replaying it after the expiry time has passed is advised. The content of the token, including timestamp parsing and expiry checking (timestamp in UTC), can be read using the jwt_tool's -R flag.
A security risk may be present if the application still validates the token, as it may imply that the token could never expire.
If you are interested in hacking career and hack the unhackable - we are hiring! (fluent polish written and spoken required).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
