Zvýšení Zabezpeˇcení Služeb Sítˇe Liane

Zvýšení zabezpeceníˇ služeb síteˇ Liane

Diplomová práce

Studijní program: N2612 – Elektrotechnika a informatika Studijní obor: 1802T007 – Informacníˇ technologie

Autor práce: Bc. Vojtechˇ Šindler Vedoucí práce: Ing. Mojmír Volf

Liberec 2017 Improvement security Liane’s network

Diploma thesis

Study programme: N2612 – Electrotechnology and informatics Study branch: 1802T007 – Information technology

Author: Bc. Vojtechˇ Šindler Supervisor: Ing. Mojmír Volf

Liberec 2017

P1'<>h1zi§e11i sez112in1e11s‘aim,Zemamou Se vzta— Byljsem diplomovoupr-éciplné— zékon5. 3b.,0 autorském,zejména60 ékolm’hujed?o.121/2000pralvu § Berunavédomi,ieTechnickéuniverzitav Liberci(TUL)nezasahu— jedomychautorskychprévuiitfmmédiplomovépraiseprovnitfni potfebuTUL. Uiiji—1idiplomovouprzicineboposkytnu—1ilicencikjejimuVyuEi— ti,jsemsivédompovinnostiinformovat0 tétoskuteénostiTUL; v tomtopfipadéméTULprévoodemnepoiadovat?hradunék1a— d?,kte1'évy11a1o%i1ana vytvofenid?a,aidojejichskuteénéVy"§e. Diplomovouprécijsemvypracovalsamostatnés pouiitimuvedené literaxurya na zzikladékonzultacis vedoucimmédiplomovépréce a konzultantem. Souéasnééestnéprohlaéuji.5.9tiéténziverzeprziceseshodujes e1ek— tronickouVerzi,vloienoudoISSTAG.

‘ Datum.. )_F ? % Popis:///rd////4/ Abstrakt

Tato práce rešíˇ problematiku IT bezpecnostiˇ a jejího zvýšení v kontextu síteˇ LIANE. Tento problém byl rešenˇ za použití penetracníchˇ test˚utypu grey box. Na vybraných segmentech síteˇ došlo k provedení penetracníchˇ test˚u.Jejich výsledkem byl seznam nalezených zranitelností, dopad˚u a návrh˚u vedoucích k jejich odstranení.ˇ Na základeˇ výsledku penetracníchˇ test˚udošlo k zhodnocení bezpecnosti,ˇ návrhu rozvoje a proces˚uvedoucích ke zvýšení bezpecnostiˇ síteˇ LIANE.

Klícováˇ slova

IT security, penetracníˇ testování, asset management, patch management, vulnerability management, zneužití zranitelností, zabezpeceníˇ síteˇ

Abstract

This thesis solves the IT security issue and its increase in the context of the LIANE network. This problem was solved using gray box penetration tests. Selective segments of the network performed penetration tests. The result was a list of vulnerabilities, impacts, and suggestions that led to their removal. Based on the results of the Penetration Tests, the security, design and development of the LIANE network were assessed.

Key words

IT security, penetration testing, asset management, patch management, vulnerability management, vulnerability abuse, network security

5 Podekováníˇ

Dekujiˇ vedoucímu práce Ing. Mojmíru Volfovi za neocenitelné rady a pomoc priˇ tvorbeˇ diplomové práce. Dále bych chtelˇ podekovatˇ rodine,ˇ prátel˚umaˇ koleg˚um bez jejichž pomoci bych studium nikdy nedokoncil.ˇ Nejvetšíˇ dík patríˇ slecnámˇ Bc. Janeˇ Strnadové a Haneˇ Mocové, dále pak pán˚umBc. Jaromíru Vaneˇckoviˇ a Ing. Dušanovi Krásovi bez jejichž odborné pomoci by tato diplomová práce nebyla napsána v této podobe.ˇ

6 Obsah

Seznam zkratek...... 9

1 Vybrané cíle v kontextu síteˇ LIANE 12 1.1 Infrastrukturní prvky...... 12 1.2 Produkcníˇ servery a testovací servery...... 13

2 Metodika testování služeb síteˇ LIANE 15 2.1 Penetracníˇ testy jako nástroj IT security...... 15 2.1.1 Black box...... 17 2.1.2 Grey box...... 17 2.1.3 White box...... 17 2.1.4 Nástroje sloužící k penetracnímˇ test˚um...... 18 2.2 Metodika penetracníchˇ test˚u...... 19 2.2.1 Cyber kill chain...... 19 2.2.2 Použité metodiky pro úcelyˇ penetracníchˇ test˚u...... 24

3 Detekce bezpecnostníchˇ rizik v síti LIANE 25 3.1 Reconnaissance...... 25 3.1.1 Nmap...... 25 3.1.2 Nessus...... 26 3.1.3 Výsledky reconnaissance fáze...... 26 3.2 Weaponization...... 28 3.3 Delivery a Exploitace...... 29 3.4 Installation a ovládnutí stroje...... 30 3.5 Vybraná webová aplikace...... 30 3.6 Ukázka exploitu...... 33

4 Vyhodnocení penetracníchˇ test˚u 37 4.1 Limity penetracníchˇ test˚u...... 37 4.2 Celkový pocetˇ nalezených zranitelností...... 37

7 4.3 Nalezené zranitelnosti a bezpecnostníˇ problémy...... 38

5 Kroky vedoucí k nápraveˇ soucasnéhoˇ stavu 43 5.1 Asset management...... 45 5.1.1 Asset management database...... 45 5.1.2 Asset management work flow...... 46 5.2 Patch management...... 46 5.2.1 Databáze patch˚u...... 47 5.2.2 Patch management work flow...... 47 5.3 Vulnerability management...... 48 5.3.1 Vulnerability management database...... 48 5.3.2 Vulnerability management workflow...... 49 5.3.3 Návrh databáze urcenéˇ pro asset, pach a vulnerability management 50

Prílohyˇ 60

A Obsah priloženéhoˇ CD 61

8 Seznam zkratek

TUL Technická univerzita v Liberci FM Fakulta mechatroniky, informatiky a mezioborových studií Technické univerzity v Liberci DPI Deap Packet Scanning DoS Denial of Services DDoS Distributed Denial of Services XSS Cros-site scripting IPS Intrusion Prevention System NDA Non-disclosure agreement RoE Rule of Engagement FQDN Fully Qualiﬁed Domain Name ACL Acess List RCE Remote Code Execution RPC Remote Procedure Call LDAP Lightweight Directory Access Protocol PM Patch Management VM Vulnerability Management VBS Visual Basic Scripting RSS Rich Site Summary

9 Úvod

V dnešní dobeˇ internetu a sociálních sítí se dostává pojem IT security stále více do popredí.ˇ M˚užemesi klást otázku procˇ se tak deje.ˇ Pokud celý tento problém prevedemeˇ na sebe, tak zajisté nikdo nechce, aby jeho soukromé údaje (napr.:ˇ rodné císlo,ˇ císloˇ bankovního úctu,ˇ adresa trvalého pobytu, . . . ) padly do nepovolaných rukou. K tomu, aby se tak nestalo je zapotrebíˇ dodržovat urcitéˇ postupy, které míru zabezpeceníˇ našich dat zvýší. Díky tomu bude pro prípadnéhoˇ útocníkaˇ (v obecné terminologii oznacovanéhoˇ jako hackera) daleko složitejšíˇ naše data získat. Již zmínenýˇ problém ochrany osobních dat se dá úplneˇ stejneˇ prevéstˇ na ochranu citlivých informací v korporátním sektoru. V soucasnéˇ dobeˇ se spisovny již témeˇrˇ nevyskytují a vetšinaˇ dat se uchovává v elektronické podobe,ˇ tím pádem nabývá pr˚umyslová špionáž nových rozmer˚u.ˇ Prevážnáˇ vetšinaˇ spolecnostíˇ má pripojeníˇ k internetu, skrze které je možné provést pr˚unikdo firemní síte.ˇ Vyvstává zde otázka, jak takovému útoku, který by vedl k odcizení citlivých informací zabránit. Odpoved’ˇ není jednoduchá, a to predevšímˇ v dobe,ˇ kdy probíhá masivní rozvoj mobilních technologií a IOT (Internet Of Things). Práveˇ s rozvojem IOT se m˚užestát každé zarízeníˇ potenciální vstupní branou do soukromých sítí, a je pritomˇ jedno zda se jedná o malou ciˇ rozlehlou firemní sít’. Proto už priˇ samotném vytváreníˇ sítí je nutné brát v potaz možné vektory útok˚u.Je samozrejmé,ˇ že v návrhu osobních a firemních sítí jsou znacnéˇ rozdíly. V prípadˇ eˇ osobních sítí je v dnešní dobeˇ nejcastˇ ejiˇ útok veden skrze uživatelský pocítaˇ c,ˇ telefon, tablet, ciˇ pomocí tzv. social hackingu, ale jak již bylo zmínenoˇ výše, s nástupem IOT m˚užebýt veden skrze každé zarízení,ˇ které je pripojenéˇ do internetové síte.ˇ Je tedy velice pravdepodobné,ˇ že postupem casuˇ se metody pr˚unikumohou znacnˇ eˇ lišit. Oproti tomu ve firemních sítích je vektor˚udaleko více. Od útoku presˇ koncové stanice až k social hackingu. Proto je nutné priˇ budování síteˇ vytvoritˇ bezpecnostníˇ politiky, které budou po celou životnost v rámci firemní síteˇ dodržovány. Je samozrejmé,ˇ že bezpecnostníˇ

10 politiky by melyˇ být v pravidelných intervalech prehodnocoványˇ a v mnoha prípadechˇ i menˇ eny.ˇ Za zmínku stojí napríkladˇ velikost klíceˇ šifrovacích algoritm˚u,v roce 2015 vyšel clánekˇ Imperfect Forward Secrecy: How Diﬃe-Hellman Fails in Practice, který blíže popisuje jak je možné, že americká agentura NSA je schopna odposlouchávat i šifrovanou komunikaci [1]. Otázka zní jak co nejlépe zabezpecitˇ vaši sít’, zarízeníˇ ciˇ aplikaci. Bohužel, odpoved’ˇ na tuto otázku není v˚ubecsnadná. Samotná problematika tvorby bezpecnýchˇ aplikací ciˇ datových sítí by vydala na samostatnou diplomovou práci. Tato diplomová práce si klade za cíl, jak co nejspolehlivejiˇ oveˇritˇ zabezpeceníˇ a odolnost datové síte,ˇ aplikace ciˇ zarízeníˇ v˚uciˇ pokus˚um,kterým mohou být vystaveny ze strany útocník˚u,ˇ jejichž cílem je nejakýmˇ zp˚usobem aplikaci, zarízeníˇ ciˇ sít’ kompromitovat. Pod slovem kompromitovat si m˚užemepredstavitˇ tyto pojmy:

• ovládnutí zarízeníˇ za úcelemˇ sberuˇ informací

• zneužití výpocetníˇ síly

• oslabení obrany systému predˇ dalšími útoky

• etc.

V soucasnéˇ dobeˇ se pro úcelyˇ bezpecnostníchˇ audit˚upoužívají tzv. penetraˇcnítesty. Penetracníˇ tester sám sebe dostává do role hackera a díky tomu je schopen docílit takového testu jako kdyby (se vaše) testovaná infrastruktura, hardware ciˇ aplikace ocitly pod reálným útokem. Má diplomová práce se presnˇ eˇ o totéž bude snažit a to v souvislosti vybraných služeb, aplikací ciˇ infrastruktury v kontextu síteˇ LIANE.

11 1 Vybrané cíle v kontextu síteˇ LIANE

Je samozrejmostí,ˇ že univerzita nem˚uženést následky za chování svých student˚u,ale predstavmeˇ si scénár,ˇ který není úplneˇ nereálný, kdy student s nakaženým PC, které melˇ umístenoˇ na kolejích, prijdeˇ do ucebnyˇ TUL. Je velice pravdepodobné,ˇ že se nákaza (nejcastˇ ejiˇ pocítaˇ covýˇ vir) bude šíritˇ skrze ostatní PC univerzity. Za urcitýchˇ okolností by takový virus mohl nakazit i pocítaˇ ceˇ úcetníhoˇ oddelení,ˇ odkud by mohly být vyneseny prihlašovacíˇ údaje k bankovním úct˚umTUL.ˇ V rámci zadání diplomové práce byly ve spolupráci s panem Petrem Adamcem vhodneˇ vybrány služby a technologie, jejichž diskreditace by mohla mít pro celou sít’ LIANE nedozírné následky. Príklademˇ m˚užebýt aplikace STAG. Samozrejmˇ eˇ by bylo velice hezké vybrat všechny služby (technologie), které jsou na univerziteˇ používány, nicméneˇ potrebnéˇ množství znalostí, které by k tomu bylo potrebaˇ jeden clovˇ ekˇ není schopen pojmout. Taková práce by byla pro celou skupinu lidí, kteríˇ se zabývají problematikou IT security. Technologie, u kterých se budu snažit zvýšit úrovenˇ zabezpeceníˇ jsou:

