WEB_SECURITY. David Sýkora. Phishing. Cryptography issues. Well known exploits. Bad configuration. Broken Auth. Injection CSRF.

Transkript

1 WEB_SECURITY David Sýkora Webové aplikace tvoří v dnešní době bránu do kyber prostoru, který se stává součastí všedního života téměř všech lidí a právě proto je potřeba se zamýšlet nad problematikou bezpečnosti této komunikace. Tento dokument by měl pomoci vyvojařům pochopit základní aspekty bezpečnosti a naučit je jak otestovat jejich kod. Phishing Well known exploits CSRF Session hijacking Cryptography issues Bad configuration Data leakage XSS Broken Auth Injection

2 Úvod do penetračního testování... 4 Co je penetrační testování?... 4 Proč bychom měli aplikace testovat?... 4 Etika... 4 Report... 4 Typy penetračních testů... 5 Metodiky testování... 6 Co to je metodika?... 6 OSSTMM... 6 OWASP... 7 ISSAF... 7 RSA... 7 Souhrn metodik... 8 Automatické nástroje... 9 Úvod... 9 V čem jsou automatické skennery dobré?... 9 V čem nejsou automatické skennery dobré?... 9 Hodnocení jednotlivých skennerů Injekce Úvod SQL Injection (SQLi) Command Injection Cross-site scripting (XSS) Úvod Persistent XSS (stored) Non-persistent XSS (reflected / DOM) Obrana Autentifikace a šifrování Úvod Útoky na autentifikaci... 15

3 Phishing Úvod Spear Phishing Detekce Prevence... 16

4 Úvod do penetračního testování Co je penetrační testování? Penetrační testování je způsob jak ověřit bezpečnost nějakého systému. Provádíme ho za účelem odhalit nedostatky v systému. Můžeme testovat aplikace, operační systémy i chování zaměstnanců. V tomto dokumentu se budem zabývat způsobem testování webových aplikací. Proč bychom měli aplikace testovat? Aplikaci testujeme za účelem předejít reálným bezpečnostním incidentům. Nahlížíme na aplikaci očima útočníka, který se snaží způsobit vývojářem nezamýšlené chování aplikace. Tímto předcházíme potencionální ztrátě financí, zákazníků nebo úniku citlivých údajů. Etika Když chceme aktivně testovat, vždy musíme mít nejen písemný souhlas vlastníka aplikace, ale také souhlasy všech lidí, kterých by se mohlo testování nějak dotknout. Tím myslím poskytovatele internetu, poskytovatele hostingových služeb, správce doménových jmen etc. Při testování provádíme úkony, které by pravěpodobně prováděl i útočník a tak je potřeba se nějak odlišit od lidí, kteři provádí trestní činnost. Musímě předpokládat, že by se situace obrátila proti nám a například by někdo podal trestní oznámení. Tester poté musí mít důkazy o legálnosti každého jeho úkonu. Před jakýmkoliv testem se musí stanovit jasné mantinely. Určí se čas, cíle testu (adresy, domény, y, osoby) a často i něco co vás odliší od ostatních při zpětném šetření (user-agent, IP, specifická hlavička HTTP etc.). Report Po skončení testu podáváme klientovi tzv. report, ve kterém ho seznamujeme s celkovou situací a v jednotlivých sekcích mu podáváme informace o jeho aplikaci. Rozdělení sekcí je čistě ponecháno na testerovi. Tester si může zvolit tzv. metodiku testování (popis metodik si ukážeme později) a ta má své vlastní rozdělení sekcí.

