Penetrační testy: Denial of Service

Cílem DoS a DDoS útoků je dosažení odepření služby oprávněnému uživateli. Tyto útoky mohou být směřovány na infrastrukturu, systém nebo samotnou aplikaci.

Útoky na samotnou infrastrukturu, a operační systémy bývají nejméně časté, neboť ty zpravidla bývají dobře chráněny, a navíc lze tyto útoky relativně snadno odhalit, protože v zásadě fungují stejně. Jejich cílem je otevřít co největší počet spojení, tím vyčerpat buffer a zamezit legitimnímu připojení (SYN flood attack), nebo zaslat paket o velikosti větší než 65536 bytů (Ping of death attack) či změnit offset v hlavičce IP socketu, se kterou se systém nedokáže vypořádat (Teardrop attack). Posledním typem z výčtu možných útoků je např. Slowloris, který je cílen na aplikační vrstvu a produkuje v podstatě legitimní http provoz. I zde je ochrana poměrně jednoduchá, neboť spočívá v omezení počtu požadavků z jedné IP adresy.

Pokud je útok veden z jednoho počítače, pak hovoříme o DoS útoku (Denial of Service), pokud je útok veden z více počítačů, hovoříme o DDoS (Distributed Denial of Service). Nedostupnost webové aplikace se může z pohledu uživatele projevit třemi rozdílnými způsoby. Po zadání adresy spojení tzv. vytimeoutuje nebo se spojení naváže, ale nejsou dostupná data či daná služba. Posledním případem pak je, že uživateli se nepovede do aplikace přihlásit. Dále se v rámci bezpečnosti webových aplikací zaměříme pouze na DoS útoky, které jsou vedeny na samotnou aplikaci. Přičemž z pohledu aplikace se jedná o „běžné akce“ uživatele.

SQL Wildcard Attacks

Cílem útočníka je položit takový dotaz, který zatíží DB server natolik, že aplikace nebude schopna vracet odpovědi ani na jednoduché dotazy. Pozor, nejedná se o SQL injection, ale o zneužití podpory tzv. wildcards (speciálních znaků) např. v souvislosti s klíčovým slovem LIKE u MS SQL serveru. Útočník využívá pouze formulářového pole aplikace umožňujícího zadat řetězec, který se má vyhledávat. Pokud do vyhledávacího pole zadáte např. řetězec %_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_% a odpověď serveru se prodlužuje, je zřejmé, že aplikace trpí danou zranitelností.

Při testování aplikací na náchylnost vůči SQL Wildcards Attacks je vhodné použít více různých řetězců a ověřit doby odezvy aplikace, např. ve spolupráci se správcem daného web serveru s přístupem k logům. Klíčovým výstupem takového testu by mělo být odhalení příčin neúměrně vysokých odezev.

Locking customer accounts

V praxi se nejen u webových aplikací běžně využívá funkcionalita uzamčení uživatelského účtu po určitém počtu neúspěšných pokusů o zadání hesla. Cílem útočníka tedy je zablokovat účet, aby se oprávněný uživatel nemohl do aplikace přihlásit. To útočník logicky provede tak, že úmyslně opakovaně zadá chybné heslo. Základním předpokladem tohoto útoku tedy je, že útočník musí znát uživatelské jméno. Ke zjištění validních uživatelských jmen do aplikace bývají v praxi zneužívány např. formuláře pro resetování hesla nebo jiné nevhodně navržené formuláře aplikace, které rozdílným způsobem reagují na zadání existujícího a neexistujícího loginu, případně obsahují jiné nevhodné (útočníkem zneužitelné) informace. Pokusit se zjistit zda zadané jméno existuje, se útočník může i na stránkách registrace, kde si nový uživatel své jméno volí..

Buffer overflows

Přetečení paměti (buffer overflow) může být trojího typu heap overflow, stack overflow a format string. Dojít k němu nemůže, pokud byl při vývoje aplikace použit tzv. managed jazyk, jako např. ASP.NET nebo PHP. Pokud jsou ale i v rámci těchto aplikací využívány např. externí komponenty naprogramované v některém z jazyků (např. CGI moduly v C/C++), kde je odpovědnost za správnou alokaci paměti na vývojáři a pokud ten udělal chybu, je možné vložit do pole např. řetězec, jehož délka bude větší než předpokládaná, což způsobí pád aplikace. U webových aplikací se ale dnes s touto chybou prakticky nesetkáme.

V případě heap overflow dojde k přepsání oblasti paměti, která uchovává velikost dynamicky alokované paměti a při pokusu o uvolnění paměti pravděpodobně dojde k Segmentation fault. V případě stack overflow dochází k zápisu za hranice staticky alokovaného pole. Z tohoto důvodu (stejně jako v předchozím případě) se doporučuje při programování v jazycích C/C++ používání bezpečných příkazů, jako je např. strncpy. V případě format string např. při využití jazyka C může být tato zranitelnost napadena za podmínky, že není použit formátovací řetězec s následným pokusem vypsat sekvenci %x následovanou sekvencí %n.

User specified object allocation

Útočník využívá skutečnosti, že aplikace umožňuje uživateli vytvářet objekty, kterými může být např. zboží v nákupním košíku. Pokud neprobíhá kontrola na maximální počet položek v košíku, může dojít k vyčerpání paměti aplikačního serveru alokováním příliš velkého počtu objektů. V praxi se jedná o další zneužití dlouhé řady vývojářských chyb spočívajících v nedostatečném ošetření vstupů aplikace.

User input as a loop counter