• infrastrukturní prvky switche, routery, ﬁrewally

• servery

• poskytované služby webové stránky, FTP, SSO (Single Sign-On)

Priˇ tvorbeˇ diplomové práce mi byly dány d˚uvernéˇ informace o síti LIANE (napr:ˇ fyzické umístení,ˇ sít’ové rozsahy, IP adresy konkrétních stroj˚u).Tyto predanéˇ informace budou zámernˇ eˇ z diplomové práce vypušteny.ˇ

1.1 Infrastrukturní prvky

Za infrastrukturní prvek síteˇ se v soucasnéˇ dobeˇ považují:

12 • switche

• routery

• ﬁrewally

• etc.

Nekdoˇ by si mohl myslet, že smerˇ útoku skrze infrastrukturní cástiˇ sítí je dnes již okrajovou záležitostí. Je pravda, že tento smerˇ útok˚unení castý,ˇ ale pokud k nemuˇ dojde, o to jsou d˚usledky takového útoku nicivˇ ejší.ˇ Lze ríci,ˇ že dnešním trendem jsou spíše DoS a DDoS útoky, priˇ kterých dochází k nedostupnosti služeb. Za zmínku stojí útok, který je znám jako Black Nurse [2]. Tento útok je také typu DoS, ale d˚uvod procˇ ho v této diplomové práci zminujiˇ je zp˚usobjeho provedení. Podstata tohoto útoku tkví v pretíženíˇ CPU ﬁrewallu, díky tomu prestaneˇ ﬁrewall provádetˇ svojí práci. Prípojenéˇ síteˇ díky tomu ztratí svou konektivitu [2]. K pretíženíˇ CPU dochází pomocí jednoduchého ICMP paketu typu 3,3 (host unreachable)[2].

1.2 Produkcníˇ servery a testovací servery

Z logiky veciˇ by melyˇ spadat servery do infrastrukturní cásti.ˇ Já osobneˇ jsem se rozhodl rozdelitˇ infrastrukturní prvky a servery do dvou skupin, protože typy a možnosti provedení útok˚una servery a sít’ové prvky se podstatneˇ liší. Servery vetšinouˇ poskytují vetšíˇ množství služeb (Web, LDAP, samba, . . . ). Oproti tomu primárním využitím infrastrukturních (sít’ových) prvk˚uje zajišteníˇ pripojeníˇ k informacníˇ síti. Správné provedení útok˚una serverovou cástˇ má mnohdy daleko vetšíˇ následky, než prolomení prvk˚usít’ové infrastruktury.

Webové služby

Webové služby jsou kapitolou samy pro sebe a to díky tomu, že v drtivé vetšinˇ eˇ prípad˚uˇ je žádoucí, aby byly webové služby dostupné z internetu. Práveˇ díky tomu je nutné priˇ vytváreníˇ webových služeb dbát zvýšené opatrnosti. Dnes existuje mnoho zp˚usob˚u,jak lze webové služby kompromitovat, poprípadˇ eˇ jak se dostat k citlivým dat˚um,která mohou obsahovat. V soucasnéˇ dobeˇ se útocníciˇ castoˇ snaží dostat k prihlašovacímˇ údaj˚um[3].Existuje procento uživatel˚u,kteríˇ používají stejné prihlašovacíˇ údaje (jméno + heslo) témeˇrˇ všude. Pokud útocníkˇ tuto kombinaci zjistí, tak je velice pravdepodobné,ˇ že ji využije k tomu, aby se prihlásilˇ do dalších služeb a systém˚u.

13 Mezi nejcastˇ ejšíˇ tipy útok˚u,kterým jsou webové služby vystaveny patríˇ [3]:

• SQL injection

• XSS

• etc.

14 2 Metodika testování služeb síteˇ LIANE

Ke zjišteníˇ soucasnéhoˇ stavu zabezpeceníˇ m˚uže být použito mnoho metod. V mé práci jsem zvolil cestu tzv. penetraˇcníhotestování z (angl. penetration testing). Pod tímto pojmem je v informatice oznacovánaˇ metoda hodnocení zabezpeceníˇ pocítaˇ covýchˇ systém˚u,zarízeníˇ ciˇ aplikací. Cílem penetracníhoˇ testu není vyrešeníˇ bezpecnostníchˇ problém˚u.Jeho úcelemˇ je speciﬁcký zp˚usobproveˇrení,ˇ lépe reˇ cenoˇ zhodnocení úrovneˇ zabezpeceníˇ a zárovenˇ vytvoreníˇ souhrnné zprávy, která bude obsahovat pohled na celou úrovenˇ zabezpeceníˇ jak z technického (verze OS, služby prístupnéˇ z internetu, IPS, IDS, . . . ) tak i z organizacníhoˇ hlediska (social engineering, phishing, politika hesel, . . . ). [4] Proces penetracníchˇ test˚u zahrnuje podrobnou analýzu systém˚u se zameˇrenímˇ na prípadnéˇ bezpecnostníˇ nedostatky. Tyto nedostatky mohou vycházet ze špatného nastavení systém˚u, ciˇ ze známých nebo neznámých hardwarových a softwarových chyb (napr.ˇ ShellShock). Penetracníˇ testy jsou provádenyˇ z pohledu útocníkaˇ a castoˇ mohou vést k odhalení nedokonalostí systém˚u.Penetracníˇ tester sám sebe staví do role hackera, snaží se tedy co nejvíce napodobit chování potenciálního útocníka.ˇ Výsledky penetracníchˇ test˚uby melyˇ být predloženyˇ jejich zadavateli a to po jejich ukoncení.ˇ K penetracnímˇ test˚umje zvykem prikládatˇ informace o možných reálných d˚usledcíchnalezených chyb, dále pak návrhy možných protiopatrení,ˇ která by melaˇ vést k jejich odstranení.ˇ Díky tomu se stanou testované systémy bezpecnˇ ejšímiˇ a jejich prolomení ciˇ diskreditace bude o to nárocnˇ ejší.ˇ Penetracníˇ testy jsou jednou z mnoha komponent bezpecnostníhoˇ auditu. Samotné informace, které jsou výstupem penetracníhoˇ testování jsou d˚uležité,nicméneˇ nejvetšíˇ pridanouˇ hodnotu mají práveˇ v rámci bezpecnostníhoˇ auditu, priˇ kterém dochází i k validaci a následnému prepracováníˇ interních proces˚u ciˇ smernicˇ zadavatele. [5]

2.1 Penetracníˇ testy jako nástroj IT security

Proto, aby se mohly stát penetracníˇ testy nástrojem IT security je nutné dodržovat NDA a ROE, které se stanovují predˇ samotným zacátkemˇ penetracníchˇ test˚u.Jejich cílem je

15 ochrana jak zadavatele, tak i vykonavatele penetracníchˇ test˚u[6]. V pr˚ubehuˇ penetracníchˇ test˚uvznikají dveˇ oddelenéˇ skupiny a to [6]:

• Red team (na straneˇ vykonavatele)

• Blue team (na straneˇ objednavatele)

Cílem Red teamu je dosáhnout požadovaných výsledk˚utak, aby jejich aktivita nebyla zpozorována blue teamem. To, že dojde k odhalení cinnostˇ red teamu není úplneˇ špatne,ˇ jedním z mnoha cíl˚upenetracníchˇ test˚u,je zjišteníˇ reakcníˇ doby blue teamu na potencioální útok [6]. Priˇ provádeníˇ penetracníchˇ test˚u na TUL jsem byl jediným clenemˇ red teamu (v praxi bývá red team složen z více osob). Blue team predstavovalˇ pan Adamec, zbytek IT oddelení,ˇ správci server˚ua dohled ze strany poskytovatele internetového pripojeníˇ (Cesnet) [6]. Je d˚uležitézmínit, že dohled Cesnetu mé aktivity detekoval ve velice krátkém casovémˇ horizontu. Pokud by IP adresy, ze kterých penetracníˇ testy probíhaly, nebyly deﬁnovány v rámci RoE, došlo by k jejich blokaci smeremˇ k IP adrrsám TUL [6]. Predˇ samotným provádenímˇ penetracníchˇ test˚udochází k domluveˇ se zadavatelem na tom, jaký typ penetracníchˇ test˚ua nástroj˚ubudou v pr˚ubehuˇ testu použity. Penetracníˇ test lze rozdelitˇ do 3 kategorií. A to na [8]:

• Black box

• Grey box

• White box

Každá kategorie se od té následující liší poctemˇ typem informací, které jsou penetracnímuˇ testerovi dány. S pribývajícímˇ množstvím informací dochází k zmenˇ eˇ smeruˇ simulovaného útoku. V prípadˇ eˇ penetracníchˇ test˚utypu black box je simulován kybernetický útok externího subjektu(útocníka).ˇ S pribývajícímˇ množstvím informací se meníˇ pohled na pozici útocníkaˇ smeremˇ k zadavateli penetracníchˇ test˚u.V prípadˇ eˇ typu penetracníchˇ test˚u white box dochází k simulaci kybernetického útoku provádenéhoˇ subjektem uvnitrˇ organizace zadavatele. V prípadˇ eˇ všech typ˚u penetracníchˇ test˚u je možné testovat reakcníˇ dobu bezpecnostníchˇ složek testovaného subjektu.

16 2.1.1 Black box

Teto typ testování stroj˚unebo aplikací, zkoumá jejich funkcnost,ˇ a to bez znalosti jejích struktury ciˇ chování. Chování se v pr˚ubeh˚utohotoˇ typu penetracníchˇ test˚unejvíce blíží chování útocníka,ˇ který se nachází mimo testovanou organizaci. Penetracníˇ tester nemá žádné informace o cílové infrastruktureˇ (aplikaci). Testovací scénáreˇ (v rámci tohoto typu testu) jsou postaveny na speciﬁckých požadavcích, které má stroj nebo aplikace provádet.ˇ Cílem tohoto typu penetracníchˇ test˚uje simulace kybernetického útoku [8].

2.1.2 Grey box

Tento typ penetracníchˇ test˚use nachází v pomyslné šedé zóneˇ mezi penetracnímiˇ testy typu black box a white box [8]. Ve vetšinˇ eˇ testovacích scénár˚ujeˇ tento typ testování uprednostˇ novanouˇ metodou. D˚uvodem je to, že penetracnímuˇ testerovi nejsou dány všechny podklady o testovaném strojích ciˇ aplikacích. Tento typ test˚u vyžaduje velmi málo informací ze strany zadavatele. Penetracnímuˇ testerovi stacíˇ znát cílové IP adresy, URL ciˇ prístupováˇ práva k jednotlivým stoj˚um ciˇ aplikacím. Dále je možné penetracnímuˇ testerovi poskytnout základní informace, a to napríkladˇ [8]:

• sít’ové schéma bezpecnostníhoˇ perimetru

• prítomnostˇ nekterýchˇ prvk˚u(ﬁrewall, proxy)

• schéma aplikací (UML,ERD, . . . )

• etc.

V pr˚ubehuˇ studia na TUL jsem získal znalosti týkající síteˇ LIANE a zavedených procesních postup˚u.Díky této skutecnostiˇ jsem se priklonilˇ k tomu, že pro potrebyˇ penetracníchˇ test˚uv rámci diplomové práce použiji metodu grey box.

2.1.3 White box

Tento zp˚usob penetracníchˇ test˚u bývá uplatnenˇ priˇ simulaci kybernetických útok˚u provádenýchˇ subjektem, který má platné prihlašovacíˇ údaje do aplikace, stroje ciˇ cástiˇ síteˇ zadavatele [8][9].

17 Pro úcelyˇ testování bývá penetracnímuˇ testerovi zrízenˇ úcet,ˇ skrze který simuluje kybernetické útoky provádenéˇ subjektem zadavatele. K tomu, aby byla simulace co nejpresnˇ ejšíˇ potrebujeˇ penetracníˇ tester znát strukturu síteˇ LAN ciˇ testované aplikace [8]. V prípadˇ eˇ testování síteˇ LAN jsou penetracnímuˇ testerovi dány všechny podklady zabývající se topologií síteˇ zadavatele. Mezi tyto podklady patríˇ [8][9]:

• deleníˇ interní síteˇ

• schéma bezpecnostníhoˇ perimetru

• seznam server˚u

• etc.

V prípadechˇ kdy je testování aplikace jsou penetracnímuˇ testerovi dány její zdrojové kódy. Nad získanými kódy jsou provádenyˇ [9]:

• unit testy

• behaviorální analýzy zdrojového kódu

• integracníˇ testy

• etc.

2.1.4 Nástroje sloužící k penetracnímˇ test ˚um

Sada nástroj˚u,která je používána priˇ penetracnímˇ testování je podobná, ne-li úplneˇ totožná s nástroji, které používají hackeri.ˇ V soucasnéˇ dobeˇ je možné veškeré tyto nástroje stáhnout a následneˇ upravovat dle vlastní libosti a to proto, že v drtivé míreˇ jsou šírenyˇ pod licencí GNU. Samotnou kapitolou, která by vydala na nekolikˇ stránek je Metasploit framework, který poskytuje prostredíˇ pro jednoduché vytváreníˇ a editování exploit˚u[10]. Všechny nástroje používané priˇ penetracníchˇ testech slouží prevážnˇ eˇ k tomu, aby automatizovaly rutinní úkony (napr.:ˇ Metasploit framework). Drtivá vetšinaˇ nástroj˚upoužívaných behemˇ penetracníchˇ test˚u,je soucástíˇ linuxové distribuce, která je známá pod názvem Kali [10][7].

