[Artículo cedido como contribución a Flu-Project]
El mundo de la seguridad también tiene sus curiosas ironías. En este post veremos cómo te la pueden meter doblada, precisamente, por intentar ser precavido.
El mundo de la seguridad también tiene sus curiosas ironías. En este post veremos cómo te la pueden meter doblada, precisamente, por intentar ser precavido.
A estas alturas ya todos conocemos y usamos de manera activa o pasiva los acortadores de URLs. Ahorramos espacio, nos sacan de apuros en Twitter, conseguimos un efecto sorpresa al ocultar la URL original...
Supongo que te hubieras pensado dos veces pulsar en el enlace anterior si hubieras leído el nombre del archivo en la URL final. O quizá no, el morbo no tiene límites :P. Aunque cueste creerlo, en esta jungla virtual hay peligros mucho mayores que nuestro amigo David desnudo, con millones de webs infectadas de todo tipo de malware y perrerías. Precisamente para intentar evitar sorpresas desagradables, nacieron las webs que nos proporcionan el servicio contrario de "unshortening", es decir, nos desvelan la URL original a partir de una URL acortada.
¿Qué pasaría si las webs que ofrecen estos servicios fueran vulnerables a ataques inyectados en la propia URL original? Por el simple hecho de ser precavidos y consultar una URL, seríamos directamente víctimas de los tipos de ataques que, irónicamente, queremos evitar. Algo así como ir a ver si la pistola está cargada y que se te dispare en la cara.
Con esta idea, se me ocurrió testear la seguridad de algunas de las webs que ofrecen servicios de "unshortening". El resultado fue terrorífico, ya que prácticamente todas las testeadas que ofrecen esta funcionalidad eran vulnerables a ataques XSS.
Este nombre de archivo es totalmente válido en sistemas Unix y puede existir perfectamente en un servidor web. No es necesario que la URL sea real para hacer la prueba, ya que de momento lo único que nos interesa es crear una URL corta que la resuelva. El siguiente paso, por tanto, es generar su hermana pequeña en cualquier servicio acortador de URLs como https://bitly.com/, y a jugar...
Al introducir la URL acortada en la gran mayoría de los servicios de URL unshortener el ataque se ejecuta con éxito:
Pero, ya que tenemos control total sobre la página, ¿por qué no hacer la gracia completa y en vez de sacar un inocente alert hacemos que el ataque fuerce al usuario directamente a visitar la web que queramos? Es decir, ¿por qué no hacer que directamente visite la web de nuestro amigo David Hasselhoff nada más consultar la URL acortada en el servicio de unshortening? Modificamos el vector de ataque...
http://www.evilchistera.com/"><script>location.href='http://bit.ly/15q0CUY'</script>
Obtenemos la correspondiente URL acortada de https://bitly.com/:
Después de esto, ¿qué podemos hacer si una URL acortada nos da mala espina y queremos saber su URL final sin preocuparnos de ser cazados? Una opción, lógicamente, es usar un servicio de unshortening que no sea vulnerable. Como no podemos asegurar nunca esto al 100%, esta opción no me gusta. Otra opción es instalar en el navegador alguno de los plugins que existen para estas tareas. NoRedirect, por ejemplo, ofrece un diálogo de confirmación antes de ser redirigido a la página final. Por último, también puedes usar cualquier método que te permita consultar el código fuente de la URL corta. Por ejemplo, puedes usar curl...
Lo primero, fue fijar una URL que referenciara a un supuesto archivo llamado "><img src="1" onerror="alert('OWNED!!')">.html. Algo como...
http://www.evilchistera.com/"><img src="1" onerror="alert('OWNED!!')">.html
Este nombre de archivo es totalmente válido en sistemas Unix y puede existir perfectamente en un servidor web. No es necesario que la URL sea real para hacer la prueba, ya que de momento lo único que nos interesa es crear una URL corta que la resuelva. El siguiente paso, por tanto, es generar su hermana pequeña en cualquier servicio acortador de URLs como https://bitly.com/, y a jugar...
Al introducir la URL acortada en la gran mayoría de los servicios de URL unshortener el ataque se ejecuta con éxito:
Pero, ya que tenemos control total sobre la página, ¿por qué no hacer la gracia completa y en vez de sacar un inocente alert hacemos que el ataque fuerce al usuario directamente a visitar la web que queramos? Es decir, ¿por qué no hacer que directamente visite la web de nuestro amigo David Hasselhoff nada más consultar la URL acortada en el servicio de unshortening? Modificamos el vector de ataque...
http://www.evilchistera.com/"><script>location.href='http://bit.ly/15q0CUY'</script>
Para que se produzca correctamente la redirección, antes de usar la URL anterior debemos encodearla:
http://www.evilchistera.com/"><script>location.href=String.fromCharCode(104,116,116,112,58,47,47,98,105,116,46,108,121,47,49,53,113,48,67,85,89)</script>
Obtenemos la correspondiente URL acortada de https://bitly.com/:
http://bit.ly/11TuJh9
Y supongo que ya adivináis lo que ocurre cuando la introducimos en un servicio de unshortening vulnerable :D.
Si visitamos esta URL corta tal cual, fallará debido a que el archivo destino no existe realmente y, simplemente, hemos hecho una prueba de concepto basándonos en una URL ficticia. Si te apetece afinarlo más (tal y como se haría en un ataque real), puedes crear en un servidor el fichero con el XSS incluido en su nombre e incrustarle en el código html una redirección a la misma página destino del ataque. De esta manera, tanto si se visita el enlace corto como si se consulta en un servicio de unshortening, la víctima será redirigida a la página que queramos.
Si visitamos esta URL corta tal cual, fallará debido a que el archivo destino no existe realmente y, simplemente, hemos hecho una prueba de concepto basándonos en una URL ficticia. Si te apetece afinarlo más (tal y como se haría en un ataque real), puedes crear en un servidor el fichero con el XSS incluido en su nombre e incrustarle en el código html una redirección a la misma página destino del ataque. De esta manera, tanto si se visita el enlace corto como si se consulta en un servicio de unshortening, la víctima será redirigida a la página que queramos.
Después de esto, ¿qué podemos hacer si una URL acortada nos da mala espina y queremos saber su URL final sin preocuparnos de ser cazados? Una opción, lógicamente, es usar un servicio de unshortening que no sea vulnerable. Como no podemos asegurar nunca esto al 100%, esta opción no me gusta. Otra opción es instalar en el navegador alguno de los plugins que existen para estas tareas. NoRedirect, por ejemplo, ofrece un diálogo de confirmación antes de ser redirigido a la página final. Por último, también puedes usar cualquier método que te permita consultar el código fuente de la URL corta. Por ejemplo, puedes usar curl...
Saludos!