VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika. Analýza bezpečnosti webových stránek veřejné správy v kraji

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika

Analýza bezpečnosti webových stránek veřejné správy v kraji bakalářská práce

Autor: Filip Svoboda Vedoucí práce: Ing. Dominik Marek Jihlava 2016

Abstrakt Tato práce je zaměřena na penetrační testování webových stránek veřejné správy v Kraji Vysočina. První část slouží jako úvod do problematiky penetračního testování. Věnuje se popisu používaných technik, nejčastějších zranitelností na webových stránkách a metodik pro penetrační testování. Ve druhé, praktické části práce je provedena analýza bezpečnosti webových aplikací podle čtyřfázové metodiky, kterou definoval Národní institut standardů a technologie USA. Testování je zaměřeno na 10 nejzávažnějších zranitelností, jak je definuje příručka OWASP Top 10. V poslední kapitole jsou shrnuty výsledky testů s doporučeními, jak rizika omezit.

Klíčová slova Bezpečnost webových aplikací, penetrační testování, OWASP Top 10, Nessus, Burp Suite, sqlmap

Abstract This thesis is focused on penetration testing of websites of public administration in Vysočina region. The first part is an introduction to penetration testing. It describes the used techniques, penetration testing methodologies and the most critical web application security risks and vulnerabilities. The second, practical part describes security analysis performed on base of four-phase methodology defined by The National Institute of Standards and Technology. The testing focuses on 10 most critical vulnerabilities as defined in OWASP Top 10 document. The last part summarizes testing results with recommendations how to prevent them.

Keywords Web application security, penetration testing, OWASP Top 10, Nessus, Burp Suite, sqlmap

Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence.

V Jihlavě dne

............................................... Podpis

Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Dominiku Markovi za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.

Obsah 1

Úvod a motivace ....................................................................................................... 9

2

Problematika testování bezpečnosti webových aplikací ......................................... 10

3

4

2.1

Penetrační test .................................................................................................. 10

2.2

Typy penetračních testů ................................................................................... 10

2.2.1

Podle pozice útočníka ............................................................................... 10

2.2.2

Podle způsobu provedení .......................................................................... 11

2.2.3

Podle úrovně znalostí o testovaném systému ........................................... 11

Metodiky penetračního testování ............................................................................ 12 3.1

OSSTMM ......................................................................................................... 12

3.2

OWASP web application security testing methodology .................................. 13

3.3

NIST Technical Guide to Information Security Testing and Assessment ....... 13

3.3.1

Plánování .................................................................................................. 14

3.3.2

Průzkum .................................................................................................... 14

3.3.3

Útok .......................................................................................................... 14

3.3.4

Report........................................................................................................ 14

OWASP Top 10 ...................................................................................................... 15 4.1

OWASP Top 10 2013 ...................................................................................... 16

4.1.1

A1 – Injection ........................................................................................... 17

4.1.2

A2 – Broken Authentication and Session Management ........................... 18

4.1.3

A3 – Cross-Site Scripting (XSS) .............................................................. 19

4.1.4

A4 – Insecure Direct Object References ................................................... 20

4.1.5

A5 – Security Misconfiguration ............................................................... 21

4.1.6

A6 – Sensitive Data Exposure .................................................................. 22

4.1.7

A7 – Missing Function Level Access Control .......................................... 22

4.1.8

A8 – Cross-Site request Forgery (CSRF) ................................................. 23

5

4.1.9

A9 – Using Known Vulnerable Components ........................................... 24

4.1.10

A10 – Unvalidated Redirects and Forwards ............................................. 25

Penetrační testování vybraných webových aplikací ............................................... 26 5.1

Plánování .......................................................................................................... 26

5.1.1

Informace o testovaných aplikacích ......................................................... 27

5.1.2

Popis a výběr použitých nástrojů .............................................................. 27

5.2

Průzkum ........................................................................................................... 28

5.3

Útok .................................................................................................................. 31

5.3.1

A1 Injection .............................................................................................. 31

5.3.2

A2 Broken Authentication and Session Management .............................. 33

5.3.3

A3 Cross-Site Scripting (XSS) ................................................................. 34

5.3.4

A4 Insecure Direct Object References ...................................................... 36

5.3.5

A5 Security Misconfiguration .................................................................. 36

5.3.6

A6 Sensitive Data Exposure ..................................................................... 37

5.3.7

A7 Missing Function Level Access Control ............................................. 38

5.3.8

A8 Cross-Site Request Forgery (CSRF) ................................................... 38

5.3.9

A9 Using Known Vulnerable Components .............................................. 38

5.3.10

A10 Unvalidated Redirects and Forwards ................................................ 39

5.4

Report ............................................................................................................... 39

5.4.1

eDotace ..................................................................................................... 40

5.4.2

Informační systém Krajského úřadu Kraje Vysočina ............................... 42

5.4.3

eAmbulance .............................................................................................. 44

5.4.4

eMeDOcS.................................................................................................. 46

5.4.5

Rowanet .................................................................................................... 48

6

Závěr ....................................................................................................................... 51

7

Seznam použité literatury ....................................................................................... 52

Seznam obrázků .............................................................................................................. 55

Seznam použitých zkratek .............................................................................................. 56 Přílohy............................................................................................................................. 57 A - Report z penetračního testování ............................................................................... 57

1 Úvod a motivace V roce 2015 bylo k internetu připojeno 43 % světové populace a toto číslo neustále roste. [1] S nárůstem využití internetu se pojí i větší množství zpracovávaných a přenášených dat a zvyšuje se i množství kyber-útočníků, kteří mají o citlivá data zájem. Podle studie 2015 Cost of Data Breach Study [2] byla v roce 2015 výše finanční ztráty, způsobené únikem informací 3,79 mil. USD, což je o 23 % vice, než v roce 2013. Cena za jeden odcizený dokument se vyšplhala v průměru na 154 USD. Z uvedených statistik je patrné, že útoků na firemní sítě a webové aplikace bude nadále přibývat a je nutné se jim bránit. V roce 2015 vstoupil v účinnost zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti) [3], který mimo jiné, ukládá provozovatelům určitých webových aplikací a informačních systémů povinnost zabezpečit data. V rámci mé bakalářské práce se mi naskytla možnost provést bezpečnostní analýzu několika webových stránek veřejné správy v Kraji Vysočina. Seznámení se s problematikou a výstup z této bezpečnostní analýzy pro mě bude jistě velkým přínosem. Práce je rozdělena na dvě části. První část je teoretická a popisuje obecná pravidla a postupy, které se používají pro otestování zabezpečení webových aplikací, a obsahuje přehled nejčastějších chyb, které se ve webových aplikacích objevují. Ve druhé časti práce je prakticky provedena bezpečnostní analýza popsaných webových zranitelností a výstupem je zpráva pro Krajský úřad o provedeném testování.

9

2 Problematika testování bezpečnosti webových aplikací Následující teoretická část si klade za cíl seznámit čtenáře s problematikou penetračního testování a s důležitými pojmy, jejichž znalost je nutná pro pochopení části praktické.

2.1 Penetrační test Jedná se o testování IT infrastruktury, ve kterém se simuluje skutečný útok, za účelem nalezení co nejvíce zranitelných míst, které by mohly být použity útočníkem k proniknutí do aplikace, systému, nebo sítě. Výsledkem penetračního testu je pak zpráva, jež obsahuje všechny nalezené zranitelnosti a také doporučení pro jejich nápravu. [4] Před samotným penetračním testem je nutné získat úplný souhlas s našimi aktivitami od všech stran, které může test nějak zasáhnout. [5]

2.2 Typy penetračních testů Penetrační testy se dají rozdělit do několika základních kategorií. Podle toho, kde se nachází útočník, jaké má znalosti o testovaném systému a dle způsobu provedení. [6]

2.2.1 Podle pozice útočníka 

Interní



Externí

Externí testy jsou prováděny z vnější sítě, typicky internetu a zaměřují se na kontrolu tzv. demilitarizované zóny1 (DMZ), firewallů nebo směrovačů Interní testy simulují útok z vnitřní sítě, do které se útočník může dostat buď fyzicky nebo prolomením vnější ochrany, např. firewallu, špatně zabezpečeného webového serveru apod. [7]

1

Demilitarizovaná zóna je podsíť, ve které jsou umístěny služby přístupné z internetu, ale je oddělena od zbytku interní sítě.

10

