Il giorno sab, 02/02/2008 alle 17.44 +0100, Andrea Dainese ha scritto: > Chiaro, persò se non sbaglio nell'articolo iniziale si parlava di > "semplice link". Allora, o e' un errore di chi scrive gli articoli, oppure se si guarda l'articolo originale non parla di cliccare su un link che ti porta sulla pagina del router, ma di andare su una pagina malicious. o precedentemente iniettata tramite Xss http://www.symantec.com/enterprise/security_response/weblog/2007/02/driveby_pharming_how_clicking_1.html Cito: "....(1) All you have to do to become a victim is simply visit the Web page that hosts this malicious code. You don’t have to click OK on any dialogue boxes or accidentally download and install malicious software. Simply viewing the page in question is enough to cause the necessary damage....."
Infatti non era un link con <a href=''> ma era un csrf sfruttato usando: < script src =" http: // 192.x.x.x/ h_wan_dhcp.cgi?dns1=69.6.6.6" > o < iframe src > o < img src > (http://www.heise-security.co.uk/news/85482) e in particolare legato a una vuln dei 2wire/linksys & co. http://securityreason.com/securityalert/3026 > Vero che nel pdf di Symantec si parlava di applet Java, ma mi > concederai che le due cose differiscono e non di poco, anche nella > potenziale diffusione (non basta una semplice link inviato via mail) Te lo concedo :), pero' nello specifico la richiesta non prevede password perche' di default non ce l'ha. > [...] > > Non e' necessario accedere all'header dal momento che pensa a tutto il > > browser(:>), sia per i cookie sia per le Authentication. > > L'importante e' che l'utente vada su una pagina che contiene il codice > > per effettuare l'attacco. > > Potresti spiegarti meglio? Nella mia mente, dato che i router > richiedono una autenticazione via authorization-basic, occorrerebbe > incapsulare dentro un link anche il passaggio di utente e password, > magari nella forma http://utente:[EMAIL PROTECTED] Solo che IE > (almeno nella versione 6) non lo permette, e Firefox2 avvisa della > cosa. Hai qualche esempio? Cambiando la password si puo' mitigare il problema sul router in questione pero': 1. Se il server (dipende dalla web app dietro) setta un cookie di autenticazione il browser lo tiene per un certo periodo definito dal server. 2. Se c'e' una richiesta di autorizzazione. (http://www.faqs.org/rfcs/rfc2617.html) e ti sei autenticato precedentemente nella sessione del browser l'attacco funziona ancora perche' il browser invia l'Authentication: header anche da altre tab senza richiedere le credenziali. Esempio: apri una tab e autenticati, poi apri un'altra tab e vai su una pagina che contiene uno di questi tag: <iframe src="http:// host/authpage.cgi?par=val"></iframe> <script src="http:// host/authpage.cgi?par=val"></script> <img src="http:// host/authpage.cgi?par=val"> Se fosse un POST : <form id='r' action="http:// host/authpage.cgi" target='iframedi1px' > <input type='hidden' value='val' name='par'> </form> <script>document.getElementById('r').submit();</script> E' il concetto del CSRF, nient'altro. Poi, ci sono modi di bruteforzare le pass, come spiega il paper sul drive by pharming e anche altri studi ma questa e' un altra storia. Stefano -- ...oOOo...oOOo.... Stefano Di Paola Software & Security Engineer Owasp Italy R&D Director Web: www.wisec.it ..................
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
