Desde hace años he querido trabajar en el mundo de la seguridad informática como pentester profesional. Tras muchas dudas, decidí coger el toro por los cuernos, apuntarme a un Máster de Seguridad Informática, y centrarme todo lo que pueda en este ámbito que las cosas hay que hacerlas de forma decidida. Dedico todo el tiempo que puedo a leer sobre el tema y ampliar mis conocimientos y, cuando puedo, navego por la red buscando cosas interesantes que probar o que me estimulen a pensar de forma diferente. Eso sí, siempre bajo las premisas de no romper nada, hacerlo a mano, que me ayuda a aprender más y de informar cuando la cosa es muy grave.
En este caso os voy a contar una historia de cómo el hurgar y probar ideas en muchas ocasiones te lleva a descubrir cosas cuanto menos curiosas. En este caso, los acontecimientos que os paso a narrar me sucedieron visitando la página de venta de artículos de un conocido mío.
El descubrimiento inicial del XSS Reflejado
La web en concreto no era un CMS de esos que se conocen bien los exploiters web y estaba muy bien estructurada. Tiene su parte de login, su pasarela de pagos y su catálogo de productos correctamente montado. Parecía en definitiva un sitio interesante para invertir algunos minutos comprobando que no había detalles malos. Abrí Mozilla Firefox y tras un par de comprobaciones muy ligeras, apareció un XSS reflejado en un campo “buscar”:
Bueno, no es que sea nada excepcionalmente grave, pero como es algo muy común y como tenía algo de confianza con el dueño le aviso. Luego almaceno la página para futuros cacharreos - ¡Otra más para el montón! - y a dormir, que son las 2.00 A.M.
Días después en el trabajo me llega un e-mail del conocido en el que me solicita información algo más detallada para reportarle todo al webmaster. En ese momento me pilla con algo de jaleo, pero saco un minuto rápidamente para hacerlo. Preparo en un momento una pequeña prueba con un alert y otra en la que re-dirija la navegación de la víctima a otro lugar - por si hay que explicar cómo funciona eso de que un XSS puede ser utilizado para lanzar un exploit desde otra web y caer en manos de un Kit de Exploits-. Dos pruebas mejor que una, y completo el correo ofreciéndole ayuda en lo que necesiten. Pienso en ponerle además un enlace a OWASP, pero al final las prisas me pueden. De momento que se apañe con eso. Y a volver al tajo...
Pasaron quince minutos hasta que decidí atender a una neurona que llevaba todo el rato intentando llamarme la atención. Por política de empresa, los navegadores web permitidos son Internet Explorer y Google Chrome. Entonces.... ¿cómo había conseguido hacer las demos que acababa de enviar con un XSS Reflejado? ¿Acaso los filtros Anti-XSS estaban fallando en alguno de los dos navegadores? Excelente, una cosa que en su momento parecía normal y aburrida ahora se acababa de convertir en algo interesante que puse en la cima del montón de la “todo list” para casa.
El filtro Anti-XSS que tuvo el bug
Una vez en casa retomé sobre el tema. Rápidamente hice un par de comprobaciones para ver cuál de los dos navegadores de la empresa fue el que utilicé para hacer las PoCs y descubrir cuál de ellos falló. Las pruebas son sencillas, hice clics en los dos enlaces con las pruebas de XSS Reflejado que creé y resulta que Internet Explorer Sí bloquea las PoCs pero Google Chrome… NO.
Por supuesto, lo primero que me vino a la cabeza fue repasar todos los detalles:
Puesto a repasar los detalles en profundidad, me decido a probar con varios dispositivos y sumo más de una decena de ellos en los que donde funciona la PoC para lanzar el XSS Reflejado con un simple mensaje de alert. Llamadme suspicaz pero esto tiene pinta de vulnerabilidad en el filtro de Anti-XSS de Google Chrome.
Esto no sería raro, ya que hemos podido ver muchas veces cosas similares en el pasado y como muestra podéis ver algunos ejemplos de Saltarse el filtro de bloqueo de JavaScript en Google Chrome 4, Saltarse el filtro AntiXSS en Google Chrome 11 o las últimas PoCs de saltarse el filtro Anti-XSS en Google Chrome y Apple Safari.
Bien. Toca ver en detalle el entorno de explotación, así que nada, a pulsar F12 y a ver qué narices pasa por debajo ¡Vaya! Esto no sé si es normal pero creo que hasta el momento no lo había visto:
Como echo de menos mis punteros… No queda otra que tirar de Internet para suplir mis carencias en programación web. Por lo que aprendo con “tito Google”, este fallo puede ser debido a cómo interpretan los parsers de XML y HTML el código para impedir que HTML interprete la etiqueta CDATA de XML, debido a todos esos símbolos que ambos lenguajes comparten. Igualmente, tiene pinta de que es eso lo que puentea el filtro, porque todo lo demás es "lo de siempre” que suelo encontrarme cuando inspecciono campos parecidos.
El final de la historia con el bug en el AntiXSS
Decido reportar al equipo de seguridad de Google Chrome, puesto que parece que es un caso que su filtro debería de bloquear. Todo apunta a ese campo CDATA, pero no estoy seguro… Mejor no dárselas de listo, así que reporto con una PoC simple y ya veremos si el tiempo nos da la razón. Unas horas después ratifican que no iba muy desencaminado.
Parece ser que los comentarios provocan un fallo en el módulo de XSS Auditor, que se encarga de evitar ataques de XSS Reflejado. En menos de 24 horas el cambio estaba subido y validado.
Intenté reproducir el error en otros lugares, pero únicamente funcionaba si se introducía desde el lado del servidor. Con la última actualización el fallo ya ha sido corregido y el “caso frontera” que permitía hacer “bypass” ya no funciona. Eso sí, siempre nos quedará lanzar Google Chrome con --args --disable-web-security …
La moraleja de la historia
Y aquí termina la feliz historia. La moraleja, si es que se puede llamar así, es que a veces encuentras cosas curiosas de la manera más tonta, e incluso en ocasiones además de ser curioso puede tratarse de algo significativo. Husmear por todas partes tiene su recompensa. Eso sí, sin romper nada, que nos conocemos…
El único punto negativo que he encontrado a todo esto es que la vulnerabilidad no entra dentro del “Vulnerability Rewards Program”. Una pena porque, aunque el dinero no da la felicidad, puestos a llorar, todos preferimos hacerlo dentro de un Ferrari.
Hable con mi profesor Chema Alonso contándole un poco la experiencia y me animó a escribir un artículo para motivar a los que comienzan con esto de la búsqueda de vulnerabilidades, y en ello estoy, retocando los textos… y borrando los metadatos (que nos conocemos y me veo en un artículo en plan “Información sensible que extraigo analizando los metadatos de mis estudiantes del máster” :P)
Autor: Pablo Alobera
Twitter: @illegalpointer
En este caso os voy a contar una historia de cómo el hurgar y probar ideas en muchas ocasiones te lleva a descubrir cosas cuanto menos curiosas. En este caso, los acontecimientos que os paso a narrar me sucedieron visitando la página de venta de artículos de un conocido mío.
El descubrimiento inicial del XSS Reflejado
La web en concreto no era un CMS de esos que se conocen bien los exploiters web y estaba muy bien estructurada. Tiene su parte de login, su pasarela de pagos y su catálogo de productos correctamente montado. Parecía en definitiva un sitio interesante para invertir algunos minutos comprobando que no había detalles malos. Abrí Mozilla Firefox y tras un par de comprobaciones muy ligeras, apareció un XSS reflejado en un campo “buscar”:
 |
