Blažej Rypák • 12. prosince 2023

Generovanie HMAC tokenu v BurpSuite

Nasledujúci článok sa bude zaoberať problematikou generovania HMAC tokenov na základe klienta a možnými riešeniami, vrátane použitia nástrojov ako Puppeteer, Headless prehliadač a Burp Suite PyScripter-er pluginu. Táto problematika je relevantná pre situácie, kedy je potrebné generovať HMAC hlavičky pre každú HTTP požiadavku, pričom HMAC sa generuje z challenge a kľúča dynamicky na strane klienta.

V minulom článku sme si predstavili využitie pluginu Pyscripter-er na generovanie HMAC hlavičiek pri každej požiadavke. V tomto článku sa budeme zaoberať ešte komplexnejším scenárom, kde využijeme tento plugin v spojení s nástrojom Puppeteer a headless prehliadačom.

Motivácia

Predstavte si situáciu, kde pracujete s webovou službou (označme ju ako "X"), ktorá využíva SRP protokol (Secure Remote Password). Táto služba vyžaduje generovanie HMAC hlavičky z tela každej HTTP požiadavky, URL a hodnoty "challenge" pre REST API volania. Táto hodnota "challenge" sa generuje dynamicky na základe predchádzajúcej hodnoty a je súčasťou každej požiadavky.

SRP protokol

SRP alebo Secure Remote Password, je protokol vyvinutý s cieľom poskytnúť bezpečnú autentifikáciu medzi klientom a serverom na nezabezpečenej sieti, ako je napríklad internet. Jeho hlavným účelom je riešiť zraniteľnosti a riziká, ktoré súvisia s tradičnými metódami autentifikácie založenými na heslách. SRP je obzvlášť užitočný v situáciách, kde je potrebné zabezpečiť silnú, spoľahlivú autentifikáciu a odolať rôznym formám útokov, vrátane hádania hesiel, odpočúvania a útokov typu man-in-the-middle.

Klient SRP je komponent alebo softvérová aplikácia, ktorá iniciovala autentifikačný proces prostredníctvom SRP.

Viac o protokole SRP, ako funguje, sa môžte dočítať tu:http://srp.stanford.edu/design.html

Kľúčové výhody klienta SRP zahŕňajú:

Silná bezpečnosť: SRP poskytuje vysokú úroveň bezpečnosti tým, že chráni heslá pred odhalením v textovej podobe, aj keď útočník zachytí komunikáciu medzi klientom a serverom.
Odolnosť voči útokom: SRP je navrhnutý tak, aby odolal rôznym typom útokov, vrátane offline útokov s použitím slovníka, útokov hrubou silou a útokov typu man-in-the-middle.
Užívateľsky prívetivý: Z pohľadu používateľa je autentifikačný proces SRP podobný tradičnej autentifikácii pomocou používateľského mena a hesla, čo umožňuje jeho jednoduché prijatie bez potreby výrazných zmien v správaní používateľa.
Zabezpečená výmena kľúčov: Stanovením kľúča relácie medzi klientom a serverom sa zabezpečuje, že dáta vymieňané počas relácie zostávajú dôverné a nemôžu byť dešifrované odpočúvaním.

V závere môžeme povedať, že klient SRP je kľúčovou súčasťou protokolu Secure Remote Password, ktorý poskytuje spoľahlivý a bezpečný spôsob autentifikácie používateľov a chráni ich heslá pred odhalením. Ponúka robustné zabezpečenie a odolnosť voči rôznym formám útokov, čo ho robí cenným nástrojom pre zabezpečenú autentifikáciu v rôznych aplikáciách a systémoch.

Riešenie

Prvým nápadom na riešenie tejto úlohy bolo reverznúť "minifikovaný" JavaScript kód, ktorý generuje hodnotu "challenge" a kľúč, ktorý sa používa na šifrovanie HMAC hlavičky. Avšak táto cesta sa ukázala byť pomerne zložitá a časovo náročná.

Druhý nápad bol vytvoriť lokálny server (označme ho ako "Y"), ktorý by generoval hodnotu "challenge" na základe reverznutého JavaScript kódu a následne ju posielal na požiadavky z nástroja Burp Suite s použitím Pyscripter-er pluginu.

Riešenie s využitím Puppeteer a Headless prehliadača

Aby sme vyriešili problémy s CORS a zabezpečením, použili sme headless prehliadač ovládaný nástrojom Puppeteer.

Proces generovania HMAC tokenov bol nasledujúci:

Nastavili sme hlavičky pre Chromium pre ignorovanie CORS zabezpečenia pomocou parametra `--disable-web-security` a nastavili sme proxy server na Burp Suite pomocou parametra `--proxy-server=`.
Vytvorili sme objekt `InterceptorManager`, ktorý bol schopný zachytiť odpoveď na dotaz na konkrétny JavaScript súbor a vložiť do nej našu časť kódu pre odoslanie prvej hodnoty "challenge".
Automatizovali sme proces prihlásenia do služby X.

Lokálny server "Y" poskytoval dva endpointy:

/authHeader - ukladanie globálnej hodnoty "challenge".
/challenge - generovanie ďalšej hodnoty "challenge".

Okrem toho sme vytvorili ďalší lokálny server (označme ho ako "Z"), ktorý slúžil na generovanie výsledného tokenu HMAC. Toto bolo potrebné kvôli rozdielom v generovaní tokenu medzi Python verziou 2.7 (ktorú používa PyScripter-er) a Python verziou 3. Python3 automaticky používa unicode encoding.

Server "Z" mal jediný endpoint:

/get_token - na základe zadaného kľúča na šifrovanie a správy vrátil výsledný HMAC token/hash.

PyScripter-er Script

Skript v PyScripter-er pracoval nasledovne:

Získal novú hodnotu "challenge", kľúč a index z lokálneho servera "Y". Index sa automaticky po každom generovaní “challenge” zvýši o 1.
Vytvoril dáta na šifrovanie na základe reverznutej verzie JavaScript kódu.
Odošle tieto dáta spolu s kľúčom na lokálny server "Z", ktorý vrátil HMAC token/hash.
Nahradil predchádzajúcu hlavičku "Authorization" v pôvodnej HTTP požiadavke novou HMAC hlavičkou, ktorú sme vygenerovali.

Celý proces bol úspešne automatizovaný a umožnil nám generovať HMAC hlavičky pre každú požiadavku, pričom dynamicky generované hodnoty "challenge" a kľúča boli integrované do procesu.

Pre jednoduchšiu predstavu ako to celé funguje znázorňuje následný diagram: