Cross Site Request Forgery - Una explicación práctica


Muy buenos días! Hoy nos vamos a divertir con pccomponentes.


Diversion 11

Hoy he decidido, ya que me puse el mono de seguridad ayer, al hablar de las vulnerabilidades en los cms con la de alguna versión de plugins de wordpress y la subida arbitraria de archivos, que es un buen día para hablar de csrf.

CSRF son las siglas de Cross Site Request Forgery. Este es una de las técnicas más básicas de hacking que hay y que por desgracia resultan ser más efectivas.

Consiste en lo siguiente:

Una aplicación web está preparada para realizar determinadas acciones en función de el usuario que está accediendo a ella, el contenido, etc.

Pongamos este blog, donde el administrador del mismo tiene el poder de eliminar artículos mediante un link. Cuando clica en el link se envía una petición al servidor quién comprueba que el usuario es el administrador y de ser así el artículo se elimina.

¿Hasta aquí vamos bien no? Esto es importante porque es la base de lo que viene a continuación. Cualquier duda... comentario.

Ahora imaginemos el siguiente escenario. El usuario administrador de blog.curiosoinformatico.com inicia sesión en el blog. Un usuario malicioso le pasa un link de una pagina web muy chula y de repente se encuentra con que 2 artículos de su blog han sido borrados. ¿Cómo? Así.

Este usuario malicioso carga ese enlace. Bien sea desde javascript, desde una imagen, un iframe o cualquier elemento. Al cargar ese enlace en navegador web manda las cookies de sesion de blog.curiosoinformatico.com al servidor web y le dicen "hola! soy el admin!". El servidor dice, el administrador ha clicado en el enlace de borrar el artículo 23 y en el de borrar el artículo 22, vale, los borro. Algo así valdría:

<img src="blog.curiosoinformatico.com/delete/id=23" style="display:none"/>

Cuando el administrador visitara la página web la etiqueta de la imagen intentaría cargar la imagen que se encontrara en la dirección de eliminar el artículo 23. Por lo que el navegador realizaría esa petición y tachán. Todo esto ya está realizado.

He dicho link pero podría ser un formulario perfectamente.

De hecho, ¿cuántos tenéis cuenta en pccomponentes? La página es genial, odio hacer publicidad, pero es así. Varios compañeros míos tuvieron algún problema con algo que compraron y se lo cambiaron sin ningún miramiento ni nada. Por lo que se han ganado mi confianza para mi próxima compra.

Si teníais la sesión iniciada y accedeis después de ver esta entrada os encontraréis con la sorpresa de que vuestra sesión se ha cerrado. Es más, (esto funciona a día de hoy), si iniciais sesión, recargáis este post y volvéis a recargar la página de pccomponentes descubriréis que habéis vuelto a cerrar sesión sin tocar ningún botón de la página.

Esto se debe a una imagen oculta que si quereis ver donde está haced 


Cuando el navegador ve la etiqueta intenta cargarla desde el hipervínculo donde haría clic el usuario para cerrar sesión. Entonces es como si vosotros cada vez que cargáis esta página hicierais clic en cerrar sesión en pccomponentes. 

Este es el ejemplo más tonto pero aún así tiene sus historias:

¿Qué sentido malicioso podría tener cerrar una sesión como en  este ejemplo?. Pues no es el caso porque utiliza una conexión https, pero si estuviéramos haciendo un mitm de esta manera forzaríamos a la entrada de credenciales para autentificarse y así poder capturarlos y usarlos en otro determinado momento. 

Hay medidas de protección a csrf como el uso de tokens. En cada formulario se crea un campo oculto que resulte tener un numero aleatorio generado para esa persona y para ese formulario, si hiciera clic en el enlace o el navegador intentara cargar la información sin el correspondiente token la aplicación web sabrá que no es un clic legítimo y hará lo que crea conveniente. Generalmente lanzar un error 404, página no encontrada.

Quería hacer algo distinto y ya que es un tema con el que me gusta mucho tratar era una buena idea hacer una "pequeña práctica".

ACTUALIZACIÓN

Recientemente hice una publicación en el blog de HoneySEC sobre CSRF explicando más detalladamente esa vulnerabilidad y poniendo un escenario para realizar pruebas de concepto.

Creando URLs con CSRF implícito

Un fuerte abrazo!

Vulnerabilidad Wordpress. Tomando el control!

No me agrada el uso de CMS excepto en determinados casos controlados o de muy bajo presupuesto donde no hay otra alternativa. Son herramientas increíbles, pero también son el foco de muchos ataques.

Un ejemplo es una vulnerabilidad en una versión del plugin de wordpress awesome-support, donde permite la subida de archivos arbitraria mediante un método POST.

<< La imagen ha sido eliminada porque olvidé el título del tabulador y no quiero revelar información de nadie >>


Otra cosa curiosa, es si alguna vez queréis reiros un rato haced la prueba de la viagra en google con un par de google dorks. Muchos ciberdelincuentes esconden en las páginas redireccionamientos y links a páginas de medicamentos para hacer black seo. Una búsqueda común es: inurl:"gob" cheap viagra
Para ver páginas gubernamentales que vendan viagra sin ni si quiera ellos saberlo. Para más información sobre este tema os recomiendo el libro Hacking con Google Bing y Shodan de Enrique Rando.

Por temas de privacidad no pondré en enlace al sitio donde realicé la prueba.

El script en php que subí fue simplemente el siguiente:

echo "This is a security test";



Nada más dado que no buscaba ningún propósito fuera de comprobar si realmente era cierta esta información. No detallaré aquí ningún proceso ya que no es mi intención hacer de este un blog para el uso de actividades delictivas ni mucho menos. Pero se puede encontrar facilmente información acerca de este tipo de vulnerabilidades en google buscando por subida arbitraria de archivos a wordpress.

El uso de un CMS no debe ser mirado como una herramienta peligrosa ni mucho menos. Son sistemas estables. El problema, como muchas veces reside en los usuarios. Cuando se descubre una vulnerabilidad se suele corregir en poco tiempo pero no todos Webmasters están al tanto de las últimas noticias de las versiones de los CMS que utilizan. No obstante el uso de este no debería ser una excusa para no aprender un lenguaje de programación. En el caso de una vulnerabilidad crítica en el que aún no haya salido un parche oficial tal vez se podría implementar una pequeña "chapuza" temporal o incluso arreglarlo por completo. La conclusión de todo esto, es altamente necesario el hecho de estar al tanto de las cosas y hay que meter en un presupuesto el tiempo que vamos a dedicar también a asegurarnos de que dicho proyecto no es vulnerable. Sea un CMS o no.

Un fuerte abrazo!