JWT Vulnerabilities (Json Web Tokens)
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
As jy belangstel in 'n hacking loopbaan en om die onhackbare te hack - ons is op soek na mense! (vloeiend Pools geskryf en gesproke vereis).
Deel van hierdie pos is gebaseer op die wonderlike pos: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology Skepper van die groot hulpmiddel om JWTs te pentest https://github.com/ticarpi/jwt_tool
Voer jwt_tool uit met die modus All Tests! en wag vir groen lyne
As jy gelukkig is, sal die hulpmiddel 'n geval vind waar die webtoepassing die JWT verkeerd nagaan:
Dan kan jy die versoek in jou proxy soek of die gebruikte JWT vir daardie versoek dump met jwt_ tool:
You can also use the Burp Extension SignSaboteur om JWT-aanvalle vanaf Burp te loods.
Jy kan net die data manipuleer terwyl jy die handtekening soos dit is laat en kyk of die bediener die handtekening nagaan. Probeer om jou gebruikersnaam na "admin" te verander byvoorbeeld.
Om te kyk of 'n JWT se handtekening geverifieer word:
'n Foutboodskap dui op voortgaande verifikasie; sensitiewe besonderhede in uitgebreide foute moet hersien word.
'n Verandering in die teruggegee bladsy dui ook op verifikasie.
Geen verandering dui op geen verifikasie nie; dit is wanneer om te eksperimenteer met die manipulasie van payload claims.
Dit is belangrik om te bepaal of die token bediener-kant of kliënt-kant gegenereer is deur die proxy se versoekgeskiedenis te ondersoek.
Tokens wat eers van die kliëntkant gesien word, dui aan dat die sleutel moontlik aan kliënt-kant kode blootgestel mag wees, wat verdere ondersoek vereis.
Tokens wat bediener-kant oorspronklik is, dui op 'n veilige proses.
Kyk of die token langer as 24h hou... dalk verval dit nooit. As daar 'n "exp" veld is, kyk of die bediener dit korrek hanteer.
Stel die algoritme wat gebruik word as "None" en verwyder die handtekeningdeel.
Gebruik die Burp-uitbreiding genaamd "JSON Web Token" om hierdie kwesbaarheid te probeer en om verskillende waardes binne die JWT te verander (stuur die versoek na Repeater en in die "JSON Web Token" oortjie kan jy die waardes van die token verander. Jy kan ook kies om die waarde van die "Alg" veld na "None" te plaas).
Die algoritme HS256 gebruik die geheime sleutel om elke boodskap te teken en te verifieer. Die algoritme RS256 gebruik die privaat sleutel om die boodskap te teken en gebruik die publieke sleutel vir verifikasie.
As jy die algoritme van RS256 na HS256 verander, gebruik die agterkant kode die publieke sleutel as die geheime sleutel en gebruik dan die HS256-algoritme om die handtekening te verifieer.
Dan, deur die publieke sleutel te gebruik en RS256 na HS256 te verander, kan ons 'n geldige handtekening skep. Jy kan die sertifikaat van die webbediener verkry deur dit uit te voer:
'n Aanvaller inkorporeer 'n nuwe sleutel in die kop van die token en die bediener gebruik hierdie nuwe sleutel om die handtekening te verifieer (CVE-2018-0114).
Dit kan gedoen word met die "JSON Web Tokens" Burp uitbreiding. (Stuur die versoek na die Repeater, binne die JSON Web Token oortjie kies "CVE-2018-0114" en stuur die versoek).
Die instruksies beskryf 'n metode om die sekuriteit van JWT tokens te evalueer, veral dié wat 'n "jku" kop eis. Hierdie eis moet skakel na 'n JWKS (JSON Web Key Set) lêer wat die publieke sleutel bevat wat nodig is vir die token se verifikasie.
Evalueer Tokens met "jku" Kop:
Verifieer die "jku" eis se URL om te verseker dat dit na die toepaslike JWKS lêer lei.
Wysig die token se "jku" waarde om na 'n beheerde webdiens te lei, wat verkeer waarneming moontlik maak.
Monitering vir HTTP Interaksie:
Waarneming van HTTP versoeke na jou gespesifiseerde URL dui op die bediener se pogings om sleutels van jou verskafde skakel te verkry.
Wanneer jwt_tool vir hierdie proses gebruik word, is dit noodsaaklik om die jwtconf.ini lêer met jou persoonlike JWKS ligging op te dateer om die toetsing te fasiliteer.
Opdrag vir jwt_tool:
Voer die volgende opdrag uit om die scenario met jwt_tool te simuleer:
'n Opsionele kop eis bekend as kid word gebruik om 'n spesifieke sleutel te identifiseer, wat veral belangrik word in omgewings waar verskeie sleutels bestaan vir token handtekening verifikasie. Hierdie eis help om die toepaslike sleutel te kies om 'n token se handtekening te verifieer.
Wanneer die kid eis in die kop teenwoordig is, word dit aanbeveel om die webgids te soek na die ooreenstemmende lêer of sy variasies. Byvoorbeeld, as "kid":"key/12345" gespesifiseer is, moet die lêers /key/12345 en /key/12345.pem in die web wortel gesoek word.
Die kid eis kan ook uitgebuit word om deur die lêerstelsel te navigeer, wat moontlik die keuse van 'n arbitrêre lêer toelaat. Dit is haalbaar om vir konnektiwiteit te toets of om Server-Side Request Forgery (SSRF) aanvalle uit te voer deur die kid waarde te verander om spesifieke lêers of dienste te teiken. Om die JWT te manipuleer om die kid waarde te verander terwyl die oorspronklike handtekening behou word, kan gedoen word met die -T vlag in jwt_tool, soos hieronder gedemonstreer:
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.
If the kid claim's content is employed to fetch a password from a database, an SQL injection could be facilitated by modifying the kid payload. An example payload that uses SQL injection to alter the JWT signing process includes:
non-existent-index' UNION SELECT 'ATTACKER';-- -
This alteration forces the use of a known secret key, ATTACKER, for JWT signing.
'n Scenario waar die kid parameter 'n lêerpad spesifiseer wat binne 'n opdrag-uitvoeringskonteks gebruik word, kan lei tot Remote Code Execution (RCE) kwesbaarhede. Deur opdragte in die kid parameter in te spuit, is dit moontlik om private sleutels bloot te stel. 'n Voorbeeldpayload om RCE en sleutelblootstelling te bereik is:
/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&
jku staan vir JWK Set URL. If the token uses a “jku” Header claim then check out the provided URL. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token. Tamper the token to point the jku value to a web service you can monitor traffic for.
First you need to create a new certificate with new private & public keys.
Dan kan jy byvoorbeeld jwt.io gebruik om die nuwe JWT te skep met die gecreëerde publieke en private sleutels en die parameter jku na die geskepte sertifikaat te wys. Om 'n geldige jku-sertifikaat te skep, kan jy die oorspronklike aflaai en die nodige parameters verander.
Jy kan die parameters "e" en "n" van 'n publieke sertifikaat verkry met:
X.509 URL. 'n URI wat na 'n stel X.509 (’n sertifikaatformaatstandaard) publieke sertifikate verwys wat in PEM-vorm gekodeer is. Die eerste sertifikaat in die stel moet die een wees wat gebruik word om hierdie JWT te teken. Die daaropvolgende sertifikate teken elk die vorige een, wat die sertifikaatketting voltooi. X.509 is gedefinieer in RFC 52807. Vervoersekuriteit is vereis om die sertifikate oor te dra.
Probeer om hierdie kop te verander na 'n URL onder jou beheer en kyk of enige versoek ontvang word. In daardie geval kan jy die JWT manipuleer.
Om 'n nuwe token te vervals met 'n sertifikaat wat deur jou beheer word, moet jy die sertifikaat skep en die publieke en private sleutels onttrek:
Then you can use for example jwt.io to create the new JWT with the gecreëerde publieke en private sleutels en die die parameter x5u na die .crt sertifikaat te wys.
You can also abuse both of these vulns vir SSRFs.
This parameter may contain the sertifikaat in base64:
If the attacker genereer 'n self-ondertekende sertifikaat and creates a forged token using the corresponding private key and replace the "x5c" parameter’s value with the newly generated sertifikaat and modifies the other parameters, namely n, e and x5t then essentially the forged token would get accepted by the server.
As die JWT 'n ingebedde publieke sleutel het soos in die volgende scenario:
Met behulp van die volgende nodejs-skrip is dit moontlik om 'n publieke sleutel uit daardie data te genereer:
Dit is moontlik om 'n nuwe privaat/openbare sleutel te genereer, die nuwe openbare sleutel in die token in te sluit en dit te gebruik om 'n nuwe handtekening te genereer:
U kan die "n" en "e" verkry met hierdie nodejs skrip:
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.
As sommige toepassings ES256 gebruik en dieselfde nonce gebruik om twee jwts te genereer, kan die private sleutel herstel word.
Here is a example: ECDSA: Onthulling van die private sleutel, as dieselfde nonce gebruik word (met SECP256k1)
Die JTI (JWT ID) eis bied 'n unieke identifiseerder vir 'n JWT-token. Dit kan gebruik word om te voorkom dat die token herhaal word. 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 Aanvalle
Dit is waargeneem dat sommige webtoepassings staatmaak op 'n vertroude JWT-diens vir die generasie en bestuur van hul tokens. Voorvalle is aangeteken waar 'n token, gegenereer vir een kliënt deur die JWT-diens, deur 'n ander kliënt van dieselfde JWT-diens aanvaar is. As die uitreiking of hernuwing van 'n JWT via 'n derdeparty-diens waargeneem word, moet die moontlikheid om 'n rekening op 'n ander kliënt van daardie diens aan te meld met dieselfde gebruikersnaam/e-pos ondersoek word. 'n Poging moet dan aangewend word om die verkregen token in 'n versoek aan die teiken te herhaal om te sien of dit aanvaar word.
'n Kritieke probleem mag aangedui word deur die aanvaarding van jou token, wat moontlik die nabootsing van enige gebruiker se rekening toelaat. Dit moet egter opgemerk word dat toestemming vir wyer toetsing benodig mag word as om aan te meld op 'n derdeparty-toepassing, aangesien dit 'n wettige grys gebied kan betree.
Vervaldatum Kontrole van Tokens
Die token se vervaldatum word nagegaan met behulp van die "exp" Payload eis. Gegewe dat JWTs dikwels sonder sessie-inligting gebruik word, is versigtige hantering nodig. In baie gevalle kan die vang en herhaling van 'n ander gebruiker se JWT die nabootsing van daardie gebruiker moontlik maak. Die JWT RFC beveel aan om JWT herhalingsaanvalle te verminder deur die "exp" eis te gebruik om 'n vervaldatum vir die token in te stel. Verder is die implementering van relevante kontroles deur die toepassing om te verseker dat hierdie waarde verwerk word en dat vervalde tokens verwerp word, van kardinale belang. As die token 'n "exp" eis insluit en toets tydsbeperkings dit toelaat, word dit aanbeveel om die token te stoor en dit na die vervaldatum te herhaal. Die inhoud van die token, insluitend tydstempel parsing en vervaldatum kontrole (tydstempel in UTC), kan gelees word met behulp van die jwt_tool se -R vlag.
'n Sekuriteitsrisiko mag teenwoordig wees as die toepassing steeds die token valideer, aangesien dit mag impliseer dat die token nooit kan verval nie.
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)
