Warning: Table './d1394_drupal/cache' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache WHERE cid = 'variables' in /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc on line 136

Warning: Table './d1394_drupal/cache' is marked as crashed and last (automatic?) repair failed query: UPDATE cache SET data = 'a:996:{s:13:\"theme_default\";s:5:\"fever\";s:13:\"filter_html_1\";s:1:\"1\";s:18:\"node_options_forum\";a:1:{i:0;s:6:\"status\";}s:18:\"drupal_private_key\";s:64:\"5fe6eae150af4e56112c001190001c50f30fff335724864ea3d95df181c7224f\";s:10:\"menu_masks\";a:30:{i:0;i:127;i:1;i:125;i:2;i:63;i:3;i:62;i:4;i:61;i:5;i:60;i:6;i:59;i:7;i:58;i:8;i:57;i:9;i:56;i:10;i:31;i:11;i:30;i:12;i:29;i:13;i:28;i:14;i:25;i:15;i:24;i:16;i:22;i:17;i:21;i:18;i:15;i:19;i:14;i:20;i:13;i:21;i:12;i:22;i:11;i:23;i:7;i:24;i:6;i:25;i:5;i:26;i:4;i:27;i:3;i:28;i:2;i:29;i:1;}s:12:\"install_task\";s:4:\"done\";s:13:\"menu_expanded\";a:1:{i:0;s:9:\"menu-user\";}s:9:\"site_name\";s:5:\"FLOPS\";s:19:\"file_directory_temp\";s:23:\"sites/default/files/tmp\&quo in /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc on line 136

Warning: Cannot modify header information - headers already sent by (output started at /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc:136) in /data/web/virtuals/1394/virtual/www/includes/bootstrap.inc on line 726

Warning: Cannot modify header information - headers already sent by (output started at /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc:136) in /data/web/virtuals/1394/virtual/www/includes/bootstrap.inc on line 727

Warning: Cannot modify header information - headers already sent by (output started at /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc:136) in /data/web/virtuals/1394/virtual/www/includes/bootstrap.inc on line 728

Warning: Cannot modify header information - headers already sent by (output started at /data/web/virtuals/1394/virtual/www/includes/database.mysql.inc:136) in /data/web/virtuals/1394/virtual/www/includes/bootstrap.inc on line 729
Penetrační testování od Adama | FLOPS

Penetrační testování od Adama

Obory článku
bezpečnost, detekce

Často se penetrační testy provádějí v situaci, kdy IT oddělení nemá plnou důvěru managementu. Někdy si dokonce penetrační testy s předem známým (samozřejmě pozitivním) výsledkem zadá samotné IT oddělení, aby ukázalo, jak skvěle pracuje. To ale není případ, který zde bude popsán dle reálné případové studie.

Jednoho dne zazvonil v naší společnosti telefon, který mě trochu překvapil. Volající se představil jako bezpečnostní manažer velké společnosti na zpracování ropy (oblast podnikání společnosti, identifikační hesla a podobně byly záměrně změněny, aby sa dotyčný klient nedal rozpoznat). Řekl, že společnost, kterou zastupuje, má zájem o naše služby a že by se s námi rád sešel. Vyjadřoval se velmi tajuplně, nechtěl říct nic bližšího a na šifrovanou komunikaci nebyl vybaven.

Během týdne se z tajuplného zavolání vyklubal požadavek na interní „zero knowledge“ penetrační testy, tedy penetrační testy, které mají za úkol odhalit slabiny zneužitelné z vnitřní sítě, kdy testující subjekt nemá na začátku testování žádné vstupní informace o testované síti a aplikacích. Dále bylo dohodnuto, že předmětem těchto penetračních testů budou pouze slabiny zneužitelné síťově.

Při přípravě smlouvy jsme si byli vědomi, že nejde o klasickou smlouvu o dílo a že je proto na místě maximální opatrnost a přesnost ve formulacích. Zákazník totiž často očekává, že zhotovitel převezme všechna rizika spojená s provedením těchto testů. A i v popisovaném případě jsme museli zákazníkovi vysvětlit, že požaduje nemožné.

Zatímco u banky nikdo nepochybuje o tom, že každou minutou nedostupnosti některého ze systému dochází k nemalým ztrátám, tak u společnosti zpracovávající ropu to není tak markantní. Nicméně výše ztrát může být podobná, neboť celá zpracující linka je závislá na počítačové síti a některých aplikacích. Musím přiznat, že i já jsem si pro sebe říkal: „Jaké tam mohou být ztráty? V nejhorším případě se pár hodin nebude zpracovávat ropa...“ Pracovníci klienta nás však z tohoto omylu rychle vyvedli. Dozvěděli jsme se, že v krajním případě by se mohlo stát, že by ropné produkty vytékaly přímo na zem místo do připravených kontejnerů. Následky je snad lépe nedomýšlet.