18 Automatické testování

Veškeré kroky a úkony spojené s penetracnímiˇ testy se dají plneˇ automatizovat. Samotná automatizace m˚užea nemusí být prínosem.ˇ Je zrejmé,ˇ že testování rozsáhlé infrastruktury by bez nich bylo velice obtížné, ale i v tomto prípadˇ eˇ dochází k deleníˇ na pomyslné skupiny. Toto deleníˇ je pouze na posouzení penetracníhoˇ testera. I prestoˇ je zde urcitáˇ šance, že penetracníˇ test skoncíˇ destruktivním výsledkem. Proto se v praxi plná automatizace bežnˇ eˇ nepoužívá [10].

2.2 Metodika penetracníchˇ test ˚u

V soucasnéˇ dobeˇ existuje mnoho metod, jak provádetˇ penetracníˇ testy a jejich následné vyhodnocení spojené s odhalováním chyb, které byly v jejich pr˚ubehuˇ nalezeny. Metodiky mnou vybrané byly zvoleny na základeˇ vlastních preferencí, kdokoliv jiný by si mohl vybrat jiné.

2.2.1 Cyber kill chain

Tento pojem vznikl odvozením z vojenské terminologie, známe jako kill chain. Cyber kill chain není prímoˇ metodikou, ale jedná se o popis základních krok˚u (milník˚u),které jsou dodržovány jak v prípadˇ eˇ penetracníchˇ test˚u,tak i v prípadˇ eˇ reálného útoku. Cyber kill chain je rozdelenˇ do 6 fází (krok˚u)[13]:

• Reconnaissance Fáze rozpoznávání/objevování zranitelností .

• Weaponization Fáze zbrojení.

• Delivery Doruceníˇ dat k cíli.

• Exploitation Využití zranitelnosti.

• Installation Instalace potrebnýchˇ nástroj˚u.

19 • Command and Control Ovládnutí cíle.

• Actions on objectives Plneníˇ predemˇ stanovených cíl˚u.

Cílem Cyber kill chainu je ovládnutí urcenéhoˇ cíle a je pritomˇ jedno o jaký cíl se jedná. V pr˚ubehuˇ penetracníhoˇ testování se standardneˇ postupuje maximálneˇ do 4 bodu. Fází exploitace aktivita na cílovém systému (stanici) koncí.ˇ

Reconnaissance

Reconnaissance je fáze rozpoznávání, která má za úkol zjistit co nejvíce informací o cíli. Na jejich základeˇ dojde k selekci cíl˚u,na které bude útok dále smeˇrovatˇ [13].

Social engineering (sociální inženýrství) odkazuje behemˇ provádenéhoˇ útoku (v kontextu informacníˇ bezpecnosti)ˇ na vystavení lidí psychologické manipulaci, která vede k vyzrazení utajovaných informací (napr:ˇ prihlašovacíˇ údaje, . . . ) [13][11]. Sociální inženýrství je jednou z mnoha podmnožin spolecenskýchˇ ved.ˇ Proto mnoho bezpecnostníchˇ pravidel stojí a padá na samotných uživatelích [13]. V soucasnéˇ dobeˇ jsou útocníkyˇ používány tyto typy útok˚u[12]:

• Baiting V tomto prípadˇ eˇ nechává útocníkˇ na frekventovaném místeˇ inﬁkovaný hardware (nejcastˇ ejiˇ USB disk). V prípadˇ eˇ pripojeníˇ disku do PC prípadnýmˇ nálezcem, dojde k nainstalování pocítaˇ covéhoˇ viru.

• Phishing Jedná se o proces rozesílání podvrženého emailu (SMS), který p˚usobíjako originál od verohodnéhoˇ zdroje(napríkladˇ od banky). Ve vetšinˇ eˇ prípad˚ujeˇ príjemceˇ zprávy požádán o sdílení svých prihlašovacíˇ údaj˚u ciˇ o jejich zmenuˇ na priloženémˇ odkaze.

• Spear Phishing Phishing cílený na urcitouˇ skupinu (napríkladˇ na zamestnance).ˇ

• Pretexting Proces utváreníˇ a využívání scénáre,ˇ behemˇ kterého se útocníkˇ snaží presvˇ edˇ citˇ obet’ˇ k provedení akce, na základeˇ které získá prístupˇ k potrebnýmˇ informacím.

20 • Scareware V tomto prípadˇ eˇ se útocníkˇ snaží presvˇ edˇ citˇ uživatele o tom, že má inﬁkovaný pocítaˇ cˇ poprípadˇ e,ˇ že došlo ke stažení nelegálního obsahu. Útocníkˇ samozrejmˇ eˇ obetiˇ podstrcíˇ rešení,ˇ které má odstranit jeho problémy. Ve skutecnostiˇ si uživatel nainstaluje do PC zadní vrátka, která útocníkˇ bez problém˚upoužije.

Obrázek 2.1: Príkladˇ phishingu

Odkaz umístenýˇ na predešlémˇ obrázku ve skutecnostiˇ neukazuje na uvedený odkaz, skutecnáˇ url je jiná viz. následující obrázek.

21 Obrázek 2.2: Príkladˇ phishingu

Po kliknutí na tento odkaz dojde ke stažení doc souboru, ve kterém jsou skrytá makra. Skrze tyto makra dochází k instalaci VBS skript˚u.V soucasnéˇ dobeˇ se pomocí takto upravených soubor˚ušíríˇ pocítaˇ covéˇ viry oznacovanéˇ jako Ransomware.

Weaponization

Weaponization (zbrojení) má za cíl pripravitˇ všechny možné prostredky,ˇ které jsou potrebaˇ k úspešnémuˇ provedení útoku. Výberˇ "zbraní"je závislý na výberuˇ cíl˚u,jiné prostredkyˇ se budou používat pro útok na webové servery, jiné pro útok na koncové stanice [13].

Delivery

Delivery znamená v prekladuˇ dorucení.ˇ Možností doruceníˇ škodlivého kódu (exploitu) je mnoho. Príklademˇ m˚užebýt [13]:

• Prílohaˇ v emailu

• Nakažená webová stránka

• USB zarízeníˇ

• etc.

22 Exploitation

V této cástiˇ dochází ke spušteníˇ exploitu. Jako exploit je v informatice oznacovánˇ program, data ciˇ sekvence príkaz˚u,kteréˇ využívají programátorskou chybu, na základeˇ které dojde k nestandardnímu chování aplikace (služby). Vzniklé chování používá útocníkˇ pro sv˚ujprospech.ˇ Exploity je možné delitˇ do dvou kategorií a to na místní (z angl. local) a vzdálené (z angl. remote). Ve vetšinˇ eˇ prípad˚ujeˇ cílem exploitu dosáhnout eskalace privilegií na úrovenˇ administrátora systému. Aby tohoto cíle šlo dosáhnout pomocí remote expoloitu, musí nutneˇ existovat nejakéˇ zranitelnost komponenty (aplikace) cílového stroje (v prípadˇ eˇ webových server˚use jednalo o zranitelnost oznacovanouˇ jako ShellShock). Pro potrebyˇ lokálního exploitu je nutné získat pristupˇ k danému zarízeníˇ ciˇ aplikaci. Nejcastˇ ejiˇ se tak stává na základeˇ social engineeringu, kdy se útocníkˇ prihlásíˇ ke službeˇ jako uživatel, od nehožˇ prihlašovacíˇ údaje získal. Dále následuje nahrání kódu, jehož cílem je dosáhnout eskalace privilegií [13].

Pivoting je oznacenímˇ metody pr˚unikudo vnitrníˇ síte.ˇ V rámci této metody využívá útocníkˇ napadenou stanici, která je oznacovánaˇ jako pivot. V prípadech,ˇ kdy není vnitrníˇ sít’ rozdelenaˇ do segment˚uoddelenýchˇ ﬁrewallem, je možné tímto zp˚usobemovládnout celou sít’ [14].

Installation

V tomto kroku má již útocníkˇ administrátorská oprávnení.ˇ Díky tomu m˚užeútocníkˇ dle vlastní libosti instalovat další nástroje, které bude používat v další fázi útoku. Poprípadˇ eˇ m˚užemodiﬁkovat služby, které na stroji již beží,ˇ príklademˇ toho m˚užebýt navázaní SSH tunelu pro potrebyˇ šifrované komunikace. V prípadech,ˇ kdy stojí v cesteˇ ﬁrewall s DPI inspekcí, je toto jediný zp˚usob,jak vynést citlivá data (v nekterýchˇ prípadechˇ je možné rozbalit i šifrovanou komunikaci, ale tento proces je výpocetnˇ eˇ nárocný)ˇ [13].

Command and Control

Za použití nainstalovaných nástroj˚ua použitých exploit˚udochází k ovládnutí stroje. Díky tomu dostane útocníkˇ prístupˇ do interní síteˇ [13].

Actions on objectives

Útocníkˇ pracuje dále na svých cílech mezi které patríˇ [13]:

23 • ovládnutí dalších systém˚u

• získávání, ciˇ mazání citlivých dat

• presmˇ erováníˇ komunikace V tomto prípadˇ eˇ m˚užedocházet ke cteníˇ šifrované komunikace (oznacovánoˇ jako útok Man in the middle).

• DoS nekterýchˇ služeb

• etc.

2.2.2 Použité metodiky pro úcelyˇ penetracníchˇ test ˚u

Za úcelemˇ správného posouzení nalezených zranitelností je nezbytné používat zavedená ohodnocení nalezených zranitelností. Jednoduchým ukazatelem je CVSS (z angl. Common Vulnerability Scoring System), díky tomuto ukazateli lze na první pohled urcitˇ možný vektor, skrze který je možné danou zranitelnost použít. Dále pak obtížnost k úspešnémuˇ provedení této zranitelnosti a v neposlední radˇ eˇ dopad zranitelnosti na cílový systém [15]. V mnoha prípadechˇ je lepší na posouzení dopadu zranitelnosti použít komplexnejšíˇ metodiku. V praxi se velice castoˇ používají:

• OWASP Tato metodika se používá pro posouzení zranitelností webových aplikací [16].

• OSSTMM Tato metodika se používá k posouzení zranitelností, které mohou mít dopad na kompromitace celých systém˚u.V rámci této metodologie se neberou v potaz jen nalezené zranitelnosti, ale dále také lidský faktor, nastavené procesy, programy a vazby mezi nimi [17].

24 3 Detekce bezpecnostníchˇ rizik v síti LIANE

K detekci bezpecnostníchˇ hrozeb na sít’ové úrovni bude docházet pomocí metodiky Cyber kill chain. Již na zacátkuˇ diplomové práce bylo rozhodnuto o tom, že penetracníˇ testy budou typu grey box.

3.1 Reconnaissance

V této fázi útoku se pokouším zjistit co nejvetšíˇ množství informací o svém cíli. Bohužel za tímto úcelemˇ jsem nemohl použít metody sociálního inženýrství a to na popud vedení TUL. Byl tedy proveden discovery sken. Pro zvýšení presnostiˇ byl discovery sken pouštenˇ z více fyzicky oddelenýchˇ lokalit a za použití vícero nástroj˚u.Pro tento úcelˇ jsem v rámci diplomové práce zvolil tyto nástroje: • Tenable Nessus

• Nmap

• Fing Pocetˇ zarízení,ˇ která byla za pomocí techtoˇ nástroj˚uobjevena, se až na jednotky shodoval. Drobné rozdíly prikládámˇ za vinu zp˚usob˚um,jak tyto nástroje zjišt’ují prítomnostˇ zarízeníˇ na síti. V další cástiˇ bylo nutné získat více informací o nalezených zarízeních.ˇ K tomuto úceluˇ jsem redukoval sadu nástroj˚una dva, a to Tenable Nessus a Nmap.

3.1.1 Nmap

Program Nmap je soucastíˇ vetšinyˇ linuxových distribucí a dá se oznacitˇ za jeden z nejpoužívanejšíchˇ nástroj˚u v oblasti IT security. Pro potrebyˇ reconnaissence, byl program spuštenˇ pomocí príkazuˇ v následujícím formátu: nmap -sT -A -T4 -pT:1-65335,U:1-65335 192.168.0/24 -oA < nazev_souboru>

25 Tento príkazˇ provádí:

• sken všech TCP a UDP port˚u

• detekci služeb na otevrenýchˇ portech

• otisk služeb (zjišteníˇ verze služby)

• detekci OS

Veškerá získaná data byla naimportována do prostredíˇ Metasploit frameworku a to za úcelemˇ zjednodušení následného testování zranitelností.

3.1.2 Nessus

Acˇ se jedná o pokrocilýˇ vulnerability skener, ve svém jádru i pro drtivou vetšinuˇ úkon˚u využívá program Nmap. Výhodou oproti Nmapu je testování stroj˚uproti celé škále zranitelností, které se každý den aktualizují.

3.1.3 Výsledky reconnaissance fáze

V rámci reconnaissance fáze jsem zjistil jeden velice zajímavý poznatek, a to i presto,ˇ že jsem provádelˇ reconnaissance pouze na nekolikaˇ vybraných segmentech síte.ˇ Stroje, které jsou pripojenéˇ do síteˇ LIANE, jsou od internetu oddelenyˇ firewallem. V prípadˇ eˇ TUL má firewall zárovenˇ funkci routeru, což samo o sobeˇ není nic neobvyklého, nicméneˇ na firewallu nejsou nastaveny žádné ACL a zárovenˇ je pridˇ elenaˇ pocítaˇ c˚umveˇ vnitrníˇ síti verejnáˇ IP. Díky kombinaci techtoˇ dvou faktor˚ujsou snadno detekovatelné i takové porty služeb, které by melyˇ být urcenyˇ pouze k interní komunikaci (napr:ˇ LDAP, RPC, JET-DIRECT, MS-DISCOVERY, . . . ). Nicméneˇ je nutné dodat, že zabezpeceníˇ server˚us OS Windows je na vyšší úrovni, než u ostatních OS. To je dáno tím, že tyto stroje jsou pripojenéˇ do domény tul.cz, komunikace na tyto porty je možná pouze ze zarízeníˇ v rámci domény. V rámci této fáze bylo nalezeno 166 stroj˚u.Tento pocetˇ odpovídá realiteˇ v testovaných rozsazích. U vetšinyˇ stroj˚uz této množiny se podariloˇ detekovat nainstalovaný operacníˇ systém.

26 Obrázek 3.3: Rozdeleníˇ operacníchˇ systém˚u

12% 8%

embedded 1% 6%

1% ESXi 2% 1% Fedora

15% FreeBSD

IOS

Linux

Unknown

VMware

Windows

54%

Na 166 strojích bylo celkem nalezeno 1383 otevrenýchˇ port˚u(služeb), v pr˚umeruˇ je tedy na každém zarízeníˇ otevrenýchˇ 8 port˚u.Priˇ cemžˇ nejvetšíˇ pocetˇ otevrenýchˇ port˚una jednom zarízeníˇ byl 48. Následující graf predstavujeˇ 13 nejcastˇ ejiˇ nalezených port˚u.Na prvním místeˇ se umístil port 80, skrze který probíhá HTTP komunikace. Mezi TOP 5 nejcastˇ ejšímiˇ porty bylo velice nezvyklé nalézt službu Telnet, který komunikuje skrze port 23, tento protokol není v soucasnéˇ dobeˇ moc používán a to z toho d˚uvodu, že neumí prenášetˇ data v šifrované podobe.ˇ

27 Obrázek 3.4: TOP 15 nejcastˇ ejšíchˇ služeb

počet 120 98 100 83 80

60 50 38 37 37 36 36 36 36 36 36 36 40

3.2 Weaponization

Fakt, že se jedná o plochou sít’ znacnˇ eˇ rozširujeˇ možnosti útok˚u.Tím pádem je možné použít vícero druh˚uexploit˚u.Bohužel, znacnáˇ cástˇ exploit˚uby mohla vést k nedostupnosti služeb stroje, ciˇ k jeho úplné likvidaci. Tyto typy exploit˚ubyly tedy zámernˇ eˇ vyrazeny.ˇ Vzhledem k tomu, že behemˇ reconnaissance fáze byly objeveny stroje, které bežíˇ již na nepodporovaném OS, v tomto prípadˇ eˇ se jednalo o Ubuntu 10.04 a Fedora 25. Tyto OS jsou zranitelné na tzv. chybu Shell Shock, bohužel, tato chyba není spojována jen s výše jmenovanými verzemi operacníchˇ systém˚u.Touto chybou napríkladˇ trpí mnoho verzí webových server˚u. Dále z pohledu útocníkaˇ bylo príjemnéˇ nalézt stroj, na kterém je implementována knihovna OpenSSL ve verzi nižší než 1.0.1g, ve všech starších knihovnách byla nalezena chyba, která je oznacovánaˇ jako HeartBleed. Jedná se o dost závažné zranitelnosti, protože provedení techtoˇ útok˚unení nikterak složité.

28 Obrázek 3.5: ShellShock curl -v -H "Content-Type:() {:;} echo /etc/passwd;" "http ://victimIP/cgi-bin/whatever.cgi"

Za úcelemˇ vytváreníˇ obsahu packet˚u (tzv. payloadu) jsem použil Metasploit framework. Vzhledem k velkému poctuˇ server˚u,na kterých je provozován webový server Apache, jsem obsah paket˚ucílil ke zneužití chyb v jazyce PHP.

3.3 Delivery a Exploitace

Škodlivý kód byl vždy dorucenˇ pomocí internetového pripojeníˇ server˚u.Ostatní metody vzhledem k zameˇreníˇ test˚unebyly použity. Samotná exploitace je velice provázana s fází zbrojení. V pr˚ubehuˇ diplomové práce jsem nejcastˇ ejiˇ používal exploitace zameˇrenéˇ smeremˇ k webovým server˚um. Tyto exploitace smeˇrovalyˇ k nesprávneˇ zabezpecenýmˇ adresár˚umˇ v rámci provozovaných stránek. Díky tomu jsem byl schopen obejít prístupováˇ práva na cílovém stroji. Jako príkladˇ slouží prístupováˇ práva ve složce cgi-bin. V této složce se nachází soubory, skrze které m˚užebýt proveden útok oznacovanýˇ jako ShellShock. V prípadˇ eˇ mnoha webových server˚uv sítí TUL je prístupˇ do této složky blokován. Bohužel byly nalezeny takové prípady,ˇ kdy šlo požadovaný škodlivý kód nahrát do jiného adresáre.ˇ Po úspešnémˇ exploitu dochází ve vetšinˇ eˇ prípad˚uk:ˇ

• RCE

• Buﬀer overﬂow

• DOS

• eskalaci privilegií

• prihlášeníˇ se pod cizími prihlašovacímiˇ údaji

• etc.

V mnoha prípadechˇ exploitací dochází k navázání spojení s cílovým strojem (napr:ˇ Shell shock). Skrze toto spojení probíhají další fáze kill chainu. V rámci provádenýchˇ exploitací nedošlo ke zneužití daných chyb. To mohlo být zapríˇ cinˇ enoˇ rozdíly v nastavení testovaných stroj˚u.K tomu, aby byly exploitace úspešnéˇ

29 by bylo zapotrebíˇ znát presnouˇ konﬁguraci testovaných stroj˚u. Toho by mohlo být docíleno instalací v rámci testovacího prostredí,ˇ kde bych se snažil dosáhnout stejného nastavení jako na p˚uvodních strojích. Vzhledem k velkému poctuˇ možných exploitací jsem od tohoto kroku zámernˇ eˇ upustil. Další cástiˇ cyber kill chainu proto nebyly reálneˇ provedeny. Proto obsah následujících kapitol bude pouze ilustracníhoˇ charakteru, který bude popisovat, jak by mohl útok dále probíhat.

3.4 Installation a ovládnutí stroje

Po tom co jsem docílil stabilního spojení s inﬁkovaným strojem, dochází k instalaci potrebnýchˇ nástroj˚u.Ve všech prípadechˇ exploit˚u,které byly provádeny,ˇ byl vždy po úspešnémˇ exploitu zaveden do pametiˇ stroje program (meterpreter), skrze který docházelo k další komunikaci. Proto, aby byla instalace potrebnýchˇ program˚uco nejméneˇ nápadná. Byly instalacníˇ balíckyˇ prenášenyˇ po zašifrovaném kanále, který zárovenˇ beželˇ na standardních portech. V prípadˇ eˇ Linuxu se jedná o port 22 (protokol SSH),v prípadˇ eˇ Windowsu šlo o port 443 (HTTPS). Oba tyto porty jsou na techtoˇ systémech hojneˇ používané. M˚ujdatový tok se tedy smíchal s datovým tokem bežnýchˇ uživatel˚ua díky šifrování komunikace, jsem prakticky znemožnil jakýkoliv DLP (z angl. Data Loss/Leak Prevention) sken prenášenýchˇ dat. Po dokonceníˇ instalací bylo nutné zahladit veškeré stopy (smazání instalacníchˇ balíck˚u),ˇ které by uživatel˚um, ciˇ administrátorovi mohly napovedˇ et,ˇ že se v jejich stroji nachází neznámý uživatel. Dalším d˚uležitýmkrokem je nastavení automatického obnovení spojení, skrze které je stroj ovládán.

3.5 Vybraná webová aplikace

V rámci penetracníchˇ test˚u došlo k oveˇreníˇ zabezpeceníˇ vybrané webové aplikace provozované na TUL. Vzhledem k povaze test˚u a jejich výsledk˚um bude jméno proveˇrovanéˇ aplikace v textu diplomové práce utajeno. Prvním krokem v rámci posouzení bezpecnostiˇ bylo získávání informací o prostredí,veˇ kterém je aplikace provozována. Aplikace bežíˇ na serveru, na nemžˇ je nainstalován OS Debian 8.0 (Jessie). Tuto informaci šlo získat jednoduše za použití programu nmap, ale u verze webového serveru nastaly komplikace s rozpoznáním jeho verze a to z d˚uvodu velice dobrého odladeníˇ aplikace a zabezpeceníˇ serveru.

30 I presˇ dobré zabezpeceníˇ zde byly drobné indicie:

• server je provozován na OS Linux

• Webová aplikace je napsána v jazyce JSP (Java Server Package).

• na serveru je otevrenýˇ port 8080 Tento port je v prevážnéˇ míreˇ užíván programem Apache/Tomcat.

• Dále otevrenýˇ port 7777. Tento port je používán databázemi Oracle a ješteˇ více meˇ utvrdil v presvˇ edˇ cení,ˇ že se jedná o program Apache/Tomcat.

Po dlouhém hledání se mi povedlo vyvolat chybu v uvnitrˇ RSS testované aplikace, která skoncilaˇ vyvoláním chybové stránky serveru.

Obrázek 3.6: Verze programu Apache/Tomcat

K nalezené verzi se vztahuje nekolikˇ zranitelností, z nichž jsou, podle mého názoru nejvážnejšímiˇ CVE-2016-8735 a CVE-2015-5174. Zneužití první zranitelnosti m˚uže vést až k RCE. Tato zranitelnost se opírá o chybu uvnitrˇ funkce JmxRemoteLifecycleListener, která komunikuje na vymezeném JMX portu. Osobneˇ si myslím, že pro potrebyˇ JMX je v prípadˇ eˇ tohoto serveru využíván port 7777 (standardneˇ se port 7777 používá pro JMX). Dle dokumentace je tato zranitelnost odstranenaˇ ve verzi 8.0.14-1+deb8u5[18]. Vzhledem k možnému destruktivnímu charakteru bylo od testu této zranitelnosti upušteno.ˇ

31 V rámci druhé zranitelnosti je možné dosáhnout preskoˇ ceníˇ do jiného adresáreˇ (v možných prípadechˇ až do /etc/passwd). Tato zranitelnost se opírá o chybu ve funkcích getResource, getResourceAsStream, a getResourcePaths. Vzhledem k nedestruktivnímu charakteru jsem se pokusil o preskoˇ ceníˇ do jiného adresáre.ˇ Tento preskokˇ se mi nepovedl, proto bych predemˇ ocekával,ˇ že již server prošel aktualizací na verzi, kde je tato zranitelnost odstranena.ˇ Tou je dle dokumentace 8.0.14-1+deb8u2 [19]. Obeˇ výše zmíneˇ zranitelnosti již dávno na testovaném stroji nemusí existovat. Detekce mnou provedené mohou být oznacenyˇ za false positive, a to z d˚uvodu backportu soubor˚u aplikací. Název sice z˚ustávástejný, ale konﬁguracníˇ soubory nikoliv. Samotná webová komunikace probíhá pomocí protokolu HTTPS. Vzhledem k povaze aplikace je dobré, že data jsou prenášenaˇ v šifrované forme.ˇ Bohužel délka šifrovacího klíceˇ je pouze 64 bit˚u,k takto zabezpecenéˇ komunikaci se váží dveˇ zranitelnosti CVE- 2016-2183 a CVE-2016-6329, které jsou souhrnneˇ oznacovanéˇ jako Sweet32: Birthday attacks[20]. Správné provedení tohoto útoku je nárocné,ˇ ale ne nemožné. Z d˚uvodu zvýšení zabezpeceníˇ bych doporucovalˇ prechodˇ na ECDSA klíceˇ o velikosti 256 bit˚u. V pr˚ubehuˇ dalšího sberuˇ informací jsem nalezl soubor robots.txt.

Obrázek 3.7: Obsah souboru robots.txt User-agent: * Disallow: /ws/services/ Disallow: /webaccess

