V minulém příspěvku jsme prošli úvodem do testování vstupů webových aplikací. Dnes půjdeme o něco dál, protestujeme scénář přihlášení v aplikaci WABANK a najdeme chybu ve validaci vstupů pro konstrukci SQL dotazu.

Testovací scénář

Protestujeme jeden vstupní bod „username“ v přihlášovacím formuláři do online bankovnictví. Použijeme k tomu webovou aplikaci WABANK, která je dostatečně naivní a děravá. Zranitelná aplikace WABANK je k dispozici zdarma.

Příprava nástrojů

Před testováním si připravíme arzenál nástrojů. Jako operační systém zvolíme Kali linux.

Testovací web proxy

K testování budeme potřebovat testovací webovou proxy Burp Suite. Burp je komerční nástroj, ale je dostupný ve „Free edici“ s omezenou funkcionalitou.

Webový prohlížeč

Bez webového prohlížeče se nehneme z místa. Můžeme použít jakýkoliv prohlížeč, ale je potřeba jej nastavit, aby odesílal data přes testovací webovou proxy. Následující stránka vás provede nastavením prohlížeče pro komunikaci s HTTP proxy Burp Suite.

Slovník

Webovou aplikace budeme testovat pomocí slovníku, který obsahuje testovací vstupy pro detekci více zranitelností.

Testovací slovník nesmí být moc velký, ideálně kolem 500 záznamů. Jak ale takový slovník sestavit? A podle jakých kritérií? Můžeme sbírat moudra z průvodce OWASP Testing Guide v kapitole Input Validation Testing, nebo jednoduše vyhledat existující slovníky penetračních testerů.

Jeden takový projekt s databází vstupů se jmenuje fuzzdb a najdeme jej na GitHubu. Otevřeme si terminál, vytvoříme si pracovní adresář /pentest/wabank.

Pro stažení projektu fuzzdb potřebujeme git klienta, případně použijeme webový prohlížeč a najdeme zip archiv projektu.

Testování z pohledu uživatele

Pokud máme vše připraveno, spustíme Burp Suite, webový prohlížeč a navštívíme webovou stránku aplikace WABANK. V úvodu jsme zmínili, že budeme testovat přihlášení uživatele do online bankovnictví a tak si to rovnou vyzkoušíme.

Pochopení funkcionality

Přihlášení prověříme nejdříve z pohledu běžného uživatele. To nám umožní pochopit akce, očekávané vstupy a identifikovat chybová hlášení. Všímáme si také toho, jak vypadají URL adresy mezi přechody z jedné stránky na druhou. Toto porozumění je pro testera zásadní, protože zvyšuje šance na objevení chyby.

Správné provolání

Přihlásíme se nejdříve jako legitimní uživatel admin s heslem pass123, abychom měli jistotu, že jsme schopni funkcionalitu správně provolat. To nám později umožní rozeznat neúspěšná volání.

Jak asi tušíte, neúspěšné přihlášení lze různě nakombinovat. Můžeme formulář odeslat pouze s názvem účtu bez hesla, heslo bez názvu účtu, nebo odeslat prázdný formulář. Během uživatelských testů se snažíme zaregistrovat i nepatrné rozdíly, zejména chybové hlášky a přesměrování.

Testování s webovou proxy

V této části se seznámíme s třemi moduly nástroje Burp Suite:

  • Proxy,
  • Repeater
  • Intruder.

Začneme tím, že nastartujeme nástroj Burp Suite.

Proxy – Intercept

Po startu Burp Suite musíme vypnout funkci „Intercept“, která nás nutí manuálně potvrzovat každý HTTP požadavek.

Tuto funkci najdeme na záložce Proxy a v druhé řadě zvolíme záložku Intercept. Zde je potřeba kliknout na tlačítko „Intercept is on“. Popisek tlačítka se následně změní na „Intercept is off“.

Ve free edici Burpu je to jedna z otravných věcí, která nejde přenastavit. Nyní se přesuneme na druhou záložku HTTP history.

Proxy – HTTP history

Pokud jsme správně nastavili webový prohlížeč proti webové proxy Burp Suite, uvidíme na této záložce všechny HTTP požadavky, které náš webový prohlížeč zaslal. Pro jistotu zopakujeme ve webovém prohlížeči pár neúspěšných přihlášení do aplikace WABANK.

Vrátíme se zpět do záložky Proxy -> HTTP history a vybereme si jeden požadavek levým tlačítkem myši. Objeví se nám oranžový pruh a v dolním panelu najdeme detail HTTP požadavku.

Nyní lze aktivovaný záznam (HTTP požadavek) odeslat přes pravé tlačítko myši do modulu Repeater pomocí kontextové volby „Send to Repeater“.

Repeater modul

Tento modul nalezneme na záložce Repeater a jak jeho název napovídá, slouží k opakovanému odesílání HTTP požadavku. Požadavek je možné před odesláním jakkoliv upravit. Po stisku tlačítka „Go“ můžeme v pravém panelu vidět výsledek HTTP odpovědi.

Na výše uvedené obrazovce vidíme pokus o přihlášení uživatele hacker s prázdným heslem. Napravo je HTTP odpověď s chybovým hlášením „incorrect login or password“. Nyní se seznámíme s modulem Intruder.

Intruder modul

Podobně jako v předchozím případě můžeme jakýkoliv označený HTTP požadavek poslat do modulu Intruderu pomocí pravého kliku myši a volby „Send to Intruder“.

Modul Intruder slouží k automatizaci testování a nabízí spoustu možností pro generování a umístění dat v HTTP požadavcích. My si ukážeme pouze jednu variantu, použití slovníku jako zdroje vstupních dat.

Intruder – Positions

Nejdříve musíme na záložce Positions určit místo v HTTP požadavku, které chceme měnit. Modul Intruder nám automaticky označí potencionální vstupní body oranžovým podbarvením, ale my použijeme tlačítko „Clear“ a jeho doporučení ignorujeme.

Přesuneme pozornost do těla HTTP zprávy. Poslední řádek HTTP požadavku obsahuje pole z přihlašovacího formuláře. Poznáváme zde parametr username, který reprezentuje název účtu a za rovnítkem následuje jeho hodnota. Tuto hodnotu budeme chtít měnit v každém požadavku a tak ji označíme kurzorem a stiskneme tlačítko „Add„. Označená pozice se obalí dvěma paragrafy, jak je vidět na níže uvedeném snímku obrazovky.

Všimněte si, že ponecháváme volbu „Attack type“ na hodnotu „Sniper“. Toto nastavení je vhodné, pokud chceme sekvenčně posílat testovací data na každou zafixovanou pozici. Nyní zbývá definovat, jak má dávkování dat vypadat. Tuto konfiguraci nastavíme na záložce „Payloads“.

Intruder – Payloads

Na záložce Payloads definujeme testovací data, která chceme doručit na zafixovanou pozici, kterou jsme stanovili v minulém kroku.

V první sekci „Payload Sets“ nastavíme „Payload type“ na „Simple list„. Tímto říkáme, že se data budou plnit ze slovníku. V druhé sekci  „Payloads options“ definujeme obsah slovníku.

Stiskneme tlačítko „Load“ a vybereme soubor all-attacks-win.txt, který se nachází v adresáři /pentest/wabank/fuzzdb/attack/all-attacks.

Payload – přívěšek

Payload doslova znamená placený náklad. V terminologii IT bezpečnosti se tím myslí škodlivý kód, který je součástí přenášených dat a po doručení způsobí neplechu. Doslovný překlad připomíná éru těžkého průmyslu a budí úsměv. Nezbývá, než se držet anglického slova payload nebo najít významově blízký překlad.

Na školeních používám slovo přívěšek. Stejně jako když na kroužek zavěsíte škodlivý klíč a poprosíte někoho, aby jej s kroužkem přenesl a zasunul do zámku. V kontextu webových aplikací je nositelem vždy HTTP požadavek a přívěškem je sekvence dat, pomocí které útočník v aplikaci způsobí destrukci, obejde bezpečnostní mechanizmus nebo získá nějakou výhodu.

Intruder – spouštíme útok

Nyní máme vše připraveno a můžeme spustit v Intruderu útok tlačítkem „Start attack„, které najdeme v pravém horním rohu. Po stisku tlačítka na nás vyskočí okno s titulkem „Intruder attack“. To je instance útoku na základě předchozí konfigurace.

Jak ukazuje následující snímek, Intruder s každým vyslaným HTTP požadavkem mění přívěšek dle definovaného slovníku.