2.2.2 Podle způsobu provedení Manuální testy Manuální testy provádí tester ručně. Takové testy jsou velmi specifické a vytvořené na míru testované aplikaci. To umožňuje detailně se zaměřit na určité místo aplikace a řádně ho otestovat. Nevýhodou manuálních testů je velká časová a znalostní náročnost. Tester musí mít detailní přehled o různých zranitelnostech a vědět jak jednotlivé zranitelnosti zneužít proti konkrétnímu druhu aplikace, kterou testuje. [6] Automatizované testy Automatizované testy jsou rychlé a dají se snadno reprodukovat. Používají se zde skenery zranitelností, které jsou vyvíjeny profesionály v této oblasti. Můžeme použít několik nástrojů, které mají široké možnosti konfigurace, ale přesto tyto nástroje nemusí nalézt všechna zranitelná místa, nebo je naopak může chybně identifikovat. [6] Semiautomatické testy Semiautomatické testy kombinují manuální a automatické testy. Tento typ testu kombinuje výhody obou výše zmíněných metod, kdy například nejprve identifikujeme potenciálně zranitelná místa automatickým skenerem a na ta místa poté útočíme. [6]

2.2.3 Podle úrovně znalostí o testovaném systému Black-box testy Black-box test napodobuje přístup skutečného útočníka, který nemá žádné informace o vnitřní struktuře aplikace a zná pouze vstupy a výstupy. Aplikace tedy pro testera představuje tzv. černou skříňku. [6] White-box testy Při tomto typu testu má tester k dispozici kompletní zdrojové kódy a zná její vnitřní strukturu. Při testování pak tester nemusí zkoušet mnoho různých útoků, ale zjistí z kódu, jak je dané místo zabezpečeno a dle toho volí další postup.

11

Výhodou tohoto přístupu je rychlejší a lepší pochopení zranitelných míst aplikace. Naopak nevýhodou je nutná znalost programovacího jazyka, ve kterém je aplikace napsána a z toho plyne i větší cenová náročnost. [6] Grey-box testy Grey-Box testy stojí mezi dvěma předchozími a snaží se maximálně využít jejich výhod. Tester má přístup pouze k některým informacím o aplikaci, např. architektuře, způsobu nakládání s daty, ověřování uživatelů apod. a při testech se je snaží využít. [8]

3 Metodiky penetračního testování Zatímco samotné testování vyžaduje určitou kreativitu testera, přístup k testování by měl být jasně definovaný a konzistentní. Metodiky testování popisují, jaké jednotlivé kroky je vhodné dodržet, avšak neměly by testera omezovat v jeho intuici a kreativitě. [9] Základní struktura jednotlivých metodik je vždy stejná, ale různé zdroje uvádějí upravené metodiky dle vlastních zkušeností.

3.1 OSSTMM The Open Source Security Testing Methodology Manual (OSSTMM) je otevřená metodika, která popisuje kroky, jež je nutné dodržet během testování. OSSTMM rozděluje penetrační testování na 6 oblastí: síťové zabezpečení, bezpečnost informací, fyzické zabezpečení, zabezpečená komunikace, zabezpečení bezdrátových sítí a sociální inženýrství. Každá sekce obsahuje moduly zaměřené na konkrétní oblast testování a jsou v nich popsané jednotlivé testovací kroky. Množství použitých modulů se může měnit v závislosti na požadavcích. [10] Projekt zastřešuje a vydává nezisková organizace Institute for Security and Open Methodologies (ISECOM), která se zaměřuje na rozšiřování povědomí o počítačové bezpečnosti a výzkum v oblasti zabezpečení. [11]

12

3.2 OWASP web application security testing methodology The Open Web Application Security Project (OWASP) je nezisková organizace a komunita zabývající se bezpečností webových aplikací. Cílem OWASP je zdarma poskytovat jednotlivcům i organizacím informace a nástroje, které pomohou zvýšit jejich bezpečnost na internetu. Organizaci jde především o sdílení informací v komunitě a zakládá si na své nezávislosti, proto nepoužívá a nedoporučuje žádné komerční produkty nebo služby. Vydala také několik významných dokumentů. Jedním z nich je OWASP Top 10, který shromažďuje 10 nejkritičtějších zranitelností webových aplikací, popisuje, jak fungují a jak jim předejít. Detailněji je rozebrán v další kapitole. [12] Neméně důležitým dokumentem je OWASP testing guide. Ten detailně popisuje jednotlivé zranitelnosti a jak je otestovat. Je zde definována OWASP web application security testing methodology. Metodika je založena na principu black-box testování a je rozdělena na 2 fáze. První fáze se nazývá pasivní režim a je zaměřená na pochopení logiky aplikace, jaké má funkce a jak s ní lze komunikovat apod. Druhá fáze se nazývá aktivní režim a dále se rozděluje na 11 podkategorií. Tyto podkategorie obsahují celkem 91 jednotlivých testů, které se věnují jednotlivým zranitelnostem a popisují jak je testovat. [13]

3.3 NIST Technical Guide to Information Security Testing and Assessment Další model pro penetrační testování, jehož název je Technical guide to Information Security Testing and Assessment pochází od Národního institutu standardů a technologií USA (NIST). Tato příručka popisuje metodiku sestávající ze 4 fází. Na obrázku 3-1 je zobrazeno, jak na sebe jednotlivé fáze navazují.

13

Obrázek 3-1: Čtyřfázová metodika dle NIST (Zdroj: [14])

3.3.1 Plánování V této fázi se na základě obecných zadání definuje rozsah testu, určí se detailnější a prioritní cíle, které se budou testovat, většinou totiž není možné otestovat úplně vše na 100 %. [14]

3.3.2 Průzkum Ve fázi průzkumu je potřeba zjistit o testované aplikaci co nejvíce informací. V závislosti na typu testu (black box, grey box, white box) se liší informace, které potřebujeme znát. Typicky zjišťujeme např. použitý programovací jazyk, Framework, webový server a operační systém na kterém běží. [14]

3.3.3 Útok V této fázi probíhá skenování testované aplikace, testování zabezpečení a pokusy o prolomení bezpečnostních mechanismů. Hlavním cílem útoku může být např. získání přihlašovacích údajů, eskalace uživatelských práv, přihlášení do aplikace bez validních přihlašovacích údajů nebo získání citlivých informací. [14]

3.3.4 Report Jak je patrné z obrázku 1, fáze reportu probíhá souběžně s ostatními. Během fáze průzkumu a útoku jsou jednotlivé zprávy z útoku hlášeny správci nebo majiteli dané aplikace. Finálním výstupem celého testu je dokument, obsahující popis nalezených zranitelností, hodnocení jejich závažnosti a doporučení pro jejich odstranění. [14] 14

4 OWASP Top 10 OWASP Top 10 je dokument vydaný organizací OWASP (The Open Web Application Security Project), který popisuje 10 nejvýznamnějších zranitelností, vyskytujících se ve webových aplikacích a zároveň způsob, jak jim předejít. Cílem tohoto projektu je zvýšit povědomí o bezpečnosti webových aplikací a poučit vývojáře, designéry i manažery o důsledcích bezpečnostních slabin aplikací. Poprvé byl OWASP Top 10 vydán v roce 2004 a další verze poté vycházely po 3 letech. Nejnovější verze, ze které vychází tato práce je z roku 2013. Žebříček u každé zranitelnosti hodnotí a popisuje pět jejích atributů, a to jak technický, tak i následný obchodní dopad na postiženou společnost. [15]

Obrázek 4-1: Schematické zobrazení cesty útoku (Zdroj: [15])

Průvodci hrozby Termín průvodci hrozby označuje jednotlivce nebo skupiny, které můžou zranitelnost nějakým způsobem zneužít a ohrozit tak společnost. Tyto skupiny a jednotlivci mohou být rozděleni následovně: 

Bez určení cíle: Mezi tyto průvodce hrozby patří počítačové viry, červy, trojské koně a logické bomby.



Zaměstnanci: Pracovníci, dodavatelé, provozní personál nebo bezpečnostní služba, kteří jsou naštvaní na společnost.



Organizovaný zločin: Zločinci se zaměřují na informace, které pro ně mají hodnotu, jako jsou bankovní účty, kreditní karty nebo duševní vlastnictví, které se dá zpeněžit. Zločinci často využívají vnitřní pracovníky, aby jim pomohli proniknout do společnosti. 15



Společnosti: Konkurenční společnosti nebo i jejich partneři.



Člověk neúmyslně: Nehody, neopatrnost.



Člověk úmyslně: Vnitřní pracovníci nebo vnější útočníci.



Přírodní pohromy: Například záplavy, požár, úder blesku, pád meteoritu, zemětřesení. [16]

Vektor útoku Vektor útoku je cesta nebo způsob, který může útočník použít k průniku do systému. Mnoho z nich využívá známá slabá místa aplikací, některé zneužívají i lidský faktor, který je často nejslabším článkem systému. [17] Bezpečnostní slabiny Bezpečnostní slabina je díra nebo slabina v zabezpečení aplikace, která může vzniknout už v době návrh nebo při implementaci a útočník ji pak může zneužít pro poškození zainteresovaných stran v aplikaci. Těmi jsou jak majitelé a provozovatelé aplikace, tak i její uživatelé a ostatní subjekty, které na danou aplikaci spoléhají. [18] Technické dopady Technický dopad popisuje dopad na systém v případě úspěšného útoku. Jedná se například o ohrožení důvěryhodnosti, integrity a dostupnosti systému. [19] Obchodní dopady Obchodní dopad udává, jaký dopad bude mít úspěšný útok na společnost z obchodního hlediska. Obecně se jedná o ztrátu financí, reputace, zákazníků. [20]