Takto nastaveným souborem se zakazuje prístupˇ všem robot˚um (crawler˚um) do zmínenýchˇ složek. Výše zmínenéˇ nastavení zakáže automatické procházení adresár˚u,aleˇ cásteˇ cnˇ eˇ dokáže napovedˇ etˇ útocníkovi,ˇ kde by se mohly nacházet zajímavé informace. Aplikace disponuje prihlašovacímˇ formulárem,ˇ který není nikterak zabezpecenˇ proti brute force pokus˚umo prihlášení.ˇ To by samo o sobeˇ nebylo problémem, kdyby predˇ tímto serverem byla správneˇ nakonﬁgurována IPS. Nyní není problém generovat tisíce požadavk˚uza vterinu.ˇ Velice elegantním rešenímˇ by v soucasnémˇ stavu bylo pridáníˇ tzv. captchy. A to napríkladˇ po 3 špatných prihlášeních.ˇ Jako další krok následoval sken pomocí aplikace Arachni. Výsledkem tohoto skenu byla objevena chyba v rámci RSS. V rámci této chyby lze menitˇ atribut URL. Tato zranitelnost neutocíˇ na server samotný, ale lze skrze ní utocitˇ na webové klienty, které se k serveru pripojují.ˇ

32 V pr˚ubehuˇ vyhodnocování výsledk˚uaplikace Arachni byly objeveny stránky, na nichž je videtˇ konﬁguracníˇ rozhraní kalendár˚u.Pˇ resnˇ ejiˇ se jedná o jscalendar-1.0. Už to, že jsem se dokázal dostat ke zdrojovým kód˚umkalendáreˇ je zarážející. Bohužel soucástíˇ zdrojových soubor˚ukalendáreˇ byl i testovací soubor test.php, který v této verzi obsahuje chybu umožnujícíˇ XSS.Prítomnostˇ této zranitelnosti se mi nepovedlo potvrdit ani vyvrátit. Dle mého názoru objevený adresárˇ slouží pouze jako základ používaného kalendáreˇ v rámci aplikace. Bylo by velice zajímavé vyzkoušet XSS po prihlášeníˇ do aplikace. Od test˚u vnitrníˇ cástiˇ aplikace, která je dostupná po prihlášení,ˇ bylo upušteno.ˇ Samotné testy by šly provést na testovací verzi webové služby, ale ta se bohužel na TUL nenachází.

3.6 Ukázka exploitu

Jedním z úspešnˇ eˇ provedených exploit˚uv˚uciˇ stroj˚umuvnitrˇ vybraných rozsah˚usíteˇ LIANE byl exploit oznacenˇ jako CVE-2014-0160 též známý jako HeartBleed. Detaily k této zranitelnosti nebudu v rámci této kapitoly popisovat, detaily zranitelnosti její dopady a zp˚usobodstraneníˇ naleznete v rámci kapitoly 4.3 ESXi 5.5 < Build 1746974 / 5.5 Update 1 < Build 1746018 OpenSSL Library Multiple Vulnerabilities (remote check) (HeartBleed). Tato zranitelnost se projevuje na serverech, kde je nainstalovaná zranitelná verze OpenSSL knihovny. Verzi knihovny je možné zjistit za pomocí ﬁnger printingu služeb, které používají OpenSSL knihovnu. K tomuto úceluˇ lze použít nástroj nmap. Po objevení zranitelnosti (v rámci reconnaissance fáze) následovala prípravaˇ nástroj˚u, za jejichž použití došlo ke z neužití zranitelnosti. Pro tento úcelˇ jsem použil program Metasploit framework, jež je soucástíˇ linuxové distribuce Kali. Tento program se ovládá skrze CLI (z angl.: Command Line Interface) a vzhledem k tomu, že v obcasnýchˇ prípadechˇ prepínáˇ sít’ovou kartu do promiskuitního režimu, je dobré spouštetˇ tento program jako root. Ke spušteníˇ slouží príkazˇ msfconsole.

33 Obrázek 3.8: Spušteníˇ programu Metasploit framework

K provedení exploitu lze použít jeden z modul˚uv rámci Metasploit frameworku. Pro HeartBleed se jedná o modul openssl_heartbleed. Pro prepnutíˇ se do daného modulu slouží príkazˇ use. Celý príkazˇ vypadá takto: auxiliary/scanner/ssl/openssl_heartbleed

Príkazˇ show options k zobrazení možností nastavení daného exploitu.

34 Obrázek 3.9: Nastavení exploitu msf auxiliary(openssl_heartbleed) > show options

Module options (auxiliary/scanner/ssl/openssl_heartbleed):

Name Current Setting Required Description ------DUMPFILTER no Patternto filter leaked memory before storing MAX_KEYTRIES 50 yes Maxtries to dump key RESPONSE_TIMEOUT 10 yes Numberof seconds to wait for a server response RHOSTS xxx.xxx.xxx.35 yes Thetarget address range or CIDR identifier RPORT 443 yes Thetarget port (TCP) STATUS_EVERY 5 yes Howmany retries until status THREADS 1 yes Thenumber of concurrent threads TLS_CALLBACK None yes Protocolto use, "None" to use raw TLS sockets (Accepted: None, SMTP, IMAP, JABBER, POP3, FTP, POSTGRES) TLS_VERSION 1.0 yes TLS/SSL version to use (Accepted: SSLv3, 1.0, 1.1, 1.2)

Auxiliary action:

Name Description ------SCAN Check hosts for vulnerability

Pro potrebyˇ zobrazení dat, která unikla z pametiˇ OpenSSL doporucujiˇ nastavit

35 parametr VERBOSE na hodnotu TRUE (ve výchozím nastavení je hodnota false). Nastavení hodnot se provádí pomocí príkazuˇ set (set RHOST xxx.xxx.xxx.35). Ke spušteníˇ exploitu je možné použít více príkaz˚uaˇ to:

• run

• exploit

Výsledky, které tento exploit vrací mohou být r˚uzné.V pr˚ubehuˇ test˚use mi povedlo z pametiˇ dostat cástˇ prihlašovacíhoˇ formuláre.ˇ Z d˚uvodu malé vytíženosti serveru nebyly v informacích z pametiˇ žádná relevantní data.

Obrázek 3.10: Výstup exploitu ...... P=0.3..Accept-Encoding: gzip, deflate, br..Cookie: _ga=GA1 .2.2123985646.1473942696; vmware_soap_session="5222701b -047d-3b2c-2336-c20308692fcd"..Connection: keep-alive.. Upgrade-Insecure-Requests: 1..Authorization: Basic TTE0MDAwMTc4OjQ0NTA4NTY0Vm9qdGFA....&...p ....D..S..Xr ...... *...... ,...... <.=.....;....." .....!...... h2oap.org/soap/encoding/". xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". xmlns:soapenv="http://schemas.xmlsoap.org/soap/ envelope/". xmlns:xsd="http://www.w3.org/2001/ XMLSchema">. <_this type="SessionManager">ha-sessionmgr. . .

36 4 Vyhodnocení penetracníchˇ test ˚u

Test zranitelností probíhal od 1.2. 2017 do 31.3. 2017 jako testy internetového perimetru. Pro testování byly použity automatické nástroje Nessus, nmap a Metasploit framework. Vzhledem k povaze dat budou reporty z techtoˇ nástroj˚usoucástíˇ diplomové práce, ale z ryze zrejmýchˇ d˚uvod˚udojde k jejich cásteˇ cnéˇ anonymizaci. Mezi nejzávaznejšíˇ nálezy patríˇ identiﬁkace server˚u,na nichž je nainstalovaný nepodporovaný OS (takový OS bývá oznacovánˇ jako EOL - End Of Live). V prípadˇ eˇ techtoˇ systém˚udoporucujiˇ co nejrychleji aktualizovat na nekterouˇ z podporovaných verzí. Mezi další castéˇ nálezy patrilaˇ detekce slabých šifrovacích algoritm˚u. Stroje, na nichž byl tento problém detekován, jsou náchylné k typ˚umútok˚ujako je napríkladˇ Bar Mitzvah ciˇ SWEET32.

4.1 Limity penetracníchˇ test ˚u

Nekteˇ ríˇ výrobci OS (typicky Redhat/Centos/Ubuntu) backportují bezpecnostníˇ záplaty do starších verzí software. Nástroje pro testování zranitelností castoˇ nedokáží oveˇritˇ prítomnostˇ záplaty, a zranitelnost detekují pouze podle zjištenéˇ verze produktu, nebo predpokládají,ˇ že je patch již nainstalován. Reporty mohou obsahovat falešneˇ pozitivní i negativní hlášení (tzv. false positive / false negative). Další zpresnˇ eníˇ výstupu je možné pomocí manuálního oveˇreníˇ zranitelnosti.

4.2 Celkový pocetˇ nalezených zranitelností

V rámci testovaných segment˚usíteˇ bylo dohromady nalezeno 165 zranitelností, z nichž bylo:

• 18 úrovneˇ critical

• 36 úrovneˇ high

• 82 úrovneˇ medium

37 • 29 úrovneˇ low

Rozložení zranitelností skrze rozsahy je velice nevyvážené. Jeden z testovaných rozsah˚uobsahuje 88 ze 165 nalezených zranitelností. Dále se v tomto rozsahu vyskytuje vetšinaˇ zranitelnosti úrovneˇ Critical a High.

4.3 Nalezené zranitelnosti a bezpecnostníˇ problémy

Vzhledem k tomu, že nalezených zranitelností je velké množství, se proto dále venujiˇ jen temˇ z mého pohledu nejzávažnejším.ˇ

Tabulka 4.1: TOP 11 nejvíce kritických zranitelnosti

Nález IP adresy Závažnost

Unix Operating System Unsupported Version xxx.xxx.18.36, Critical 10 Detection xxx.xxx.xxx.37, xxx.xxx.xxx.82 PHP Unsupported Version Detection xxx.xxx.xxx.111, Critical 10 xxx.xxx.xxx.34 PHP prior to 5.5.x < 5.5.31 / 5.6.x < 5.6.17 Multiple xxx.xxx.xxx.34 Critical 10 Vulnerabilities VMware ESXi 5.5 < Build 3029944 OpenSLP RCE xxx.xxx.xxx.35 Critical 10 (VMSA-2015-0007) ESXi 5.5 < Build 3568722 / 6.0 < Build xxx.xxx.xxx.35 Critical 10 3568940 glibc DNS Resolver RCE (VMSA-2016- 0002) (remote check) OpenSSL 1.0.2 < 1.0.2i Multiple Vulnerabilities xxx.xxx.xxx.70 Critical 9.8 (SWEET32) PHP 5.6.x < 5.6.29 Multiple Vulnerabilities xxx.xxx.xxx.54 Critical 9.8 ESXi 5.5 < Build 1746974 / 5.5 Update 1 < Build xxx.xxx.xxx.35 High 9.4 1746018 OpenSSL Library Multiple Vulnerabilities (remote check)(Heartbleed) OpenSSL ’ChangeCipherSpec’ MiTM Vulnerability xxx.xxx.xxx.35 High 9.3 PHP < 5.3.12 / 5.4.2 CGI Query String Code xxx.xxx.xxx.111 High 8.3 Execution Unsupported Web Server Detection xxx.xxx.xxx.111 High 7.5

38 Operating System Unsupported Version

Pro odstraneníˇ zranitelností na postižených strojích je nutné provést aktualizaci nainstalovaných OS na podporovanou verzi. V rámci penetracníchˇ test˚ubyl objeven stroj, na nemžˇ nainstalovaný OS má podporu ukoncenouˇ k datu 24.6.2011.

PHP Unsupported Version Detection

Stejneˇ jako v minulém prípadˇ eˇ se jedná o již nepodporovanou verzi. V tomto prípadˇ eˇ se konkrétneˇ jedná o nepodporovanou verzi jazyka PHP a to verzi 4.0.3p11. Datum ukonceníˇ podpory této verze PHP je k 5.4.2012. Pro odstraneníˇ doporucujiˇ aktualizovat stroj alesponˇ na verzi 5.6.x.

PHP prior to 5.5.x < 5.5.31 / 5.6.x < 5.6.17 Multiple Vulnerabilities

Na postihnutém stroji se nachází verze jazyka PHP 5.5.22. Tato verze PHP obsahuje více zranitelností. Mezi nejnebezpecnˇ ejšíˇ patríˇ zranitelnost oznacenáˇ jako CVE-2016- 7132. Zranitelnost spocíváˇ v chybeˇ funkce php_wddx_pop_element(), která se nachází v souboru wddx.c. Tato chyba se m˚užeprojevit priˇ deserializaci paket˚u.Behemˇ probíhající deserializaci dochází k uvolneníˇ místa v pameti,ˇ kam m˚uže být nahrán libovolný spustitelný kód [21]. Pro odstraneníˇ této chyby je nutné aktualizovat verzi jazyka PHP na verzi 5.6.17 a vyšší.

VMware ESXi 5.5 < Build 3029944 OpenSLP RCE (VMSA-2015-0007)

Na postiženém stroji je nainstalován VMware ESXi ve verzi 5.5 predˇ sestavením 3029944. Tato verze systému obsahuje chybu, díky které lze docílit vzdáleného spušteníˇ kódu. Tato chyba se nachází ve funkci SLPDProcessMessage(), která je soucástíˇ OpenSLP knihovny. Tuto chybu lze využít za úcelemˇ vzdáleného spušteníˇ kódu (RCE - Remote Code Execution) nebo nedostupnosti služeb (DOS). Odstraneníˇ chyby je možné po prechoduˇ na verzi ESXi 550-201509101 [22].

ESXi 5.5 < Build 3568722 / 6.0 < Build 3568940 glibc DNS Resolver RCE (VMSA- 2016-0002) (remote check))

Tato zranitelnost postihuje systémy VMware ESXi 5.5 predˇ predˇ sestavením 3568722 nebo systém VMware ESXi 6.0 predˇ sestavením 3568940. Takový stroj je ovlivnenˇ

39 Obrázek 4.11: Nastavení IP tables iptables -I INPUT -p udp --sport 53 -m length --length 2049: -j DROP iptables -I INPUT -p udp --sport 53 -m length --length 2049: -j LOG iptables -I INPUT -p tcp --sport 53 -m length --length 2049: -j DROP iptables -I INPUT -p tcp --sport 53 -m length --length 2049: -j LOG ip6tables -I INPUT -p udp --sport 53 -m length --length 2049: -j DROP ip6tables -I INPUT -p udp --sport 53 -m length --length 2049: -j LOG ip6tables -I INPUT -p tcp --sport 53 -m length --length 2049: -j DROP ip6tables -I INPUT -p tcp --sport 53 -m length --length 2049: -j LOG chybou v knihovneˇ GLIBC (GNU C library) na straneˇ DNS klienta. Pokud útocníkˇ vytvoríˇ správný DNS dotaz, tak pak skrze vstupní parametry funkce getaddrinfo(), je možné docílit vzdáleného spušteníˇ kódu (RCE) ciˇ prevzetíˇ kontroly nad DNS službou, což m˚uže vést k útoku MiTM (Man in The Middle). Pro odstraneníˇ této chyby doporucujiˇ update na verzi vCenter Server 5.5 Update 3c v prípadˇ eˇ VMware 5.5, nebo na verzi vCenter Server 6.0 Update 2, v prípadˇ eˇ VMware 6.0 [23]. V prípadˇ eˇ kdy update není možný, je nutné nastavit IPtables na jednotlivých strojích následujícím zp˚usobem:[24]

OpenSSL 1.0.2 < 1.0.2i Multiple Vulnerabilities (SWEET32)

Tato zranitelnost se opírá o nalezené chyby v rámci knihovny OpenSSL 1.0.2h. Zmínenáˇ knihovna obsahuje mnoho zranitelností, za zmínku stojí zranitelnosti [25]:

• CVE-2016-2178

• CVE-2016-2183 - známá jako SWEET32.

• CVE-2016-6307 - známá jako GHOST.

40 K odstraneníˇ této zranitelnosti stacíˇ aktualizovat knihovnu na alesponˇ na verzi 1.0.2i.

PHP 5.6.x < 5.6.29 Multiple Vulnerabilities

Na postižené stanici došlo k detekci zranitelné verze jazyka PHP a to ve verzi 5.6.27. Tato verze je náchylná k mnoha druh˚umexploit˚u.Jeden z možných exploit˚uje oznacenýˇ jako VulnDB 146957, tento exploit je veden v pod PHP bug id #73418. V tomto prípadˇ eˇ se nachází chyba ve funkci _php_imap_mail(), která je uložena v souboru php_imap.c. Pokud je na vstup této funkce zaslán dostatecnˇ eˇ dlouhý retˇ ezec,ˇ tak priˇ jeho zpracování dochází k preteˇ ceníˇ pametiˇ zásobníku. Preteˇ ceníˇ m˚uževést k nedostupnosti služeb ciˇ provedení libovolného kódu. K odstraneníˇ chyby je nutné prejítˇ alesponˇ na verzi 5.6.29 [26].

ESXi 5.5 < Build 1746974 / 5.5 Update 1 < Build 1746018 OpenSSL Library Multiple Vulnerabilities (remote check) (Heartbleed)

V tomto prípadˇ eˇ se jedná o chybu OpenSSL knihovny. Dotycnáˇ chyba je známá pod kódem CVE-2014-0160, ale castˇ ejiˇ pod jménem HeartBleed. Tato zranitelnost umožnujeˇ komukoliv cístˇ citlivá data alokovaná v pametiˇ a to až o velikosti 64KB. V rámci dat lze najít [27]:

• prihlašovacíˇ údaje

• privátní klíceˇ

• etc.

Získání vyjmenovaných údaj˚um˚uževést k:

• ovládnutí stoje

• krádeži dat

• etc.

I presˇ vysoké skóre je tato chyba kategorizována jako High a ne jako Ciritical. Chyba je takto kategorizovaná z toho d˚uvodu, že ve vetšinˇ eˇ prípad˚udostaneˇ útocníkˇ data, se kterými nelze pracovat dál. Tato chyba je odstranenaˇ v patchy ESXi550-201404420 pro ESXi 5.5. Pro systém ESXi 5.5 update 1 je chyba odstranenaˇ v patchy ESXi550-201404401 [28].

41 OpenSSL ’ChangeCipherSpec’ MiTM Vulnerability

Opetˇ se jedná o zranitelnost OpenSSL knihovny. Tato chyba je založena na prijetíˇ speciálneˇ vytvorenéhoˇ handshaku. Pokud server/klient takový požadavek prijme,ˇ stává se z útocníkaˇ prostredníkˇ v komunikaci (Man in The Middle). Uvedená chyba byla plneˇ odstranenaˇ ve verzi knihovny 1.0.1h [29]. Kategorizace High je z d˚uvodu obtížnosti tohoto exploitu.

PHP < 5.3.12 / 5.4.2 CGI Query String Code Execution

Jedná se o chybu ve verzi jazyka PHP 4.0.3.p11, která je na serveru nainstalována. Chyba je umístenaˇ v souboru cgi_main.c. Zneužití chyby umožnujeˇ útocníkoviˇ získat zdrojový kód apliakce ze serveru nebo spustit potencionálneˇ škodlivý kód. Zárovenˇ v postihnutých verzích PHP se používají stejné prepínaˇ ceˇ príkaz˚u,jakoˇ jsou argumenty príkazovéˇ rádkyˇ (napr:ˇ ’-s’,’-d’, . . . ) [30]. Tato chyba jazyka je zneužitelná pouze v prípadˇ e,ˇ kdy je na stroji nainstalován webový server Apache používající CGI skripty. Proti zneužití této zranitelnosti je imunní Apache server, na kterém je možno konﬁgurovat mod_php. Samotná chyba je opravena od verze jazyka 5.3.12. Ve verzi 5.4.1 byla znova tato chyba objevena. Od verze 5.4.2 se tato zranitelnost již neobjevuje [30].

Unsupported Web Server Detection

Na stroji je nainstalována nepodporovaná verze webového serveru a to Apache 1.3.12. Doporucovalˇ bych tedy prechodˇ na z verzi 2.4.x a vyšší.

42 5 Kroky vedoucí k nápraveˇ soucasnéhoˇ stavu

Soucasnýˇ stav zabezpeceníˇ síteˇ LIANE nelze shrnout z jediného pohledu. Z pohledu fyzického zabezpeceníˇ je sít’ dobreˇ chráne.ˇ Dále disponuje záložní konektivitou v prípadˇ eˇ výpadku primárního pripojení,ˇ které zprostredkováváˇ CESNET. Z pohledu správy uživatelských úct˚uaˇ nastavené politiky hesel je nutné prihlédnoutˇ k tomu, že se jedná o akademickou organizaci, tudíž celkový prístupˇ je více benevolentní, než je tomu zvykem v korporátním prostredí,ˇ ale i prestoˇ by pro zamestnanceˇ univerzity melyˇ platit striktnejšíˇ predpisyˇ (z pohledu správy úct˚uaˇ s tím zmínenouˇ politikou hesel). Nicméneˇ benevoletní prístupˇ ke správeˇ ostatních úct˚ubyˇ se melˇ zmenit.ˇ Dne 25.5. 2018 vejde v platnost nová evropská smerniceˇ o ochraneˇ osobních údaj˚u.Tato smerniceˇ je oznacovánaˇ jako GDPR. (z angl. General Data Protection Regulation) [31].

GDPR se dotkne každého, kdo zpracovává nebo shromažd’uje data fyzických osob. Toto narízeníˇ míríˇ na ﬁrmy, instituce i jednotlivce p˚usobícív rámci EU. Od již zmínenéhoˇ data nahradí GDPR do soucasnéˇ doby používaný zákon c.ˇ 101/2000 Sb., o ochraneˇ osobních údaj˚u.Období od dubna 2016 do kvetnaˇ 2018 je urcenéˇ k prípravˇ e.ˇ V tomto období by u všech organizací meloˇ dojít k zrevidování zp˚usobu a informacníchˇ systém˚u, které nakládají s osobními údaji [31]. Predˇ tím, než prejduˇ k samotnému hodnocení zabezpeceníˇ infrastruktury síteˇ LIANE, bych rád rozdelilˇ úrovenˇ zabezpeceníˇ infrastruktury do nekolikaˇ úrovní [32]:

1. V této úrovni nejsou na ochranu síteˇ nasazené žádné produkty.

2. Produkty byly zakoupené, ale nejsou nakonﬁgurované.

3. Produkty jsou nakonﬁgurované, ale v pr˚ubehuˇ casuˇ nedochází ke zmenˇ eˇ konﬁgurací vzhledem k aktuálním hrozbám.

4. V této úrovni dochází k napojení produkt˚una log management.

43 5. Poslední úrovenˇ se zabývá vyhodnocováním sbíraných log˚u.V soucasnéˇ dobeˇ se takové vyhodnocování provádí na systémech SIEM (z angl. Security Information and Event Management).

Z mého pohledu, který vyplývá z provádenýchˇ penetracníchˇ test˚u, jsem došel k záveru,ˇ že zabezpeceníˇ síteˇ je na pomezí 2. a 3. úrovne.ˇ V sítí se nachází nekolikˇ firewall˚u,které filtrují provoz na základeˇ definovaných ACL. Takovým príklademˇ budiž firewall oddelujícíˇ koleje TUL od zbytku síte.ˇ Univerzitní sít’ je sice logicky rozdelenaˇ na virtuální podsíteˇ (VLAN - Virtual Local Area Network), ale mezi temitoˇ sítemiˇ nejsou nastavené žádné ACL. Je tedy možné bez sebemenších potíží pristupovatˇ i do takových cástíˇ síte,ˇ které by melyˇ být bežnémuˇ uživateli skryty (napr.:ˇ management porty zarízení,ˇ . . . ). Dalším vcelku zarážejícím nastavením je absence ACL priˇ pohledu z venkovní (internetu) síte.ˇ Díky adresaci urcitýchˇ zarízeníˇ pomocí verejnýchˇ IP adres je v celku jednoduché se k takovým zarízenímˇ dostat. Behemˇ penetracníchˇ test˚ujsem objevil na zarízeníchˇ takové porty, které by melyˇ být viditelné pouze v rámci síteˇ LAN. Jedná se o tyto porty:

• 445 - MS-DS

• 135 - RPC

• 389 - LDAP

• etc.

Tento stav vidím jako velice vážný a pokud možno bych doporucilˇ zavést ACL, které by tento stav vyrešily.ˇ Dalším ponekudˇ znepokojujícím stavem je absence IPS. Díky této absenci bylo možné provádetˇ penetracníˇ testy bez sebemenšího omezení. Pokud by byla IPS nasazená, tak komunikace, spojená s 99% provádenýchˇ exploit˚u,by byla ukoncenáˇ na ﬁrewallu. Proto bych doporucovalˇ aktivování a nastavení IPS/IDS proti d˚uležitým systém˚umuniverzity. Dle mého názoru by bylo dobré dostat zabezpecíˇ síteˇ LIANE až na úrovenˇ 5. K tomu by bylo zapotrebíˇ zavést log managemat a další vyhodnocování log˚u.Za tímto úcelemˇ je možné použít Open Source rešení.ˇ V dnešní dobeˇ se pro tyto úcelyˇ castoˇ požívají programy Logstash (jako log management) a Kibana (jako vizualizacníˇ nástroj). Jedná o soucástiˇ open source produktu Elasticsearch. Vzhledem k velkému poctuˇ zranitelností, které byly v rámci penetracníchˇ test˚u odhaleny, doporucujiˇ zavést na TUL v Liberci následující buisness procesy:

44 • Asset management

• Patch management

• Vulnerability management

Tyto procesy pomohou se zlepšením soucasnéhoˇ stavu. Dále pak budou nápomocné priˇ potírání takzvaného Shadow IT. Zavedení techtoˇ proces˚uby meloˇ být ruku v ruce s vytvorenímˇ jednotné IT smerniceˇ na TUL

5.1 Asset management