Od odhadu ztrát a možných rizik je nezbytné odvíjet nejen samotné testování, ale i smlouvu mezi zhotovitelem a klientem. Z povahy penetračních testů vyplývá, že se jedná o činnosti odporující většině pokynů a nařízení  pro pracovníky organizace. Ve smlouvě je především nutné rozlišit, kdo za které situace odpovídá. Vzhledem k riziku velmi vysokých potencionálních škod a vzhledem ke skutečnosti, že se nám nepodařilo najít pojišťovnu, jenž by nás proti těmto rizikům pojistila, nebylo pro nás akceptovatelné převzít rizika vyplývající z provádění testů bez detailní znalosti a konfigurace veškerých systémů, zařízení a aplikací. A tyto informace jsme nemohli dostat, neboť by to odporovalo zvolenému typu penetračních testů.

I přes skutečnost, že obě smluvní strany chtěly mít ve smlouvě zcela přesně definovánu zodpovědnost za vznik konkrétních situací, tento požadavek se ukázal jako nerealizovatelný. Výsledná smlouva samozřejmě rozdělovala odpovědnosti za situace, které by případně vznikly. Bohužel v některých věcech nebylo možné převzít zcela odpovědnost, neboť jsme neznali konfiguraci systémů a nemohli jsme se přesvědčit, zda jsou aplikovány patřičné bezpečnostní opravy (patche) atd. Smluvní odpovědnosti za případnou nedostupnost některého ze systémů či ztráty dat byla upravena následovně:

  1. Objednatel je bezprostředně před započetím testů povinen udělat kompletní zálohy veškerých dat a konfigurací a tyto uložit v bance.
  2. Objednatel zajistí po dobu trvání penetračních testů odpovídající pohotovostní servis, který bude bezodkladně řešit případné havárie jednotlivých systémů. Tento pohotovostní servis bude zajištěn pro všechny klíčové systémy a aplikace.
  3. Zhotovitel si je vědom, že pracuje v real-time provozu a tomu přizpůsobí metody testování a bude postupovat s maximální opatrností.

Kromě dalších obvyklých ustanovení byl ve smlouvě ustanoven nezávislý arbitr, který v případě problému posoudí, zda problém vznikl chybou dodavatele (např. použitím neadekvátních metod), či objednatele (např. chybou v konfiguraci některého ze systému, absenci klíčových bezpečnostních oprav atd.).

Obě strany k testům přistoupily zodpovědně a tak výše zmíněné ustanovení nebylo použito.

Technické zázemí pro penetrační testy

Po více než týdnu byla smlouva konečně hotova a podepsána oběma stranami a bylo možné začít s testováním. Když jsme se dostavili na místo konání penetračních testů, byla nám přidělena malá zasedačka se dvěma PC, z nichž každé bylo zapojeno do jiného segmentu sítě a jejich prostřednictvím jsme se mohli dostat do všemi uživateli používané sítě VLAN. Po uvedení adresy síťové karty jsme obdrželi IP adresu z rozsahu, který používají běžní uživatelé. Tyto dvě PC a potřebné know-how bylo veškeré vybavení k provedení penetračních testů. Také jsem byl vybaven čipovou kartou pro docházkový systém objednatele umožňující přístup do přidělené místnosti a na toalety.

Pro penetrační testy jsme používali stolní PC s linuxovou distribucí Debian unstable s jádrem řady 2.6 a notebook se dvěma operačními systémy – a to Windows XP a stejnou linuxovou distribuci, jako u PC. Dále pak speciální bezpečnostní sondu, kterou jsme pro tyto účely vyvinuli.

Vlastní penetrační testy

Samozřejmě bylo možné začít penetrační testy tím, že bychom pustili několik bezpečnostních scannerů (nejlépe s volbou pro testování všech slabin) a na základě těchto výsledů bychom začali s „ruční prací“. Bohužel existují i společnosti, které na základě výsledků testů napíší zprávu a tím skončí. Protože se touto činností zabýváme již řadu let, tak nás tato metoda ani nenapadla. Zvláště v tomto prostředí by se jednalo o velmi nešťastnou volbu. Některé OS a aplikace nemají zrovna nejlépe ošetřenu síťovou komunikaci a tak takovéto chování velmi lehce může způsobit DoS. Existují i takové OS a aplikace, kde na DoS stačí obyčejný Nmap. Nehledě na to, že toto chování by bylo v příkrém rozporu se smlouvou, neboť jej lze jen velmi těžko označit jako „postup s maximální opatrností“.