4.1 OWASP Top 10 2013 V této kapitole je popsáno 10 nejkritičtějších zranitelností webových aplikací roku 2013 tak, jak je uvádí OWASP Top 10 z roku 2013. 

A1 – Injection



A2 – Broken Authentication and Session Management



A3 – Cross-Site Scripting (XSS)



A4 – Insecure Direct Object References 16



A5 – Security Misconfiguration



A6 – Sensitive Data Exposure



A7 – Missing Function Level Access Control



A8 – Cross-Site Request Forgery (CSRF)



A9 – Using Known Vulnerable Components



A10 – Unvalidated Redirects and Forwards

4.1.1 A1 – Injection K chybám tohoto typu, jakými jsou např. SQL a LDAP injection, dochází, když jsou nedůvěryhodná data poslána přímo do interpretru jako součást příkazu nebo dotazu. Útočník tak může v interpretru vykonat vlastní kód a přistupovat tak k datům bez řádné autorizace. [15] SQL injection SQL injection je metoda, kdy útočník vloží vlastní kód SQL dotazu do vstupu na webové stránce (formulář, URL adresa, HTTP hlavička). Pokud vstupy na webové stránce nejsou správně ošetřeny, útočníkův kód se předá databázovému (DBMS) a ten ho vykoná. Při úspěšné injekci může útočník číst a modifikovat databázová data, provádět administrátorské operace s databází (jako je vypnutí DBMS), zobrazit obsah souboru ve filesystému DBMS a v některých případech spouštět příkazy operačního systému. [21] Průvodci hrozby Útočníkem může být kdokoliv, kdo má možnost posílat do systému nedůvěryhodná data, včetně externích a interních uživatelů a administrátorů. Vektor útoku Útočník odesílá textové příkazy, které zneužívají syntaxi cílového interpretru. Vektorem útoku může být téměř každý zdroj dat, včetně interních zdrojů. Bezpečnostní slabiny Chyby typu injection se objevují velmi často v zastaralém kódu, který se stále používá. Dají se nalézt v SQL, LDAP, Xpath nebo NoSQL dotazech, příkazech operačního sytému, XML parserech, SMTP hlavičkách, argumentech programu, atd. Zranitelnost se 17

dá snadno odhalit prozkoumáním zdrojového kódu, ale poměrně obtížně se zjišťuje testováním aplikace. S tím v dnešní době mohou pomoci automatizované nástroje a skenery. Technické dopady Injekce může vést ke ztrátě dat, narušení integrity, nebo až k úplnému převzetí kontroly nad serverem. Obchodní dopady Musíme brát v úvahu obchodní hodnotu dat, která mohou být ohrožena (upravena, vymazána).

4.1.2 A2 – Broken Authentication and Session Management Aplikační funkce spojené s autentizací a správou relací často nejsou implementovány správně, což útočníkům umožňuje kompromitovat hesla, klíče nebo tokeny relací, nebo jinak zneužít chyby k vydávání se za jiného uživatele. [15] Průvodci hrozby Zde je potřeba brát v úvahu anonymní externí útočníky i uživatele s vlastními účty, kteří mohou ukrást účty jiných uživatelů. Vektor útoku Útočník využívá trhlin v autentizaci nebo v použitých funkcích pro správu relace (např. nechráněná hesla, identifikátory relace) k tomu, aby se vydával za jiného uživatele. Bezpečnostní slabiny Vývojáři často vytváří vlastní schéma pro ověření uživatele a správu relace. Navrhnout bezpečné řešení není triviální záležitostí, a proto vlastní pokusy často vedou k chybám v oblastech, jako jsou odhlášení uživatele, správa hesel, zapamatování přihlášeného uživatele, bezpečnostní otázky, aktualizace profilu, atd. Hledání takových zranitelností může být obtížné, pokud je implementace unikátní.

18

Technické dopady Může být ohroženo mnoho, nebo dokonce všechny účty na serveru. Útočník může provádět vše, co skutečný majitel účtu. Častým cílem jsou administrátorské a jinak privilegované účty. Obchodní dopady Je třeba uvážit, jakou hodnotu mají dotčená data a informace a také obchodní dopad případného zveřejnění zranitelnosti.

4.1.3 A3 – Cross-Site Scripting (XSS) Chyby typu XSS se vyskytují, když aplikace posílá nedůvěryhodná data přímo do internetového prohlížeče uživatele bez řádného ověření nebo ošetření. Chyba umožňuje útočníkovi spouštět skripty v prohlížeči oběti a tak např. ukrást relaci uživatele, pozměnit webové stránky, nebo přesměrovat uživatele na nebezpečné stránky. [15] Průvodci hrozby Útočníkem může být kdokoliv, kdo má možnost posílat do systému nedůvěryhodná data, včetně externích a interních uživatelů a administrátorů. Vektor útoku Útočník posílá textové skripty, které exploitují interpretr v prohlížeči. Vektorem útoku může být téměř každý zdroj dat, včetně interních zdrojů, jako jsou data uložená v databázi. Bezpečnostní slabiny XSS je nejrozšířenější bezpečnostní chyba objevující se ve webových aplikacích. K XSS chybě může dojít, pokud aplikace umožňuje uživatelům přidat na stránku obsah, který pak bez kontroly zobrazuje dalším uživatelům. XSS se dělí do 3 základních kategorií: 

perzistentní – kód je v aplikaci uložen



neperzistentní – kód je vložen v URL adrese

19



DOM based XSS – škodlivý kód je vložen pomocí manipulace s DOMem 2 stránky

Technické dopady Útočník může ukrást relaci uživatele, změnit vzhled stránek, vkládat škodlivý obsah, přesměrovat uživatele, atd. Obchodní dopady Je potřeba zvážit hodnotu postiženého systému a dat, které zpracovává. Také je třeba brát v úvahu, jaký dopad může mít zveřejnění zranitelnosti.

4.1.4 A4 – Insecure Direct Object References Nezabezpečený odkaz na objekt se objevuje, pokud aplikace umožňuje přistoupit k objektu na základě vstupu od uživatele nebo např. parametru v URL adrese. Uživatel pak může snadno takový parametr změnit a získat neoprávněný přístup k datům. [15] Průvodci hrozby Zde je třeba si uvědomit, jaké typy uživatelů používají daný systém a zda by někteří z nich neměli mít přístup pouze částečný přístup k některým datům. Vektor útoku Útočník, který je uživatelem systému, změní hodnotu parametru, který odkazuje na objekt, ke kterému by neměl mít přístup. Bezpečnostní slabiny Aplikace často používají k vygenerování stránky skutečný klíč nebo název nějakého objektu a ne vždy ověřují, zda je uživatel oprávněn k cílovému objektu přistupovat. Technické dopady Taková chyba může zpřístupnit všechna data, která na která se dá odkázat parametrem. Pokud jsou klíče předvídatelné, útočník může snadno získat přístup ke všem takovým datům.

2

Document Object Model je rozhraní, které popisuje obsah a strukturu HTML dokumentu v podobě stromu [22]

20

Obchodní dopady Je třeba vzít v úvahu obchodní hodnotu vystavených dat a také dopad odhalení zranitelnosti veřejnosti.

4.1.5 A5 – Security Misconfiguration Zabezpečení aplikace vyžaduje řádnou konfiguraci použitých nástrojů, frameworků, aplikačních serverů, webových serverů a databázových serverů. Výchozí hodnoty v nastavení často nejsou bezpečné, a proto by měly být správně nakonfigurovány a udržovány. [15] Průvodci hrozby Zde je potřeba brát v úvahu anonymní externí útočníky i uživatele s vlastními účty, kteří se mohou pokusit kompromitovat systém. Vektor útoku Útočník může získat přístup do systému použitím výchozích přihlašovacích údajů, zneužitím nepoužívaných stránek, neopravených chyb nebo nechráněnými adresáři a soubory. Bezpečnostní slabiny K chybě může dojít na každé úrovni aplikace, jako jsou platforma, webový server, databáze, framework a vlastní kód. Vývojáři a systémoví administrátoři musí pracovat společně na správné konfiguraci systému. Technické dopady Chyby tohoto typu poskytují útočníkovi přístup k některým systémovým souborům nebo funkcím. Obchodní dopady Systém může být zcela kompromitován bez vědomí správce. Data mohou být ukradena nebo postupně měněna a náklady spojené s obnovou se mohou být značné.

