Autor: .cCuMiNn. | 18.10.2012 |
Tyto terminály vás ovšem nepustí mimo spuštěný webový prohlížeč. Jedinou možností, jak se dostat k datům v nich uloženým, tedy zůstává právě zneužití webové aplikace, kterou máme k dispozici. Pokud bych se vás nyní zeptal, která zranitelnost je ve webových aplikacích nejčastěji zastoupena, jistě byste mi bez prodlevy odpověděli, že Cross-Site Scripting. Ano, je to skutečně tak. XSS najdete téměř v 80% webových aplikací, a ne jinak tomu bude i u těchto jednoúčelovek, případně u dalších vybraných webových stránek, které máte kioskem povoleno navštívit. Může nám ale XSS nějak pomoci v přístupu k souborům, které jsou v daném kiosku lokálně uloženy, a jaká data bychom tak mohli získat?
Mnoho informačních kiosků nejspíš příliš zajímavých dat obsahovat nebude. Najdou se ale i takové, které obsahují databáze s diskrétními daty a jejich kompromitaci pak již rozhodně není radno podceňovat. Útočníka ale mohou zajímat například i různé konfigurační soubory, jež by mohly obsahovat hesla, či jiné důležité údaje.
Co se týká samotného přístupu k lokálně uloženým souborům, tak nám XSS v tomto směru může být nápomocno hned několika způsoby. Musím zmínit, že k sepsání tohoto článku mě inspiroval Subber, který před nedávnem právě tento problém řešil a hledal možnosti, kterými lze lokálně uložené soubory pomocí XSS přečíst. Protože mě samotného překvapilo, jaké rozličné varianty ataku má útočník k dispozici, rozhodl jsem se pro jejich ucelené sepsání.
Ne všechny uvedené varianty půjde využít u všech terminálů. Někde sice mohou být použitelné všechny, jinde naopak nemusí být funkční žádný z nich. Vždy záleží na použitém webovém prohlížeči, nastavených právech a konfiguraci daného terminálu. Rozhodujícími faktory, které ovlivňují úspěch útoku, jsou především:
Prvním krokem, který útočníkovi umožní procházet adresářovou strukturu lokálního disku, bude využití některého neošetřeného výstupu (XSS) k injektáži HTML prvku input typu file.
Načtením takto nakažené webové stránky na ní útočník vykouzlí pole, které mu umožní snadný průzkum disku a pomůže odhalit zajímavé soubory, které jsou na lokálním disku uloženy.
Procházením disku ovšem celý útok zdaleka nekončí. Jedna věc je zjistit strukturu adresářové struktury, druhá a často složitější věc, je dostat se k samotnému obsahu jednotlivých souborů.
Útočník může vyzkoušet vyvolat kontextové menu nad kterýmkoliv souborem již během jeho výběru, a bude-li mít štěstí a toto se mu podaří, může v něm klidně najít i volbu pro otevření souboru. Tato varianta bude ovšem spíše výjimkou.
Druhou z variant, která se pro načtení obsahu nabízí, je využít XSS zranitelnosti k injektáži rámu, který by obsah souboru přímo zobrazil. Zde je ovšem podmínkou OS Windows, zpřístupnění výchozích sdílených složek a běh pod administrátorským účtem. S tím se ovšem v praxi s největší pravděpodobností asi také nesetkáte.
Pokud browser pochází z rodiny Internet Explorerů a má povoleno spuštění důvěryhodných Active X komponent, pak se dá této skutečnosti využít k výpisu obsahu souboru následujícím kódem
Protože se už jedná o relativně delší kód, je vhodné si nejdříve zjistit, zda a z jakých umístění je možné injektovat externí skripty. Pokud je toto možné, může to výrazně zkrátit čas strávený u terminálu, protože si útočník může kód vytvořit a uploadovat na svou stránku předem. V kiosku pak stačí injektovat pouze krátký kód.
V mladších verzích webových prohlížečů je k dispozici také další zajímavá novinka, kterou je File API. S jeho pomocí je možné přečíst obsah lokálně uloženého souboru podobně, jako tomu bylo v případě Active X komponenty. Bohužel není File API aktuálně podporováno ze strany Internet Exploreru. V jeho případě se podpory dočkáme až ve verzi IE 10.
V kiosku může být povoleno také načítání Flashových animací, nebo Java appletů. Pokud navíc není omezeno, odkud je možné tyto objekty načítat, stojí za zkoušku injektovat do stránky jeden z níže uvedených kódů, který by odkazovat na odpovídající soubor.
Původně jsem měl v plánu na tomto místě přiložit jednuchý Flash a Java applet, který by nedělal nic iného, než jen poskytl vstupní pole pro výběr souboru a následně zobrazil jeho obsah. Nepodařilo se mi však sehnat žádného dobrovolníka, který by byl ochoten to naprogramovat. Pokud byste měli chuť se do toho pustit, pak na toto místo rád vaše výtvory přidám dodatečně.
V případě, že žádná z výše uvedených variant zobrazení obsahu souboru přímo v terminálu nevedla ke zdaru, zbývá ještě možnost odeslat soubor na svůj webový server, nebo na některou z domén, jejich načítání je v terminálu povoleno.
V případě zaslání souboru na vlastní server, pokud to terminál umožňuje, bude situace velice jednoduchá. Pomocí XSS zranitelnosti v tomto případě nebude útočník do zranitelné stránky injektovat pouze element input, ale rovnou celý formulář s vhodně nastavenými atributy.
Skript save.php na útočníkově serveru pak bude pouze přebírat a ukládat obdržené soubory, které si útočník následně může procházet v klidu domova.
Otázkou ovšem zůstává, zda je v tomto případě ještě nutné hledat a zneužívat XSS. Snad jen v případě, kdy požadavky mimo povolené domény sice odchází, ale je blokováno zobrazení vrácených stránek.
Pokud není umožněno načítání jiných, než několika vyjmenovaných domén, pak útočníkovi nezbývá, než se na nich pokusit najít takovou stránku, která by umožňovala upload souborů, odeslání emailu s přílohou, nebo třeba vracela v chybové hlášce obsah obdrženého požadavku.
Vidíte, že možností, jak se dostat k lokálně uloženým souborům na strojích, které uživatele nepustí mimo webový prohlížeč, existuje celá řada. Nelze přitom jednoznačně říci, který z nich je nejlepší, neboť vždy záleží na konfiguraci a mnoha dalších faktorech konkrétního terminálu. Na vaše vlastní zkušenosti a další metody hackování těchto zařízení se těším v komentářích…