Pokud je vstup od uživatele použit jako čítač cyklu, potom hrozí, že špatně napsaná aplikace, která nebude mít shora omezený počet cyklů, může být tímto způsobem donucena k opakování určité operace. Důsledkem velkého počtu opakování dané operace může dojít k vytížení CPU aplikačního serveru. Typickými vstupními branami, které umožňují zneužití této zranitelnosti, jsou textová pole, kam se zadávají číselné hodnoty nebo skrytá pole. Pokud se zvyšující se hodnotou cyklu vzrůstá doba odezvy, je vysoce pravděpodobné, že daná aplikace je na tuto zranitelnost náchylná.

Writing user provided data to disk

Útočník využívá skutečnosti, že server z nejrůznějších důvodů provádí zápis uživatelem poskytnutých dat na disk, např. za účelem analýzy apod., takže i když se nezpracovávají a nezapisují do DB, tak se zapisují do aplikačního logu. Útok je tedy opět zaměřený na vyčerpání zdrojů. A je v podstatě jedno, jak velké soubory má uživatel aplikace možnost do ní ukládat.

V případě, že není např. správně navržena logika logování, např. není vyhrazen samostatný oddíl pro logovací záznamy a není zvolena vhodná souslednost logovacích záznamů, může dojít k vyčerpání diskového prostoru serveru. Nemusí se ale jednat pouze o logy. V podstatě kdykoliv, když má uživatel aplikace možnost přímo nebo nepřímo cokoliv na server uložit, může vyčerpání diskového prostoru nastat.

Zranitelnost tohoto typu je v rámci penetračních testů často velice těžké a hlavně časově náročné odhalit. Pomocí automatizovaných skenů je třeba vhodně odhadnout danou aplikaci a vhodně nastavit nástroje (nejčastěji speciální skripty). Při manuálních testech se jedná o téměř neproveditelný úkol. Pro efektivní odhalení těchto zranitelností musí mít tester dostatečně podrobnou znalost testované aplikace nebo může např. vycházet přímo z analýzy jejího kódu.

Failure to release resources

Útočník využívá skutečnosti, že na serveru dochází k chybnému uvolňování prostředků. Může se jednat o soubory, paměť, databázové objekty atd. Pokud je soubor aplikací otevřen, je následně uzamknut pro ostatní. Není-li po ukončení práce uvolněn, tak nemůže být jinou aplikací použit, zároveň aplikace může mít otevřen jenom určitý počet souborů a v případě, že nejsou uvolňovány, můžeme takříkajíc narazit na maximální hodnotu otevřených deskriptorů. Chybné uvolnění prostředků může nastat např., pokud je vyvolána výjimka a nejsou v ní řádně uvolněny všechny prostředky.

Chybné uvolňování paměti je dominantou především u aplikací vytvořených v C/C++, kde programátor má plnou kontrolu nad správou paměti. Chybné uvolňování databázových objektů principiálně odpovídá chybnému uvolňování souborů. Může dojít k otevření max. počtu spojení a další již nelze navázat. Nalezení zranitelností souvisejících s chybným uvolňováním prostředků není v rámci penetračních testů jednoduché. Testům zaměřeným tímto směrem je třeba věnovat poměrně hodně času, v ideálním případě by měl mít tester k dispozici SNMP nebo přístup k souborovému systému serveru.

Storing too much data in session

Session představuje mechanismus pro uchování stavu v HTTP protokolu. Jednou z možností jak uchování stavu dosáhnout jsou tzv. cookie, které jsou předávány v HTTP hlavičce. Cílem tohoto typu útoku je tedy zahltiti server prostřednictvím velkého množství dat uložených v session. Ukládání velkého množství dat v session může nastat např., když má uživatel možnost nějakým způsobem data v session ovlivňovat. Aplikace má problém o to horší, pokud umožňuje podobnou operaci i nepřihlášených uživatelům.

Z pohledu penetračního testera tento typ zranitelnosti patří také k obtížněji testovatelným. Nalézáme je většinou u webových aplikací, které zobrazují velké množství záznamů. Pro testování je zpravidla třeba mít vhodný automatizovaný skript, který vytváří velké množství session, a mít přístup k datům SNMP pro monitorování aktivit serveru.

Závěr: Současně s tím, jak se DoS a DDoS útoky vyvíjejí a v praxi stále častěji vyskytují, setkáváme se častěji i s požadavky na prověření odolnosti aplikací vůči nim. Z pohledu útočníka jsou DoS útoky a zejména DDoS útoky poměrně účinnou zbraní. Z pohledu penetračního testera je nalezení některých zranitelností docela tvrdým oříškem. Z pohledu businessu dané organizace, která aplikaci provozuje, zase mohou úspěšné DoS a DDoS útoky znamenat velké negativní dopady a tedy i velké riziko.

V rámci obrany aplikace vůči různým typům těchto útoků je třeba pamatovat na bezpečnost v rámci celého SDLC, protože čím později je bezpečnostní slabina odhalena, tím nákladnější je pak její odstranění. Asi největší část práce třeba odvést již u samotných programátorů, kteří by měli aplikaci vyvíjet v souladu s doporučeními bezpečného vývoje. Pokud se toto nepodaří a například penetrační testy nebo v horším případě samotná praxe ukážou, že aplikace DoS a DDoS útoky neustojí, pak již zpravidla nezbude, než toto řešit na dalších úrovních sítě, např. pomocí WAF nebo v rámci jiných aktivních síťových prvků.

Tento příspěvek vznikl ve spolupráci s firmu Cleverlance.

Štítky: penetrační testy

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.