Fake Applications in Browser

Připomeňme si, jak zmíněný útok Browser Event Hijacking, o kterém jsem psal zde, funguje. JavaScript ve webové aplikaci se postará o odchycení klávesové zkratky CTRL+F a zabrání prohlížeči v jejím zpracování. To by totiž vedlo k zobrazení search baru. Namísto toho kód zobrazí na webové stránce grafický prvek, který je k nerozeznání od skutečného vyhledávacího řádku. Uživatel je tím pádem přesvědčen, že to co jeho oči vidí, je součást prohlížeče, tak jak je zvyklý, a o nějakém podvodu proto vůbec nepřemýšlí. Když pak například hledáním zjišťuje, zda seznam zobrazený v prohlížeči neobsahuje náhodou jeho heslo, odesílá nevědomky své heslo útočníkovi.

Řekl jsem si, že když jde podvrhnout vyhledávací řádek v prohlížeči tak, aby se tvářil jako legitimní součást prohlížeče, půjde stejným způsobem přesvědčit uživatele o pravosti i jakýchkoli dalších prvků, na které je zvyklý. A nemusí jít jen o prvky webového prohlížeče. Nejlepší bude, pokud si vše předvedeme na několika příkladech.

Příklad 1 – Aktualizace Adobe Readeru

Je běžné, že pokud uživatel otevírá ve webovém prohlížeči PDF dokument, zobrazí se mu tento v Adobe PDF plug-inu. Co ale, když je na serveru pomocí souboru .htaccess namísto PDFka podstrčen HTML dokument, který bude mít grafickou podobu PDF plug-inu?

Uživatel bude přesvědčen o tom, že se spustil doplněk pro prohlížení PDF a vyžádaný dokument je mu v něm zobrazen.
Ukázka: O červené karkulce 1

Vzhledem k častým updatům Adobe readeru uživatele ani nepřekvapí, když na něj krátce po otevření dokumentu vyskočí okno, které se tváří, že se jedná o aktualizaci od Adobe.

Pokud je obsah dokumentu pro uživatele dostatečně zajímavý, aby stál o jeho přečtení, musí se zbavit překryvného okna s aktualizací (které se mimochodem po stornování zobrazuje stále znovu). A proč by uživatel neměl tuto aktualizaci nainstalovat, když je na podobné okno zvyklý? A to nemluvím o tom, že se k němu ze všech stran stále dostávají rady odborníků, aby udržoval svůj software aktuální :) Uživatel proto s velkou pravděpodobností s klidným svědomím provede instalaci.
Ukázka: O červené karkulce 2

Uvědomme si ovšem, že se stále nacházíme pouze na úrovni HTML a o žádné skutečné aktualizaci nemůže být vůbec řeč. Webová stránka je ovšem tak přesvědčivá, že velké procento uživatelů bude přesvědčeno o tom, že aktualizace skutečně proběhla. Co z toho ale bude útočník mít? Z uvedeného opravdu téměř nic. Celé to ale zatím byla pouze příprava na samotný útok, který nyní může přijít hned v několika variantách:

Krádež administrátorského hesla

Především uživatelé, kteří dodržují bezpečnostní pravidlo o práci pod jiným než administrátorským účtem, jsou zvyklý na situaci, kdy je operační systém během instalace požádá o vložení hesla k administrátorskému účtu. Nebudou proto nijak překvapeni, když je systém o toto heslo požádá i během naší fake instalace aktualizací Adobe Readeru. Samozřejmě, že opět nepůjde o dialogové okno systému pro řízení uživatelských účtů, ale o součást útočné HTML stránky.

Uživatel vloží heslo do formuláře a odešle. Heslo se odešle útočníkovi a fake instalace bude pokračovat až do svého zdárného konce. Uživatel tak vůbec nezapochybuje o tom, že šlo o skutečnou aktualizaci, a nenapadne jej, že právě přišel o své administrátorské heslo.
Ukázka: O červené karkulce 3

Krádež souboru

Uživatelé jsou také zvyklí na to, že po nich operační systém během instalace občas požaduje, aby vyhledali na disku určitý soubor, který je k instalaci potřeba. Obdobným způsobem jako v naší předchozí ukázce si tedy může útočná fake aktualizace vyžádat zacílení určitého souboru na disku. Uživatel, pak takový soubor uploaduje na server útočníkovi, aniž by o tom opět věděl. Může tak útočníkovi nevědomky odeslat různé konfigurační soubory, soubory s hesly, apd.

