JWT Vulnerabilities (Json Web Tokens)
Last updated
Last updated
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ako ste zainteresovani za hakera karijeru i da hakujete nehakovano - zapošljavamo! (potrebno je tečno pisanje i govorenje poljskog).
Deo ovog posta se zasniva na sjajnom postu: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology Autor sjajnog alata za pentesting JWT-ova https://github.com/ticarpi/jwt_tool
Pokrenite jwt_tool u režimu All Tests! i sačekajte zelene linije.
Ako imate sreće, alat će pronaći neki slučaj gde web aplikacija pogrešno proverava JWT:
Tada možete pretražiti zahtev u vašem proxy-ju ili izvući korišćeni JWT za taj zahtev koristeći jwt_ alat:
Možete takođe koristiti Burp Extension SignSaboteur za pokretanje JWT napada iz Burp-a.
Možete samo manipulisati podacima ostavljajući potpis nepromenjenim i proveriti da li server proverava potpis. Pokušajte da promenite svoje korisničko ime na "admin", na primer.
Da biste proverili da li se potpis JWT-a verifikuje:
Poruka o grešci sugeriše da je verifikacija u toku; osetljive detalje u opširnim greškama treba pregledati.
Promena na vraćenoj stranici takođe ukazuje na verifikaciju.
Nema promene sugeriše da nema verifikacije; tada treba eksperimentisati sa manipulacijom tvrdnjama u payload-u.
Važno je utvrditi da li je token generisan na strani servera ili klijenta pregledom istorije zahteva proksija.
Tokeni prvi put viđeni sa strane klijenta sugerišu da bi ključ mogao biti izložen klijentskom kodu, što zahteva dalju istragu.
Tokeni koji potiču sa strane servera ukazuju na siguran proces.
Proverite da li token traje više od 24h... možda nikada ne ističe. Ako postoji polje "exp", proverite da li server ispravno obrađuje to.
Postavite korišćeni algoritam na "None" i uklonite deo sa potpisom.
Koristite Burp ekstenziju pod nazivom "JSON Web Token" da biste isprobali ovu ranjivost i promenili različite vrednosti unutar JWT-a (pošaljite zahtev u Repeater i na kartici "JSON Web Token" možete modifikovati vrednosti tokena. Takođe možete odabrati da postavite vrednost polja "Alg" na "None").
Algoritam HS256 koristi tajni ključ za potpisivanje i verifikaciju svake poruke. Algoritam RS256 koristi privatni ključ za potpisivanje poruke i koristi javni ključ za autentifikaciju.
Ako promenite algoritam sa RS256 na HS256, kod na backend-u koristi javni ključ kao tajni ključ i zatim koristi HS256 algoritam za verifikaciju potpisa.
Zatim, koristeći javni ključ i menjajući RS256 u HS256 mogli bismo kreirati validan potpis. Možete preuzeti sertifikat web servera izvršavajući ovo:
Napadač ugrađuje novi ključ u zaglavlje tokena, a server koristi ovaj novi ključ za verifikaciju potpisa (CVE-2018-0114).
Ovo se može uraditi sa "JSON Web Tokens" Burp ekstenzijom. (Pošaljite zahtev u Repeater, unutar taba JSON Web Token izaberite "CVE-2018-0114" i pošaljite zahtev).
Uputstva detaljno opisuju metodu za procenu bezbednosti JWT tokena, posebno onih koji koriste "jku" zaglavlje. Ovo zaglavlje bi trebalo da se povezuje sa JWKS (JSON Web Key Set) datotekom koja sadrži javni ključ neophodan za verifikaciju tokena.
Procena Tokena sa "jku" Zaglavljem:
Proverite URL "jku" tvrdnje da biste osigurali da vodi do odgovarajuće JWKS datoteke.
Izmenite "jku" vrednost tokena da biste usmerili ka kontrolisanoj veb usluzi, omogućavajući posmatranje saobraćaja.
Praćenje HTTP Interakcije:
Posmatranje HTTP zahteva ka vašem specificiranom URL-u ukazuje na pokušaje servera da preuzme ključeve sa vašeg pruženog linka.
Kada koristite jwt_tool za ovaj proces, ključno je ažurirati jwtconf.ini datoteku sa vašom ličnom JWKS lokacijom kako bi se olakšalo testiranje.
Komanda za jwt_tool:
Izvršite sledeću komandu da simulirate scenario sa jwt_tool:
Opcionalna zaglavna tvrdnja poznata kao kid koristi se za identifikaciju specifičnog ključa, što postaje posebno važno u okruženjima gde postoji više ključeva za verifikaciju potpisa tokena. Ova tvrdnja pomaže u odabiru odgovarajućeg ključa za verifikaciju potpisa tokena.
Kada je kid tvrdnja prisutna u zaglavlju, preporučuje se pretraživanje veb direktorijuma za odgovarajuću datoteku ili njene varijacije. Na primer, ako je "kid":"key/12345" specificirano, datoteke /key/12345 i /key/12345.pem treba pretražiti u veb korenu.
kid tvrdnja se takođe može iskoristiti za navigaciju kroz fajl sistem, potencijalno omogućavajući izbor proizvoljne datoteke. Moguće je testirati povezanost ili izvršiti Server-Side Request Forgery (SSRF) napade menjajući kid vrednost kako bi se ciljali specifični fajlovi ili usluge. Manipulacija JWT-om da se promeni kid vrednost dok se zadržava originalni potpis može se postići korišćenjem -T oznake u jwt_tool, kao što je prikazano u nastavku:
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.
A scenario where the kid parameter specifies a file path used within a command execution context could lead to Remote Code Execution (RCE) vulnerabilities. By injecting commands into the kid parameter, it's possible to expose private keys. An example payload for achieving RCE and key exposure is:
/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&
jku stands for 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.
Zatim možete koristiti na primer jwt.io da kreirate novi JWT sa kreiranim javnim i privatnim ključevima i usmerite parametar jku na kreirani sertifikat. Da biste kreirali validan jku sertifikat, možete preuzeti originalni i promeniti potrebne parametre.
Možete dobiti parametre "e" i "n" iz javnog sertifikata koristeći:
X.509 URL. URI koji pokazuje na skup X.509 (standard formata sertifikata) javnih sertifikata kodiranih u PEM formatu. Prvi sertifikat u skupu mora biti onaj koji se koristi za potpisivanje ovog JWT-a. Sledeći sertifikati svaki potpisuju prethodni, čime se završava lanac sertifikata. X.509 je definisan u RFC 52807. Transportna sigurnost je potrebna za prenos sertifikata.
Pokušajte da promenite ovaj header u URL pod vašom kontrolom i proverite da li je primljena neka zahtev. U tom slučaju, mogli biste da manipulišete JWT-om.
Da biste falsifikovali novi token koristeći sertifikat koji kontrolišete, potrebno je da kreirate sertifikat i izdvojite javne i privatne ključeve:
Zatim možete koristiti na primer jwt.io da kreirate novi JWT sa kreiranim javnim i privatnim ključevima i usmerite parametar x5u na sertifikat .crt koji je kreiran.
Takođe možete zloupotrebiti obe ove ranjivosti za SSRF.
Ovaj parametar može sadržati sertifikat u base64:
Ako napadač generiše samopotpisani sertifikat i kreira lažni token koristeći odgovarajući privatni ključ i zameni vrednost parametra "x5c" sa novokreiranim sertifikatom i modifikuje ostale parametre, naime n, e i x5t, tada bi suštinski lažni token bio prihvaćen od strane servera.
Ako JWT sadrži ugrađeni javni ključ kao u sledećem scenariju:
Koristeći sledeći nodejs skript, moguće je generisati javni ključ iz tih podataka:
Moguće je generisati novi privatni/javni ključ, ugraditi novi javni ključ unutar tokena i koristiti ga za generisanje novog potpisa:
Možete dobiti "n" i "e" koristeći ovaj nodejs skript:
Na kraju, koristeći javni i privatni ključ i nove "n" i "e" vrednosti, možete koristiti jwt.io da falsifikujete novi validan JWT sa bilo kojim informacijama.
Ako neke aplikacije koriste ES256 i koriste isti nonce za generisanje dva jwta, privatni ključ može biti obnovljen.
Evo jednog primera: ECDSA: Otkriće privatnog ključa, ako se koristi isti nonce (sa SECP256k1)
JTI (JWT ID) tvrdnja pruža jedinstveni identifikator za JWT token. Može se koristiti za sprečavanje ponovnog korišćenja tokena. Međutim, zamislite situaciju u kojoj je maksimalna dužina ID-a 4 (0001-9999). Zahtev 0001 i 10001 će koristiti isti ID. Dakle, ako backend povećava ID sa svakim zahtevom, mogli biste to iskoristiti da ponovno pošaljete zahtev (trebalo bi poslati 10000 zahteva između svake uspešne ponovne upotrebe).
Napadi međuslužbene relacije
Primećeno je da se neke web aplikacije oslanjaju na pouzdanu JWT uslugu za generisanje i upravljanje svojim tokenima. Zabeleženi su slučajevi kada je token, generisan za jednog klijenta od strane JWT usluge, prihvaćen od strane drugog klijenta iste JWT usluge. Ako se primeti izdavanje ili obnova JWT-a putem usluge treće strane, treba istražiti mogućnost registracije na račun drugog klijenta te usluge koristeći isto korisničko ime/email. Zatim bi trebalo pokušati ponovo poslati dobijeni token u zahtevu ka cilju da se vidi da li će biti prihvaćen.
Kritični problem može biti naznačen prihvatanjem vašeg tokena, potencijalno omogućavajući lažno predstavljanje bilo kog korisničkog računa. Međutim, treba napomenuti da bi mogla biti potrebna dozvola za šire testiranje ako se registrujete na aplikaciji treće strane, jer bi to moglo ući u pravnu sivu zonu.
Provera isteka tokena
Istek tokena se proverava korišćenjem "exp" Payload tvrdnje. S obzirom na to da se JWT-ovi često koriste bez informacija o sesiji, potrebna je pažljiva obrada. U mnogim slučajevima, hvatanje i ponovna upotreba JWT-a drugog korisnika moglo bi omogućiti lažno predstavljanje tog korisnika. JWT RFC preporučuje ublažavanje napada ponovnog korišćenja JWT-a korišćenjem "exp" tvrdnje za postavljanje vremena isteka za token. Pored toga, implementacija relevantnih provera od strane aplikacije kako bi se osiguralo procesuiranje ove vrednosti i odbijanje istečenih tokena je ključna. Ako token uključuje "exp" tvrdnju i vremenska ograničenja testiranja to dozvoljava, savetuje se čuvanje tokena i ponovna upotreba nakon što je vreme isteka prošlo. Sadržaj tokena, uključujući analizu vremenskih oznaka i proveru isteka (vremenska oznaka u UTC), može se pročitati korišćenjem -R opcije jwt_tool-a.
Bezbednosni rizik može postojati ako aplikacija i dalje validira token, jer to može implicirati da token nikada ne može isteći.
Ako ste zainteresovani za hacking karijeru i hakovanje nehakovanog - zapošljavamo! (potrebno je tečno pisano i govorno poljski).
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
