[05/11/2021] Los ataques de falsificación de solicitudes del lado del servidor (SSRF, por sus siglas en inglés) consisten en un atacante que engaña al servidor para que realice una solicitud no autorizada. El nombre en sí implica que el atacante ha falsificado una solicitud que, de otro modo, debería haber sido realizada por el servidor.
Los ataques SSRF son mucho más peligrosos que los ataques de falsificación de solicitudes entre sitios (CSRF, por sus siglas en inglés). Esto se debe a que, en cierto modo, los ataques CSRF implican que un atacante se apropie del navegador web de un usuario, y realice acciones no autorizadas en nombre del usuario. Durante un exploit CSRF activo, la actividad maliciosa se desencadena desde el lado del cliente y, por lo general, el objetivo es el usuario individual o sus activos. Por supuesto, los ataques CSRF se vuelven peligrosos cuando el usuario objetivo tiene privilegios de administrador en la aplicación web; en tal caso, toda la aplicación podría verse comprometida.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Los ataques SSRF, por otro lado, tienen como objetivo el servidor web en sí, sin la participación o interacción necesaria de sus usuarios. Con solo realizar una solicitud HTTP maliciosa al servidor, el atacante puede indicarle al back end que realice acciones maliciosas.
El principal robo de datos de Capital One, en el 2019, que afectó a aproximadamente 106 millones de usuarios en Estados Unidos y Canadá, se debió a un exploit de vulnerabilidad de la SSRF. Parte de la información comprometida incluía nombres de clientes, direcciones, información de contacto, fechas de nacimiento, SSNs (números de seguro social de Estados Unidos), SINs (números de seguro social de Canadá), puntajes de crédito, historial de pagos e ingresos reportados por los clientes.
Muchos expertos en ciberseguridad, incluido Evan Johnson de Cloudflare, atribuyeron el incidente a un ataque SSRF. Más recientemente, tanto los días cero de Microsoft Exchange explotados activamente desde marzo del 2021 (CVE-2021-26855) como las vulnerabilidades de ProxyShell descubiertas recientemente son el resultado de fallas SSRF.
¿Cómo funciona un ataque SSRF?
Al realizar una solicitud a un servidor web o hacer clic en un hipervínculo, los visitantes reciben archivos que están destinados a ser vistos por el mundo, es decir, los presentes en public_html o carpetas www. Todo lo que esté presente en carpetas o bases de datos privadas suele estar restringido a usuarios con más privilegios, como los administradores del servidor.
Sin embargo, los archivos y activos que son directamente accesibles para la audiencia general que navega por la web pueden ser accesibles por el propio servidor. Por ejemplo, como visitante, puede solicitar fácilmente una URL pública como https://www.csoonline.com/uk/events pero no los archivos confidenciales del sistema en el servidor de CSO como /etc/shadow o /etc/passwd. Es probable que el servidor web pueda acceder a estos archivos.
SSRF básico o no ciego
En un ambiente vulnerable, una aplicación web que se ejecuta en un servidor, también podría tener acceso a estos archivos. La base de cualquier ataque SSRF es que el usuario final puede engañar a un servidor de acceso público (web) para que proporcione acceso a archivos confidenciales en ese servidor, o acceso a otros sistemas u operaciones de mayor privilegio que, de otro modo, están restringidos para el usuario final.
Por ejemplo, tome el ejemplo de un sitio de comercio electrónico vulnerable en shop.example.com que utiliza varios servidores. Los usuarios pueden visitar shop.example.com para navegar por los productos, pero los detalles del producto se encuentran en otro servidor, al que los usuarios no tienen acceso directo. Supongamos que el servidor detrás de shop.example.com lo tiene.
Entonces, cuando hace clic en un producto, el servidor principal de la tienda realiza una solicitud secundaria. Para simplificarlo, supongamos que se trata de una simple solicitud GET con la URL visible en la barra de direcciones de su navegador: shop.example.com/?url=shop-server-2.example.com/product555/
Ir a esta URL completa le proporciona los detalles del producto Nro. 555. Si un atacante puede deducir razonablemente que no tiene acceso directo a http://shop-server-2.example.com/product555/ pero shop.example.com sí, ha encontrado una forma de utilizar el servidor principal de la tienda como área mediadora. Potencialmente, pueden explotar este servidor web para obtener acceso a activos y archivos restringidos.
Si shop.example.com tiene una protección laxa y es vulnerable a SSRF, un atacante podría simplemente navegar a shop.example.com/?url=file:///etc/passwd, y es muy probable que el servidor vulnerable ahora devuelva el contenido de la información confidencial del archivo /etc/passwd si no hay protecciones. Dependiendo del objetivo del atacante, la misma URL podría modificarse para incluir localhost o una dirección IP interna, junto con un número de puerto personalizado, entre otras cosas.
Este es solo uno de los ejemplos más básicos de las muchas posibilidades que ofrecen los ataques SSRF. El escenario anterior demuestra un SSRF "básico” o no ciego en el que una solicitud maliciosa, realizada por el atacante, da como resultado que el servidor devuelva datos visibles. Dichos ataques son excelentes para los actores de amenazas que buscan extraer datos de archivos y activos secretos o verificar si los puertos del sistema específicos están abiertos y ejecutando servicios.
SSRF ciego
Los ataques ciegos de SSRF, por otro lado, no necesariamente devuelven ningún dato, sino que se centran en realizar acciones no autorizadas en el backend del servidor. Con los ataques SSRF ciegos, el enfoque del atacante sería, por ejemplo, modificar algo en el servidor, alterar o eliminar archivos, cambiar permisos, y realizar una variedad de operaciones no autorizadas en lugar de buscar la extracción de datos.
Como una extensión del ejemplo anterior, suponga que la URL anterior se modificó para ir a shop.example.com/?url=http://example.com/some-very-large-file.png donde el servidor sigue intentando obtener un archivo anormalmente grande de un servidor externo. Tal solicitud puede hacer que el servidor web de shop.example.com se bloquee, lo que resultará en una denegación de servicio (DoS, por sus siglas en inglés) para todos. Este tipo de ataque SSRF es "ciego” ya que el objetivo no es recuperar una respuesta o datos visibles, sino realizar una acción perjudicial en nombre del servidor.
Cómo mitigar las vulnerabilidades de SSRF
La base para mitigar las fallas de SSRF sigue siendo evitar que los usuarios influyan en el input que llega a sus aplicaciones internas. Sus aplicaciones internas nunca deben confiar ciegamente en el input o asumir que proviene de una fuente auténtica.
Por ejemplo, en el ejemplo anterior de shop.example.com, ¿por qué el servidor incluso acepta archivos:/// URLs? Lo mismo se aplicaría a ftp:// o esquemas URI específicos de la aplicación, como slack: o skype:. Idealmente, el sistema debería restringirse a unos pocos protocolos seleccionados, como HTTP y HTTPS, según las necesidades de la aplicación. Hay mejores formas de realizar la misma operación descrita en este ejemplo, para que nunca sea necesario pasar un parámetro de URL a un servidor interno desde el lado del cliente.
¿Qué tal simplemente pasar un número de producto--shop.example.com/?product=555--y dejar que el back end de shop.example.com obtenga los detalles del producto 555 de otro servidor, cuya dirección está codificada en el back-end? Usted lo haría solo después de desinfectar el parámetro numérico "producto”, y asegurarse de que esté libre de datos maliciosos.
En segundo lugar, si la lógica del programa no se puede modificar y es absolutamente necesario una URL, un enfoque de lista de permitidos y denegados es una solución. Por ejemplo, algunas aplicaciones que implementan inicios de sesión basados en OAuth envían "URLs de redireccionamiento”, entre otros parámetros de URL, entre solicitudes y se ha descubierto que son vulnerables a SSRF.
Los enfoques de listas de permisos o listas blancas son más seguros, ya que el programa permite el acceso solo a los objetos permitidos o, en este contexto, a las ubicaciones, lo que hace que el proceso sea más selectivo y seguro. El enfoque de la lista de denegación, por otro lado, niega el acceso solo a ciertas ubicaciones de su elección, como localhost o 127.0.0.1, pero permite todo lo demás. Los enfoques de lista de denegación corren el riesgo de que un atacante inteligente encuentre soluciones alternativas, por ejemplo, a través de redirecciones HTTP, URLs confusas, reenlace de DNS o, de manera más realista, el administrador del servidor se olvida de incluir algo en la lista de denegación que luego llama la atención del atacante.
Como ocurre con la mayoría de las vulnerabilidades, las fallas SSRF se pueden eliminar adoptando una mentalidad de no confiar en nadie -desinfectando el input y minimizando la posibilidad de que el input sea influenciado por el usuario final. Además, un enfoque sólido para reducir las vulnerabilidades de SSRF es adoptar el principio de privilegio mínimo. En este enfoque el sistema solo otorga acceso a las API y los sistemas internos, que son absolutamente necesarios para la operación, a través de una lista de permisos.
Basado en el artículo de Axe Sharma (CSO) y editado por CIO Perú