Seguridad de la Informacion ¿Cómo funciona un ataque de tipo CSRF?

[pic 1]

 [pic 2]

[pic 3][pic 4][pic 5][pic 6][pic 7]

[pic 8]

Índice

Introducción        2

Ataque CSRF        3

Ejemplo Real        6

¿Cómo funciona un ataque de tipo CSRF?        6

Autenticación: Sesiones y Cookies        6

Videos Explicativos        7

Demostración de un ataque CSRF:        7

Protección contra ataques CSRF:        7

Políticas de CORS:        7

OWASP        8

BSIMM        10

Conclusión        11

Bibliografía        12

Introducción

En los últimos años, la tecnología y la arquitectura de las aplicaciones ha cambiado significativamente. Los microservicios escritos en node.js y Spring Boot reemplazan a las aplicaciones monolíticas tradicionales. Estos microservicios tienen sus propios desafíos de seguridad, incluyendo el establecimiento de confianza entre microservicios, contenedores, gestión de secretos, etc.

El antiguo código, que nunca esperó ser accesible desde Internet, ahora se encuentra detrás de un API o servicio RESTful, pudiendo ser consumido por aplicaciones de una sola página (SPAs) y aplicaciones móviles. Con este acceso a la Web, se abre todo un nuevo abanico de posibles amenazas a los sistemas: los ataques informáticos.

Los ataques informáticos son un intento de exponer, desestabilizar, alterar, destruir o de obtener acceso no autorizado a información sensible. Desde el momento en el que nació la informática como la conocemos hoy en día, siempre hubo personas tratando de encontrar la manera de comprometer a las empresas y a sus sistemas. En este trabajo, nos centraremos en un tipo de ataque en específico: Cross Site Request Forgery (CSRF). Empezaremos hablando de en qué consiste este ataque, cómo surgió y daremos varios ejemplos de cómo ha comprometido a varias de las empresas más importantes del mundo (Netflix, YouTube, bancos). También explicaremos cómo lograr protegerse ante estos ataques.

Para hacer la explicación mucho más clara y llevadera hemos decidido programar un ejemplo de ataque CSRF real, mostrando las fortalezas y debilidades del mismo. Luego indagaremos en qué es OWASP y cómo puede ayudarnos a combatir todo este tipo de amenazas. Además, también veremos brevemente en qué consiste BSIMM y cómo puede ayudarnos.

Como cierre hablaremos de la importancia de programar teniendo en cuenta que existen muchos tipos de ataques, y también de la importancia de las buenas prácticas.

Ataque CSRF

Cross-Site Request Forgery, o CSRF, es un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una aplicación web en la que está autenticado. Con herramientas como el envío de un enlace por correo electrónico o chat, es decir Phishing, un atacante puede engañar a los usuarios de una aplicación web para que ejecuten acciones de su elección. Si la víctima es un usuario normal, un ataque CSRF exitoso puede forzar al usuario a realizar solicitudes de cambio de estado como transferir fondos de su cuenta bancaria, cambiar su dirección de correo electrónico, etc. Si la víctima es una cuenta administrativa, el CSRF puede comprometer toda la aplicación web.

     CSRF es un ataque que engaña a la víctima para que envíe una solicitud maliciosa. Hereda la identidad y los privilegios de la víctima para realizar una función no deseada en su nombre. En la mayoría de los sitios, las solicitudes del navegador incluyen automáticamente cualquier credencial asociada al sitio, como la cookie de sesión del usuario, la dirección IP, las credenciales de dominio de Windows, etc. Por lo tanto, si el usuario está autenticado en el sitio, el sitio no tendrá forma de distinguir entre la solicitud falsificada enviada por la víctima y una solicitud legítima enviada por la víctima.

     Los ataques CSRF se dirigen a funcionalidades que provocan un cambio de estado en el servidor, como cambiar la dirección de correo electrónico o la contraseña de la víctima. Forzar a la víctima a recuperar datos no beneficia al atacante porque éste no recibe la respuesta, sino que la víctima lo recibe. Por lo tanto, los ataques CSRF se dirigen a las solicitudes de cambio de estado.

     A veces es posible almacenar el ataque CSRF en el propio sitio vulnerable. Estas vulnerabilidades se denominan "defectos CSRF almacenados". Esto puede lograrse simplemente almacenando una etiqueta IMG o IFRAME en un campo que acepte HTML, o mediante un ataque de scripting cruzado más complejo. Si el ataque puede almacenar un ataque CSRF en el sitio, la gravedad del ataque se amplifica. En particular, la probabilidad aumenta porque es más probable que la víctima vea la página que contiene el ataque que alguna página al azar en Internet. La probabilidad también aumenta porque es seguro que la víctima ya está autenticada en el sitio.

     Los ataques CSRF también se conocen con otros nombres, como XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery y Hostile Linking. Microsoft se refiere a este tipo de ataque como ataque One-Click en su proceso de modelado de amenazas y en muchos lugares de su documentación en línea.

     Un atacante puede lanzar un ataque CSRF cuando conoce la combinación de parámetros y valores que se utilizan en un formulario. Por lo tanto, si se añade un parámetro adicional con un valor desconocido para el atacante y que pueda ser validado por el servidor, se pueden evitar los ataques CSRF.

     Uno de estos parámetros a utilizar puede ser un token anti-CSRF. Un token anti-CSRF es un tipo de protección CSRF del lado del servidor. Es una cadena aleatoria que sólo conocen el navegador del usuario y la aplicación web. El token anti-CSRF suele almacenarse dentro de una variable de sesión. En una página, suele estar en un campo oculto que se envía con la solicitud. Si los valores de la variable de sesión y del campo oculto del formulario coinciden, la aplicación web acepta la solicitud. Si no coinciden, la solicitud se descarta. En este caso, el atacante no conoce el valor exacto del campo oculto del formulario que se necesita para que la solicitud sea aceptada, por lo que no puede lanzar un ataque CSRF. De hecho, debido a la política de mismo origen, el atacante ni siquiera puede leer la respuesta que contiene el token.

     Sin embargo, hay medidas de prevención que no funcionan como, por ejemplo, usar una cookie secreta, ya que todos los tokens de autenticación se enviarán independientemente de si el usuario final fue engañado para enviar la solicitud. Otra medida de prevención que no funciona puede ser solo aceptando solicitudes POST. Las peticiones HTTP POST se utilizan para enviar datos que se publican en la aplicación web. Hay numerosos métodos en los que un atacante puede engañar a una víctima para que envíe una solicitud POST falsificada, como un simple formulario alojado en un sitio web del atacante con valores ocultos.

     Aunque las vulnerabilidades CSRF ya existían desde antes del año 2000, el término fue definido por primera vez por Peter Watkins en 2001. La primera explotación conocida fue el gusano de MySpace de Samy Kamkar en 2005 que combinó XSS y CSRF para propagarse. Otros ataques que son conocidos son por ejemplo Netflix en 2006 que podrían haber permitido a un atacante realizar acciones como añadir un DVD a la cola de alquiler de la víctima, cambiar la dirección de envío en la cuenta o alterar las credenciales de inicio de sesión de la víctima para comprometer completamente la cuenta. La aplicación bancaria ING Direct que permitía realizar transferencias de dinero ilícitas, Youtube en 2008 que permitía a cualquier atacante realizar casi todas las acciones de cualquier usuario, y McAfee Secure que permitía a los atacantes cambiar el sistema de la empresa. Instagram, la famosa red social, también fue víctima de este tipo de ataque (2014). Lo que hacía era hacer públicas fotos de usuarios que debían ser privadas. A Facebook le tomó casi 6 meses arreglar esta vulnerabilidad.

     En 2018 se llevaron a cabo nuevos ataques contra dispositivos habilitados para la web, incluyendo intentos de cambiar la configuración DNS de los routers. Algunos fabricantes de routers se apresuraron a lanzar actualizaciones de firmware para mejorar la protección, y aconsejaron a los usuarios que cambiarán la configuración del router para reducir el riesgo.

Mientras que el CSRF pareciera ser un problema resuelto en este momento, un ataque muy similar ha surgido con la llegada de las aplicaciones web modernas: Clickjacking. En lugar de enviar una solicitud a la página de la víctima directamente, el atacante coloca la página de la víctima en un iframe y la sitúa bajo el cursor, de modo que cuando el usuario hace clic en algún lugar de la página del atacante, el clic se activa en un lugar arbitrario de la página de la víctima. El primer ataque de clickjacking fue documentado por Robert Hansen y Jeremiah Grossman en 2008, y la técnica fue perfeccionada en 2010 por Paul Stone como "clickjacking de nueva generación". Esta última versión hace uso de trucos de arrastrar y soltar para robar o inyectar datos en la página de la víctima además de secuestrar un clic.

...