Proto jsme penetrační testy započali testováním nastavení DHCP. Na stolním PC jsem si pomocí programu Ifconfig změnil MAC adresu a zkusili jsme, zda se připojím do sítě. A hned jsme objevili první bezpečnostní nedostatek. Nejen, že jsme se do sítě připojili (přepínač nás neodmítl), ale dokonce jsme z DHCP dostali i IP adresu. Takto přidělená IP adresa byla ze stejného rozsahu jako ta, která nám byla přidělena oficiálně. Měli jsme tedy i stejné možnosti a omezení (např. stejná omezení přístupu na Internet). Jednalo se o první závažnější bezpečnostní nedostatek, neboť kdokoli, kdo se dostane k „živému ethernetu“, si může prohlížet cizí sít a připojovat se pod adresou objednatele na Internet.

Dalším krokem bylo zmapování „živých strojů“ v uživatelské podsíti. To jsme provedli hromadným pingem na tyto stroje. Samozřejmě jsme si byli vědomi, že na některých strojích může být nainstalován firewall a nemusí na ping odpovídat. Nicméně jakýsi hrubý přehled pro prvotní orientaci jsme tím získali. Protože uvedený hromadný ping jsme prováděli pomocí programu Nmap se správnými volbami, dostali jsme jako výstup také MAC adresu jednotlivých strojů a výrobce síťových karet. Samozřejmě jsme tento výstup brali jako orientační, neboť MAC adresu a tím i jejího výrobce lze falšovat, ale není to zcela běžné. Toto jsem z Cronu (systémový program, který spouští automaticky příkazy, skripty či programy) pouštěl každých 10 minut a seznam doplňoval. Tím se do tohoto seznamu dostaly i stroje, které se zapínají jen občas.

Když jsme měli tento výstup, napsali jsme jednoduchý skript, který nám všechny interní adresy přeložil na DNS jména. Jiným skriptem jsme zase získali jména jednotlivých zařízení (jména hostujících počítačů). Prošli jsme si seznamy jmen DNS a hostů a zjistili jsme například, že u uživatelských PC a notebooků jména hostů obsahovala příjmení uživatele a DNS suffix PC00x.domena.cz. Objednatel zjevně používal pro zařízení ve vnitřní síti syntaxi DNS nazev.domena.cz . Dále v tomto seznamu byla zařízení s DNS jmény Printer0x a stejnými hostname. Další skupinou byly jména postaviček z českých pohádek (Křemílek, Amálka atd.). Nyní jsem dospěl k teorii, že jména jsou rozdělena následovně:

  • PC00x jsou uživatelské stanice;
  • Printer0x jsou síťové tiskárny;
  • postavičky z pohádek jsou aktivní prvky, servery a jiná významná zařízení.

Nyní se nabízely dvě základní možnosti. Mohli jsme tuto hypotézu přijmout a ušetřit si poměrně značné množství rutinní práce. Rozhodli jsem se však pro druhou, pracnější, časově náročnější ale po mém soudu správnou možnost a začali jsme tuto hypotézu dále prověřovat.

Uživatelské stanice

Pro přijatou hypotézu hovořil i fakt, že cca 90 procent zařízení s DNS jmény PC00x mělo v testu uvedeno jako výrobce síťové karty společnost Realtek, což je nejběžnější síťová karta, která bývá integrovaná na základní desce uživatelských PC. Dále jsme pomocí utility Nmap předběžně orientačně zjistili používaný operační systém. Všude byly Windows XP, o čemž mě ujistilo i několik dalších bezpečnostních scannerů (i zde bylo nutné postupovat s maximální opatrností); za všechny jmenujme například Nessus. Dále jsem pomocí klientských programů z balíku Samba získal název domény, seznam všech viditelných i skrytých sdílení dat (sharing) a mnoho dalších informací, které jsem později vyhodnotil a použil pro další průzkum.

Tiskárny

Nejdříve jsme se soustředili na IP adresy, o kterých jsme se dle názvu domnívali, že se jedná o tiskárny, a to jsem si potvrdil programem Nmap. Společným znakem síťových tiskáren, faxů zařízení pro videokonferenci apod. totiž bývá relativně snadná predikovatelnost identifikátorů v TCP spojení, což potencionálnímu útočníkovi zjednodušuje případné převzetí již navázaného spojení. V této kategorii byla všechna zařízení s názvem Printer0x programem Nmap špatně hodnocena (TCP Sequence Prediction: Class=increments by 800, Difficulty=10 (Easy) nebo hůře).