| Figura 1: El bug XSS en el formulario de Búsqueda de una web |
Bueno, no es que sea nada excepcionalmente grave, pero como es algo muy común y como tenía algo de confianza con el dueño le aviso. Luego almaceno la página para futuros cacharreos - ¡Otra más para el montón! - y a dormir, que son las 2.00 A.M.
Días después en el trabajo me llega un e-mail del conocido en el que me solicita información algo más detallada para reportarle todo al webmaster. En ese momento me pilla con algo de jaleo, pero saco un minuto rápidamente para hacerlo. Preparo en un momento una pequeña prueba con un alert y otra en la que re-dirija la navegación de la víctima a otro lugar - por si hay que explicar cómo funciona eso de que un XSS puede ser utilizado para lanzar un exploit desde otra web y caer en manos de un Kit de Exploits-. Dos pruebas mejor que una, y completo el correo ofreciéndole ayuda en lo que necesiten. Pienso en ponerle además un enlace a OWASP, pero al final las prisas me pueden. De momento que se apañe con eso. Y a volver al tajo...
Pasaron quince minutos hasta que decidí atender a una neurona que llevaba todo el rato intentando llamarme la atención. Por política de empresa, los navegadores web permitidos son Internet Explorer y Google Chrome. Entonces.... ¿cómo había conseguido hacer las demos que acababa de enviar con un XSS Reflejado? ¿Acaso los filtros Anti-XSS estaban fallando en alguno de los dos navegadores? Excelente, una cosa que en su momento parecía normal y aburrida ahora se acababa de convertir en algo interesante que puse en la cima del montón de la “todo list” para casa.
El filtro Anti-XSS que tuvo el bug
Una vez en casa retomé sobre el tema. Rápidamente hice un par de comprobaciones para ver cuál de los dos navegadores de la empresa fue el que utilicé para hacer las PoCs y descubrir cuál de ellos falló. Las pruebas son sencillas, hice clics en los dos enlaces con las pruebas de XSS Reflejado que creé y resulta que Internet Explorer Sí bloquea las PoCs pero Google Chrome… NO.
Por supuesto, lo primero que me vino a la cabeza fue repasar todos los detalles:
- “¿Versión de Chrome? Actualizado a la última disponible."Había que extender las pruebas, así que envié unos e-mails a compañeros en otros lugares:
- “¿Serán las extensiones? Encendidas, le duele, apagadas, le sigue doliendo."
- “Compi, mírame este enlace con Google Chrome y me cuentas"La respuesta generalizada es: “Bonito alert”
Puesto a repasar los detalles en profundidad, me decido a probar con varios dispositivos y sumo más de una decena de ellos en los que donde funciona la PoC para lanzar el XSS Reflejado con un simple mensaje de alert. Llamadme suspicaz pero esto tiene pinta de vulnerabilidad en el filtro de Anti-XSS de Google Chrome.
Esto no sería raro, ya que hemos podido ver muchas veces cosas similares en el pasado y como muestra podéis ver algunos ejemplos de Saltarse el filtro de bloqueo de JavaScript en Google Chrome 4, Saltarse el filtro AntiXSS en Google Chrome 11 o las últimas PoCs de saltarse el filtro Anti-XSS en Google Chrome y Apple Safari.
Bien. Toca ver en detalle el entorno de explotación, así que nada, a pulsar F12 y a ver qué narices pasa por debajo ¡Vaya! Esto no sé si es normal pero creo que hasta el momento no lo había visto:
 |