21

4.1.6 A6 – Sensitive Data Exposure Tato zranitelnost se objevuje, když aplikace nesprávně uchovává citlivá data, jako např. bankovní údaje, hesla, rodná čísla, zdravotní záznamy a jiné osobní údaje. Data tohoto typu vyžadují zvláštní ochranu, jako je šifrování dat nebo řízení přístupu k zálohám. [15] Průvodci hrozby Je třeba vzít v úvahu všechny, kdo mají přístup k citlivým datům a jejich případným zálohám. Jedná se o uložená data, ale i o přenášená data a data uložená v prohlížečích uživatelů. Vektor útoku Útočník většinou neprolomí přímo šifrování, ale zaměří se například na krádež šifrovacích klíčů nebo nešifrovaných dat. Bezpečnostní slabiny Tato zranitelnost se vyskytuje v případě, kdy nejsou citlivá data šifrována nebo jsou použity slabé šifrovací klíče a algoritmy. Technické dopady Chyba často kompromituje všechna data, která by měla být chráněna. Typicky osobní údaje, kreditní karty, atd. Obchodní dopady Je potřeba zvážit obchodní hodnotu odcizených dat a dopad na důvěryhodnost.

4.1.7 A7 – Missing Function Level Access Control Většina webových aplikací řeší úroveň přístupu k dané funkci tím, že danou funkci nezobrazí neoprávněnému uživateli. Každá dostupná funkce musí mít ověřovat přístupová práva i na serveru. Jestliže požadavek odeslaný na server není řádně ověřen, může toho útočník zneužít a používat tak administrátorské funkce. [15]

22

Průvodci hrozby Kdokoliv, s přístupem k síti, ve které aplikace běží, jí může poslat požadavek. Je třeba zvážit, zda může anonymní uživatel používat dané funkce. Vektor útoku Útočník, který je autorizovaným uživatelem aplikace, změní URL adresu a v případě nedostatečné kontroly oprávnění může využít funkci, na kterou adresa odkazuje. Bezpečnostní slabiny Někdy je úroveň přístupu k funkcím špatně nakonfigurována a vývojáři zapomenou kontrolu implementovat. Technické dopady Zranitelnost umožňuje útočníkovi neoprávněný přístup k funkcím. Administrační funkce jsou hlavním cílem takových útoků. Obchodní dopady Je nutné zvážit hodnotu dostupných funkcí a dat, se kterými pracují. Také je třeba brát v úvahu dopad na reputaci v případě zveřejnění chyby.

4.1.8 A8 – Cross-Site request Forgery (CSRF) CSRF útok přiměje prohlížeč uživatele, přihlášeného ke zranitelné stránce, k odeslání podvrženého HTTP požadavku. K takovému požadavku jsou automaticky připojeny session cookies3, hlavičky a jiné ověřovací informace oběti. Pro zranitelnou aplikaci se pak takový požadavek tváří jako regulérní akce uživatele. [15] Průvodci hrozby Kdokoliv, kdo může podstrčit obsah do prohlížeče uživatele a donutit je tak odeslat požadavek na stránku.

3

Session cookies jsou soubory, obsahující identifikátor relace uživatele

23

Vektor útoku Útočník vytvoří podvržený HTTP požadavek a různými podvodnými metodami ho odešle z prohlížeče oběti. Útok uspěje, pokud je uživatel ke zranitelné aplikaci přihlášen. Bezpečnostní slabiny CSRF využívá toho, že prohlížeč automaticky odesílá některé identifikační údaje, např. cookies. Útočník tak může generovat požadavky, které jsou k nerozeznání od oprávněných. Technické dopady Útočník může oběť přimět, aby provedla operaci, ke které má přístup, jako např. změnit údaje na účtu, nakupovat, odhlásit nebo přihlásit uživatele. Obchodní dopady Je třeba zvážit hodnotu dotčených dat a funkcí. Zranitelnost může mít také velký dopad na pověst.

4.1.9 A9 – Using Known Vulnerable Components Používané komponenty, jako jsou knihovny, frameworky a jiné softwarové moduly jsou většinou na severu spouštěny se všemi právy. V případě exploitace 4 zranitelné komponenty může takový útok vést k vážné ztrátě dat nebo ovládnutí serveru útočníkem. Aplikace, používající komponenty, se známými zranitelnostmi mohou oslabit aplikační obranu a umožnit řadu možných útoků. [15] Průvodci hrozby Některé zranitelné komponenty mohou být identifikovány a zneužity za pomoci automatizovaných nástrojů, což značně rozšiřuje skupinu možných útočníků. Vektor útoku Útočník odhalí zranitelnou komponentu automatickými nástroji nebo manuální analýzou a tu poté zneužije.

4

Zneužití zranitelnosti ve webové aplikaci nebo programu.

24

Bezpečnostní slabiny Mnoho aplikací má tyto nedostatky, protože spousta vývojářů používá starší verze knihoven. Vývojáři někdy ani nevědí, jaké všechny komponenty aplikace používá, a závislosti mezi komponentami situaci ještě zhoršují. Technické dopady Mohou se vyskytovat jakékoliv zranitelnosti, jako jsou XSS, injection, atd. Dopad na aplikaci se tak pohybuje od minimálního až po úplné převzetí kontroly nad systémem. Obchodní dopady Je třeba zvážit, jaká dopad může mít každá zranitelnost na postiženou společnost.

4.1.10 A10 – Unvalidated Redirects and Forwards Webová aplikace často přesměrovávají uživatele na jiné stránky a používají nedůvěryhodné údaje k určení cílové stránky. Bez řádného ověření může útočník přesměrovat oběť na podvodnou nebo jinak nebezpečnou stránku nebo použít předávané údaje k neoprávněnému přístupu na stránky. Průvodci hrozby Bereme v úvahu každého, kdo může přimět uživatele odeslat požadavek dané aplikaci. Vektor útoku Útočník vytvoří odkaz na neověřené přesměrování a přiměje uživatele, aby na něj kliknul. Takový odkaz vypadá, že vede na důvěryhodnou stránku a tak uživatel nemusí poznat rozdíl. Bezpečnostní slabiny Webové aplikace často přesměrovávají uživatele jinam a někdy je cílová adresa uvedena v neošetřeném parametru, který umožní útočníkovi cílovou adresu podvrhnout.

25

Technické dopady Chyba může vést k instalaci malwaru 5 , nebo odhalení uživatelského hesla a jiných informací. Obchodní dopady V případě úspěšného útoku je možné ztratit důvěru uživatelů a je tedy třeba se zamyslet nad její hodnotou.

5 Penetrační testování vybraných webových aplikací V této kapitole je popsán průběh samotného penetračního testování vybraných webových aplikací. Test byl proveden podle metodiky definované v Technical guide to Information Security Testing and Assessment od NIST, která byla popsána v kapitole 3.3. V první části kapitoly je popsán plán testu a jeho cíle. Je zde zahrnut i výběr vhodných nástrojů, použitých pro testování. V další části je popsána fáze útoku a analýza zranitelností pro webovou aplikaci eDotace. V kapitole Report jsou popsány nalezené zranitelnosti pro jednotlivé webové aplikace a doporučení pro jejich odstranění.

5.1 Plánování V rámci penetračních testů budou otestovány následující aplikace: 

Informační systém Krajského úřadu Kraje Vysočina



eAmbulance kraje Vysočina



eDotace kraje Vysočina



eMeDOcS



Rowanet

Analýza všech aplikací bude provedena jako white-box testy z pozice vnějšího útočníka prostřednictvím sítě internet. Z hlediska míry automatizace budou testy probíhat poloautomatizovaně za použití nástrojů popsaných dále. Aplikace budou testovány na 10 nejrozšířenějších zranitelností, popsaných v dokumentu OWASP Top 10. 5

Označení pro škodlivý počítačový program.

26