5 Každá oblast aplikace, která obsahuje tzv. vektor útoku, musí obsahovat stručný popis, jak by případný útočník mohl chybu využít, popsat potencionální následky zdařilého zneužití tohoto vektoru, dokázat přitomnost chyby (tzv. POC - Prove of Concept) a volitelně i nárys toho, jak by klient mohl tomuto zabránit. Report může mít libovolnou podobu (např. PDF, HTML, PPT, Word etc.). Je důležité klást důraz na přehlednost! Musíme také počítat s tím, že zadavatel testu pravěpodobně předá naší zprávu programatorům, kteří pomoci naší zpravý aplikaci postupně zabezpečí. Typy penetračních testů Penetrační testy se rozdělují na tři základní skupiny podle toho kolik informací klient poskytuje testerovi. Tímto můžeme simulovat jednotlivé scénáře. Black box Grey box White box Tester neví defakto nic jiného než adresu webového serveru a ke všemu ostatnímu se musí dostat sám. Nemá přístup ke kodu, nezná funkcionalitu jednotlivých kompenent a neví nic o prostředí běhu aplikace (webový server, HW, hosting etc.). Tento typ testů provádíme, jestliže klient chce aplikaci otestovat vůči útočníkovi, který nic z výše popsaných věcí nezná a takových útočníků bude pravěpodobně většina. Klient si tento typ testu může vyžádat, aby si ověřil, zda-li je jeho aplikace chráněna proti vnějším útočníkům. Tester je obeznámen s funkcionalitou komponent, ale neví, jaký je zdrojový kod. Tento typ testování se aplikuje, pokud chceme aplikaci otestovat proti útočníkům, kteří jsou obeznámeni funkcionalitou aplikace. Může jít o řadové zaměstnance firmy nebo také o útočníka, který se k informacím o aplikaci dostal přes chybu zaměstnance. Tester dostane informace o všem, o co si zažádá (hesla, zdrojové kody etc.). Tento typ testování se aplikuje, pokuď klient chce provést vnitřní audit aplikace a chce zamezit i takovým útokům, ke kterým by při black box testingu nemohlo logicky dojít a které vyžadují znalost zdrojového kodu. Tester prochází aplikaci soubor po souboru a hledá místa, které by se mohly stát vektorem útoku. Tester zároveň oveřuje vedlejší faktory, jako je dostatečná síla hesel, možnost přístupu zaměstnanců k údajům, které nepotřebují ke své činnosti etc.

6 * Metodiky testování Co to je metodika? Metodika testování je způsob přístupu k penetračnímu testování. Rozděluje ho do několika částí a říká nám, co bychom v jednotilvých částech měli dělat. Testování je pak systematičtejší a efektivnější. Metodika také často určuje samotnou filosofii PT tzn. jak by k němu měl tester přistupovat, co by mělo obsahovat etc. Níže ukážu jaké metodiky existují a popíšu jejich filosofii, popř. jejich klady a zapory. Nakonec vypracuji tabulku, kde jednotlivé metodiky ohodnotím. OSSTMM Open Source Security Testing Methodology Manual Metodika, která je určena pro testování firemní a vládní bezpečnosti. Je rozložena do šesti modulů. Určuje mezinárodní standart penetračního testování. Kategorizuje bezpečnosti do počitatelných kompenent. Rozděluje testy do šesti skupin: Metodika se zabývá bezpečností obecně a jijí filosofií. Testování webových aplikací tedy nepopisuje tak detailně jako ostatní metodiky.

7 OWASP Open Web Application Security Project Tato metodika vznikla na základě neziskové činnosti lidí, kteří se dlouhodobě snadží vylepšit bezpečnost na internetu. Dle mého názoru je jednoznačne nejobsáhlejší co se týče tématu webové bezpečnosti. OWASP Foundation pracuje na dvou typech projektů. Za prvé na vývojářských projektech, kde OWASP F figuruje jako vývojář a vyvíjí nástroje, které približují internet k jijich představě a za druhé projekty dokumentační, které se snaží dokumentovat bezpečnost (průvodce testováním webů, code snippets etc). Tato metodika má velkou výhodu v tom, že je jí možné vložit do jednotilivých fází SDLC. ISSAF Information Systems Security Assessment Framework Metodika strukturovaná do freamworku. Testování rozděluji do 9 kroků. Zaměřuje se na webové aplikace. RSA Metodika založená na urovni nebezpečí jednotlivých vektorů. Rozděluje je do pěti úrovní: Critical, High, Medium, Low a Informational. Úrovně jsou rozděleny podle bodů, které rozděluje metodika. Z mého pohledu je to nejlehčí a nejpřehlednější metodika, problém je, že na bezpečnost nahlíží pouze a jen ze stránky webových aplikací, což například OWASP nedělá.

8 Souhrn metodik Metodika penetračního testování Kroky při testování Výhody OSSTMM 6 kroků Mnoho různých testů OWASP 9 kroků Code snippets, Web Goat, DVWA, mnoho různých návodů ISSFS 9 kroků Jasný a pochopitelný postup při testování RSA 6 kroků Výhoda v bodování jednotlivých vektorů Všechny metodiky mají společné rysy, co se týče hlavního rozložení testu: Získávání informací V této části se metodiky zabývají získáváním informací o webovém serveru a aplikaci. Tato část zahrnuje průzkum Search enginů, průzkum DNS záznamů, identifikaci serveru a jeho infrastruktury etc. Průzkum funkcnionality Exploitace Tato část zahrnuje bližší prozkoumání fungování aplikace, což zahrnuje průzkum startovacích bodů aplikace, vztahy mezi jednotlivými komponentami, rozdělení rolí, způsob přihlašování etc. Nyní už tester má všechny potřebné informace a může začít testotovat jednotlivé komponenty jak po stránce technické tak po logické.

