Zpět na seznam článků     Číst komentáře (1)     Verze pro tisk

PTWA: Průzkum prostředí

Autor: .cCuMiNn.   
26.5.2016

Tento text je součástí on-line testovací příručky, která pro vás na tomto serveru vzniká. Budeme rádi za vaše připomínky v komentářích a za vaši aktivní účast v doprovodných projektech.


Nad tím, zda testy prostředí, ve kterém webová aplikace běží, spadají ještě do oblasti penetračního testování webových aplikací, nebo zda by tyto testy měly být zahrnuty do testů síťové infrastruktury, by se daly vést dlouhé polemiky. Jisté je, že penetrační tester, který zkoumá bezpečnost webové aplikace, má hned dva dobré důvody, proč by měl kromě samotné aplikace zmapovat a otestovat také prostředí, které tato aplikace využívá ke svému běhu. Zaprvé je pro testera důležité vědět, na jakém webovém serveru je aplikace spuštěna, v jakém programovacím jazyce byla naprogramována, či jaký framework byl při vývoji použit, aby mohl lépe porozumět samotnému vnitřnímu fungování aplikace, a mohl těmto skutečnostem lépe přizpůsobit své testy. Na co by například bylo dobré vyhledávat na webovém serveru soubory s koncovkou .asp, pokud byla aplikace naprogramována v php, nebo nač by bylo dobré se snažit načítat soubor .htaccess, pokud aplikace běží na IIS. Při inkluzi lokálních souborů by pak obdobně postrádalo smysl snažit se načítat soubor /etc/passwd na serveru, který běží na platformě Windows a obráceně. Pokud tester přesně ví, o jakou aplikaci se jedná (že jde například o Wordpress), má také ušetřeno mnoho práce při mapování zdrojů. Bude tak mnohem úspěšnější, neboť struktura adresářů a umístění konkrétních souborů je v tomto otevřeném redakčním systému veřejně známá.

Druhým důvodem, proč by penetrační tester, který má za úkol prověřit zabezpečení webové aplikace, měl současně prověřit i samotné prostředí, je známý fakt, že každý řetěz je pouze tak silný, jak silný je jeho nejslabší článek. Jak byste se asi cítili, kdyby pouhý jeden týden po odevzdání Vaší závěrečné zprávy došlo ke kompromitaci webového serveru, na kterém jste testovali, skrz dlouho veřejně známou zranitelnost, o jejíž existenci jste ve své zprávě neuvedli ani slovo? Přestože vzájemná smlouva neobsahovala žádnou zmínku o tom, zda jsou od Vás tyto testy očekávány, nemusel by na Vás podobný incident vrhnout zrovna nejlepší světlo. Se zadavatelem si proto předem jasně stanovte rozsah Vašeho testování a testy prostředí z něj explicitně vyjměte, nebo berte tuto oblast jako neodmyslitelnou součást penetračních testů samotné webové aplikace a raději všechny tyto testy zahrňte, i v případě, kdy nebyly ve smlouvě zmíněny.

Tato kapitola si klade za cíl seznámit Vás s postupy a metodami, jak o cílovém prostředí shromáždit co nejvíce relevantních informací.

Identifikace operačního systému

Identifikace operačního systému by se měla stát Vaším prvním krokem na dlouhé cestě napříč mapováním prostředí. Naštěstí pro Vás ale tato cesta nebude příliš dlouhá ani trnitá. Zjištění operačního systému se dá totiž zvládnout poměrně elegantně, efektivně a hlavně spolehlivě také pomocí automatických nástrojů.

HTTP response hlavičky

Verzi operačního systému lze často vyčíst přímo z HTTP hlaviček obsažených v odpovědi serveru, například z hlavičky Server.

Výpis HTTP komunikace s vloženou hlavičkou Server


Obsah těchto hlaviček se ale nutně nemusí zakládat na pravdě, protože jej administrátoři čím dál častěji záměrně spoofují (uvádějí nepravdivou hodnotu), aby zmátli případného útočníka. Rozhodně by se proto pro Vás neměl tento údaj stát bernou mincí, a i když tato HTTP hlavička prozrazuje na první pohled přesnou verzi běžícího operačního systému, měli byste pokračovat dále ve sběru informací a tuto skutečnost byste měli potvrdit, nebo vyvrátit i ostatními popsanými metodami.

Obsah hlavičky Server můžete snadno získat pomocí nástrojů jako je Telnet, Netcat, nebo pomocí některého z nástrojů, které plní roli lokálního proxy, například Burp Suite, ZAP či Fiddler2.

S nástrojem Netcat, který je k dispozici pro Linux i pro Windows, zjistíte obsah HTTP hlavičky Server jednoduše tak, že se tímto nástrojem připojíte na webový server a metodou GET nebo HEAD si prostě řeknete o odpověď, ve které všechny vrácené HTTP hlavičky naleznete.

Získání HTTP hlavičky Server nástrojem Netcat
C:\>nc www.example.cz 80
HEAD / HTTP/1.1
HOST: www.example.cz

HTTP/1.1 200 OK
Date: Mon, 21 Dec 2015 11:22:38 GMT
Server: Apache/2.2.22 (Win64) mod_ssl/2.2.22 OpenSSL/1.0.1c PHP/5.3.13
X-Powered-By: PHP/5.3.13
Content-Type: text/html

V případě vynikajícího nástroje Burp Suite bude situace díky nutnosti jeho prvotního nastavení poněkud složitější. Protože se ale bez tohoto programu (nebo jemu podobných) během následujících testů neobejdete, pojďme si jej nakonfigurovat již nyní.

Burp Suite je nástroj, který je napsán v Javě, což znamená, že k jeho běhu budete potřebovat Runtime verzi Javy. Burp Suite následně můžete stáhnout z webových stránek společnosti PortSwigger Ltd, kde je k dispozici jednak zdarma dostupná Free Edition verze nástroje Burp Suite, nebo placená verze Professional Edition. Free verze je oproti placenému vydání ochuzena o některé funkce, které testování s tímto nástrojem velmi usnadňují. I ve Free verzi je ale tento nástroj velice zdatným pomocníkem, který by neměl chybět ve výbavě žádného penetračního testera. Pokud to ovšem myslíte s bezpečnostním testováním skutečně vážně, určitě neprohloupíte, pokud si licenci k Professional verzi zakoupíte. Aktuální cena pro jednoho uživatele je 299$ za rok.

Ať už jste si stáhli volnou, nebo pořídili placenou verzi Burp Suite, konfigurace bude probíhat v obou případech stejně. Tento nástroj, který se všeobecně označuje jako lokální HTTP proxy, je totiž potřeba postavit do pozice MiTM (Man in The Middle) mezi Váš webový browser a testovaný webový server. Díky tomu, že budete veškerou komunikaci mezi nimi směřovat přes toto Vaše proxy, budete mít veškerý přenášený obsah plně pod kontrolou. Budete tak moci sledovat nejen všechny odchozí požadavky, ale také všechny vrácené odpovědi serveru.

Schéma postavení lokálního proxy mezi prohlížeč a webový server


Burp Suite defaultně naslouchá na portu 8080, což musíte sdělit Vašemu webovému prohlížeči. Jde Vám totiž o to, aby prohlížeč nesměroval požadavky přímo na webový server, ale namísto toho je zasílal právě na lokální port 8080, kde Burp Suite naslouchá. Pokud byste z nějakého důvodu potřebovali výchozí port změnit, můžete tak učinit v Burp Suite na záložce Proxy / Options. Na stejném místě si můžete také ověřit, zda je zaškrtnuta volba Running, která indikuje, že vše běží tak, jak má.

Nastavení a ověření naslouchání nástroje Burp Suite na konkrétním portu


Nastavení prohlížeče Firefox provedete prostřednictvím volby Nástroje / Možnosti / Rozšířené / Síť / Nastavení připojení / Ruční konfigurace proxy serverů, kde do vstupního pole HTTP proxy vložíte IP adresu 127.0.0.1 (localhost) a do pole Port hodnotu 8080, pokud jste ji explicitně nezměnili. V případě jiných webových prohlížečů bude konfigurace obdobná.

Nastavení proxy v prohlížeči Firefox


Burp Suite umožňuje také zachytávání a průzkum šifrované HTTPS komunikace. Máte-li zájem i o tuto funkci, nezapomeňte ve svém prohlížeči nastavit stejné hodnoty také pro SSL proxy. Nebuďte ale v takovém případě překvapeni, když Vám bude během surfování po internetu Váš webový prohlížeč oznamovat, že je něco v nepořádku s certifikátem právě navštívených serverů. Tím, že nástroj Burp Suite zaujme pozici muže uprostřed (MiTM), bude do komunikace podstrkávat své vlastní certifikáty, které pro Vás nebudou důvěryhodné. V případě, že se těchto oznámení budete chtít zbavit, budete si muset naimportovat certifikát PortSwigger CA mezi své důvěryhodné root certifikační autority.

Pro stažení certifikátu navštivte při spuštěném nástroji Burp Suite adresu http://burp, kde v menu najdete odkaz CA Certificate. Kliknutí na tento odkaz povede ke stažení souboru cacert.der.

CA certifikát PortSwiggeru získáte návštěvou adresy http://burp


Následně přejděte ve Firefoxu skrze menu Nástroje / Možnosti / Rozšířené / Certifikáty / tlačítko „Certifikáty“ / záložka „Autority“ k importu staženého certifikátu a povolte jej pro identifikaci webových serverů. Po správném importu by se Vám mezi důvěryhodnými autoritami měla objevit certifikační autorita PortSwigger CA, viz následující obrázek.

Přidaná certifikační autorita PortSwigger CA


Nyní, když Vám Burp Suite běží a Váš prohlížeč ví, že má komunikaci směřovat přes tento nástroj, který teprve následně Vaše požadavky přepošle na webový server, můžete zkusit navštívit libovolnou webovou stránku. Ať již zapíšete její adresu do URL, nebo kliknete na libovolný odkaz, měla by se ve webovém prohlížeči začít točit ikona načítání stránky. Prohlížeč se bude chovat, jako byste právě přišli o připojení k síti. Na svědomí to má Intercept, který je součástí modulu Proxy v nástroji Burp Suite. Intercept totiž Váš požadavek, který jste odeslali webovému serveru, zachytil a pozastavil.

Request zachycený interceptem v nástroji Burp Suite


Možnost pozastavit požadavek, provést v něm libovolné úpravy a teprve po té jej odeslat webovému serveru, budete při svých testech často využívat. V tuto chvíli by Vám ale byla spíše na obtíž a proto pozastavování requestů vypněte tlačítkem Intercept is on, které se po kliknutí na něj přepne do stavu Intercept is off. Nyní se již můžete po internetu volně pohybovat bez toho, abyste o existenci nástroje Burp Suite vůbec věděli. Přesto ale nebudete přicházet o žádná data, která si během surfování vyměňuje Váš webový prohlížeč se serverem. Kdykoliv se můžete v případě potřeby přepnout do Burp Suite, kde všechny requesty, které opustily Váš prohlížeč, najdete na záložce Proxy / HTTP history.

Seznam requestů zachycených nástrojem Burp Suite


Kliknutím na libovolný požadavek ze zobrazeného seznamu se Vám ve spodní části ukáže obsah requstestu nebo obsah odpovědi serveru v závislosti na tom, zda se ve spodní části právě nacházíte na záložce Request, nebo Response.

HTTP response hlavičky zobrazené v nástroji Burp Suite


No a to už jsme se oklikou vrátili zpět k tématu, jak zjistit obsah HTTP hlavičky Server, kterou webový server propaguje ve svých odpovědích. V historii HTTP komunikace klikněte na libovolný požadavek směřující na testovaný server a přepněte se na záložku Response. Zde naleznete celý obsah odpovědi včetně všech HTTP response hlaviček. Na předchozím obrázku si můžete všimnout, že hlavička Server obsahuje mimo jiné také údaj Win64.

Přesto, že jste již zjistili vše, co jste v tomto kroku zjistit potřebovali, přesto se zkuste v nástroji Burp Suite, konkrétně v modulu Proxy, ještě chvíli zdržet. Proklikejte si například všechny záložky, které umožňují zobrazit požadavky a odpovědi v různých formátech (Raw, Headers, Hex, Render, atd.), Všimněte si také řádku začínajícího textem Filter:, který najdete hned pod záložkami Intercept a HTTP history. Kliknutím na tento řádek máte možnost ovlivnit viditelnost konkrétních requestů v seznamu. Důkladně si také zažijte použití interceptu a jeho tlačítek Forward, Drop, Intercept is on/off. V dalším textu totiž již budu předpokládat, že Vám prohlížení historie a pozastavování requestů nečiní žádné potíže.

Souvislost mezi běžícími službami a OS

Některé operační systémy se vyznačují tím, že mají defaultně spuštěné některé služby naslouchající na konkrétních portech. Mezi dobrou techniku vedoucí ke zjištění běžícího operačního systému tak lze zcela jistě zahrnout také skenování otevřených portů a průzkum bannerů, které naslouchající služby propagují. I když je možné tyto bannery také spoofovat a služby přesídlit na jiné než defaultní porty, k čemuž se dnes uchyluje stále více administrátorů, stále zůstává tato technika v identifikaci OS velmi účinnou.

V praxi by podobný sběr informací znamenal připojit se telnetem na každý otevřený port a sklidit obsah bannerů, které naslouchající služby poskytují. V reálu tento typ manuálního průzkumu ale není z důvodu jeho časové náročnosti příliš vhodný a je proto běžné, že je k tomuto sběru informací použito některého automatického skeneru portů. Asi nejčastěji se pro tento účel používá známý a hlavně spolehlivý nástroj Nmap, případně s jeho grafickou nástavbou Zenmap.

Snímek nástroje Zenmap (grafické nástavba Nmapu)


Pokud budete chtít otestovat pouze to, které ze všech 65.535 portů jsou na cílovém systému otevřené, provedete to pomocí nástroje Nmap z příkazové řádky, následujícím příkazem:

nmap –p 1-65535 192.168.1.1

Rozšíření testů o rozpoznání služby na základě rozdílů v implementaci služeb, nebo ze sběru dat z uvítacích bannerů provedete přidáním přepínače -sV.

nmap –sV –p 1-65535 192.168.1.1

Nmap se nyní vždy připojí na každý z portů a pokud je port otevřený, bude se s běžící službou snažit prohodit „pár slov“, aby zjistil, co přesně naslouchá na druhé straně. Největší nevýhoda Nmapu se projeví ve chvíli, kdy mu služba předhodí zfalšovaný banner, který odpovídá jiné existující službě, jež má Nmap ve své databázi. Nmap v takovém případě ukončí bez dalšího testování okamžitě svůj průzkum na daném portu a službu, které odpovídá spoofovaný banner nám oznámí jako závěr svého průzkumu. Obelstít Nmap tedy není rozhodně nic složitého.

Použití nástroje Nmap
C:\>nmap -sV -p 1-65535 192.168.56.102

Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-21 15:37 Střední Evropa (běžný čas)
Nmap scan report for 192.168.56.102

Host is up (0.00070s latency).
Not shown: 65523 closed ports
PORT      STATE SERVICE     VERSION
80/tcp    open  http        Apache httpd 2.2.21 ((Win32) PHP/5.3.10)
135/tcp   open  msrpc       Microsoft Windows RPC
139/tcp   open  netbios-ssn
445/tcp   open  netbios-ssn
3306/tcp  open  mysql       MySQL (unauthorized)
5357/tcp  open  http        Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
49152/tcp open  msrpc       Microsoft Windows RPC
49155/tcp open  msrpc       Microsoft Windows RPC
MAC Address: 08:00:27:4A:57:50 (Cadmus Computer Systems)
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/
Nmap done: 1 IP address (1 host up) scanned in 110.79 seconds

Zmíněnou nevýhodu Nmapu se snaží eliminovat nástroj podobného jména Amap od skupiny The Hacker’s Choice. Vrácených bannerů si tento nástroj všímá pouze okrajově. V prvé řadě se totiž Amap snaží navázat s každou službou několik spojení, aby z ní vylákal nějaké smysluplné informace, na základě kterých by se služba dala rozlišit. Takto je docíleno toho, že i v případě, kdy služba poskytuje pozměněný banner, nebo běží na nestandardním portu, bude přesto správně identifikována. Počítejte ovšem s tím, že je Amap na síti poměrně hlučný díky množství nestandardních paketů, jež odesílá. Vaše testy díky tomu mohou být poměrně snadno odhaleny ze strany IDS. Významnou výhodou Amapu je ale také to, že umožňuje identifikovat i služby obalené pomocí SSL.

Ukázka použití nástroje Amap
C:\>amap.exe 46.167.245.70 80
amap v5.4 (www.thc.org/thc-amap) started at 2015-12-21 20:33:52 - APPLICATION MAPPING mode

Protocol on 46.167.245.70:80/tcp matches http
Protocol on 46.167.245.70:80/tcp matches http-apache-2

Unidentified ports: none.
amap v5.4 finished at 2015-12-21 20:33:58

TCP/IP komunikace

Pravděpodobně nejspolehlivější a současně nejrychlejší způsob, jak identifikovat operační systém, nám poskytne samotná TCP/IP komunikace. Každý operační systém totiž implementuje tuto komunikaci trochu odlišně, což umožňuje poněkud volnější specifikace některých částí TCP packetu. Pokud tedy navážete s cílovým systémem kontakt, a odešlete mu sadu speciálně upravených (nestandardních) packetů, zareaguje na ně každý operační systém trochu jinak. Díky tomu jste schopni porovnat vrácené odpovědi vůči databázi vzorků získaných z jednotlivých systémů a dokážete tak konkrétní systém poměrně přesně identifikovat.

Protože by podobná identifikace byla pro ruční analýzu příliš složitá, určitě bude v tomto případě lepší poohlédnout se po nějakém automatickém nástroji, který OS fingerprinting umožňuje. Asi nejoblíbenějším a nejspolehlivějším nástrojem s velice rozsáhlou databází vzorků z různých operačních systémů je bezpochyby opět Nmap. Ten jsme použili již pro identifikaci běžících služeb v předchozí kapitole. Pro detekci operačního systému na základě aktivní komunikace lze v Nmapu použít přepínač -O.