Asset management se dá považovat za jeden z nejzákladnejšíˇ buisness proces˚u,který by se melˇ v rámci univerzity provozovat. Bez udržovaného asset managementu je zavedení proces˚u patch managementu a vulnerability managementu velice obtížné, ne-li nemožné. Asset management dává administrátorovi prehledˇ o všech zarízeních,ˇ které se v jeho sítí nachází a spolecnˇ eˇ s použitím NAC (Network Acess Control) dokáže velice efektivneˇ potírat Shadow IT.

5.1.1 Asset management database

Samotná struktura asset databáze není složitá, ale složité ciˇ spíše casovˇ eˇ nárocnéˇ je udržovat jí ve stavu, který odpovídá realite.ˇ Položky, které budou mnou vybrány jako soucástˇ asset DB jsou výsledkem poznatk˚u,které jsem získal v rámci konzultace výsledk˚u penetracníchˇ test˚u.Priˇ tvorbeˇ jsem tedy vycházel z potrebˇ NTI a ne celé univerzity. Pokud bych vycházel z potrebˇ celé univerzity, je možné, že by struktura databáze mohla být naprosto odlišná. Databáze by tedy melaˇ obsahovat seznam pripojenýchˇ zarízeníˇ spolecnˇ eˇ s:

• seznamem nainstalovaného SW a jeho verzí

• Odpovednouˇ osobou za dané zarízeníˇ

• FQDN

• IP adresou (v prípadˇ eˇ kdy má stroj pevnou IP)

• management IP adresu (v prípadˇ eˇ server˚ua sít’ových prvk˚u)

• typem zarízeníˇ

45 • datem zapojení zarízeníˇ

• statusem zarízeníˇ (produkce,instalace,test)

5.1.2 Asset management work ﬂow

Následující obrázek predstavujeˇ navržený workﬂow asset managementu pro potrebyˇ TUL.

Obrázek 5.12: Asset management workﬂow

5.2 Patch management

Hlavní cíl patch managementu je udržovat produkcníˇ systémy aktualizované, primárneˇ vzhledem k bezpecnostnímˇ hrozbám, sekundárneˇ s ohledem na stabilitu a v neposlední radˇ eˇ kv˚uli dostupnosti nových funkcí. Patch management je realizován na úrovni jednotlivých vývojových vetvíˇ spravovaných produkt˚u,tj. do procesu PM patríˇ nasazování kritických oprav, drobných ﬁx˚u,vetšíchˇ oprav (service pack, hotﬁx akumulator) a to ve spolupráci s technickým týmem a TSA. Pod proces PM nepatríˇ nasazování nových vývojových vetvíˇ produkt˚u. V souvislosti s PM je nutné zavést v rámci IT univerzity tyto pojmy:

• Databáze patch˚u

• Patch hunter

46 Osoba odpovednáˇ za udržování aktuální databáze patch managementu. Sleduje webové stránky výrobce, release notes, mailing listy a ostatní zdroje a v prípadˇ eˇ vydání nové verze nebo patche aktualizuje databázi patch managementu.

• Patch tester Osoba odpovednáˇ za otestování noveˇ vydaného patche a to obecneˇ bez ohledu na plán nasazení. Výsledky testování sdelíˇ clen˚umservisníhoˇ týmu.

• Patch implementátor Osoba poveˇrenáˇ touto rolí má na starost implementaci patche v produkcnímˇ prostredí,ˇ dále pak i provedení akceptacníchˇ test˚u.V mnoha prípadechˇ bývá Patch tester a Patch implementátor jednou a tou samou osobou.

5.2.1 Databáze patch ˚u

Databáze sama o sobeˇ musí obsahovat seznam používaných produkt˚uv rámci LIANE a seznam jejich aktuálních verzí. Dále by melaˇ být úzce svázána s asset databází a to do takové míry, že asset databázi rozširujeˇ o informace jako:

• Dostupné verze (nové verze produkt˚u, (ne)nasazené patche/service packy, (ne)nasazené hot ﬁxi)

• Predpokládanýˇ plán nasazení

• Sadu akceptacníchˇ test˚u,poprípadˇ eˇ HW/SW požadavky pro testovací lab, které slouží ve fázi obecného testování

5.2.2 Patch management work ﬂow

Za úcelemˇ zvýšení IT bezpecnostiˇ musí probíhat patch management neustále. Po objevení nového patche vždy následuje jeho kategorizace a následné uložení do databáze patch˚u. Níže priloženýˇ obrázek deﬁnuje workﬂow patch managementu.

47 Obrázek 5.13: Patch management workﬂow

5.3 Vulnerability management

Hlavním cílem vulnerability management je odhalení chyb zarízení,ˇ které nejsou na první pohled viditelné. Díky tomu, je možné si udelatˇ detailnejšíˇ predstavuˇ o tom, jak by mohl vést potencionální vektor útoku. Dalším beneﬁtem je možnost nalezené zranitelnosti odstranit a to na základeˇ výstup˚uz Patch managementu. V prípadech,ˇ kdy patch ješteˇ nebyl vydán, má administrátor síteˇ minimálneˇ informace o zranitelnosti, na základeˇ kterých m˚užeprovést nastavení IPS/IDS ciˇ samotného systému tak, aby možnost napadaní eliminoval. Bohužel velice castoˇ vedou tyto kroky k omezení funkcnostiˇ systému. To, zda takový postup bude nasazen, záleží na rozhodnutí administrátora síteˇ a TSA. (z angl. Technical Solution Architect)

5.3.1 Vulnerability management database

K tomu, aby používání této databáze dávalo smysl musí dojít k její integraci s asset databází a patch databází. Ve chvíli, kdy je objevena zranitelnost, je možné ji priˇ raditˇ ke konkrétní množineˇ asset˚ua dále nastavit kroky vedoucí k jejich odstranení.ˇ Mezi informace, které by melyˇ bezpodmínecnˇ eˇ být soucástíˇ databáze zranitelností patrí:ˇ

• množina asset˚u,na nichž se zranitelnost objevuje

48 • seznam opravných patch˚u

• CVSS (z angl. Common Vulnerability Scoring System) Pod tímto oznacenímˇ bývá uvádenˇ vektor, skrze který m˚užebýt zranitelnost zneužita, dále je pak uvedeno císloˇ od 1-10, které znacíˇ míru rizikovosti.

• fáze, ve které se nachází odstraneníˇ této zranitelnosti

• priˇ razenýˇ rešitelˇ

5.3.2 Vulnerability management workﬂow

Vulnerability management workﬂow bývá nekdyˇ oznacovánoˇ jako životní cyklus zranitelnosti. K tomu, aby mohl být v˚ubecproces VM managementu prováden,ˇ je nutné mít ve své síti dedikovaný stroj, z nehožˇ bude vulnerability sken prováden.ˇ Termín spušteníˇ VM skenu je cistˇ eˇ v režii správc˚usíteˇ a TSA, ale z pravidla tak bývá první pracovní den nového mesíce.ˇ

Obrázek 5.14: Vulnerability management workﬂow

49 5.3.3 Návrh databáze urcenéˇ pro asset, pach a vulnerability management

Návrh databáze vychází z potrebˇ deﬁnovaných v predešlýchˇ kapitolách. V pr˚ubehuˇ tvorby databáze jsem došel k názoru, že bude vhodné implementovat všechny následující prvky do jedné databáze:

• Asset management

• Patch management

• Vulnerability management

V rámci celé databáze byla vytvorenaˇ entita Persons (Osoby). V rámci této entity jsou udržovány informace o všech osobách, které jsou v asset management workﬂow oznacoványˇ jako odpovˇednéosoby. Tato, mnou vytvorenáˇ entita je zcela nahraditelná integrací se systémem STAG, který se v rámci TUL používá pro udržování informacích o zamestnancíchˇ a studentech univerzity. O prítomnostiˇ služeb ciˇ nástroj˚unahrazujících ostatní entity nemám žádné informace. Proto byly tyto prvky doplnenyˇ o další atributy, které nebyly zmínenyˇ v kapitolách zabývající se deﬁnicí proces˚uasset, patch a vulnerability managementu. Návrh databáze byl vytvorenˇ pomocí ER Diagramu za použití notace Crow’s Foot.

50 Obrázek 5.15: ER Diagram databáze

Tvorba databáze

Databáze byla vytvorenaˇ za pomocí jazyka MS SQL a to na platformeˇ MS SQL Database 2012. Tvorba databáze probíhala v nekolikaˇ krocích:

1. Tvorba entit a integracníchˇ omezení Tím je myšlena deﬁnice datových typ˚ua kardinality jednotlivých atribut˚uentit.

2. Vytváreníˇ vazeb mezi entitami

51 Obrázek 5.16: Tvorba entit a integracníchˇ omezení CREATE TABLE [VsindlerThesis].[dbo].Assets ( FQDN VARCHAR(50) NOT NULL, Installed_day DATE NOT NULL, "Status" INT NOT NULL, "Description" VARCHAR(300) NOT NULL, IP VARCHAR(15), Mangement_IP VARCHAR(15), Buisness_impact INT NOT NULL, Resposible_person INT NOT NULL, Asset_status INT NOT NULL, PRIMARYKEY(FQDN), UNIQUE(IP), UNIQUE (Mangement_IP) );

CREATE TABLE [VsindlerThesis].[dbo].InstalledPrograms ( "Program_name" VARCHAR(40) NOT NULL, Program_version VARCHAR(40) NOT NULL, FQDN VARCHAR(50) NOT NULL, Patch_in_deployment VARCHAR(50) NOT NULL );

Vazby mezi entitami (tabulkami) jsou oznacoványˇ jako relace. ER diagramu jsou tyto relace naznacenyˇ caramiˇ propojující jednotlivé entity. Samotné propojení je na úrovni jazyka SQL realizováno pomocí tzv. cizích klíˇc˚u. Jak je videtˇ v ukázce SQL kódu, tak tabulka Assets obsahuje jako primární klícˇ FQDN. Tento atribut je použit jako cizí klícˇ v tabulce InstalledPrograms. K tomu, aby se z atributu stal cizí klíc,ˇ bylo nutné modiﬁkovat tabulku InstalledProgram následujícím príkazem:ˇ

Obrázek 5.17: Editace tabulky InstalledPrograms ALTER TABLE VsindlerThesis.Installed_programs ADD FOREIGN KEY (FQDN) REFERENCES VsindlerThesis.Assets(FQDN);

52 Je zrejmé,ˇ že od struktury databáze se bude do znacnéˇ míry odvíjet tvorba SQL dotaz˚u.Pro znacnéˇ zjednodušení práce s databází jsem vytvorilˇ nekolikˇ pohled˚u(views) na uložena data a to:

• All_installed_programs

• All_patchs_remove_vuln

• All_availible_patchs

• All_vulnerable_assets

V pr˚ubehuˇ tvorby databázových pohled˚ujsem si uvedomil,ˇ že ne vždy je zapotrebíˇ dostat všechna data (z pohledu). Za tímto úcelemˇ došlo k vytvoreníˇ databázových procedur, které dokážou pocetˇ vrácených výsledk˚uomezit. Príklademˇ m˚užebýt procedura pojmenovaná jako All_assets_vulnerabilities. Tato procedura má jako vstupní parametr promenouˇ FQDN. Do této promennéˇ je uložený retˇ ezecˇ odpovídající doménovému jménu stroje. Výsledkem této procedury jsou informace o hledaném stroji, dále pak seznam všech nevyrešenýchˇ zranitelností vztahující se k hledanému stroji, který je serazenˇ vzestupne.ˇ

53 Obrázek 5.18: Vytváreníˇ uložené procedury CREATE PROCEDURE [All_assets_vulnerabilities](@FQDN VARCHAR (50)) as BEGIN Select [VsindlerThesis].[dbo].Assets.FQDN,[ VsindlerThesis].[dbo].Assets.IP,[VsindlerThesis].[dbo ].Assets.Mangement_IP,[VsindlerThesis].[dbo].Assets. Installed_day, [VsindlerThesis].[dbo]."Status"."Description" as "Server status",[VsindlerThesis].[dbo].Persons.Email,[ VsindlerThesis].[dbo].Assets."Description" FROM [VsindlerThesis].[dbo].Assets JOIN [VsindlerThesis].[ dbo].Persons ON [VsindlerThesis].[dbo].Assets. Resposible_person = [VsindlerThesis].[dbo].Persons.ID JOIN [VsindlerThesis].[dbo]."Status" ON [VsindlerThesis].[ dbo].Assets."Status" = [VsindlerThesis].[dbo]."Status". ID WHERE [VsindlerThesis].[dbo].Assets.FQDN = @FQDN;

Select [VsindlerThesis].[dbo].Vulnerabilities."Name", [ VsindlerThesis].[dbo].Vulnerabilities."Description", [VsindlerThesis].[dbo].Vulnerabilities.CVSS, [VsindlerThesis].[dbo].Vulnerabilities.URL_info FROM [ VsindlerThesis].[dbo].Vulnerable_assets JOIN [VsindlerThesis].[dbo].Vulnerabilities ON [ VsindlerThesis].[dbo].Vulnerable_assets.Vulnerability = [VsindlerThesis].[dbo].Vulnerabilities.ID WHERE [VsindlerThesis].[dbo].Vulnerable_assets.FQDN = @FQDN AND [VsindlerThesis].[dbo].Vulnerable_assets. Status_reapir = 0 ORDER BY [VsindlerThesis].[dbo].Vulnerable_assets. Detect_date ASC; END