9 Automatické nástroje Úvod Při penetračním testování často provádíme úlohy, které lze provádět automaticky pomocí automatických testerů a tím zvýšit efektivitu celého testu. Je nutné si ale také uvědomit limity těchto nástrojů. Největším omezením je nepřizpusobivost konkretní aplikaci, to znamená, že programy jsou psané obecně pro všechny typy aplikací a nejsou schopny se přizpůsobit testované aplikační logice. V čem jsou automatické skennery dobré? mapováním struktury aplikace vyhledávání vstupů sběr a analýza dat ( y, citlivé údaje) detekování základních bezpečnostních rizik (XSS, CSRF, RFI,LFI etc.) rozpoznaní použitých knihoven, freamworků etc. V čem nejsou automatické skennery dobré? analýza logiky aplikace detekce složitějších rizik Obcházení Turingových testů

10 Hodnocení jednotlivých skennerů Název skenneru Přehledno st Licence Úspěšnost Platformy Použitelné reporty Acunetix 9 Komerční 9 Win Ano Nikto 5 Open Source 5 Cross platform Burp Suite Pro 6 Komerční 7 Cross platform Ano Arachni 10 Open Source 10 Cross platform Ano w3af 7 Open Source 8 Cross platform Vega 7 Open Source 6 Cross platform Wapiti 7 Open Source 6 Cross platform OWASP Zap 5 Open Source 7 Cross platform Podle tabulky výše vychází jednoznačně nejlepé projekt Arachni. Popíši Vám blíže to, jak funguje. Program je napsán v ruby a je možné ho spouštět přes přikazový řádek, webové rozhraní nebo REST API. Proces testování jsem rozdělil do 3 částí. 1. Nastavování skennu: 1. každé testování má vlastní název a popis (skenny jsou ukládány do DB) 2. každé testování užívá tzn. Profil, kterému definujeme: 1. název a popis 2. parametry testování (počet vláken, priorita na síti, která určuje rychlost přenosu dat) 3. oblasti testování (XSS, CSRF etc.) 4. ostatní (jaké údaje sbírat, jaké HTTP hlavičky používat) 2. Když spustíme sken dostáváme průběžně informace (čas, počet HTTP požadavků a zjištěné problémy) 3. Na konci skenner generuje výstup v mnoha podobách (PDF, HTML, CSV, TXT etc)

11 Injekce Úvod Injektace je jedna z nejzávažnějších bezpečnostních chyb. Základní princip injekcí je možnost provedení operace, která může poškodit aplikaci. Toto je provedeno pomoci vsunutí nebezpečného kodu do příkazu. Takto můžeme například získat nadvládu nad databází nebo spustit nebezpečný kod. SQL Injection (SQLi) Představme si webový blog, který obsahuje několik různých článků. Každý článek ma unikatní itentifikátor ID. Na hlavní stránce je seznam všech článků s odkazama ve tvaru: kde parametr ID určuje článek. Aplikace poté spustí SQL dotaz na databázi ve tvaru: SELECT nazev, obsah, autor FROM clanky WHERE ID = 1 a místo ID doplní hodnotu parametru z URL. Nyní si představte, že do hodnoty parametru dosadíme apostrof, který ukončíme otevřené uvozovky v SQL příkazu a dosadíme za ním například tento příkaz: UNION ALL SELECT nick, pass FROM admin Konečný příkaz bude tedy vypadat takto: SELECT nazev, obsah, autor FROM clanky WHERE ID = 1 UNION ALL SELECT nick, pass FROM admin Úspěšně jsme injektovali SQL dotaz a budou nám neservírovány údaje o adminovi včetně hesla. Problém tedy spočívá v apostrofu, který vyznačuje meze hodnoty paremetru v dotazu. Náchylnost aplikaci vůči SQLi testujeme tedy dosazením apostrofu do hodnot parametrů a sledujeme výstup. Rozlišujeme 3 druhy SQLi: 1. Inejkce s jasným výstupem, kde jsme schopni vypsat data z DB (Error based)