Na jednom testu (#25) s přívěškem %00 se zastavíme. Při analýze jeho HTTP odpovědi vidíme chybu, která evidentně probublala přímo z databáze SQLite3. Máme tady podezření na chybu SQL injektáže. Pošleme tento konkrétní požadavek zpět do modulu Repeater.

Exploitace zranitelnosti

Uživatelský vstup username je bez validace. Data zaslaná na tento vstup jsou součástí SQL dotazu, který se posílá do databáze. Nyní musíme přijít na to, jak se SQL dotaz skládá a zda lze objevenou slabinu zneužít.

Analýza struktury SQL dotazu

V Repeatru budeme postupně zkoušet nové vstupy pro pole username. Zvolíme si nové uživatelské jméno, například hacker, a doplníme jej o znak apostrofu. Znak apostrof by měl rozbít integritu SQL dotazu a zobrazit další chybu. S očekáváním pošleme dotaz do aplikace tlačítkem „Go“.

V odpovědi vidíme varovnou zprávu s částí SQL příkazu ‚hacker‘‚ AND pass=“ LIMIT 1.
Kdo zná jazyk SQL tak ví, že je to zbytek podmínky dotazu, která se nachází v klauzuli WHERE. Tato klauzule filtruje záznamy, které vstupují jako zdroje dat do výsledkové sady.

Odhadujeme chování aplikace

Z chybových hlášení zjišťujeme, že aplikace sestrojí SQL dotaz, který reprezentuje operaci najdi uživatele s daným jménem a heslem. Následně tento dotaz pošle do databáze a zkoumá výsledkovou sadu dat z SQL dotazu. Pokud výsledková sada obsahuje alespoň jeden záznam, aplikace uživatele autentizuje. Když se nenajde žádný záznam, přihlášení je zamítnuto.

To ale znamená, že pokud ovlivníme SQL dotaz tak, aby vrátil alespoň jeden řádek, projdeme autentizací.

Modifikace SQL dotazu

Dobře, takže vstupním parametrem username přímo ovlivňujeme SQL dotaz v klauzuli WHERE. Aplikace za vstupní hodnotu ještě přidá zbylou část podmínky (AND pass=“), která má ověřit heslo uživatele.

Vnucuje se myšlenka propašovat do SQL dotazu komentář, který by zakomentoval celou pravou část SQL dotazu a vyřadil tak podmínku (AND pass=“). Pak bychom skutečně kontrolovali exekuci SQL dotazu. Náš vstup pro pole username bude vypadat takto.

Po odeslání požadavku tlačítkem „Go“ již nevidíme SQL chybu, ale stále nejsme přihlášeni. Projdeme HTML zdrojový kód odpovědi, zda nenajdeme vysvětlení.

Evidentně v databázi neexistuje uživatel hacker a tak podmínku doplníme o výraz OR 1=1, aby byla podmínka vždy splněna.

Pojdmě test zopakovat, odešleme znovu modifikovaný HTTP požadavek tlačítkem „Go“.

To už vypadá dobře, dostali jsme HTTP odpověď 302 s přesměrováním na stránku /wba/user/account.

Pokud si výslednou odpověď zobrazíme v prohlížeči pomocí kontextové volby „Show Response in browser“, vidíme, že jsme přihlášeni jako uživatel admin. To zní skvěle.

Úspěšná exploitace a co dál

Tímto zábava teprve začíná a měli bychom hledat všechny možné důsledky této chyby. Můžeme se pokusit vytáhnout všechna data z databáze. Můžeme se zcela určitě přihlašovat pod různými uživateli a zjišťovat stav jejich bankovních účtů.

Závěr

V dnešním příspěvku jsme se seznámili s webovou proxy Burp Suite a našli zranitelnost SQL injektáže ve webové aplikaci WABANK. Použili jsme také kompaktní slovník z projektu fuzzdb.

Na závěr mám pro vás testovací kvíz. Zkuste si sami upravit vstup tak, abyste postupně získali identitu dalších uživatelů. Prozradím, že atribut „id“ rozlišuje unikátní uživatele. Ti otrlejší z vás, co zvládnou instalaci aplikace WABANK, mohou testovat přímo. Posílejte vaše tipy ve formě komentářů na náš facebook.

To je pro dnešek vše. Zvažujete-li cestu etického hackera, vyzkoušejte školu pro začínající etické hackery.