5.1.1 Informace o testovaných aplikacích Informační systém Krajského úřadu Kraje Vysočina (http://www.kr-vysocina.cz/) Tento informační systém se podle určujících kritérií [23] řadí mezi významné informační systémy6, na něž jsou podle zákona o kybernetické bezpečnosti [3] kladeny větší bezpečnostní požadavky a z toho důvodu mu byla v mém testu věnována největší pozornost. eAmbulance kraje Vysočina (http://www.eambulance.cz/) eAmbulance slouží jako rozcestník ke službám v krajském zdravotnickém systému, které lze obsluhovat prostřednictvím internetu. Uživatelé se tam mohou objednat do ambulancí krajských nemocnic apod. eDotace kraje Vysočina (http://extranet.kr-vysocina.cz/edotace/) Aplikace eDotace slouží k zobrazení všech dostupných dotací a pro jejich elektronické vyřizování. eMeDOcS (http://www.emedocs.cz/) Informační stránka projektu eMeDOcS (Exchange Medical Documets System), který buduje a rozšiřuje komunikační strukturu pro bezpečnou a důvěryhodnou výměnu zdravotnické dokumentace mezi zdravotnickými zařízeními v rámci zdravotnického systému České Republiky. Rowanet (http://www.rowanet.cz/) Tato aplikace slouží jako informační stránka o projektu ROWANet, který má na starost páteřní optickou datovou síť veřejné správy v kraji Vysočina.

5.1.2 Popis a výběr použitých nástrojů Pro celkový sken různých zranitelností jsem vybíral z 2 dostupných komerčních nástrojů: Rapid7 Nexpose a Tenable Nessus. Oba nástroje nabízejí širokou škálu možností a nastavení pro bezpečnostní analýzu a oba je možno zdarma vyzkoušet. V mých testech jsem se rozhodl použít Nessus, protože má menší hardwarové nároky

6

Významný informační systém má zásadní význam pro fungování veřejné správy

27

a celkově mi přišel rychlejší. V případě, že by bylo potřeba pokračovat v testech po uplynutí zkušební doby také Nessus vychází cenově výhodněji. Pro důkladnější testování některých zranitelností budou použity specializované nástroje na daný problém. Pro otestování SQL injection bude použit SQL map, který podporuje testy velkého množství útoků pro různé databázové systémy. K odhalení XSS zranitelností bude použit doplněk do prohlížeče HackBar, který usnadňuje vkládání různě kódovaných příkazů na stránku, dále bude použit nástroj XSSer, který automaticky hledá a testuje zranitelnosti typu XSS. K dalším detekcím bude použit nástroj Burp Suite, který funguje jako lokální proxy server, přes který probíhá komunikace s webovou aplikací. To nám umožňuje monitorovat a upravovat zasílané HTTP požadavky. Mimo to má Burp Suite další nástroje pro zmapování struktury aplikace, opakované zasílání požadavků s různými parametry a placená verze obsahuje automatický skener zranitelností.

5.2 Průzkum V této fázi je potřeba zjistit o aplikaci co nejvíce informací a udělat si tak přehled, jaké typy zranitelností se mohou vyskytnout a kde je hledat. Adresářová struktura aplikace Pro zjištění adresářové struktury aplikace jsem používal nástroj Burp Suit, konkrétně tedy jeho modul Spider, který slouží právě k tomuto účelu.

28

Obrázek 5-1: Výstup skenování aplikace nástrojem Burp Suite (Zdroj: autor)

Na obrázku 5-1 vidíme soubory a adresáře, které dokázal Burp Suite najít, zároveň vidíme, jaké požadavky byly odesílány k jejich detekci. Z adresářové struktury si můžeme udělat poměrně dobrou představu o tom, jak aplikace funguje, jaká data kde odesílá, s jakými parametry pracuje apod. Automatický sken zranitelností a identifikace použitých technologií Dalším krokem je spuštění automatické detekce zranitelností. K tomuto účelu použiji nástroj Nessus, nastavený pro testování webových aplikací. V nástroji lze nastavit, jestli chceme provést rychlý, nebo důkladný test. Zde byl použit méně důkladný test, který poskytuje dobrý náhled na zranitelná místa v aplikaci v přiměřené době.

29

Obrázek 5-2: Zranitelnosti identifikované nástrojem Nessus (Zdroj: autor)

30

Na obrázku 5-2 je vidět, že skener detekoval několik zranitelností a rozdělil je podle závažnosti. Mimo to ale skener detekoval i jiné důležité informace: 

Webový server: Apache, verze



PHP verze 4.4.6

5.3 Útok Ve fázi útoku je třeba prověřit nálezy ze skeneru, který jsme použili v předchozí fázi a otestovat další citlivá místa aplikace.

5.3.1 A1 Injection U analýzy zranitelnosti typu injection je třeba nejprve identifikovat všechny vstupy aplikace. K tomu se dá dobře využít výstup z nástroje Burp Suite, který byl použit ve fázi průzkumu a kromě adresářové struktury zaznamenal i všechny HTTP požadavky i s jejich parametry. Penetrační tester tak může na základě zkušeností a intuice vybrat, které parametry je vhodné dále testovat.

Obrázek 5-3: HTTP požadavky testované na SQL injection (Zdroj: autor)

31

Na obrázku 5-3 jsou zvýrazněny požadavky, které jsem se rozhodl postoupit dalšímu testování nástrojem SQLmap. Jako

první

byl

otestován

požadavek

na

URL

http://extranet.kr-

vysocina.cz/eDotace/ajax.php?akce=zalozka_zmen&val=neziskovky , který metodou GET přebírá parametry akce a val zadané přímo v URL adrese. Nástroj SQLmap byl spuštěn příkazem: sqlmap -u "http://extranet.krvysocina.cz/eDotace/ajax.php?akce=zalozka_zmen&val=neziskovky" --time-sec 10 –b kde přepínač -time-sec nastavuje dobu čekání pří detekci injection podle doby odezvy, -b určuje, že SQLmap při úspěšné injekci zjistí pouze uvítací zprávu DBMS a podle ní určí, o který typ databázového systému se jedná. První provedený test dopadl neúspěšně a nebyla nalezena žádná zranitelnost. Stejně tak dopadl druhý test, na URL http://extranet.kr-vysocina.cz/eDotace/abon/ . Dále byl testován požadavek na URL http://extranet.kr-vysocina.cz/edotace/index.php s POST parametry sub a hledej, který slouží k vyhledávání na stránkách eDotací. Nástroj SQLmap byl v tomhle případě upraven do tvaru: sqlmap -u "http://extranet.kr-vysocina.cz/edotace/index.php" -data="sub=Hledej&hledej=test" -b --time-sec 10 -p hledej kde přepínač -p určuje, které parametry se mají testovat.

Obrázek 5-4: Výstup nástroje SQLmap po nalezení SQL injection (Zdroj: autor)

Z obrázku 5-4 je patrné, že útok byl tentokrát úspěšný a detekoval zranitelnost SQL injection typu stacked queries, cože je typ útoku, kdy se za korektní SQL dotaz vloží další, který se vykoná také. Zranitelnost byla odhalena metodou tzv. blind SQL 32

injection, která spočívá v použití SQL funkce pro pozastavení běhu a porovnává se doba trvání dotazu. Tohoto typu testu se využívá v případech, kdy na stránce, ani v kódu, není žádný viditelný výstup, odtud tedy blind injection (naslepo). Zranitelnost lze vyzkoušet přímo na stránce, zadáním testovacího payloadu7 do pole pro vyhledávání.

Obrázek 5-5: Ověření blind SQL injection pomocí Tamper Data (Zdroj: autor)

5.3.2 A2 Broken Authentication and Session Management Testovaná webová aplikace pří návštěvě nastavuje v prohlížeči cookies, obsahující tokeny relace. Pro analýzu náhodnosti těchto tokenů se dá využít modul sequencer nástroje Burp Suite. Nejprve je nutné nalézt požadavek, který do cookies ukládá hodnotu session id a předat ho sequenceru. Ten začne generovat velké množství požadavků a zachytávat tokeny. Poté Burp Suite předloží analýzu náhodnosti tokenů, analýzu na úrovni znaků a na úrovni bitů.

7

Část zprávy (požadavku), která obsahuje útočný kód

33

Obrázek 5-6: Analýza náhodnosti tokenů relace (Zdroj: autor)

Graf na obrázku 5-6 znázorňuje náhodnost znaků na jednotlivých místech tokenu. Analýza byla provedena na základě 9177 tokenů. Z grafu nejsou patrné žádné anomálie, které by umožňovali útočníkovi odhadnout alespoň část tokenu.

5.3.3 A3 Cross-Site Scripting (XSS) Při testování zranitelností XSS je třeba identifikovat všechny vstupy, kde lze zadat škodlivý kód. Vstupy mohou být formulářové prvky na stránce, ale i parametry v HTTP požadavcích. Jako první test byl spuštěn nástroj XSSer, který automaticky prošel cílovou adresu a útočil na všechny identifikované vstupy. Program neodhalil žádné zranitelnosti. Na webu se nachází vyhledávací pole, které bylo podrobeno ručnímu testování. Bylo zjištěno, že po vyhledání výrazu se tento po odeslání promítne do parametru value daného formulářového prvku.

34

Obrázek 5-7: Zdrojový kód formuláře pro vyhledávání (Zdroj: autor)

Ze zdrojového kódu stránky je vidět, že pro injektáž javascriptového kódu je nutné nejprve se dostat mimo kontext elementu input a poté až vložit samotný script. Testováním

bylo

zjištěno,

že

po

zadání

hledaného

výrazu,

např.

"><script>alert(document.cookie); dojde k vykonání scriptu. Pole pro vyhledávání tedy obsahuje zranitelnost XSS.

Obrázek 5-8: Zneužití vyhledávacího pole pomocí XSS (zdroj: autor)

Při použití nástroje Nessus byla odhalena veřejně dostupná stránka8, na které je použita funkce phpinfo(). Tato funkce vypisuje na stránku informace o konfiguraci PHP na serveru, použitých modulech, operačním systému, cestách, kde se nachází konfigurační soubory, atd. Stránka sama nesděluje žádné kritické informace, ovšem některé z uvedených údajů se dají využít v jiných typech útoků. Z odhalené stránky je možné vyčíst, že na serveru je použito PHP ve verzi 4.4.6. PHP interpretr ve verzích 4.4.3 – 4.4.6 obsahuje ve funkci phpinfo() zranitelnost typu XSS9. Za použití testovacího payloadu info.php?a[]=<script>alert(/XSS/);

8 9

http://extranet.kr-vysocina.cz/nepotrebny-majetek/info.php https://www.exploit-db.com/exploits/3405/

35

lze pak jednoduše ověřit, že stránka je skutečně zranitelná.

Obrázek 5-9: XSS zranitelnost ve funkci phpinfo (Zdroj: autor)

5.3.4 A4 Insecure Direct Object References Zde musíme otestovat, zda v aplikaci existuje parametr, jehož změnou by bylo možné získat přístup neoprávněný přístup k datům. V aplikaci byla identifikována adresa pro ukládání souborů na základě jeho id: http://extranet.kr-vysocina.cz/eDotace/download.php?id=3785 Změnami hodnoty parametru id bylo staženo několik souborů. Tyto soubory obsahovaly veřejně dostupné informace, přístupné i z webové stránky samotné. Zranitelnost tohoto typu zde nebyla objevena.

5.3.5 A5 Security Misconfiguration Při hledání zranitelností tohoto typu je vhodné pokusit se nalézt konfigurační stránku aplikace (serveru), nebo jiné, kde vyzkoušíme, zda nejsou ponechány výchozí přihlašovací údaje. Bylo zjištěno, že při zadání adresy http://extranet.kr-vysocina.cz/edotace/config server odpovídá stavovým kódem 403 Forbidden. Na požadovaném místě se tedy 36

zřejmě nachází nějaký konfigurační soubor, ke kterému nám ale webový server neumožňuje přistoupit. Analýzou nebylo zjištěno žádné chybné nastavení webového serveru nebo aplikace.

5.3.6 A6 Sensitive Data Exposure Při testování této chyby je třeba zmapovat všechny odkazy a ujistit se, že nevedou na citlivá data. Taková data se mohou vyskytovat i v podobě komentářů ve zdrojových kódech, mohou být předávána jako parametry HTTP požadavku, ukládána v cookies apod. K průzkumu zde byl použit Burp Suite, ve kterém jsme odhalili volně dostupné adresáře download/ a download/eDotace/

Obrázek 5-10: Adresářový výpis volně dostupného adresáře (Zdroj: autor)

37

Po bližším prozkoumání nalezených dokumentů nebyla odhalena žádná citlivá data a adresář je zřejmě volně dostupný záměrně.

5.3.7 A7 Missing Function Level Access Control V testované webové aplikaci nelze bez přihlášení identifikovat žádné administrátorské funkce. Protože nemáme přístup k žádnému účtu, nebylo možné otestovat, zda jsou použité funkce dostatečně ošetřeny proti zneužití neautorizovaným uživatelem.

5.3.8 A8 Cross-Site Request Forgery (CSRF) V aplikaci byla bez přihlášení identifikována jedna akce, která by měla být chráněna proti zneužití metodou CSRF. Po provedení pokusu o přihlášení byl odeslaný HTTP požadavek zachycen nástrojem Burp Suite.

Obrázek 5-11: HTTP požadavek, odesílaný po přihlášení (Zdroj: autor)

Ze zachyceného požadavku můžeme vyčíst, že odesílá parametry jméno, heslo a submit. Neobsahuje tedy žádný token, který by formulář ochránil před neoprávněným odesláním.

5.3.9 A9 Using Known Vulnerable Components Pohledem do zdrojového kódu lze identifikovat použitý redakční systém Vismo5. Po provedení

neplatného

pokusu

o

přihlášení

na

adrese

https://edotace.kr-

vysocina.cz/edotace lze z chybové hlášky vyčíst, že pro autentizace je použit serverový modul mod_auth_sspi ve verzi 1.0.4.

38

Použitím internetového vyhledávače a prohledáním databáze zranitelností Exploit Database

10

nebyly nalezeny žádné veřejně dostupné zranitelnosti a exploity pro tyto

použité komponenty. Skener zranitelností Nessus, který byl použit ve fázi průzkumu identifikoval webový server Apache ve verzi 2.0.54 a zároveň podal hlášení o tom, že tato verze obsahuje chybu HTTP Server Byte Range DoS, která zneužívá nedostatečné kontroly při použití HTTP hlavičky Range. Tato hlavička se používá např. pro stahování velkých souborů, které by se celé nevešly do jednoho požadavku. Parametr range pak udává, kterou část souboru od serveru požadujeme. Chyba spočívá v použití velkého množství rozsahů, webový server tak vytvoří velké množství kopií daného souboru a může zahltit celou paměť a vytížit procesor. Takový útok může vést až k odepření služby (DoS). [24]

5.3.10 A10 Unvalidated Redirects and Forwards Prvním krokem při hledání zranitelností tohoto typu, je identifikace každého místa aplikace, kde dochází k přesměrování. Aplikace mlže uživatele přesměrovat na jinou stránku několika způsoby: [25] 

Server odpoví stavovým kódem 3xx a uvedenou hlavičkou Location, která specifikuje cíl přesměrování



Odpověď serveru obsahuje hlavičku Refresh se zadanou cílovou adresou



HTML tag <meta> může být použit pro simulaci HTTP hlavičky a nastavovat parametry Location a Refresh



Přesměrování může být docíleno použitím javascriptu

Dalším krokem je procházení webu a kontrola požadavků provedených na aktuální stránce skrz lokální proxy (např. Burp Suite). Pokud stránka obsahuje přesměrování, je třeba identifikovat, zda cílová adresa může být ovlivněna uživatelem. V aplikaci nebyla nalezena žádná přesměrování.

5.4 Report V této kapitole jsou popsány výsledky penetračního testování pro 5 testovaných webových aplikací. Ke každé zranitelnosti uvedeno doporučení k nápravě. 10

https://www.exploit-db.com/

39

5.4.1 eDotace Test: Injection 

Cíl: Otestovat aplikaci na odolnost proti SQL injection.



Zjištění: Aplikace obsahovala zranitelnost SQL injection.



Zranitelná místa: o Vyhledávací formulář, nacházející se na úvodní stránce.



Doporučení k nápravě: Pro vykonávání SQL dotazu využívat prepared statements, které definují strukturu dotazu a dosazené hodnoty samotný dotaz nemohou ovlivnit.

Test: Session Management 

Cíl: Otestovat, zda jsou generované session tokeny dostatečně náhodné.



Zjištění: Použitá funkce pro generování session tokenů splňuje požadavky a není možné token odhadnout.



Zranitelná místa: -



Doporučení k nápravě: -

Test: Cross-Site Scripting (XSS) 

Cíl: Otestovat aplikaci na odolnost proti XSS.



Zjištění: Aplikace obsahovala zranitelnosti typu XSS.



Zranitelná místa: o Vyhledávací formulář, nacházející se na úvodní stránce. o Funkce phpinfo() na adrese http://extranet.kr-vysocina.cz/nepotrebnymajetek/info.php



Doporučení k nápravě: o Ošetřit vstup vyhledávacího pole převedením speciálních znaků na entity, např. použitím PHP funkce htmlspecialchars(). o Odstranit stránku využívající funkci phpinfo() a updatovat PHP na novější verzi

Test: Insecure Direct Object References 

Cíl: Zjistit, zda uživatel může přistupovat k informacím, ke kterým by neměl.

40



Zjištění: Všechny privátní soubory jsou chráněny proti neoprávněnému přístupu.







Test: Security Misconfiguration 

Cíl: Otestovat aplikaci a použité komponenty, jestli jsou správně nastaveny.



Zjištění: Nebyla odhalena žádná chybná nastavení nebo nebezpečné výchozí hodnoty.







Test: Sensitive Data Exposure 

Cíl: Otestovat, jestli se útočník může dostat k citlivým datům v aplikaci.



Zjištění: Aplikace neumožňuje přístup k citlivým datům.







Test: Missing Function Level Access Control 

Cíl: Otestovat ochranu aplikačních funkcí před neoprávněným přístupem.



Zjištění: V aplikaci nebyly identifikovány žádné zneužitelné funkce.







Test: Cross-Site Request Forgery (CSRF) 

Cíl: Otestovat aplikaci na odolnost proti CSRF.



Zjištění: Aplikace byla náchylná na útok typu CSRF.



Zranitelná místa: o Formulář pro přihlášení



Doporučení k nápravě: Při odeslání formuláře připojit k požadavku náhodně generovaný token.

Test: Using Known Vulnerable Components

41



Cíl: Otestovat aplikaci na veřejně známé a dostupné chyby.



Zjištění: Aplikace obsahovala zranitelnost typu DoS.



Zranitelná místa: o Použitá verze webového serveru Apache.



Doporučení k nápravě: Aktualizovat Apache na novější verzi.

Test: Unvalidated Redirects and Forwards 

Cíl: Otestovat aplikaci na přítomnost neošetřených přesměrování.



Zjištění: Aplikace neobsahuje žádná zranitelná místa pro útok tohoto typu.







5.4.2 Informační systém Krajského úřadu Kraje Vysočina Test: Injection 




Zjištění: V aplikaci nebyla nalezena žádná chyba typu SQL injection.






















Zjištění: V aplikaci nebyly odhaleny žádné zranitelnosti typu XSS.







42

















































Zjištění: Aplikace nebyla náchylná na útok CSRF.







43

Test: Using Known Vulnerable Components 




Zjištění: Aplikace neobsahovala žádné zranitelné komponenty.











Zjištění: Aplikace obsahovala přesměrování, které přebírá cílovou adresu z URL adresy.



Zranitelná místa: o Formulář pro přihlášení, dostupný z https://www.krvysocina.cz/AA/index.asp přebírá z URL parametr ReturnUrl



Doporučení k nápravě: Kontrolovat cílovou adresu proti seznamu povolených adres nebo domén.

5.4.3 eAmbulance Test: Injection 























Cíl: Otestovat aplikaci na odolnost proti XSS. 44

























Zjištění: Na webovém serveru byla povolena debugovací metoda DEBUG.



Zranitelná místa: Celá aplikace.



Doporučení k nápravě: Vypnout debugovací metodu nastavením v konfiguračním souboru aplikace.




























45






















Zjištění: V aplikaci nebylo nalezeno žádné zranitelné přesměrování.







5.4.4 eMeDOcS Test: Injection 




Zjištění: V aplikaci byla odhalena zranitelnost SQL injection.



Zranitelná místa: o Parametr arg2 na adrese http://emedocs.cz/index.php/detail/https:/?akce=zarizeni&arg1=detail&a rg2=https



Doporučení k nápravě: Pro vykonávání SQL dotazu využívat prepared statements, které definují strukturu dotazu a dosazené hodnoty samotný dotaz nemohou ovlivnit.











Doporučení k nápravě: 46
























































47



























Zjištění: V aplikaci nebylo nalezeno žádné zranitelné přesměrování.







5.4.5 Rowanet Test: Injection 






















48
























































49



























Zjištění: Aplikace obsahovala přesměrování, které přebírá cílovou adresu z URL adresy.



Zranitelná místa: o Formulář pro přihlášení, dostupný z https://www.krvysocina.cz/AA/index.asp přebírá z URL parametr ReturnUrl



Doporučení k nápravě: Kontrolovat, cílovou adresu proti seznamu povolených adres nebo domén.

50

6 Závěr Tato bakalářská práce se ve své první části věnovala popisu důležitých pojmů a technik v oblasti penetračního testování. Dále pak čtenáře seznámila s dokumentem OWASP Top 10 a s 10 nejčastějšími zranitelnosti, objevujícími se ve webových aplikacích. Byla zde představena také metodika penetračního testování dle National Institute of Standards and Technology (NIST), kterou se řídilo vlastní testování webových aplikací. Ve druhé části práce jsou popsány testované aplikace. Je zde provedena jejich analýza, nejprve plně automatickým nástrojem pro rychlou identifikaci důležitých a zranitelných míst webové aplikace. Poté přišly na řadu nástroje, které se specializují na určité typy zranitelností a bylo provedeno i několik ručních testů. Aplikace byly testovány na 10 nejčastějších chyb dle OWASP Top 10. Analýze bylo podrobeno 5 webových stránek a bylo nalezeno 12 zranitelností, z toho 7 závažných, 1 středně závažná a 4 méně závažné. Po otestování všech aplikací byl sepsán report, obsahující popis nalezených zranitelností a také doporučení pro jejich odstranění. Všechna tato zjištění budou předána zadavateli bakalářské práce.

51

7 Seznam použité literatury [1] ITU releases 2015 ICT figures: Statistics confirm ICT revolution of the past 15 years. International Telecommunication Union [online]. [cit. 2016-01-21]. Dostupné z: http://www.itu.int/net/pressoffice/press_releases/2015/17.aspx#.VqCZ3SrhDDc [2] PONEMON INSTITUTE. 2015 Cost of Data Breach Study: Global Analysis [online]. 2015 [cit. 2016-01-21]. Dostupné z: http://www03.ibm.com/security/data-breach/ [3] ČESKO. Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti). In Sbírka zákonů ČR, ročník 2014, částka 75, [cit. 2015-01-01]. Dostupné z: http://www.zakonyprolidi.cz/cs/2014181 ISSN 1211-1244 [4] Penetrační testování. SOOM.cz [online]. [cit. 2016-01-21]. Dostupné z: http://www.soom.cz/clanky/1062--Penetracni-testovani [5] PETER, Kim. The hacker playbook: practical guide to penetration testing. North Charleston, South Carolina: Secure Planet, LLC, 2014. ISBN 9781494932633. [6] SELECKÝ, Matúš. Penetrační testy a exploitace. 1. vyd. Brno: Computer Press, 2012, 303 s. ISBN 978-80-251-3752-9. [7] Typy penetračních testů. Zabezpecujeme.net [online]. [cit. 2016-01-21]. Dostupné z WWW: https://www.zabezpecujeme.net/typy-penetracnich-testu [8] Grey Box Penetration Testing. Secure Ideas [online]. 2012 [cit. 2016-01-21]. Dostupné z: https://blog.secureideas.com/2012/12/grey-box-penetration-testing.html [9] Penetration testing methodology and standards. SearchNetworking [online]. [cit. 2016-01-21]. Dostupné z WWW: http://searchnetworking.techtarget.com/tutorial/Penetration-testing-methodology-andstandards [10] ISECOM, The Open Source Security Testing Methodology Manual: Contenporary Security Testing and Analysis [online]. 2010 [cit. 2016-01-21]. Dostupné z WWW: http://www.isecom.org/mirror/OSSTMM.3.pdf

52

[11] ISECOM [online]. [cit. 2016-01-21]. Dostupné z WWW: http://www.isecom.org/ [12] OWASP: The Open Web Application Security Project [online]. [cit. 2016-01-21]. Dostupné z WWW: https://www.owasp.org [13] MEUCI, Matteo a Andrew MULLER. OWASP Testing Guide [online]. 4.0. The OWASP Foundation, 2015 [cit. 2016-01-21]. Dostupné z WWW: https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf [14] SCARFONE, Karen, Murugiah SOUPPAYA, Amanda CODY a Angela OREBAUGH. Technical Guide to Information Security Testing and Assessment: Recommendations of the National Institute of Standards and Technology[online]. National Institute of Standards and Technology, 2008 [cit. 2016-01-21]. Dostupné z WWW: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf [16] OWASP: Category:Threat Agent [online]. [cit. 2016-05-25]. Dostupné z: https://www.owasp.org/index.php/Category:Threat_Agent [17] MORANA, Marco a Scott NUSBAUM. Input Validation Vulnerabilities, Encoded Attack Vectors and Mitigations [online]. The OWASP Foundation, 2008 [cit. 2016-0525]. Dostupné z: https://www.owasp.org/images/6/6c/Encoded_Attacks_Threats_Countermeasures_9_30 _08.pdf [18] OWASP: Category:Vulnerability [online]. [cit. 2016-05-25]. Dostupné z: https://www.owasp.org/index.php/Category:Vulnerability [19] OWASP: Category:Technical Impact [online]. [cit. 2016-05-25]. Dostupné z: https://www.owasp.org/index.php/Category:Technical_Impact [20] OWASP: Category:Business Impact [online]. [cit. 2016-05-25]. Dostupné z: https://www.owasp.org/index.php/Category:Business_Impact [21] OWASP: SQL Injection [online]. [cit. 2016-05-25]. Dostupné z: https://www.owasp.org/index.php/Category:Business_Impact [22] W3C: Document Object Model [online]. [cit. 2016-05-25]. Dostupné z: https://www.w3.org/DOM/

53

[23] ČESKO. Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích. In Sbírka zákonů ČR, ročník 2014, částka 127. Dostupné z: http://www.zakonyprolidi.cz/cs/2014-317 [cit. 2015-01-01]. ISSN 1211-1244 [24] EDITED BY SABU M. THAMPI..[ET AL.]. Recent trends in computer networks and distributed systems security: International Conference, SNDS 2012, Trivandrum, India, October 11-12, 2012. proceedings. New York, NY: Springer-Verlag Berlin Heidelberg, 2012. ISBN 36-423-4134-9. [25] STUTTARD, Dafydd a Marcus PINTO. Web application hacker's handbook: finding and exploiting security flaws. 2nd ed. Indianapolis: John Wiley, c2011. ISBN 978-1-118-02647-2.

54

Seznam obrázků Obrázek 3-1: Čtyřfázová metodika dle NIST [Zdroj: 14] .............................................. 14 Obrázek 4-1: Schematické zobrazení cesty útoku (Zdroj: [top10] ................................. 15 Obrázek 5-1: Výstup skenování aplikace nástrojem Burp Suite (Zdroj: autor) ............. 29 Obrázek 5-2: Zranitelnosti identifikované nástrojem Nessus (Zdroj: autor) .................. 30 Obrázek 5-3: HTTP požadavky testované na SQL injection (Zdroj: autor) ................... 31 Obrázek 5-4: Výstup nástroje SQLmap po nalezení SQL injeciton (Zdroj: autor) ........ 32 Obrázek 5-5: Ověření blind SQL injection pomocí Tamper Data (Zdroj: autor) ........... 33 Obrázek 5-6: Analýza náhodnosti tokenů relace (Zdroj: autor) ..................................... 34 Obrázek 5-7: Zdrojový kód formuláře pro vyhledávání (Zdroj: autor) .......................... 35 Obrázek 5-8: Zneužití vyhledávacího pole pomocí XSS (zdroj: autor) ......................... 35 Obrázek 5-9: XSS zranitelnost ve funkci phpinfo (Zdroj: autor) ................................... 36 Obrázek 5-10: Adresářový výpis volně dostupného adresáře (Zdroj: autor) .................. 37 Obrázek 5-11: HTTP požadavek, odesílaný po přihlášení (Zdroj: autor) ...................... 38

55

Seznam použitých zkratek DMZ

demilitarized zone

OSSTMM

Open Source Security Testing Methodology Manual

ISECOM

Institute for Security and Open Methodologies

OWASP

The Open Web Application Security Project

NIST

National Institute of Standards and Technology

SQL

Structured Query Language

XSS

Cross-Site Scripting

CSRF

Cross-Site Request Forgery

DBMS

Database Management System

XML

Extensible markup language

DOM

Document Object Model

HTTP

Hypertext Transfer Protocol

DoS

Denial of Service

56

Přílohy A - Report z penetračního testování

57

Příloha A – Report z penetračního testování

Report z Penetračního testování webových aplikací veřejné správy v kraji Vysočina

Tester: Filip Svoboda Datum: 23. 5. 2016

1


Souhrnná zpráva Tento dokument popisuje výsledek provedeného penetračního testování vybraných webových stránek veřejné správy v kraji Vysočina. Testování bylo provedeno v rámci bakalářské práce a mělo za cíl, identifikovat zranitelná místa a navrhnout řešení.

Rozsah práce Penetrační test byl zaměřen na testování 10 nejčastějších zranitelností podle dokumentu OWASP TOP 10 na následujících webových aplikacích:

    

Informační systém Krajského úřadu Kraje Vysočina eAmbulance kraje Vysočina eDotace kraje Vysočina eMeDOcS Rowanet

Souhrn nalezených zranitelností Počet zranitelností na stránkách

IS Krajského úřadu; 1

Rowanet; 4

eDotace; 5

eMeDOcS; 1 eAmbulance; 1 Graf 1: Zobrazení počtu zranitelností na jednotlivých stránkách

2

Příloha A – Report z penetračního testování Rozdělení zranitelností dle míry rizika

Nízká; 4

Vysoká; 7 Střední; 1

Graf 2: Zobrazení počtu zranitelností podle míry rizika

Popis nalezených zranitelností a navrhnutá opatření eDotace (http://extranet.kr-vysocina.cz/edotace/) Zranitelnost Vyhledávací formulář na stránce není správně ošetřen a obsahuje zranitelnost typu SQL injection. Využitím zranitelnosti byly odhaleny názvy databází, tabulek a jejich obsah. Injekci je možno vyzkoušet na stránce, vyhledáním dotazu ');WAITFOR DELAY ' 0:0:10'— Část za středníkem je možné nahradit jiným dotazem. Stejný vyhledávací formulář, obsahuje i zranitelnost typu XSS. Možno vyzkoušet vyhledáním dotazu "><script>alert(document.cookie); Mezi tagy <script> je možné dosadit jakýkoliv jiný javascriptový kód. Na URL http://extranet.krvysocina.cz/nepotrebny-majetek/info.php je dostupný výpis konfigurace PHP na serveru. Navíc použitá funkce obsahuje zranitelnost XSS. Možno vyzkoušet dosazením parametru do URL: info.php?a[]=<script>alert(/XSS/); Použitá verze webového serveru (Apache 2.0.54) obsahuje zranitelnost byte range attack.11 U přihlašovacího formuláře chybí ochrana proti CSRF. 11

Míra rizika Vysoká

Doporučení Pro vykonávání SQL dotazu využívat prepared statements, které definují strukturu dotazu a dosazené hodnoty samotný dotaz nemohou ovlivnit.

Vysoká

Ošetřit vstup vyhledávacího pole převedením speciálních znaků na entity, např. použitím PHP funkce htmlspecialchars().

Vysoká

Aktualizovat PHP na novější verzi. Odstranit stránku, využívající funkci phpinfo()

Vysoká

Aktualizovat webový server na novější verzi.

Nízká

Implementovat ochranu pomocí CSRF tokenu.

https://httpd.apache.org/security/CVE-2011-3192.txt

3


Informační systém Krajského úřadu Kraje Vysočina (https://www.krvysocina.cz) Zranitelnost Stránka obsahuje zranitelnost typu Unvalidated Redirects. Po přihlášení na adrese https://www.krvysocina.cz/AA/index.asp aplikace přebírá cílovou adresu pro přesměrování z URL adresy parametrem ReturnUrl

Míra rizika Střední

Doporučení Před přesměrováním kontrolovat cílovou adresu proti seznamu povolených adres nebo domén.

eAmbulance (http://www.eambulance.cz) Zranitelnost Na webovém serveru je povoleno použití metody DEBUG, které může vést k vykonávání debugovacích částí kódu uzavřených v direktivách #IF DEBUG….…#ENDIF

Míra rizika Nízká

Doporučení Vypnout debugovací metodu nastavením v konfiguračním souboru aplikace.

eMeDOcS (http://www.emedocs.cz/) Zranitelnost V aplikaci byla nalezena zranitelnost SQL injection na adrese http://emedocs.cz/index.php/detail/https:/ ?akce=zarizeni&arg1=detail&arg2=https Konkrétně je zranitelný parametr arg2, a to těmito typy SQL injection:  Boolean-based blind  AND/OR time-based blind  UNION query Využitím zranitelnosti byl zjištěn seznam databázových uživatelů, názvy databází, tabulek, obsah tabulek, včetně přihlašovacích jmen a hesel.





Rowanet (http://www.rowanet.cz/) Zranitelnost V aplikaci byla nalezena zranitelnost SQL injection ve funkci pro přepínání stránky do anglického jazyka na adrese http://www.rowanet.cz/index.php?akce=se kce&id_sekce=eng Konkrétně je zranitelný parametr id_sekce, a to těmito typy SQL injection:  Boolean-based blind  AND/OR time-based blind  UNION query Využitím zranitelnosti byl zjištěn seznam databázových uživatelů, názvy databází, tabulek, obsah tabulek, včetně přihlašovacích jmen a hesel.

4

Příloha A – Report z penetračního testování Aplikace obsahuje zranitelnost typu XSS na adrese http://rowanet.cz/session/index.php?sub mit=<script>alert(/XSS/); Stránka na adrese http://rowanet.cz/session/ zobrazuje zobrazuje informace o serveru, které může útočník dále využít. Byly identifikovány volně dostupné adresáře, které můžou obsahovat potenciálně citlivé informace. Věnujte pozornost adresám:  http://www.rowanet.cz/config/  http://www.rowanet.cz/download/  http://www.rowanet.cz/download/

Vysoká

Nízká

Nízká

Ošetřit vstup převedením nebezpečných znaků na entity, např. PHP funkcí htmlspecialchars() Odstranit stránku, nebo ji zpřístupnit pouze oprávněným uživatelům. Zkontrolovat, zda by adresáře mely být veřejně dostupné a případně je zpřístupnit pouze oprávněným uživatelům.

5

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika. Analýza bezpečnosti webových stránek veřejné správy v kraji

Recommend Documents