12 2. Injekce, která vevypisuje žádné data. Tím ale nebezpečí nezaniká. Utočník je schopen inejktovat boolean dotaz do SQL dotazu a postupne získat co potřebuje. Útočník rozeznává dva druhy výstupu: zobrazeno / nezobrazeno. Dotaz se tedy po injektaci apostrofu skládá ze dvou částí. První část vyzvedává data z DB o článku s určitým ID a druhá se ptá například na to jestli první znak adminova hesla je `a`. Pokud se stranka zobrazí a je skutečně první znak adminova hesla. Kdyby se nezobrazilo nic, znamenalo by to, že admin nemá první znak hesla `a` a útočník tedy přechází na písmeno `b`. Takto je schopen vydedukovat obsah celé DB. 3. Injekce, u kterých uživatel nevidí hodnotu výstupu. Toto se děje například u registračních formulářů, kde se na základě vyplněných formulářu vloží data do tabulky hostů. Útočník přestože neví výstup příkazu může například poslad příkaz na vložení nového admina stránky do DB nebo smazání celé DB. Command Injection Tento vektor útoku můžeme vidět u aplikací, které spuští systémové programy. Např: aplikace, které pingují určitou adresu nebo aplikace, které konvertují DOC do PDF etc. Problematiku si vysvětlíme u následujícího příkladu: <?php $output = system("host $_GET[ host']"); print($output);?> Do místa kde vkládáme hodnotu parametru host dosadíme středník a za něj cat /etc/ passwd a sledujme co se stane. Aplikace nejenom že vypíše výsledek příkazu host, ale také vypíše zásadní systémový soubor passwd.

13 Cross-site scripting (XSS) Úvod Jak už název napovídá, XSS jde o spouštění scriptů na straně uživatele. Nejčastěji jde o Javascript, ale existují také Flashové vektory. Cílem útočníka, který využívá xss chybu, je spustit nežádaný script na straně prohlížeče. Tuto chybu lze rozdělit na dvě různé podskupiny: Stored a Reflected XSS. Persistent XSS (stored) Představme si aplikaci, která nabízí návštěvníkům zanechat komentář pod článkem. Komentář se po odeslání serveru uloží do DB a vypisuje se jeho obsah všem návštěvníkům webu. Útočník může do komentáře, který je špatně filtrován aplikací vložit javascriptový script, který se později spustí všem návštěvníkům webu. Takto může například přečíst cookies a zjistit jejich SessionId, pomocí kterého je aplikace autentifikuje. Pro tento typ XSS je typické ukládání do DB (proto se také jmenuje Stored = uloženo). Ze všech XSS je toto jednoznačně nejnebezpečnější typ útoku. Non-persistent XSS (reflected / DOM) Pro tento vektor útoku je typická inejktace klientských scriptů pomocí patametrů v URL a částí za #hashtagem. Tyto parametry se využívají například pro odkazování na určitou část stránky. Klient přejde na stranáku blog.cz/#nadpis1 a po načtění stránky se automaticky spustí skript, který si převezme parametr a najde DIV s id nadpis1 a provede operaci pro scroll na daný DIV. Útočník, ale může do hashtagu vložit takovou hodnotu, že místo scrollu na DIV, se například ukáže alert box. Druhý scénář, který patří určitě mezi ty nejčastější, je načítání hodnot do formulářů. Představme si vyhledávácí aplikaci s URL: hledej.cz/vyraz= nove auto. Hodnota parametru vyraz se automaticky po nactení vlozi do Inputu pro vyhledání. Pro tento příklad uvedu názornou ukázku: PHP script na strane serveru:

14 Útočník pošle oběti odkaz na URL ve tvaru: xss )</script><! Když toto obět otevře vypiše se input a dosadi se do něho hodnota z parametru vyraz: Následně se oběti spustí javascriptový kod a vyskočí alert box s nápisem XSS. Nyní si představte scénář, kde by útočník chtěl získat přístup do administrace a nějakým způsobem by admina přinutil kliknout na odkaz, který by ho přesměroval do administrace a do přihlašovacího formuláře by se načetla data z URL a krom toho by obět nic netušícně odeslala své Cookies na server útočníka. Ukázka takového kodu: Obrana Prevence XSS je jednoduchá. Všechny proměné, které by se mohli vypsat do browseru je nutdno filtrovat a to pomocí funkce filter_var v PHP. Tato funkce převede následující znaky na neškodné HTML entity:

15 Autentifikace a šifrování Úvod Proces autentifikace je klíčový pro správný chod každé aplikace, která nějakým způsobem ověřuje identitu uživatele. Když je logika ověřování prolomena, utočník je schopný využít identitu někoho jiného. Útoky na autentifikaci Přenášení dat přes nezašifrované spojení, může znamenat únik přihlašovacích údajů, proto je nutné využít HTTPS s validním certifikátem a nastavit striktní vyžadování šifrování (HSTS) Politika hesel je na první pohled samozřejmností, ale bohužel tak často není. Snaha uhodnout heslo je nejbeženější způsob útoku a proto je nutné vybrat takové heslo, které není možné dedukovat a které obstojí proti slovníkovým útokům. Časté je také ponechání výchozích hesel, což je také velký problém. Proti procesu automatického uhádnutí hesla tzn. brute-force je potřeba implementovat ochranu. Tato ochrana vyhodnocuje unikatnost uživatele na základě spousta faktorů (např. IP, OS, HTTP-Agent atd.). Existují také cloudové služby, které toto zajištují (např. CloudFlare). Funkce, které umožňují obnovit heslo jsou často kritickým bodem a je nutné je důkladně promyslet. Toto obsahuje i spravné zvolení bezpečnostních otázek. Phishing Úvod Phishing je technika, kterou se útočník snaží dostat z oběti citlivé údaje pomocí manipulace. Cílem útoku je přinucení oběti provést akci, která je podvrhnuta útočníkem. Akcí může být odesílání formuláře, ale například i nakoupení položek ne e-shopu. Tato technika bývá často kombinováná s XSS, kdy útočník oběť přesměruje na falešnou stránku. Spear Phishing

16 Specifický druh teté techniky, která je založená na personizaci útoku. Útočník nesbírá data o oběti (může být i celá firma) a vytvoří důvěryhodný útok, který nebude oběd podezírat. Detekce Pro odhalení tohoto typu útoku se používá hlavně ověřování důvěrzhodnosti pomocí vytvoření databazí serverů, kterým je možné důvěrovat. Tuto funkci přináší antiviry nebo doplňky do prohlížečů (např. Web of Trust). Prevence Aby vůbec nedošlo k navštívení podvodné stránky je nutné vnímát odkud kam se na internetu pohybujete. Vždy nahlížejte na cílovou adresu odkazu, před tím než na něj kliknete. K návštěvě zvláště citlivých serverů (např. internetové bankovnictví, firemní administrace) zadávejte adresu vždy manuálně do prohlížeče. Predejdete tak návštěvě podvodného webu. Když už je nutné přejít na stránku pomocí odkazu, důsledně si prohlídněte, z jakých domén a subdomén se adresa skládá. Postup popíši na příkladu: Podvodná adresa je vytvořena často subdoménou, kterou v tomto případě tvoří slovo paypal a hlavní doménou (com-renew.net), která je odlišná od pravé domény sužby. Vždy je nutné zkontrolovat hlavní doménu. Dalším způsobem jak ověřit pravost stránky je kontrola SSL certifikátu. Váš prohlížeč je natolik inteligentní, že dokáže rozeznat certifikáty, které byly podepsané veřejně uznávanou autoritou od certifikátů, které nejsou podepsané jednou z věrohodných firem. Když chce vlastník webu bezpečné přihlašování do aplikace, musí si nechat certifikovat svou aplikaci pomocí certifikátu, který mu vydá certifikační autorita. Vlastník je nucen autoritě předat základní info o stránce a autorita dalé podepíše certifikát pravosti a stránka se stane důvěryhodnou pro rohlížeče (tzn. trusted). Přítomnost certifikátu zajišťuje nejen šifrovaný přenost dat pomocí HTTPS, ale také zvýší pocit bezpečí zákazníků a navýší ochranu proti phishingu. Celý tento proces popíši v ktrátkém příkladu: Útočník pošle oběti podvodný s odkazem (paypal.com-renew.net) na falešnou přihlašovací stránku paypal. Oběť, která je znalá pokročilých principů bezpečného chování na internetu odkaz ani neotevře, protože vidí že doména neodpovídá standartní doméně používané paypalem. Předpokládejme, že oběť si toto neuvědomí a odkaz otevře. Nyní ale zpozorní protože vidí, že v stránka není potvrzená HTTPS certifikátem (není trusted) a pro jistotu otevře paypal manuálně přes paypal.com. Utok tedy nebyl uspěšný a útočník jde o ovou adresu dál.

17 To jestli je stránka trusted nebo ne se pozná na první pohled pomocí zavřeného zámku v poli pro zadávání adresy. Níže najdete fotografie tohoto znaku: Safari Chrome Firefox