lunes, 1 de febrero de 2010

Ocultación XSS/CSRF en Short URL

En los últimos tiempos se ha puesto muy de moda Twitter (ando probandolo recientemente), que como todos sabreis es una manera cómoda de compartir mensajes cortos, reenviar los mensajes de otros a nuestros otros contactos, etc. Con la aparición de Twitter y la limitación de 140 caracteres por mensaje surgieron los primeros problemas: ¿cómo pongo una URL? Si es del tipo http://www.pentester.es no hay ningún problema, es corta y podemos incluirlo en nuestro mensaje. Sin embargo las limitaciones del Twitter se pegan de morros con la longitud actual de las URL, sobretodo cuando referenciamos a posts o artículos concretos de un periódico: http://www.pentester.es/2009/09/conferencias-source-barcelona-21-y-22.html .Esta última son, por si sola, 77 caracteres.

Como respuesta, han aparecido muchísimos servicios para hacer "Short URL Redirection", es decir, tú le das a la web la URL más larga que un día sin pan y él te lo convierte a algo del tipo http://bit.ly/9qAPvE, que aunque mucho menos legible, es mucho más corta y no nos va a dar ningún problema. Cuando el usuario pinche sobre esa URL será redireccionado inmediatamente a la URL larga, y todo funcionará sin mayor problema.

¿Sin mayor problema? Va a ser que no...

Cada vez está todo el mundo más acostumbrado a pinchar en este tipo de enlaces sin pensar que no tenemos ni idea de sobre que estamos pinchando.

Así que... vamos al grano, vamos a suponer que tenemos una web vulnerable a XSS o CSRF y que la URL con la que conseguimos explotarla es la siguiente:



Vale, ya tenemos una URL para que si alguien la pincha ejecute las acciones que queremos. En este caso algo tan tonto como sacar un mensaje con la versión del navegador, pero podriamos haber estado robando cookies o cualquier otra maldad.

Para disfrazar nuestro ataque un poco más, vamos a modificar un poco la URL que tenemos para que tras ejecutar nuestro script sea redirigida a otra página, así la aparición de la URL con el código del script será solo instantanea, y es probable que el usuario no se de cuenta ni de que está pasando (eso si estuvieramos usando algo que no fuera un "alert", claro).



Esto nos va a hacer ejecutar primero nuestro script y posteriormente ir a la raiz de esa misma web, aunque podriamos haber elegido cualquier otro path o incluso otra web, por ejemplo hacer pensar que queremos ir a una web X y que el enlace vaya a una web Y, robe cookies y posteriormente redirija a la web X, con lo cual se completa el engaño.

Bien, ahora que ya tenemos nuestra URL maliciosa, ya solo tenemos que ponerle un poco de chapa y pintura para que parezca otra cosa, y aquí es donde entran los servicios de Short URL. De entre estos servicios, hay algunos que tienen la precaución de filtrar los caracteres peligroso, pero es posible encontrar en Internet algunos que no lo hacen. Sin embargo, nos vamos a poner en el caso en que lo hagan, como hace por ejemplo bit.ly, que sería el caso más complicado.

Y si nos van a filtrar mayores, menores, comillas, etc... ¿cómo lo hacemos?
La respuesta es... pues vamos a hacer un salto intermedio, en lugar de con una con dos redirecciones.

Así pues, voy a la web de bit.ly y le pongo el enlace al servidor web público bajo mi control, devolviendome esta URL corta: http://bit.ly/9fwBrb



Una vez hecho esto, solo tengo que ir a esta página y crear un pequeño index.html que redirija de nuevo a la web vulnerable, lanzando el exploit:



Como podeis ver, he tenido que cambiar el "/" por un String.fromCharCode(47), que es exactamente lo mismo, pero que haciendolo así me evito usar las comillas, que como ya las estoy usando en el "onload" me puede dar problemas.

Pues bien, ya tenemos la URL con la que atacar, nuestra web preparada para que cualquiera que la visite sea redirigido a la URL con el ataque, y una URL Corta que apunta a la web bajo nuestro control, así que solo tenemos que dejar esta URL Corta en algún sitio anunciando algo interesante y...



Inmediatamente tras aceptar el mensaje que nos aparece (si hubieramos puesto un robo de cookies se hubiera realizado sin necesidad de intervención del usuario), el navegador redirecciona la web a la que queremos, la página principal:



Así que ya sabeis, mucho ojito con las URLs Cortas y con las Rusas en ropa interior, tienen mucho peligro y no sabemos lo que pueden esconder...

9 comentarios :

Julian J. Gonzalez dijo...

Imagina si utilizamos el recientemente publicado exploit para Metasploit con la generación de firmas para código applet de Java...

Tendríamos una shell meterpreter si el usuario pica y pincha en una dirección URL corta...

Jose Selvi dijo...

Gracias por tu comentario @Juliá.

Todavía no he jugueteado con ese exploit, sigo encabotado con otro al que le quiero sacar un poco de "jugo" ;)

Pero sí, echale imaginación: BeEF, Exploits de Metasploits para navegadores, XSS, CSRF, ... lo que quieras que necesites que el usuario pinche sobre un enlace que, tal cual, puede resultar un poco sospechoso.

Adrian dijo...

¿Una alternativa a utilizar tu propio servidor para alojar el script podría ser utilizar un segundo portal de short-url que no filtre?
Acortas la url que lanza el script con un portal de los que no filtran, llamese X, y esta url corta la vuelves a acortar con bit.ly.
De esta forma obtendriamos un enlace de bit.ly que apunta a X, que contiene el enlace con script. No sé si queda claro...

Un saludo!

Jose Selvi dijo...

@adrian, si utilizamos un Short URL que permita estos caracteres no nos hace falta hacer un segundo salto, podríamos lanzar el ataque directamente.

Como mucho te puede servir para "ocultar" el Short URL raro y utilizar uno de más confianza, pero yo creo que la gente pincha sobre ellos sin mirar demasiado, así que no sé si aportaría mucho.

Gracias por el comentario! Saludos!

Anónimo dijo...

Buena entrada!

Newlog

Jose Selvi dijo...

@Anónimo: Gracias! ;)

David dijo...

Muy interesante el post :)

Sólo añadiría que para conocer la URL real que se esconde tras el acortador, se puede usar esta extensión de Firefox: http://www.longurlplease.com/

He probado tanto la extensión como el API mediante Curl y vale la pena.

Jose Selvi dijo...

Gracias por el aporte @David, usar una extensión como la que comentas puede ayudar a mitigar los riesgos de este tipo de ataques :)

manuonda dijo...

Muy bueno el post .
Saludos