| Figura 2: Código con el código del XSS Reflejado insertado |
Como echo de menos mis punteros… No queda otra que tirar de Internet para suplir mis carencias en programación web. Por lo que aprendo con “tito Google”, este fallo puede ser debido a cómo interpretan los parsers de XML y HTML el código para impedir que HTML interprete la etiqueta CDATA de XML, debido a todos esos símbolos que ambos lenguajes comparten. Igualmente, tiene pinta de que es eso lo que puentea el filtro, porque todo lo demás es "lo de siempre” que suelo encontrarme cuando inspecciono campos parecidos.
El final de la historia con el bug en el AntiXSS
Decido reportar al equipo de seguridad de Google Chrome, puesto que parece que es un caso que su filtro debería de bloquear. Todo apunta a ese campo CDATA, pero no estoy seguro… Mejor no dárselas de listo, así que reporto con una PoC simple y ya veremos si el tiempo nos da la razón. Unas horas después ratifican que no iba muy desencaminado.
 |
| Figura 3: La contestación del equipo de Chromium. Clic para leer en grande |
Parece ser que los comentarios provocan un fallo en el módulo de XSS Auditor, que se encarga de evitar ataques de XSS Reflejado. En menos de 24 horas el cambio estaba subido y validado.
 |
| Figura 4: El bug resuelto en 24 horas |
Intenté reproducir el error en otros lugares, pero únicamente funcionaba si se introducía desde el lado del servidor. Con la última actualización el fallo ya ha sido corregido y el “caso frontera” que permitía hacer “bypass” ya no funciona. Eso sí, siempre nos quedará lanzar Google Chrome con --args --disable-web-security …
La moraleja de la historia
Y aquí termina la feliz historia. La moraleja, si es que se puede llamar así, es que a veces encuentras cosas curiosas de la manera más tonta, e incluso en ocasiones además de ser curioso puede tratarse de algo significativo. Husmear por todas partes tiene su recompensa. Eso sí, sin romper nada, que nos conocemos…
El único punto negativo que he encontrado a todo esto es que la vulnerabilidad no entra dentro del “Vulnerability Rewards Program”. Una pena porque, aunque el dinero no da la felicidad, puestos a llorar, todos preferimos hacerlo dentro de un Ferrari.
Hable con mi profesor Chema Alonso contándole un poco la experiencia y me animó a escribir un artículo para motivar a los que comienzan con esto de la búsqueda de vulnerabilidades, y en ello estoy, retocando los textos… y borrando los metadatos (que nos conocemos y me veo en un artículo en plan “Información sensible que extraigo analizando los metadatos de mis estudiantes del máster” :P)
Autor: Pablo Alobera
Twitter: @illegalpointer
Felicidades Pablo!!! Me encanto lo del Ferrari hahaha , solo te puedo decir que uno nunca sabe .. esto ya te sirve como experiencia para demostrar lo original que puedes ser y tal vez en vez de 500 dólares te ofrecen una plaza en una buena empresa ;-)
ResponderEliminarBueno, eso no estaría nada mal la verdad :P.
ResponderEliminar