Příklad 2 – Prohlížeč v prohlížeči

Když už umíme přesvědčit uživatele o tom, že to co vidí na naší útočné stránce, je určitá aplikace nebo součást operačního systému, nic nám nebrání dokonce ani v tom, abychom vytvořili rovnou celý webový prohlížeč v prohlížeči :) Co tím myslím? Řekněme si z čeho se pro uživatele webový browser skládá: Z vrchní části, která obsahuje menu a addressbar a z okna pro prohlížení. Nám tedy bude stačit, pokud vytvoříme falešnou vrchní část prohlížeče (menu + addressbar) a zobrazíme ji uživateli namísto té skutečné.

To se sice snadno řekne, ale hůře provádí, protože webová stránka samozřejmě nemůže zmíněnou vrchní oblast prohlížeče překrýt. Jak tedy na to? Musíme uživatele nějakým způsobem přinutit, aby přepnul prohlížeč do fullscreenu. Tedy aby stiskl klávesu F11. Ve své ukázce jsem tento krok vyřešil tak, že uživatel klávesou F11 spustí hru Snake. Po té, co uživatel přijde ve hře o život, nenápadně se mu vrchní část prohlížeče opět sama zobrazí. Tentokrát však již ta podvržená. Opakovaný stisk klávesy F11 je pak ošetřen aplikací stejně, jako tomu bylo u CTRL+F z úvodu článku. Tedy tak, že pouze skrývá nebo zobrazuje fake menu prohlížeče.

Ukázka: Hra Snake (FF 1280x800px)

A co tím útočník může získat? Snadno se tak může dostat do pozice Man in the middle (MITM) mezi uživatele a servery, které uživatel navštěvuje. To znamená, že všechny požadavky jdou z fake prohlížeče nejprve na server útočníka, který je zpracuje a vrátí odpovídající obsah. V podstatě se chová jako webová proxy. Veškerý obsah, který uživatel odešle, nebo který mu je zobrazen, je tak pod útočníkovou kontrolou.

Co útok vyžaduje

Pro úspěšný útok bude často potřeba, aby se webová aplikace přizpůsobila operačnímu systému, nebo webovému prohlížeči, který uživatel používá. Odlišný vzhled totiž mají okna zobrazovaná operačním systémem Linux a jiná při použití Windows XP nebo Windows 7. Stejně tak vypadají jinak součásti webových browserů IE, Firefox, Chrome, Opera, apd.

Pro útočníka ale není problém útočnou aplikaci přizpůsobit použitému softwaru. A to buď na straně serveru, kde se o uživatelově systému dozví podrobnosti z HTTP hlavičky User-Agent, kterou browser na server odesílá, nebo může o vzhledu aplikace rozhodnout i JavaScript až za běhu aplikace v prohlížeči. I ten totiž má k dispozici informaci o použitém prohlížeči.

Pro útočníka to ovšem znamená psát docela obsáhlý kód, ve kterém musí ošetřit všechny kombinace operačních systémů a webových browserů. Osobně jsem ve svých Proof of Concept ukázkách přizpůsobil vzhled pouze prohlížeči Firefox.

Dalším předpokladem pro úspěšný útok bude zřejmě také defaultní nastavení systému a prohlížeče. Pokud si totiž uživatel nastaví nějaký specifický skin, nebo bude mít v prohlížeči různé explicitně přidané panely, těžko je bude útočník ve své útočné aplikaci napodobovat.

Pokud ale budeme předpokládat, že uživatel ponechal vše v defaultním nastavení, pak bude úspěšnost útoku hodně vysoká. Na konferenci SOOM.cz Hacking & Security 2013, kde jsem výše uvedené metody prezentoval, si během prezentace útoků nikdo nevšiml a téměř všichni účastníci přiznali, že by se jimi s největší pravděpodobností nechali sami oklamat.

Video z prezentace na SOOM.cz Hacking & Security konference.

Závěr

Uvedené příklady jsou jen malou ukázkou z nekonečného množství různých variací tohoto typu útoků. Nevěřte tedy vždy všemu co vidíte.