Mohli jsme dále analyzovat výsledky Nmapu ve verbose modu a hledat skutečného výrobce zařízení. Takových metod bylo možné použít několik. Je to ale velmi zdlouhavé. Zde jsme zvolili výrazně jednodušší možnost, která ovšem žádný systém neohrožovala. Využil jsem skutečnosti, že většina zařízení má otevřený port 80. Stačilo pak připojit se pomocí programu Links na jednotlivá zařízení a ujistit se, že se skutečně jedná o tiskárny. Navíc jsme zjistili, že 3 z 11 tiskáren, měly defaultní nastavení a po přečtení krátkého read_me od výrobce jsme tyto tiskárny mohli administrovat. Samozřejmě jsme na nich žádné změny nedělali, jen jsme to zdokumentovali pro účely pozdější zprávy.

Servery a aktivní prvky

U zařízení, která nesla názvy pohádkových postaviček, jsme se domnívali, že se jedná o servery, aktivní prvky a jiná klíčová zařízení. Mohli jsme začít tím, že bychom na všechna tato zařízení pustili Nmap pod rootem nebo dokonce Nessus či jiný bezpečnostní scanner s volbou testování všech zranitelností včetně DoS. Bylo by to bezesporu velmi pohodlné a pokud by nedošlo k havárii některého systému či aplikace, bylo by to i velmi rychlé.

Zde to naráželo opět na bariéru smlouvy, která mi toto neumožňovala a rizika s tím spojená, která byla po našem soudu příliš vysoká. Proto jsem začal opět programem nmap, tentokráte na každý stroj zvlášť. Důležitou skutečností také bylo, že jsme v rámci opatrnosti nespouštěli tento program jako root, což způsobilo, že jsme dostali jen značně omezené informace. Nmap nám například „neřekl“ verzi operačního systému přímo. Nicméně i tak jsme dostali bezpečnější cestou poměrně dost informací. U většiny zařízení jsme byli více či méně přesně schopni určit verzi operačního systému. Tam kde byl otevřen port 80 či 443, jsme použili oblíbený Links (prohlížeč Internetových zdrojů) a hned jsme měli více informací.

Dále jsme se zkoušeli připojit na některé další porty známých služeb jako jsou Telnet, SSH, SMP, POP3, IMAP a dalších. Při pokusu o připojení vyběhne zpravidla nějaký banner, který o systému něco vypovídá. Je jasné, že i tento banner je možné falšovat. Proto jsme museli provádět dodatečné kontroly. Například stroj Vochomůrka poskytující do vnitřní sítě službu SMTP se „představoval“ jako Microsoft Exchange 2003. Pomocí pár testů jsme však zjistili, že Vochomůrka striktně dodržuje RFC, což se o Microsoft Exchange 2003 říci nedá. Až později jsme si všimli, že na tomto stroji běží služba HTTP.

Při připojení na tuto službu jsme měli o Vochomůrkovi jasno. Jeho představování se jako MS Exchange je skutečně falešné, neboť Qmailadmin, který tam běžel doposud, nebyl na platformu MS Windows portován… Bylo tedy jasné, že Vochomůrka je unixový stroj. Pro jistotu jsme se ještě ujistili pohledem do zdrojového kódu HTML stránky, že se nejedná o pouhý obrázek. Samozřejmě jsem se pokusil i špatně přihlásit a zdrojový kód chybové stránky následně odpovídal proklamované aplikaci.

Na stroji Vochomůrka jsme neúspěšně provedli ještě několik dalších testů. Výsledkem tedy bylo zjištění, že jsme sice prokoukli jednoduchou lest administrátora, ale nenašli jsem slabinu, která by nám umožnila získat přístup na tento stroj nebo jej dokonce kompromitovat.

Obdobný průběh měly i testy na dalších šesti serverech. Pak jsme ale narazili na jeden server, který se tvářil, jako unixový stroj. Nejzajímavější na něm bylo, že měl otevřený port 23 a naopak neměl otevřený port 22, z čehož  jsme předběžně usoudili, že z nějakého důvodu je pro administraci systému používán Telnet namísto SSH. Za použití programů Hunt, Dsniff a díky koncepční chybě v implementaci ARP protokolu (mapuje IP adresy na adresy MAC) se nám i na síti vybavené přepínači povedlo odchytit heslo uživatele root.

Heslo nebylo triviální a uhádnout by se je pravděpodobně nepodařilo. Jednalo se o heslo „2aFrodisIakum24“. Velmi nám pomohlo, že na tomto stroji měli účty ještě další tři uživatelé. Hesla těchto uživatelů nebyla v podobě plaintext, ale dostupný byl pouze MD5 hash hesel. Algoritmus MD5 je však již dlouho považován za prolomený. Dvě hesla jsme odhalili v RainbowTables.

Vzhledem k tomu, že disponujeme velmi rozsáhlými RainbowTables, byla časová náročnost odhalení posledního hesla metodou bruteforce vysoká a limitně se blížící nekonečnu. Proto jsme se rozhodli, že nám stačí tři ze čtyř hesel.

Nyní jsme byli v situaci, kdy jsme kromě rozkrytí struktury sítě získali kontrolu nad jedním z důležitých serverů a mělo jsme k dispozici tři hesla, která na něm byla použita. Nyní jsme pomocí jednoduchého skriptu vygenerovali druhý soubor s hesly. Jednalo se pouze o hesla různě odvozená od tří použitých hesel. I přesto nebyl soubor zrovna malý.

Samozřejmě jsme mohli ke všem systémům přistupovat jako k izolovaným zdrojům a testovat každý samostatně. Rozhodli jsme se znovu využít výše zmíněných negativních vlastností člověka a také skutečnosti, že každý systém či aplikace nemá většinou svého vyhrazeného správce. Proto hesla bývají buď stejná či různě obměněna, ale se stejným základem. Proto jsme usoudili, že nastal čas, abychom využili dříve získané podklady. Vygenerovali jsme podle nejpoužívanějších syntaxí možné username, k tomu jsme přidali dva soubory s hesly a pustil několik instancí programu Brutus (zkoušeč hesel). Ta důležitější instance se snažila pomocí slovníkového útoku kompromitovat Windows doménu. Ostatní měly za úkol získat přístup k dalším zdrojům, které jsme dříve zaevidovali v síti (HTTP, FTP apod.). Touto metodou se podařilo získat přístup k administraci celé Windows domény a tím i dvou SQL serverů a jednomu FTP serveru.

Závěr z provedených penetračních testů

Během testů jsme našli celou řadu jiných méně významných bezpečnostních chyb. Jednalo se například o to, že na stanicích byla povolena tzv. „null session“, pomocí které jsme o stanicích lehce zjistili jméno a příjmení uživatele, uživatelské účty definované na stanici a dokonce i informace o hardware. Vážnější slabinou bylo používání SNMP v2, které není šifrováno. Nyní byly penetrační testy u konce a zbývalo udělat srozumitelný výstup. Zde jsme se snažili (a snad se to povedlo) být struční, doprovázet text obrázky a samozřejmostí je kromě popisu bezpečnostních slabin, také klasifikace jejich nebezpečnosti a návrh řešení.

Výsledná zpráva měla včetně obrázků a všech náležitostí cca 50 stránek. Tato zpráva byla sice poměrně kritická, ale pro bezpečnostního manažera, který si penetrační testy zadal, nepříliš překvapivá, protože o všech závažných nedostatcích byl v souladu se smlouvou průběžně informován. Kromě této zprávy jsme dle dohody s objednatelem vypracovali též Manažerské shrnutí, což byl dvoustránkový výtah ze zprávy o provedení penetračních testů. V manažerském shrnutí bylo zkráceně řečeno zadání, výsledek a doporučení vyplývající z penetračních testů. Vzhledem k tomu, že tento dokument byl určen pro management, nebyly v něm žádné technické termíny.

Nechtěný test mimo zadání

Jak již bylo řečeno, na počátku penetračních testů jsme dostali přístupové karty, se kterými jsme se dostali skutečně jen do jedné určené místnosti a na toalety. Asi pět dní před dokončením penetračních testů jsem si zapomněl vzít přístupovou kartu. Když jsem to zjistil u zákazníka, řekl jsem to na vstupní recepci a očekával jsem, že recepční zvedne telefon a zavolá bezpečnostnímu manažerovi, co se mnou má dělat. To se nestalo a k mému zděšení jsem dostal náhradní zaměstnaneckou kartu s dotazem, zda trefím. Řekl jsem po pravdě, že ano, a odebral se do vyhrazené „zasedačky“. Odtamtud jsem zavolal bezpečnostnímu manažerovi a upozornil ho na vzniklou situaci. Společně jsme pak šli zjišťovat závažnost situace a zjistili jsme, že jediná místnost, kam se nedostanu, je serverovna…

Autor
Miroslav Ludvík
Váš hlas: Žádné Průměr: 5.8 (9 votes)