martes, septiembre 02, 2014

Google Chrome: Bug para esconder el Path en una URL

Supongamos que en una página web existe una vulnerabilidad de HTML Injection o de XSS que permite a un atacante manipular el contenido que ve un usuario a la hora de pulsar un enlace malicioso. Supongamos que el atacante, con ese HTML Injection, o ese bug de XSS quiere hacer un ataque de Phishing para robar las credenciasles, de ClickJacking para robar acciones, o conseguir ejecutar un ataque que lance un SQL Injection a un servidor de la Intranet desde un enlace malicioso en una web.  En esos entornos, ver toda la URL a la que nos estamos conectando puede ayudar a tener la máxima información posible para saber si algo ha pasado.

Bugs de Address Bar Spoofing

Así, los investigadores de seguridad catalogan como bugs todos los ataques que permiten ocultar, cambiar o engañar al usuario jugando con la barra de direcciones. En el caso de los dispositivos móviles, se han visto muchos bugs de Address Bar Spoofing que han sido corregidos en el pasado, pero a día de hoy ya no parece tan importante.

De hecho, en los navegadores se empieza a eliminar incluso el Path de la URL, dejando sólo como información útil el nombre de dominio. Se supone que si alguien es capaz de inyectar código HTML o un XSS en la URL, el problema no es que se juegue con el Path, sino que existe un bug de HTML Injection o XSS en la web. En el caso de Google Chrome es posible manipular desde un enlace el Path que se muestra en la barra de direcciones. Para tratar de comprender esta característica, debemos tener claro las partes que componen una URL:

Figura 1: Estructura de una URL 

