- Útoky na Internetový uživatelé  -

Návěští „Safe for Scripting"

V létě 1999 objevili nezávisle na sobě Georgi Guninski a Richard M. Smith dvě bezpečnostní díry ve způsobu, jakým IE zpracovává ActiveX. Nastavením návěští „safe for scripting" mohou vývojáři ve svých ovládacích prvcích úplně obejít autentizaci pomocí mechanismu Authenticode. Dva příklady takovýchto ovládacích prvků byly distribuovány společně s IE verze 4 a starší. Jednalo se o Scriptlet.typelib a Eyedog.OCX, které obsahovaly výše uvedené návěští a byly Internet Explorerem vykonávány bez jakéhokoli upozornění.

Automatický update Internet Explorerem

Juan Carlos Garcia Cuartango zveřejnil dokument popisující tento problém na svém webu http://www.kriptopolis.com. Závažnost dokumentu lze posoudit z faktu, že je jako jediný přeložen do angličtiny (zbytek webu je ve španělštině). Jedná se o útok DoS, který zneužívá ovládacího prvku ActiveX používaného k instalaci souborů .CAB. Útok umožňuje uložit verifikovaný soubor .CAB na jakékoli místo disku uživatele, a to i v případě, že přepíše již existující soubor. Obrana proti chybě v automatickém updatů

Chyby JVM Netscape Communicatoru

V dubnu roku 1999 objevil Karsten Sohr na univerzitě v Marburgu chybu v důležité bezpečnostní komponentě JVM implementované v Netscape Communicatoru. Pokud byly splněny určité podmínky, JVM nedokázal prověřit kód, který měl vykonávat. Zneužití této chyby vede k porušení kontroly typů. Útok je podle toho nazýván útokem „zmatení typů" (type confusion attack). Jedná se o klasický případ odchylky implementace od návrhu systému.

Chyba v Microsoft Java Sandboxu

IE byl postižen podobnými problémy nedlouho poté. Díky chybám v implementaci sandboxu bylo možné úplně obejít bezpečnostní mechanismy JVM pomocí záškodnického appletu umístěného na webovém serveru nebo vloženého do elektronického dopisu naformátovaného pomocí HTML.

Brown Orifice - další chyby v Jávě

Během léta 2000 oznámil Dan Brumleve, že objevil dvě chyby implementace Javy v Netscape Communicatoru. Zvláště upozorňoval na chyby v třídách pro práci se soubory, které vedly k nedostatečné kontrole v případě choulostivých operací. Jednalo se o třídy java.net.ServerSocket (třída, která vytváří sokety akceptující síťová spojení), netscape.net.URLConnection a netscape.net.URLInputSteam, které představují Java metody pro čtení lokálních souborů. Ve všech třech případech obsahovaly třídy metodu, která chybně pracovala s metodou SecurityManager.check v případě ověřování, zda má applet právoprovádět uvedené akce.

Kradení cookies

Razantním způsobem zneužití cookies je jejich odposlechnutí a následné podstrčení webového serveru. K tomuto účelu lze sice použít libovolný program pro analýzu paketů, ale vhodnější je nasadit specializovaný nástroj SpyNet/PeepNet od Laurentiu Nicula (naleznete ho v archivech serveru http://packetstormsecurity.org). SpyNet se skládá ze dvou nástrojů, které se vzájemně doplňují: CaptureNet zachytí pakety tvořící relaci a uloží je na disk. PeepNet otevře soubor s relací a zobrazí její průběh ve formě přijatelné pro člověka.

Krádež cookies pomocí zákeřného URL

Uživatelé IE mohou pouhým klepnutím na chytře vytvořené URL odhalit své cookies. Skript, který má tuto schopnost (http://www.peacefire.org/security/iecookies), vymysleli Bennet Haselton a Jamie McCarthy. Stačí, abyste zvolili odkaz uvedený na této stránce, a vaše cookies jsou pro server rázem dostupné.

Chyby rámců HTML (frame) Internet Exploreru

Jednou málo známých bezpečnostních funkcí Internet Exploreru je takzvaný mezidoménový bezpečnostní model (cross-domain security model). Popis tohoto konceptu najdete v dokumentu http://www.microsoft.com/technet/security/bulletin/fq00-009-asp. Krátce řečeno se jedná o to, že IE vnitřně zabraňuje
v přístupu k datům nacházejícím se v okně otevřeném jedním webovým serverem z okna otevřeného jiným serverem. Server je přitom definován jako nejjednodušší forma IE domény. Důsledkem tohoto mechanismu je, že HTML rámec otevřený uvnitř okna může být přístupný pouze rodičovskému oknu, které je ve stejné doméně.

Zneužití IFRAME a příkazu document.exec ke čtení cizích domén

Guru přes webové prohlížeče, Georgi Guninsky, identifikoval několik případů, kdy je mezidoménový bezpečnostní model narušen. Podrobnosti lze nalézt na http://www. guninski.com/browsers.html. K demonstraci problémů Georgi často používá tag IFRAME. IFRAME je rozšířením jazyka HTML 4.0. Oproti standardnímu tagu FRAME vytváří IFRAME plovoucí rámec, který je umístěn uprostřed běžné stránky HTML stejně jako vložený obrázek. Jedná se o relativně nenápadný způsob vložení dat z jiných serverů nebo dokonce dat z lokálního souborového systému do webové stránky a dobře se hodí k utajenému přístupu k datům z jiných IE domén.

Kontrola IE domény

Andrew Nosenko z Mead & Company v červnu 2000 oznámil, že dvě funkce v IE nesprávně kontrolují příslušnost k doméně, což umožňuje zákeřné HTML stránce otevřít rámec obsahující lokální soubor a přečíst ho (viz http://www.ntsecurity.net/go/loader.asp?iD=/security/ie5-17.htm). Georgi Guninsky se nenechal zahanbit a na svém serveru zveřejnil podobnou chybu.

Obejití validace SSL certifikátu

Tento útok využívá podvržení legitimního SSL certifikátu cílového webového serveru, který bývá normálně ověřován DNS jménem a IP adresou serveru. Tak to má alespoň fungovat podle specifikací SSL. Tým ACROS ze Slovinska však objevil, že všechny verze Netscape Communicatoru starší než 4.73 ověřují proti existující relaci pouze IP adresu z certifikátu. Pokud tedy útočník donutí klienta napojit se na záškodnický WWW server, který se vydává za ten pravý, budou všechny další SSL relace k pravému serveru ve skutečnosti uskutečněny na server útočníka, a to bez jakéhokoli varování.

Vykonání dokumentů MS Office pomocí ActiveX

Když Georgi Guninski prozkoumal ActiveX tagy vložené do e-mailů ve formátu HTML a vykonávající nebezpečné ovládací prvky, neusnul na vavřínech a publikoval dokumenty obsahují informace o tom, že pomocí té samé techniky lze spustit potenciálně nebezpečné dokumenty Microsoft Office (dokumenty Office se chovají téměř jako ovládací prvky ActiveX). Problém je popsán v dokumentu http://www.gumnski. com/sheetex-desc.html (Excel a PowerPoint) a v dokumentu http://www.guninski.com/access-desc. html (Access a VBA).

Spouštění souborů pomocí nenulového parametru CLSID ActiveX

Základem tohoto útoku byla téměř nedbalá poznámka v konferenci Bugtraq (http://www.securityfocus. com/bugtraq/archive) týkající se malware.com útoku, označovaného jako „force feeding" (dostaneme se k němu později). Weld Pond z LOpht, proslavený NT netcatem, vytvořil na základě ponoukání svého kolegy DilDOga ze skupiny Cult of the Dead Cow, proslaveného programem Back Orifice 2000, mechanismus, který umožnil vykonání souboru podstrčeného uživateli pomocí techniky malware.com. Uvedením ActiveX tagu OBJECT s nenulovým parametrem CLSID v e-mailu lze spustit libovolný soubor na disku uživatele.

Přeplnění pole datum Outlooku/OE

Máte dojem, že příčinou všech problémů je ActiveX? 18. července roku 2000 byl do konference Bugtraq (http://www.securityfocus.com/bugtraq/archive) odeslán popis chyby Outlooku/OE, která nemá s ActiveX nic společného. Jedná se o klasický problém přeplnění bufferu, způsobený vložením neobvykle dlouhé GMT sekce do datového pole hlavičky dopisu. Jestliže je takováto zpráva stahována ze serveru pomocí protokolu POP3 nebo IMAP4, způsobí program INCETCOMM.DLL, zodpovědný za zpracování GMT tokenu, zhroucení Outlooku/OE a umožní vykonání libovolného kódu.

Vykonání MIME přílohy

Tento útok, který zneužívá tag IFRAME a zákeřné chování e-mailové přílohy, objevil význačný analytik otázek bezpečnosti IE Juan Carlos García Cuartango.  Juan přišel na to, že vykonavatelné soubory mohou být v IE nebo e-mail klientovi vykonány automaticky v případě, že jsou označeny nesprávnými MIME typy. Toto nekorektní označení typů může dokonce obejít filtry kontrolující obsah e-mailů.

Vykonání skryté přílohy v programu Eudora

Populární klient Eudora se také nevyhnul zkoumání hackery a výsledkem je odhalení chyby, která umožňuje vykonání kódu na cílovém počítači. Chybu odhalili lidé z malware.com, a pokud jsou splněny dále uvedené podmínky, stačí k vykonání útočného kódu pouhé spuštění programu a stažení pošty. Musí být použita následující konfigurace volně šiřitelné verze Eudory 5.0.2 pod operačním systémem Win9x, NT4 nebo 2000.

Útoky zneužívající obálky objektů

Málo známým tajemstvím Windows je, že koncovka .SHS není ve jménu souboru implicitně (díky nastavení klíče HKEY_CLASSES_ROOT\ShellScrap\NewerShowExt. v Registry) zobrazována. Asi by to nebylo nic tragického, kdyby nebyly soubory s touto koncovkou (zvané též Shell Scrap Objects) používány ke spouštění příkazů. Podstata těchto souborů je úzce spjata s technologií OLE a zjednodušeně řečeno se jedná o „obálky" pro jiný vložený objekt. Pod objektem si můžeme představit tabulku Excelu (kterou jistě mnozí z vás viděli vloženou v dokumentu Wordu) nebo nějaký další soubor. Nejjednodušší cesta, jak soubor s koncovkou .SHS vytvořit, je vložit soubor do nějaké aplikace podporující OLE (můžete zkusit třeba Wordpad) a následně zkopírovat jeho ikonu do jiného adresáře. Soubor se nyní nachází v obálce, která je reprezentována ikonou a koncovkou .SHS. Jakmile klepnete na obálku, je pomocí balíčkovače objektů (Microsoft Object Packager) spuštěn i vložený objekt. Tento mechanismus otevírá znalcům DOSu netušené obzory.

Skrývání koncovek příloh doplněním mezer

18. května 2000 popsal Volker Werth metodu (viz http://www.securityfocus.com/archive/75/60687), pomocí které lze odeslat přílohu tak, že nebude viditelná koncovka přiloženého souboru. Doplněním jména souboru mezerami (hexadecimálně %20) lze odsunout skutečnou koncovku souboru mimo prostor,
který je k zobrazení příloh v mnohých poštovních klientech vymezen.

Obelhávání uživatelů

Přímou cestou, jak donutit uživatele uložit přílohu na disk, je jemná psychologická práce. Dostali jste již někdy e-mail s takovýmto textem? „Tato zpráva obsahuje znakovou sadu, která není vaším klientem podporována. Pokud chcete vidět původní obsah zprávy, otevřete soubor uvedený v příloze. Pokud text nebude zobrazen korektně, uložte přílohu na disk a poté ji otevřete programem, který dokáže danou znakovou sadu zobrazit správně."

Ovládnutí funkce Uložit jako Excelu a PowerPointu

Princip tohoto útoku pochází ze zkoumání funkce Uložit jako (SaveAs) MS Excelu a PowerPointu Georgi Guninskim (viz http://www. guninski.com/sheetex-desc.html). Georgi zjistil, že jakmile je na dokument Office v rámci IE odkazováno pomocí již zmíněného tagu OBJECT, vzniká možnost uložení dat na libovolné místo lokálního disku. Georgiho ukázka extrahuje data, která mají být uložena, přímo ze souboru Bookl.xla (obyčejný soubor Excelu přejmenovaný na xla). Koncovka .xla je použita proto, že pokud takový soubor umístíme do adresáře Startup, bude po restartu počítače vykonán.

Násilné vnucení příloh

Lidé z http://www.malware.com vymysleli frázi „force feeding" (doslovně násilné nakrmení), aby označili mechanismus, kterým lze uložit soubory na disk uživatele bez jeho vědomí. Podstatou mechanismu je jejich tvrzení, že Outlook/OE v případě ukládání přílohy v podstatě ignoruje odpověď uživatele na nabídky dialogového okna. Pokud uživatel otevře přílohu přímo v poštovním klientovi, dotáže se Outlook/OE, zda ji má otevřít, uložit na disk nebo akci stornovat. Lidé z malware.com tvrdí, že ať uživatel zvolí cokoli, je příloha vždy uložena do adresáře %temp% (C:\Windows\temp ve Win9x a C:\temp v NT). Dočasné adresáře Win2000 jsou umístěny v prostředí jednotlivých uživatelů, a jsou tedy hůře lokalizovatelné. Jakmile je soubor uložen, je jeho spuštění zajištěno pomocí HTTP meta tagu refresh, který slouží k automatickému přesměrování prohlížeče na stránku uvedenou v tagu. Například řádek

Použití IFRAME k uložení přílohy do TEMP

V dokumentu z roku 2000 (http://www.guninski.com/eml-desc.html) Georgi prokázal svůj cit pro zdánlivý detail, který však vede k rozsáhlým důsledkům. Základní myšlenkou tohoto útoku je zneužití dočasných souborů vytvářených Outlookem/OE, které mají známá jména a libovolný obsah (jedná se o mechanismus podobný tomu, který zveřejnili lidé z malvare.com). Georgi však útok doplnil o chybu umožňující vykonání souborů .CHM (viz http://www.guninski.com/chm-desc.html) a zneužití nám již dobře známého tagu IFRAME. Zdá se, že se mu podařilo objevit spolehlivý mechanismus instalace zákeřného kódu a jeho následného spuštění. Proto jsme také ocenili celkové riziko tohoto útoku hodnotou 8 (jednou z nejvyšších). Útok se totiž nejvíce blíží stavu ideálnímu pro útočníka: uložit na disk, spustit a to vše bez intervence napadeného uživatele.

Přesměrování SMB autentizace

Tento základní, ale obzvláště ďábelský trik byl nastíněn v jedné z raných verzí programu LOphtcrack (viz kapitola 5). Oběti odešlete e-mail s vloženým odkazem na podvodný SMB server. Oběť odkaz následuje(manuálně nebo automaticky) a klient odešle serveru autentizační data SMB protokolu. Podobné odkazy se velmi snadno maskují a k tomu, aby byly použity, většinou vyžadují jen minimální spolupráci oběti. Windows se totiž automaticky pokoušejípřihlásit jako aktuální uživatel (pokud není explicitně poskytnuta jiná autentizační informace). Toto je pravděpodobně z hlediska bezpečnosti jedna z nejnebezpečnějších vlastností Windows.

Dolovaní NTLM autentizačních údajů pomocí telnet://

Jako kdyby nebylo problémů s URL filé:// dost, klienti Microsoftu automaticky zpracovávají i URL a automaticky se serverem navazují spojení. Umožňuje to vytvoření HTML e-mailu, který způsobí odeslání autentizacena libovolný port.

DCC útoky

Zajímavá diskuse o tomto útoku se objevila v poštovní konferenci Incidents (incidenty), provozované lidmi ze Security Focus (http://www.securityfocus.com). Hledejte digest INCIDENTS od 10. do 11. července 2000, #2000-131. Jeden zvláštní uživatel nabídl prostřednictvím DCC (IRC metody DCC Send a DCC Get se používají k přímému spojení klientů a následnému přenášení souborů, místo toho, aby byly soubory přenášeny přes IRC server) soubor, který se jmenoval LIFE_STAGES.TXT. Jednalo se buď o snahu útočníka přímo narušit systém uživatele nebo o automatizovaný útok odeslaný napadeným IRC klientem bez vědomí jeho uživatele.

HTTP Flood

Povodeň HTTP je metoda útoku používají hackeři k útoku na webové servery a aplikace. Skládá se ze zdánlivě legitimní sad relace vycházejících HTTP GET nebo POST požadavky zaslané na cílový webový server. Tyto požadavky jsou speciálně navrženy tak, aby konzumovat značné množství prostředků serveru, a proto může mít za následek stavu denial-of-service (aniž by nutně vyžaduje vysokou míru síťového provozu). Tyto požadavky jsou často posílány hromadně pomocí botnetu, zvýšit celkovou sílu Attack. HTTP povodní útoky může být jedním z nejvyspělejších hrozeb non-zranitelnosti čelí webové servery dnes. Je to velmi těžké pro zabezpečení sítě zařízení rozlišovat mezi legitimní HTTP a škodlivého HTTP, a pokud není správně zacházet, mohlo by to způsobit vysoký počet falešně pozitivních detekcí. Detekce motory Hodnotit založené také nejsou úspěšní v odhalování HTTP povodňové útoky, protože objem dopravy povodní HTTP může být pod limity detekce. Z tohoto důvodu je nutné použít několik parametrů, včetně detekce rychlosti na bázi a rychlosti-neměnný.