54 Záverˇ

Téma IT bezpecnostiˇ se vzhledem ke stoupajícímu poctuˇ kybernetických útok˚ustává více diskutovanejším,ˇ než tomu bývalo v minulosti. V souvislosti se stoupajícím poctemˇ útok˚u vzr˚ustápotrebaˇ kvalifikovaných odborník˚uv oblasti IT security. V kontextu této diplomové práce došlo ke zjišteníˇ úrovneˇ zabezpeceníˇ v rámci internetové síteˇ Liberecké Technické univerzity (souhrnneˇ oznacovanéˇ jako LIANE). Jedním z prvních cíl˚udiplomové práce bylo seznámení se s aktuálními hrozbami v kontextu síteˇ LIANE. Analýza možných bezpecnostníchˇ hrozeb byla mírenáˇ proti vybraným segment˚umsíte,ˇ nikoliv proti celé síti LIANE. I prestoˇ je možné brát vybrané segmenty jako referencníˇ množinu stroj˚u,a to z d˚uvodu jejich r˚uznorodostia prítomnostiˇ kritický systém˚ua aplikací TUL. Více než na konkrétní zranitelnosti jsem se díval na celou problematiku aktuálních bezpecnostníchˇ hrozeb z globálního kontextu. Po zhodnocení aktuálních hrozeb muselo dojít k výberuˇ vhodné metodiky testování. Na základeˇ výstup˚uzvolené metodiky meloˇ dojít k analýze soucasnéhoˇ stavu zabezpeceníˇ síteˇ LIANE. Pro potrebyˇ plynoucí ze zadání jsem si zvolil metodu penetracníchˇ test˚u. Provádenéˇ penetracníˇ testy byly kategorie Grey box a to z d˚uvodu mé znalosti síteˇ LIANE, které jsem získal v pr˚ubehuˇ studia na TUL a dále dle podklad˚uod pana Adamce. Penetracníˇ testy byly provádenéˇ proti definovaným sít’ovým segment˚um, a to v souladu s podepsaným ROE. V rámci techtoˇ test˚udošlo k simulaci scénár˚uvyplývajícíchˇ z definovaných hrozeb, které mohou být v˚uciˇ síti LIANE realizovatelné. V první fázi penetracníchˇ test˚u(1. fáze Cyber kill chainu) bylo objeveno velké množství zranitelností, které meˇ svým rozsahem a r˚uznorodostíprekvapilo.ˇ V pr˚ubehuˇ dalších fází docházelo k pokus˚umo zneužití zranitelností. Vzhledem k velkému poctuˇ zranitelných stroj˚ujsem nebyl schopen v rámci definovaného období (toto období bylo soucástíˇ ROE), uskutecnitˇ zneužití všech nalezených zranitelností. V rámci penetracníchˇ test˚udošlo i ke zhodnocení zabezpeceníˇ jedné z klícovýchˇ webových aplikací na TUL. Výsledky tohoto testu byly zajímavé, ale z d˚uvodu absence testovacího prostredíˇ nebyly nekteréˇ typy zranitelností v˚ubectestovány. Mnou provádenéˇ penetracníˇ testy neobsahovaly pokusy o zneužití zranitelností, které

55 by mohly vést k nedostupnosti ciˇ destrukci testovaných stroj˚u.Vzhledem k faktu, že nedošlo k oveˇreníˇ ciˇ vyvrácení všech nalezených zranitelností, hodnotím tento bod jako ne zcela splnený.ˇ V poslední fázi diplomové práce došlo ke zhodnocení výsledk˚upenetracníchˇ test˚u a deﬁnování zp˚usob˚uodstraneníˇ nejzávažnejšíˇ zranitelností. Dále jsem se zameˇrilˇ na bezpecnostˇ síteˇ LIANE a to z pohled˚usprávy uživatelských úct˚uaˇ samotného sít’ového zabezpecení.ˇ Výsledkem techtoˇ pohled˚uje vytyceníˇ možných smer˚u,kudyˇ by se meloˇ zabezpeceníˇ síteˇ LIANE vyvíjet. Konec diplomové práce je venovánˇ tvorbeˇ proces˚u, jejichž implementace pom˚užezlepšit soucasnýˇ stav na TUL. Aplikace techtoˇ proces˚uby melaˇ vyústit k tvorbeˇ jednotné IT smerniceˇ (politiky) na TUL. V souvislosti s mnou navrženými postupy vznikla databáze, kterou je možné implementovat v rámci vývoje budoucí aplikace, která by melaˇ mít na starost asset, patch a vulnerability management. Poslední bod hodnotím z pohledu zadání jako splnený.ˇ

56 Literatura

[1] ADRIAN, David, Luke VALENTA, Benjamin VANDERSLOOT, et al. Imperfect Forward Secrecy. In: SPRINGALI, Drew, Benjamin VANDER SLOOT, David ADRIAN, Luke VALENTA, Tim GÜNEYSU, Akshayaram SRINIVASAN, C. Pandu RANGAN a Jan CAMENISCH. CCS ’15 Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. Denver, Colorado, USA: ACM, 2015, s. 5-17. DOI: 10.1145/2810103.2813707. ISBN 978-1-4503- 3832-5. Dostupné také z: http://dl.acm.org/citation.cfm?doid=2810103. 2813707

[2] BlackNurse. BLACKNURSE it CAN bring you down: Only do testing on ﬁrewalls and routers that you own [online]. Örsundsbro Sweden: NETRESEC, 2016 [cit. 2017-01-03]. Dostupné z: http://blacknurse.dk/

[3] Top 10 2013-Top 10 [online]. USA, San Francisco: OWASP Foundation, 2013 [cit. 2017-01-03]. Dostupné z: https://www.owasp.org/index.php/About_The_ Open_Web_Application_Security_Project

[4] KRUTZ, Ronald L. a Russell Dean VINES. The CISSP and CAP prep guide [online]. Platium ed. Indianapolis, IN: Wiley, c2007. ISBN 978-0-470-00792-1.

[5] Penetration testing: protecting networks and systems. New Edition. Cambs: IT Governance Pub, 2012. ISBN 978-184-9283-717.

[6] HARRIS, Shon. Hacking: manuál hackera. Praha: Grada, 2008. ISBN 978-80-247- 1346-5.

[7] Kali Linux Tools Listing. Kali Linux [online]. USA: Kali Linux, 2017 [cit. 2017-03- 04]. Dostupné z: http://tools.kali.org/tools-listing

[8] SELECKÝ,Matúš. Penetraˇcnítesty a exploitace. Brno: Computer Press, 2012. ISBN 978-80-251-3752-9.

57 [9] WILLIAMS, Laurie. White-Box Testing. USA, North Carolina State University Department of Computer Science, 2006. Dostupné také z: http://agile.csc. ncsu.edu/SEMaterials/WhiteBox.pdf

[10] FAIRCLOTH, Jeremy. Penetration tester’s open source toolkit. 3rd ed. Waltham, MA: Elsevier/Syngress, c2011. ISBN 15-974-9627-8.

[11] MANN, Ian. Hacking the human: social engineering techniques and security countermeasures. 1rd ed. Burlington, VT: Gower, c2008. ISBN 978-0-566-08773-8.

[12] Social engineering (security). In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2012 [cit. 2017-05-03]. Dostupné z: https://en.wikipedia.org/wiki/Social_engineering_(security)

[13] The Cyber Kill Chain or: how I learned to stop worrying and love data breaches [online]. USA, New York: VARONIS, 2016 [cit. 2017-05-03]. Dostupné z: https://blog.varonis.com/ the-cyber-kill-chain-or-how-i-learned-to-stop-worrying-and\ -love-data-breaches/

[14] Metasploit Basics – Part 3: Pivoting and Interfaces. Digital Bond [online]. USA: Digital Bond, 2010 [cit. 2017-05-04]. Dostupné z: https://www.digitalbond.com/blog/2010/07/12/ metasploit-basics-part-3-pivoting-and-interfaces/

[15] Common Vulnerability Scoring System v3.0: User Guide. First Improving Security Together [online]. USA: FIRST.org, 2017 [cit. 2017-04-18]. Dostupné z: https: //www.first.org/cvss/user-guide

[16] Testing: Introduction and objectives [online]. USA, San Francisco: OWASP Foundation, 2014 [cit. 2017-01-03]. Dostupné z: https://www.owasp.org/ index.php/Testing:_Introduction_and_objectives

[17] Open Source Security Testing Methodology Manual (OSSTMM). ISECOM [online]. Spain: ISECOM, 2017 [cit. 2017-04-04]. Dostupné z: http://www. isecom.org/research/

[18] Accepted tomcat8 8.0.14-1+deb8u5 (source all) into proposed-updates->stable- new, proposed-updates. Debian [online]. USA: Canonical, 2016 [cit. 2017- 05-13]. Dostupné z: https://lists.debian.org/debian-changes/2016/12/ msg00022.html

58 [19] Tomcat8 8.0.14-1+deb8u2 source package in Debian. Debian: tomcat8 package [online]. USA: Canonical, 2016 [cit. 2017-05-13]. Dostupné z: https:// launchpad.net/debian/+source/tomcat8/8.0.14-1+deb8u2

[20] Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN: CVE- 2016-2183, CVE-2016-6329. Sweet32 [online]. France: INRIA, 2016 [cit. 2017-05- 13]. Dostupné z: https://sweet32.info/

[21] PHP Vulnerability: CVE-2016-7132. Rapid7 [online]. USA: Rapid7, 2016 [cit. 2017-05-04]. Dostupné z: https://www.rapid7.com/db/vulnerabilities/ php-cve-2016-7132

[22] VMSA-2015-0007: VMware ESXi OpenSLP Remote Code Execution (CVE-2015-5177). Rapid7 [online]. USA: Rapid7, 2016 [cit. 2017-05- 04]. Dostupné z: https://www.rapid7.com/db/vulnerabilities/ vmsa-2015-0007-cve-2015-5177

[23] VMware Security Advisories: VMSA-2016-0002.1. VMware [online]. USA: VMware, 2016 [cit. 2017-05-04]. Dostupné z: http://www.vmware.com/ security/advisories/VMSA-2016-0002.html

[24] VMware vCenter Server Appliance workaround for CVE-2015-7547: glibc getaddrinfo stack-based buﬀer overﬂow (2144075). VMware Knowleage Base [online]. USA: VMware, 2015 [cit. 2017-05-04]. Dostupné z: https://kb.vmware.com/selfservice/search.do?cmd=displayKC& docType=kc&docTypeID=DT_KB_1_1&externalId=2144075

[25] OpenSSL Security Advisory: OCSP Status Request extension unbounded memory growth (CVE-2016-6304). Openssl [online]. USA: Openssl org, 2016 [cit. 2017-05- 04]. Dostupné z: https://www.openssl.org/news/secadv/20160922.txt

[26] Bug #73418 Integer Overﬂow in "_php_imap_mail"leads Heap Overﬂow. PHP Bugs [online]. USA: The PHP Group, 2016 [cit. 2017-05-04]. Dostupné z: https:// bugs.php.net/bug.php?id=73418

[27] OpenSSL Security Advisory: TLS heartbeat read overrun (CVE-2014-0160). Openssl [online]. USA: Openssl org, 2014 [cit. 2017-05-04]. Dostupné z: https: //www.openssl.org/news/secadv/20140407.txt

[28] Resolving OpenSSL Heartbleed for ESXi 5.5 - CVE-2014-0160 (2076665). VMware Knowleage Base [online]. USA: VMware, 2015 [cit. 2017-05-04].

59 Dostupné z: https://kb.vmware.com/selfservice/microsites/search. do?language=en_US&cmd=displayKC&externalId=2076665

[29] OpenSSL Security Advisory: SSL/TLS MITM vulnerability (CVE-2014-0224). Openssl [online]. USA: Openssl org, 2014 [cit. 2017-05-04]. Dostupné z: https: //www.openssl.org/news/secadv/20140605.txt

[30] PHP 5.3.12 and PHP 5.4.2 Released!. PHP [online]. USA: The PHP Group, 2012 [cit. 2017-05-04]. Dostupné z: http://php.net/archive/2012.php# id2012-05-03-1

[31] Co je GDPR a jak bude aplikováno v Ceskuˇ [online]. Praha: GDPR.cz, 2016 [cit. 2017-05-03]. Dostupné z: https://www.gdpr.cz/gdpr/co-je-gdpr/

[32] ICT SECURITY ROADMAP. Corpus [online]. Praha: Corpus Solutions, 2015 [cit. 2017-03-03]. Dostupné z: https://corpus.cz/produkty/ ict-security-roadmap.html

60 A Obsah priloženéhoˇ CD

/ pdf...... Diplomová práce ve formátu pdf. IMG...... Obrázky použité v diplomové práci. diagramy ...... Diagramy vytvorenýchˇ workﬂow DB...... Konﬁguracníˇ soubory vytvorenéˇ databáze Skeny ...... Výsledky vulnerability sken˚u