Normalmente cuando los que estamos en el campo de la seguridad informatica nos encontramos con un enlace que explota una vulnerabilidad de XSS reflejada que está siendo explotada, podemos reconocerla fácilmente mirando el Pathname de la URL o viendo que en la URL hay código HTML/Javascript/CSS/* inyectado. La mayoría de las personas, por el contrario, ignoran lo que hay en el Path de la URL y simplemente les basta con saber que el sitio en el que están navegando es legitimo, fijándose en el dominio del sitio web pudiendo ser engañadas más fácilmente.

Figura 2: Código inyectado en una URL

Si un sitio tiene una vulnerabilidad de HTML Injection o XSS y si se puede de alguna manera ocultar el Path de la URL a todos, - con o sin conocimientos en seguridad - tal vez nos pase desapercibido que el sitio en el que estamos conectados tiene código inyectado por un tercero. Si así fuere, en la barra de navegación del navegador solo veríamos el dominio del sitio sin más, o bien el dominio del sitio con un Path cambiado por el atacante.

Ocultar el Path de una URL en Google Chrome con XSS [Conocido]

Ocultar el Path de una URL es posible en Google Chrome si somos capaces de inyectar un código script en la página vulnerable. Así, inicialmente se vería la URL con todo el Path, pero luego, tras la ejecución del código script inyectado se podría cambiar. Para ello es necesario inyectar un código script como el siguiente que "abuse" de las funciones de HTML5.
<script>window.history.pushState("change", "title", "/nuevo-path");</script>
Figura 3: Ejemplo de cambio de Path por medio de inyección XSS

Ahora bien, esto no es nada nuevo y está contemplado ya que al instalar el navegador,viene por defecto activado el Google Chrome XSS Auditor, por lo que para poder inyectar un script en la URL hay que tenerlo desactivado, o bien lograr saltarse el filtro de seguridad con algunos de los casos que van saliendo y que el equipo de seguridad corrige, como hemos visto en el pasado. Aquí hay algunos ejemplos:
- El 0day del Anti XSS de Google Chrome que duró 24 horas
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11
Hacer un bypass y conseguir ejecutar un XSS, por consiguiente, implicaría tener un bug XSS en la web objetivo y un bug en Google Chrome XSS Auditor.

Figura 4: Ocultando la URL en la barra de estado

Junto a este efecto, un atacante podría valerse del viejo truco de cambiar el href de un hipervínculo cuando pasa el ratón por encima para engañar a la barra de estado cuando alguien lo quiere comprobar.
<a target="_blank" onmouseup="this.href='http://www.sitioalqueseredireccionara.com' "href="http://www.facebook.com">http://www.facebook.com</a>
Un ejemplo el truco del hipervínculo que cierra todas las sesiones en Facebook, podemos hacer que cualquiera que ingrese a un cierto enlace http://www.facebook.com/ se le cierre la sesión en Facebook, y ¿quién podría sospechar?.

Ocultar el Path de una URL en Google Chrome un URL overflow [new]

Pero, ¿y si de alguna manera pudieramos ocultar el Path teniendo activado Google Chrome XSS Auditor sin saltarnos ningún filtro? Resulta ser que - teniendo activado el Auditor XSS de Google Chrome - he encontrado la manera en la cual puedo ocultar el Path de cualquier URL, con o sin vector XSS, con o sin parámetros en la URL. Esto es aplicable a cualquier URL. Aquí tendríamos un hipervínculo que ocultaría el Path al explotar el enlace

Figura 5: Explotación del "bug" con un enlace con XSS en la web de autodesk. Código en Pastebin.

El bug - o "feature" según el equipo de seguridad de Google ya que no lo consideran un bug - es que si hacemos que la cantidad de caracteres de la URL sea mayor a 32.760 caracteres, por alguna razón, el navegador limpia de la barra de direcciones todo el Pathname de la URL, y deja únicamente el dominio del sitio, algo bastante curioso. En este ejemplo, con el truco de cerrar las sesiones de Facebook.

Figura 6: El ejemplo del truco de Facebook sería así. Código en Pastebin.

Por lo que si alguien se estuviese aprovechando de un XSS, HTML Injection o hiciese un ataque CSRF con un SQL Injection, o similar, bastaría con agregarle ese trozo de código para ocultar el vector. Como se puede ver, usando comentarios o el carácter sharp es posible añadir tantos caracteres como sea necesario sin que deje de funcionar el hipervínculo.

Ideas finales

Básicamente este fallo abre una gran puerta a los ciberdelincuentes para hacer más efectivos sus ataques y así engañar mucho más fácilmente a los usuarios. A continuación les muestro en un vídeo este “bug” o al menos a mi me parece así, ya que los de Google no piensan de la misma manera, tal vez sea un nuevo “feature” para ellos.


Figura 7: Vídeo con la PoC de este ataque

Realmente es peligroso para cualquier tipo de usuario porque en general, la mayoria de las personas confían en la barra del navegador y la barra de estado para comprobar la veracidad de un sitio, y si el sitio es un sitio confiable, ¿Qué podemos sospechar? En Chrome Canary este bug se vuelve tal vez más peligroso, si el usuario tiene activada la bandera: chrome://flags/#origin-chip-in-omnibox

Este bug fue reportado a Google, pero sin embargo no lo consideran como un fallo de seguridad, y sí una feature, como en el caso de saltarse el filtro de contenido JavaScript con un iframe. ¿Tú qué piensas?


Autor: Ariel Ignacio La Cono
e-mail: msignataur@hotmail.com
Twitter: @IgnacioLaCono

2 comentarios:

Anónimo dijo...

Estos de google...
Con tanto colorines y tantas lampara de lava están flipadisimos vamos, si eso no eso es una falla que baje Dios y lo vea.
Creo que no consideran fallo de seguridad todo lo que dependa del usuario, hay se lavan las manos y no mueven un dedo, o mas tarde o temprano quizás si como en otros casos.

Tengo visto y comprobado que los usuarios que no están relacionados con el mundo de la seguridad no miran nada, ni URL ni nada de nada he aquí una demo de lo que digo, con un Fake Facebook o Phishing en un Localhost, aun poniéndolo a lo descarado y es mas, a conciencia http://localhost como URL, pues ya van dos, yo lo hago para concienciarlos y pasar un buen rato a la hora de enseñárselo XD, y no les queda otra que reconocerlo, y todos dicen lo mismo, no miran nada de nada y con el tiempo y una caña hasta las verdes caen.

Fake Facebook Localhost for Friends XD (DEMO)
https://www.youtube.com/watch?v=WSfKOHZALUU

Esto da mucho juego, hay un abanico muy amplio de cosas que se podrían hacer y por parte de Google, vamos que no hay ciego mas ciego que el que no quiere ver, pero vaya... una vez mas, ni pagao ni agradecio :-)

Salu2!

Anónimo dijo...

Google, cada vez con más prepotencia...

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares