Autor: .cCuMiNn. | 15.8.2016 |
Mezi průzkum prostředí lze zařadit také zjištění povolených HTTP metod. V ideálním případě by měl server reagovat pouze na ty metody, které aplikace skutečně využívá. Všechny ostatní by měly být zakázány. Standardními metodami, které jsou protokolu HTTP definované v RFC, patří HEAD, GET, POST, PUT, DELETE, OPTIONS, TRACE a CONNECT. Některé frameworky a rozšíření ale mohou zařazovat také jiné nestandardní metody. Například známé rozšíření WebDAV zavádí nové metody PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK a UNLOCK.
Důvodem pro otestování a zakázání nepoužívaných metod je skutečnost, že některé metody mohou být zneužity útočníkem. Příkladem budiž zneužití metody HEAD pro útok HTTP Verb Tampering. Metodu TRACE je možné zneužít pro útoky Cross-Site Tracing a díky povolené metodě CONNECT si může útočník z Vašeho serveru udělat proxy. Nakonec, povolení metod PUT a DELETE, může vést v případě špatné konfigurace zneužito útočníkem pro upload nebo odstranění souborů. Zmíněné útoky budou podrobně rozebrány později.
Povolené HTTP metody zjistíte nejsnadněji pouhým odesláním požadavku metodou OPTIONS. Tato metoda nemá totiž za úkol nic jiného, než sdělit Vám, které metody jsou na serveru povoleny. Váš požadavek můžete na server odeslat například pomocí nástroje Telnet nebo Netcat, viz následující výpis.
V případě, že metoda OPTIONS není povolená, použijte pro zjištění povolených metod enumeraci. To znamená, že na server budete postupně odesílat requesty pro jednotlivé testované metody. Toho můžete dosáhnout jednoduchým skriptem, nebo například využitím modulu Intruder z nástroje Burp Suite. S tímto modulem se důkladněji seznámíte později v kapitole věnované autentizaci uživatelů a guessingu. Některé webové servery, mezi které patří například Apache, vrací při neimplementovaných a zakázaných metodách stejnou odpověď, jako kdyby byl požadavek odeslán metodou GET. Pokud se Vám tedy na Váš request vrátí odpověď se status kódem 200, neznamená to ještě, že je metoda povolena, a že byla použita. Vždy je v takovém případě potřeba důkladně prozkoumat vrácenou odpověď.
Do sekce mapování prostředí by jistě spadalo také zjištění, zda se testovaná aplikace nachází na dedikovaném serveru, VPS, nebo na sdíleném hostingu. Této oblasti se ale budeme důkladně věnovat až v následující kapitule „mapování aplikace“, kde nám toto lépe zapadne do kontextu.
Zjistíte-li ovšem, že testovaná aplikace běží na serveru s množstvím dalších webových aplikací, a patrně se tedy jedná o webhosting, nevynechejte zjistění, o jakého poskytovatele se jedná, a zda si na stejném serveru můžete objednat prostor i pro Vaší vlastní aplikaci. Většina sdílených hostingů není totiž nakonfigurována právě bezpečně a možnost vzájemného napadení aplikací na stejném serveru se tak může stát největší slabinou celého soukolí.
Zjistíte-li, že existuje možnost objednat si na stejném serveru, na kterém se nachází i testovaná aplikace, vlastní prostor, rozhodně neváhejte a této možnosti využijte. Po té, co budete mít vlastní přístup na server k dispozici, shromážděte o cílovém systému všechny dostupné informace, ke kterým máte jako zákazník přístup. Odpovězte například na otázky z následující tabulky.
Jako zákazníci sdíleného hostingu zodpovězte následující otázky |
---|
K jakým službám jste dostali přístup (mail, FTP, databáze, SSH, apd.)? |
Uživatelské jméno Vám bylo přiděleno, nebo jste si jej zvolili sami? |
Pokud bylo uživatelské jméno přiděleno, lze odhadnout, jaká jména mají ostatní zákazníci? |
Lze uživatelské jméno změnit? |
Bylo Vám vygenerováno náhodné heslo, nebo jste jej volili sami? Jaký je jeho formát? |
Můžete heslo změnit? |
Jaká je nasazena politika hesel? Je vyžadována určitá délka hesla a jeho komplexita? |
Platí stejné autentizační údaje ke všem přiděleným službám, nebo jsou údaje různé? |
Kde se nacházejí lokace pro přístup k jednotlivým službám? |
Jaké technologie můžete na serveru využívat (možné skriptovací jazyky, typ databáze)? |
Jaké je nastavení serveru? V PHP spusťte například funkci phpinfo(). |
Konkrétním zranitelnostem a možnostem útoků na sdílených serverech se budeme detailně věnovat později.
Úvodní část věnovanou průzkumu prostředí můžete vztáhnout také na vyhledání veřejně dostupných informací o cílové organizaci, jejich systémech, případně i o jejích zaměstnancích. Tyto informace Vám mohou poskytnout kontakty pro případné sociotechnické útoky, přístupová hesla, a další relevantní údaje.
Během této fáze se nesoustřeďte pouze na vyhledávač Google, ale také na enumeraci kontaktů přímo z testované webové aplikace, na obchodní rejstřík, Facebook, LinkedIn a další sociální sítě. Projděte služby jako je Pastebin a ověřte, zda se na nich nenachází data (uživatelská jména, hesla, nebo zdrojové kódy) z případných datových úniků, ke kterým došlo v historii.
Nyní, když jste se seznámili s technikami identifikace součástí použitých v testovaném prostředí, nadešel vhodný čas pro zjištění, zda některé z těchto součástí netrpí zranitelnostmi, které by bylo možné exploitovat a zneužít.
Rozhodně se po Vás v tuto chvíli neočekává, že jako penetrační testeři webové aplikace sáhnete po zdrojových kódech webového serveru Apache, nebo programovacího jazyka php a začnete vyhledávat zranitelnosti, které ve zdrojovém kódu zanechali jejich tvůrci. Od toho zde máme jistě povolanější jedince, kteří studiu těchto zdrojových kódů obětovali (často s úspěchem) nemalou část svého života.
Co se od Vás ale naopak očekává, je, že se podíváte, zda jsou všechny použité součásti v aktualizovaném stavu, a že neexistují exploity, které by umožnily napadnout jejich veřejně známé slabiny. Na všechny nedostatky musíme upozornit ve své závěrečné zprávě. Samotná zjištění, která se Vám při shromažďování informací podařilo získat, ve své závěrečné zprávě samozřejmě uveďte také, aby měl zadavatel testů přehled o tom, k jakým informacím může dospět případný útočník. Tyto nálezy ovšem označujte pouze stupněm závažnosti „informační“. Nejedná se totiž o zranitelnosti, které by bylo možné samo o sobě zneužít pro napadení systému. V jedné z příloh této knihy najdete ukázku závěrečné zprávy, která podobná zjištění obsahuje. Pokud máte zájem, nalistujte si tuto přílohu již nyní a podívejte se, jaké skutečnosti jsou očekávané, že ve své zprávě v souvislosti s průzkumem prostředí uvedete.
Výjimku budou pochopitelně tvořit ta zjištění, u nichž dojdete k závěru, že použitá součást není aktuální a podařilo se Vám dohledat její relevantní zranitelnosti. V takovém případě může hodnocení závažnosti dosáhnout bez problému i stupeň závažnosti „kritická“. Stále ale zůstává otázkou, jak takové zranitelnosti v běžících systémech a spuštěných službách najít, když tato oblast není Vaší specializací. Na tuto otázku se pokusí odpovědět následující odstavce.
Poznámka: V případě vyhledávání zranitelností se nezaměřujte pouze na ty součásti, které mají co dočinění s testovanou webovou aplikací, ale zaměřte se také na všechny služby naslouchající na stejném serveru na otevřených portech. K jejich identifikaci Vám již dříve posloužil Nmap.
Při manuálním vyhledávání známých zranitelností bude Vaší úlohou ověření, zda se verze softwaru, které jste identifikovali v předchozích krocích, nenachází ve veřejně dostupných databázích zranitelností. Nejznámější a nejobsáhlejší databází tohoto druhu je bezpochyby Common Vulnerabilities and Exposures (CVE). V databázi CVE můžete vyhledávat podle jména produktu, jeho konkrétní verze nebo podle výrobce. Poměrně rychle se tak dostanete k relevantním informacím. Databáze CVE přiděluje všem známým zranitelnostem v softwaru jednoznačný identifikátor (CVE ID), který je brán za jakýsi standard pro odkazovaní se na konkrétní zranitelnost. Příkladem CVE ID je například CVE-2014-0231, který jednoznačně identifikuje zranitelnost modulu mod_cgid v Apache serveru nižší verze než 2.4.10, umožňující vyvolat DoS.
Pokud v testovaném systému najdete nějakou zranitelnost, vždy se pokuste najít její CVE ID a toto ID uveďte ve svém reportu. Díky tomu nebudete muset ve své zprávě zranitelnost detailně popisovat. Všechny relevantní informace je totiž na základě znalosti CVE ID možné dohledat na internetu.
Mezi další zdroje pro vyhledávání zranitelností můžete zařadit například Common Weakness Enumeration (CWE), National Vulnerability Databázi (NVD), Open Sourced Vulnerability Databázi (OSVD), nebo různé mailingové skupiny. Můžete se rovněž pokusit o nalezení databáze zranitelností pro konkrétní produkt. Ty mnohdy najdete přímo na webových stránkách výrobce daného softwaru. Například známé zranitelnosti Apache najdete na stránkách Apache.org. Pro Wordpress, jeho pluginy a témata najdete podobnou databázi zranitelností například ve WPScan Vulnerability Databázi.
Manuální vyhledávání veřejně známých zranitelností pro všechny identifikované součásti cílového systému může být časově velmi náročné. Existuje proto množství automatizovaných nástrojů - vulnerability scannerů, které dokáží cílový systém důkladně otestovat a na základě svých interních databází zranitelností dokáží identifikovat konkrétní bezpečnostní slabiny. Mezi nejznámější nástroje tohoto druhu patří například Nexpose, Nessus nebo OpenVAS.
Všechny uvedené nástroje pracují na architektuře klient/server, což znamená, že pro běh nástroje musíte na lokální nebo vzdálený počítač nejprve nainstalovat démona (serverovou část), který bude vykonávat samotné testy. Vy se k tomuto démonu budete během testování připojovat prostřednictvím klienta, kterým bývá běžně webový prohlížeč. Ten slouží jako rozhraní pro zadávání úkolů a pro zprostředkování výsledků testů.
V případě scanneru Nexpose je k dispozici několik edicí, přičemž community edice je k dispozici zdarma. Největší omezení této edice je, že s ní můžete otestovat maximálně 32 různých hostů (IP adres). Všechny ostatní edice jsou placené.
Nástroj Nessus byl původně vytvářen a šířen pod GPL licencí, tedy s otevřenými kódy a zdarma. Následně ale přešel do komerční sféry a jeho následný vývoj se rozdělil do dvou větví. První větví je komerční Nessus, druhou pak GPL projekt OpenVAS. Oba tyto nástroje tedy stojí na stejných základech.
Po té co vyhledáte relevantní zranitelnosti, měli byste svou pozornost zaměřit také na nalezení odpovídajících exploitů, pomocí kterých je možné dané zranitelnosti využít. Myslete na to, že před tím, než zranitelnost zanesete do závěrečné zprávy, měli byste se vždy ujistit, že je skutečně exploitovatelná. Administrátoři mohli klidně aplikovat patche, které zranitelnost řeší bez toho, aby museli nutně updatovat na novější verzi softwaru. Uvedení nepravdivého zjištění ve zprávě by mohlo zbytečně snížit důvěryhodnost celé zprávy. Pokud si tedy nejste zcela jisti, zda je zranitelnost exploitovatelná, pak tuto skutečnost ve své závěrečné zprávě zmiňte. Popište dostatečně všechna svá zjištění a uveďte, že se Vám zranitelnost, která by měla být v dané verzi obsažena, nepodařilo zneužít. Základem ovšem vždy bude, abyste ke konkrétní zranitelnosti vyhledali všechny dostupné informace a zveřejněné exploity a pokusili se ověřit možnost exploitace.
Před použitím exploitu byste z jeho kódu ale měli nejprve zjistit a dobře pochopit, jak vlastně funguje a co je jeho úkolem. Jeho dopady byste také měli před ostrým použitím nejprve vyzkoušet na vlastních testovacích systémech. V případě, že testujete aplikaci nasazenou v produkčním prostředí, byste asi zadavatele příliš nepotěšili, pokud by spuštění exploitu zanechalo na datech nevratné škody.
Vedle databází zranitelností existují na internetu také veřejně dostupné databáze exploitů. Nejznámější a nejvyužívanější z nich je Offensive Security Exploit Database. Pro jednoduché exploitování můžete také zkusit dohledat, zda k dané zranitelnosti není dostupný modul pro Metasploit. Vyhledávač jeho modulů najdete na webových stránkách společnosti Rapid7. Při vyhledávání a získávání exploitů Vám pomůže rovněž nástroj nazvaný Searchsploit, který patří do standardní výbavy Kali Linuxu.
Ne všechny zranitelnosti a exploity se musí objevit v uvedených databázích. Největší studnicí vědomostí je dnes nezpochybnitelně Google a proto se pokuste vyhledat prostřednictvím tohoto vyhledávače, zda někdo nezveřejnil informace o zranitelnosti v konkrétní verzi softwaru, nebo použitelný exploit na svých webových stránkách, či blogu.
Před tím, než opustíme část věnovanou mapování prostředí, měli bychom si vše stručně shrnout a uvést nějaká doporučení. Následuje tedy přehled postupů, které byste neměli během svého testu vynechat.