Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
XSS ejemplar con Gmail y Firefox
En las II Jornadas de Seguridad Informática de la Universidad de A Coruña el nivel de las ponencias ha sido espectacular. Sí, he visto charlas mucho mejor impartidas que la que yo tenía preparada, y es que el amigo Alejandro Ramos “dab” y Ángelo Prado, de Spectra, dieron unas charlas super curradas y super divertidas que dejaron mi charla de Correos spoofeados en Gmail, Hotmail y Yahoo! [slides] en un segundo lugar. ¡Estos jovenzuelos aprenden rápido!
Me encantó sobre todo una demo que preparó Ángel en la que enviaba un correo suplantando la dirección de correo de un dominio de @coruna.es. Este mail llevaba un link con XSS al dominio principal y le permitía suplantar la página web para robar las credenciales del usuario engañado. Vamos, un ataque XSS clásico ejemplarizado en una demo bien currada.
Cuando vi este ejemplo empecé a buscarle tres pies al gato. Lo primero que hice fue buscar la configuración SPF del dominio suplantado y, como era de esperar, el dominio coruna.es tiene configurado correctamente el registro SPF. Así que el ejemplo funcionó perfectamente porque Ángel lo estaba haciendo con Gmail, y ya sabemos lo mal que se comporta Gmail con este tipo de correos.
Figura 1: Configuración SPF de acoruna.es
En segundo lugar, el XSS funcionó porque no se estaba utilizando Internet Explorer 8. Con Internet Explorer 7 o con la última versión de Firefox estos ataques pueden realizarse pero, con la última versión de Internet Explorer, esto no funciona.
Para probarlo se puede utilizar una web preparada para tales pruebas por el equipo de Spectra llamada ie8demos. Sin embargo, yo he preferido usar un XSS clásico de la web del partido político del gobierno.
Como se puede ver, si usamos Internet Explorer 8, el resultado es distinto. Aparece un mensaje que avisa de que la página web ha sido modificada para proteger al usuario de un ataque. Esto es debido a que el filtro Anti XSS de Internet Explorer ha detectado la manipulación de la página mediante la inyección de código en un parámetro.
Figura 2: XSS detectado y bloqueado en IE8
Si se echa un ojo al código de fuente inyectado, se puede ver como el filtro Anti XSS de IE8 ha roto las etiquetas srcipt y el carácter igual de la etiqueta img. El resultado es que cualquier código malicioso ha dejado de tener efecto.
Figura 3: Código modificado
En Firefox se ha anunciado que para la versión 3.7 se incorporará esta característica también, así que decidí bajarme la versión alpha que está disponible en el servidor FTP de Mozilla y probarlo, pero los resultados aun son los de una versión alpha. Es decir, no lo detecta.
Figura 4: XSS funcionando en Firefox 3.7-alpha
En conclusión, esa demo funcionó, y quedó impresionante, porque la hizo con Gmail y Firefox en lugar de usar Hotmail e Internet Explorer 8. ¿Curioso, no?
Saludos Malignos!
Me encantó sobre todo una demo que preparó Ángel en la que enviaba un correo suplantando la dirección de correo de un dominio de @coruna.es. Este mail llevaba un link con XSS al dominio principal y le permitía suplantar la página web para robar las credenciales del usuario engañado. Vamos, un ataque XSS clásico ejemplarizado en una demo bien currada.
Cuando vi este ejemplo empecé a buscarle tres pies al gato. Lo primero que hice fue buscar la configuración SPF del dominio suplantado y, como era de esperar, el dominio coruna.es tiene configurado correctamente el registro SPF. Así que el ejemplo funcionó perfectamente porque Ángel lo estaba haciendo con Gmail, y ya sabemos lo mal que se comporta Gmail con este tipo de correos.
Figura 1: Configuración SPF de acoruna.es
En segundo lugar, el XSS funcionó porque no se estaba utilizando Internet Explorer 8. Con Internet Explorer 7 o con la última versión de Firefox estos ataques pueden realizarse pero, con la última versión de Internet Explorer, esto no funciona.
Para probarlo se puede utilizar una web preparada para tales pruebas por el equipo de Spectra llamada ie8demos. Sin embargo, yo he preferido usar un XSS clásico de la web del partido político del gobierno.
Como se puede ver, si usamos Internet Explorer 8, el resultado es distinto. Aparece un mensaje que avisa de que la página web ha sido modificada para proteger al usuario de un ataque. Esto es debido a que el filtro Anti XSS de Internet Explorer ha detectado la manipulación de la página mediante la inyección de código en un parámetro.
Figura 2: XSS detectado y bloqueado en IE8
Si se echa un ojo al código de fuente inyectado, se puede ver como el filtro Anti XSS de IE8 ha roto las etiquetas srcipt y el carácter igual de la etiqueta img. El resultado es que cualquier código malicioso ha dejado de tener efecto.
Figura 3: Código modificado
En Firefox se ha anunciado que para la versión 3.7 se incorporará esta característica también, así que decidí bajarme la versión alpha que está disponible en el servidor FTP de Mozilla y probarlo, pero los resultados aun son los de una versión alpha. Es decir, no lo detecta.
Figura 4: XSS funcionando en Firefox 3.7-alpha
En conclusión, esa demo funcionó, y quedó impresionante, porque la hizo con Gmail y Firefox en lugar de usar Hotmail e Internet Explorer 8. ¿Curioso, no?
Saludos Malignos!
24 comentarios:
Es decir, funcionó por qué usó algo muy común en lugar de un servicio de correo que está totalmente de capa caida y un navegador que aún no usa ni el tato... :P
¡Vaya, hoy parece un post mio! ¡Firefox y XSS! Solo que yo no me hubiese metido con Firefox :P
Ahora en serio, un detalle que se te ha pasado por alto: La solucion que Firefox va a incorporar no es algo para que funcione "del tiron" en todas las paginas como es la de IE8. En Firefox debemos de especificar una serie de cabeceras que le indicaran al navegador como tiene que comportarse a la hora de tratar, no solo el XSS, si no tambien otra serie de vectores de ataque.
Tienes una demo aqui: http://people.mozilla.org/~bsterne/content-security-policy/demo.cgi con mas informacion. Si miras las peticiones con un sniffer HTTP (no, Odysseus no vale :P) veras como cada uno de los iframes envia una cabecera X-Content-Security-Policy propia. Para que la web del PSOE dejase de ser vulnerable al ataque de XSS reflejado deberian de implementar una de estas cabeceras.
Y ahora que he defendido al Firefox... atacaremos a Internet Explorer 8! Todas las veces que he enseñado en los cursos y las charlas la demo de XSS permanente de robo de sesion con Internet Explorer 8, nunca me lo ha detectado ni me ha saltado el filtro!
Un saludo!
Chemita se te ve demasiado el plumero: por muy guay que lo pintes eso de hotmail + explorer cuéntaselo a otros...
Jajaja. Me parto.
La realidad es que un mensaje spoofeado de un dominio con SPF -all no entra en el inbox de Hotmail ni de coña.
La realidad es que un XSS en un mail con IE8 así, no rula...
Con Gmail y Firefox te lo comes con chips & fish.
Saludos!
Me gustaria a mi ver ese XSS... Seguro que alguna cosa se puede hacer: http://www.abysssec.com/blog/2008/10/internet-explorer-8-xss-filter-bypassing/
@Pedro Laguna, sí, pero ya no sería un "XSS ejemplar" ;)
Saludos!
Hay que tener mala ostia para después de la charla pensar: ahora vamos a dar mala prensa a Firefox y Gmail.
Pero bueno, no tenía idea del filtro de XSS. Me da un poco de miedo, me pregunto si tendrá falsos positivos. Porque juguetear con eso, si cometes un fallo es una puta mierda que te jode la vida y manda a tomar por saco la aplicación.
Personalmente no soy nada partidario de este tipo de iniciativas. Si el desarrollador la caga, problema del que la caga. La solución es arreglar la cagada, no meter un filtro que seguro me va a joder la vida.
Nada, seguiremos diciendo eso de:"puto iexplorer de mierda".
mmm... viendo el contenido de mañana del Innovation Tour en Sevilla, la última charla tendra algo que ver con esto? :P
Anda Chemita... Voy a discutirlo con mi taza de te a ver si encuentro algo "ejemplar" para ti :P
Que poco te gusta dar tu brazo a torcer!!
Por cierto, como la ha cagado Mozilla con lo del componente .Net de Firefox (a mi parecer): https://bugzilla.mozilla.org/show_bug.cgi?id=522777
La ventaja de firefox, es que le pones un plugin como el no-script, y te bloquea "todo" ... jaja
un saludo
Gran Maligno!!! La realidad es que Gmail + Firefox es una combinación más insegura que Hotmail + IE8 con filtro antiXSS en muchas ocasiones, como muy bien has descrito.
Yo conocía esto perfectamente, y por tanto no fue casual que la demo fuera con Google+Mozilla
De vez en cuando hay que darle caña a los del logo multicolor ;-)
@Ángel, eres un crá!, tienes mis respetos.
@Hu64, desactivar JavaScript para no caer en un ataque XSS es como no acostarse con mujeres porque alguna una entre un millón es peligrosa. Además... NO Script tb rula en IE, hombre... ;)
Cortar todos los XSS sin romper funcionalidad: JA!
Que no se trague XSS de libro no significa nada. Si se le puede colar se puede hacer y punto no hay ninguna diferencia.
@dreyercito... no me seas hacker malo, malo. Of course que los firewalls no quitan el 100 % de los ataques, pero es de gilipollas vivir sin ellos. Of course que el Anti XSS no quita todo, pero tal vez sea una gilipollez en el futuro vivir sin uno de ellos ¿no?. Conozco a muchos hackers malos malosos que viven pegados a la configuración de NOScript. Cualquier ayuda es buena. Además, si te da problemas con esa página que tanto te gusta... siempre puedes desactivarlo pero... mejor tenerlo que no tenerlo, ¿no?
Saludos!
Como me gusta decir, parafraseando un chiste de Eugenio: "Cosa curiosa Rusia"
Bueno. Veo un poco de todo:
- Anónimo #nosecuantos: vale que la cagada es del programador, pero el filtro ayuda a que esa cagada no se convierta en un desastre.
- Chema: días después de que escribieras el post sobre el SPF y el DKIM, los de Gmail tuvieron la magnifica idea de mostrar al usuario si ese correo era bueno o no... pero sólo de eBay y PayPal. Si es que...
- Pedro Laguna: Has dicho "discutirlo con la taza de te" y me he imaginado a Fred de Sinergia sin control.
Y no se qué mas contar!!!
Sólo decir que estuve allí y es cierto, el nivel de las charlas de este año ha sido increíble. Desde Coruña, esperamos con ganas las III Jornadas de Seguridad para 2010 :)
Un saludo.
El curso de los viernes está bastante bien. Yo lo recomiendo!!!!
Gratamente sorprendido de encontrarme un blog de este nivel en castellano.
A ver si puedo ponerme al dia con estos temas y pasarme al lado oscuro aunque sea para que me de sombra.
Lo que me pude reír con este comentario sobre Google + Firefox en su momento fue poco. No podía comentar cierta información, por supuesto, pero ahora que ya es público...
Ah, Chema, en todos lados cuecen habas, y en Spectra/IE a calderadas ;)
@Manuel, Manuel, veo que disfrutas con un bug de un sistema de protección que otros no tienen...
Se corrige, y a otra cosa, mariposa... A ver como lo hacen los demás para introducirlo, para reducir la cantidad ingente de bugs por año que tiene Firefox, o para cambiar su arquitectura monólitica de acuerdo a los niveles de integridad....
Saludos para las habas!
No te equivoques Chema, yo no me alegro de que haya un bug en IE. Simplemente me hace gracia que en este post intentaras vender lo inseguro que es Firefox y Gmail porque en ellos se puede explotar un XSS de otra página, en comparación con IE, que tiene su (vulnerable, aunque nadie parecía saberlo) filtro anti-XSS. No hay que escupir al cielo, porque te puede caer encima ;)
Tampoco he dicho que Firefox (o Gmail) sean más o menos seguros que IE (o un servidor Exchange propio), porque en mi opinión no hay forma de demostrar que una u otra combinación sea mejor. Por eso soy escéptico cuando tú comparas a la ligera, o lo insinúas. Ya te discutí una opinión similar hace bastante tiempo, no hay forma de decir si Win/IE es más seguro que Lin/FF, y me da pena que a veces pierdas el tiempo (en tu blog y en tus presentaciones, que tuve la suerte de verte un rato en un evento que tú y el Chico Maravillas hicistéis en Sevilla hace años) en vendernos la moto en vez de hablar de cosas más interesantes sobre seguridad (que además, como ya he escrito en otros comentarios, creo que se te da bastante mejor :). Pero oye, es tu bitácora y te la f... como quieras :)
Lo del filtro anti XSS: por supuesto, es un fallo que se arregla (tardando más o menos, que ya llevan unos meses en Spectra con el tema pendiente) y ya está. Todo el mundo comete fallos, ¿verdad? :) Es anecdótico que en este caso hubo gente que advirtió a Spectra de que esto les iba a pasar y, claro, les pasó.
Sobre la ausencia de similar funcionalidad en FF, como ya alguien ha comentado antes NoScript funciona bastante bien para evitar XSS, desde antes que IE 8 existiese siquiera.
Y no me malinterpretes, yo no vengo a hacer crítica destructiva, sólo intento aportar una visión diferente de los hechos.
Un saludo.
@Manuel, NoScript quita Javascript, los filtros AntiXSS quitan el Javascript introducido como ataque. Hay NoScript apara IE.
Este artículo deja claro que ese tipo de ataques, el diseñado, no se podía hacer con IE8. De nuevo un hacker ha encontrado una vulnerabilidad. Mola, porque a mi me gustaría haberla encontrado, pero eso no desmonta la tecnología.
FF tiene muchos problemas hoy como la arquitectura, el alto volumen de vulnerabilidades y, a día de hoy, no tiene Anti XSS.
Saludos!
Chema,
En cuanto a NoScript:
1. NoScript tiene protección anti XSS para reflected XSS que, según entiendo de tu entrada en el blog, es el ejemplo que estábais utilizando para hackear Firefox en vuestra presentación.
2. La opción por omisión de NoScript es eliminar todo el Javascript de las páginas que no estén en una lista blanca (configurable). Esa opción por omisión puede cambiarse, por supuesto (por ejemplo, a un sistema de lista negra). Así que NoScript no simplemente "elimina el javascript". No todo, si tú no quieres y, por omisión, no de los sitios "confiables".
3. NoScript sólo está disponible para navegadores basados en Mozilla. Directamente de la página de NoScript: The NoScript Firefox extension provides extra protection for Firefox, Flock, Seamonkey and other mozilla-based browsers (el resaltado es mío). Salvo que IE 8 de repente haya sido basado en Mozilla, no veo cómo vas a usar NoScript con IE.
En cuanto al artículo:
Demostraba que Firefox sin NoScript es vulnerable cuando visitas enlaces maliciosos a páginas vulnerables a (reflected) XSS. De acuerdo, eso lo sabemos todos. Lo que nadie sabía (y mucha gente aún no sabe) es que IE 8 es vulnerable a reflected XSS cuando visitas enlaces maliciosos a páginas no vulnerables a reflected XSS.
Es decir, Firefox sin NoScript hace que páginas vulnerables a reflected XSS puedan ser explotadas. En cambio, el filtro anti XSS de IE 8 hace que páginas seguras frente a reflected XSS puedan ser explotadas. Yo no sé con qué prefieres quedarte tú. Yo creo que con lo primero.
Respecto a Firefox.
En efecto, tiene muchos problemas con su arquitectura. Pero IE, a lo largo de su historia, no ha tenido un número de vulnerabilidades significativamente inferior al de Firefox. IE 8 parece un buen navegador, pero de momento no sigo viendo una diferencia importante. Cualquier comparativa es discutible, pero te dejo un enlace al TippingPoint Pwn2Own 2009 por si te interesa. Según esa competición, Chrome es el más seguro del grupo IE 8, Firefox, Safari, Chrome.
Un saludo.
Hola Manuel,
me hubiera gustado a mí hacer esa demo, pero no era mía. Era de Angelo, yo sólo la ví. Con respecto a NoScript, es un plugin (el cual pensé que tenía una versión para IE, pero ya veo que no) externo y, curiosamente, Firefox ha anunciado que iba a meter un filtro AntiXSS en la versión 3.7 [http://blog.server-monitor.info/2009/10/firefox-37-will-have-anti-xss-policy/]. Y, por supuesto, NoScript no viene de serie con Firefox ni con Chrome.
Respecto a las listas blancas y negras, esas viene en IE desde que existen las zonas de Internet.
Respecto al trick, es fantástico, pq un hacker ha encontrado como metersela a un sw. Es igual que cuando salió el XSS en los códigos de error de Apache o cuando aparece un BO en un firewall. Perfecto, pero no desestima para nada la tecnología.
Este artículo no trataba de ser una comparación de seguridad, sino el caso de una demo concreta con un componente que viene por defecto en IE8 y que, para el ejemplo puesto, no funcionaba con IE8. Y Chrome, creo que tampoco lo tiene.
Saludos Manuesl!
Publicar un comentario