Zjištění OS nástrojem Nmap
C:\> nmap -O www.example.cz
Starting Nmap 6.47 ( http://nmap.org ) at 18:46 Střední Evropa
Nmap scan report for www.example.cz (18X.150.12.4)
Host is up (0.028s latency).
rDNS record for 18X.150.12.4: example.cz
Not shown: 987 closed ports
PORT    STATE    SERVICE
22/tcp  open     ssh
25/tcp  open     smtp
80/tcp  open     http
143/tcp open     imap
443/tcp open     https
Aggressive OS guesses: Linux 3.2-3.8 (95%), Linux 3.1-3.2 (94%), Linux 2.6.32-2.6.39 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 10 hops
OS detection performed. Please report any incorrect results at http://nmap.org/submit
Nmap done: 1 IP address (1 host up) scanned in 41.22 seconds

Podobně jako tomu bylo v případě použití nástroje Amap, odesílá i uvedené použití nástroje Nmap na cílový server množství TCP packetů s nestandardním obsahem. Díky tomu může být test detekován a v horším případě i zablokován a předčasně ukončen. Pokud byste tedy potřebovali provést testování a zůstat při tom nezpozorováni, pak budete muset sáhnout k jinému nástroji, nebo k určení cílového systému na základě pasivního odposlechu komunikace.

Nástrojem, který se snaží uvedenou slabinu Nmapu odstranit, je Xprobe2. Jeho autoři se během identifikace systému rozhodli použít pouze standardní TCP, UDP a ICMP packety, které odpovídají všem RFC specifikacím. Díky tomu se Vaše komunikace během testování v běžném síťovém provozu snadno ztratí. Více se o nástroji Xprobe2 dočtete například ve článku Sbíráme otisky: aktivní Nmap a Xprobe2, který vyšel na serveru Root.cz.

V případě pasivního skenování se s cílovým systémem naváže běžná TCP komunikace například z webového browseru a detekce operačního systému je prováděna na základě jejího pasivního odposlechu a vyhledáváním některých odlišností v zachycené TCP komunikaci. Tyto odlišnosti se týkají například velikosti TCP okna, hodnoty Time To Live (TTL), hodnoty Initial Sequence Number (ISN), příznaku segmentace (DF) a podobně. Asi nejrozšířenějším nástrojem pro pasivní detekci OS je nástroj p0f, jenž je k dispozici defaultně pro Linux, ale který byl portován i na Windows. Pro více informací o pasivní detekci a o nástroji p0f Vás odkáži na článek Sbíráme otisky: pasivní p0f.

Když už jsme u automatických nástrojů, které nám umožňují identifikovat použitý operační systém, možná by nebylo na škodu, podívat se současně i na jeden on-line nástroj, který je penetračními testery poměrně často vyhledáván. Tímto nástrojem je Netcraft.

Výhodou tohoto on-line nástroje je, že nám vedle aktuálních dat, poskytne k cílovému systému také náhled do jeho historie. Dozvíme se tak, jak často se u testované domény mění servery, systémy, nebo poskytovatelé webhostingu. I toto totiž může mít pro penetračního testera svou hodnotu. Údaje uvedené u zkoumaného systému na stránkách netcraft.com, berte ale raději s rezervou. Informace o operačním systému a webovém serveru jsou totiž přebírány pouze z HTTP hlaviček, které server propaguje a jak již bylo uvedeno, nemusí se tyto údaje zakládat na pravdě.

Historie vedená ke konkrétní doméně na Netcraft.com


Zbývá ještě dodat, kde údaje z předešlého screenshotu na stránkách netcraft.com naleznete. Po příchodu na web http://www.netcraft.com/ zapátrejte v pravém sloupci stránky, kde vyhledejte formulář nadepsaný „What that site running?“, do něhož stačí vepsat Vámi tetovanou doménu.

Formulář pro vyhledávání informací na homepage Netcraft.com


O nástroji Netcraft bude řeč ještě později v kapitole věnované identifikaci subdomén. I v této oblasti totiž dokáže být tento nástroj skvělým pomocníkem. Pokud byste se chtěli poohlédnout po nějaké profesionální, byť placené, alternativě k Necraftu, doporučuji Vám navštívit webové stránky domaintools.com.

Information leakage

Dalším dobrým postupem pro správné určení operačního systému může být nalezení takového místa ve webové aplikaci, které nám tuto informaci prozradí prostřednictvím různých chybových hlášení. Zde se pozastavíme nad vyvoláním defaultních chybových stránek a nad zranitelností Full Path Disclosure.

Defaultní chybové stránky

Metodou, která nám často pomůže poměrně rychle identifikovat operační systém a často i mnohem více, jsou defaultní chybové stránky webového serveru. Jedná se o webové stránky vrácené se stavovými kódy 400, 401, 402,403, 404, 500, 501, 502 nebo 503. Pokud správce stránek ponechá implicitní nastavení a nepoužije své vlastní upravené chybové stránky, pak jejich obsah může prozrazovat jednak použitý operační systém, ale i verzi běžícího webového serveru nebo interpretu použitého jazyka. Následující obrázek zobrazuje několik defaultních chybových stránek webového serveru Apache, které ve své patičce uvádí v závorce verzi operačního systému.

Patičky defaultních chybových stránek prozrazující verzi OS


Dokonce i v případech, kdy Vám defaultní chybová stránka přímo nesdělí konkrétní operační systém, na kterém webový server běží, dokáže často poměrně dobře napovědět. Webový server Apache, ze kterého byly výše uvedené chybové hlášky, může běžet téměř na libovolné platformě. Pokud ale uvidíte defaultní chybové stránky, které vypadají jako ta z následujícího obrázku, můžete si být téměř jisti, že server, který máte před sebou, běží na platformě Windows. Ze vzhledu těchto defaultních chybových stránek pak dokážete také určit minimálně přibližnou verzi IIS (pokud není v chybové zprávě přímo uvedena) a od ní pak lze často také dále odvodit i konkrétní verzi běžících Windows, viz tabulka.

Defaultní chybová stránka IIS


Verze IIS versus verze Windows
IISWindows
IIS 1.0Windows NT 3.51
IIS 2.0Windows NT 4.0
IIS 3.0Windows NT 4.0 Service Pack 2
IIS 4.0Windows NT 4.0 Option Pack
IIS 5.0Windows 2000
IIS 5.1Windows XP Professional, Windows XP Media Center Edition
IIS 6.0Windows Server 2003, Windows XP Professional x64 Edition
IIS 7.0Windows Server 2008, Windows Vista
IIS 7.5Windows Server 2008 R2, Windows 7
IIS 8.0Windows Server 2012, Windows 8
IIS 8.5Windows Server 2012 R2, Windows 8.1

Defaultním chybovým stránkám je věnováno více prostoru v kapitole Identifikace webového serveru.

Dostat se k chybovým stránkám přitom není často vůbec obtížné. Tyto stránky dokážete vyvolat často na první pokus pomocí vstupů z následující tabulky.

Některé možnosti, jak vyvolat chybové stránky s různými status kódy
StatusNázev
400Bad request Do URL vložit znak procento [%]
401Unautorized Na výzvu k HTTP autentizaci odpovědět stornem
403Forbidden Pokusit se o přístup k souboru .htaccess
404Not found Do URL vložit za doménu null char [%00]
414Request-URI Too Long Odeslání velice dlouhého GET requestu
500Server error Pokusit se načíst cestu LPT1, AUX, COM1
501Not implemented Odeslat request s neexistující HTTP metodou

Rezervované názvy souborů

Operační systém Windows má jednu výraznou vlastnost. Totiž, že rezervuje některé řetězce, které není možné použít pro názvy souborů nebo složek. Vyzkoušejte si například na filesystému vytvořit složku pojmenovanou AUX, LPT1, apd. Zjistíte, že Vám to Windows nepovolí. Obdobná situace nastane i v případě, kdy se budete snažit přistoupit k souboru a v cestě uvedete některý z těchto speciálních názvů. Pokud povede vložení některého rezervovaného názvu LPT1, COM1, PRN, nebo AUX do URL k vyvolání status kódu 403, nebo 500, pak si můžete být jisti, že server běží na systému Windows. V Linuxu totiž názvy těchto souborů rezervované nejsou.

Vložení LPT1 do URL vede k chybě se stavovým kódem 500

Full Path Disclosure

Mezi další metody, jak se dá alespoň zhruba zjistit, na jakém operačním systému server běží, je pokusit se najít zranitelnost Full Path Disclosure (FPD), nebo-li odhalení celé cesty. Tato zranitelnost se vyznačuje tím, že v chybové hlášce zobrazí celou cestu na filesystému, kde je uložen skript, jež chybu vyvolal. Z této chybové zprávy můžete snadno vyčíst, zda se jedná o Unixový systém nebo o Windows. V Linuxu bude totiž cesta vypadat nějak takto /var/www/myweb, kdežto ve Windows například takto C:\Inetpub\wwwroot\myweb.

O zranitelnostech Full Path Disclosure se více dočtete v jim věnované kapitole, kde najdete i mnoho doporučení, jak tuto chybu vyvolat.

Chybové zprávy zobrazující celé cesty na filestému (FPD)


I bez vyvolání této chyby se ale již nyní můžete pokusit o její vyhledání na testované doméně s použitím vyhledávače Google. Toto řešení má tu výhodu, že Vám odhalí chybové zprávy, jejichž možnost vyvolání byla v aplikaci již odstraněna, a chybovou zprávu tak již není aktuálně možné zobrazit.

Google dork, který dokáže na testované doméně vyhledat FPD
site:example.cz  error OR warning OR notice "on line"

Použitý programovací jazyk

I samotný programovací jazyk, ve kterém je webová aplikace napsána, může o operačním systému leccos napovědět. ASP stránky budete totiž na Linuxu hledat nejspíš marně. Pokud tedy zjistíte, že webové stránky v testované aplikaci mají právě tuto příponu, pak si můžete být téměř stoprocentně jisti, že Vám na druhém konci odpovídá operační systém Windows. Úplně stoprocentně se ale ani na toto spolehnout nelze. Dnes již existují možnosti rozběhnutí ASP stránek i pod Linuxem. Kvůli zmatení případného útočníka mohou administrátoři také klidně sáhnout i k takovému činu, jako je změna přípony spustitelných skriptů. Přestože se pak stránky tváří, že jsou naprogramovány v ASP, mohou ve skutečnosti obsahovat například PHP kód. Pro více informací o tom, jak zjistit použitý programovací jazyk, navštivte kapitolu Identifikace programovacího jazyka.


Tento text je součástí on-line testovací příručky, která pro vás na tomto serveru vzniká. Budeme rádi za vaše připomínky v komentářích a za vaši aktivní účast v doprovodných projektech.
Líbil se Vám článek?
Budeme potěšeni, pokud vás zaujme také reklamní nabídka

Social Bookmarking

     





Hodnocení/Hlasovalo: 1.06/17

1  2  3  4  5    
(známkování jako ve škole)