Cada día surgen miles de nuevas vulnerabilidades, que crean nuevas oportunidades para los piratas informáticos. Los malos no se toman descansos ni vacaciones. Trabajan activamente para comprometer sus sistemas.
La importancia de mantenerse a la vanguardia de las últimas vulnerabilidades no se puede enfatizar lo suficiente en el panorama de amenazas en constante evolución. En esta ocasión, vamos a hablar de la vulnerabilidad de falsificación de petición del lado del servidor. Sin más preámbulos, vamos a explorar cómo funciona SSRF, cómo descubrir vulnerabilidades SSRF en sus aplicaciones, y qué medidas deben tomarse para evitarlas.
¿Qué es la falsificación de peticiones del lado del servidor?
La vulnerabilidad, denominada oficialmente Falsificación de solicitudes del lado del servidor (SSRF), figura en el Top 10 de OWASP como uno de los principales riesgos para la seguridad de las aplicaciones. Hackers de diversos tipos se aprovechan de la vulnerabilidad SSRF para abusar de la funcionalidad del servidor y enviar peticiones salientes arbitrarias desde un servidor.
Mediante la codificación de una URL, la manipulación de las cabeceras HTTP y la alteración del recorrido de la URL, los actores de amenazas pueden realizar solicitudes no autorizadas a una URL específica. Las vulnerabilidades SSRF pueden provocar la interrupción del servicio y, en algunos casos, la toma total del sistema.
Tipos de ataques de falsificación de petición del lado del servidor
Si te estás rascando la cabeza, preguntándote qué son los distintos ataques SSRF, estamos aquí para ayudarte a aclarar las cosas. En función de cómo responda el servidor a la solicitud inicial, existen tres tipos de SSR:
SSRF ciego
El SSRF ciego se produce cuando el servidor host no devuelve ningún dato visible a los ciberdelincuentes. El objetivo de los delincuentes de ransomware es cambiar o eliminar archivos críticos, modificar la configuración del servidor y ajustar los permisos de usuarios o archivos, en lugar de limitarse a robar datos específicos del servidor. No se envía nada desde el servidor al estafador, lo que convierte en una tarea ardua detectar estos ataques hasta que el daño está hecho.
En general, el SSRF ciego es el más difícil de explotar, aunque puede provocar una denegación de servicio (DoS) y la ejecución remota completa de código en el servidor o en otros componentes back-end.
SSRF semiciego
En este escenario, la instancia semiciega devuelve datos parciales sobre una solicitud resultante. Como resultado, el atacante obtiene acceso a ciertos datos secretos pero no al conjunto completo. Esto podría abarcar información como mensajes de error o tiempos de respuesta. El SSRF semi-ciego es a menudo suficiente para validar la vulnerabilidad pero no expone ningún dato sensible.
SSRF no ciego
El SSRF no ciego suele ser el más perjudicial de todos, ya que se pueden obtener datos de una URL arbitraria y devolvérselos a las entidades maliciosas que realizaron la consulta. Tras el éxito de un ataque SSRF no ciego, los operadores maliciosos se marchan con acceso a recursos de red restringidos que les ayudarán a lanzar nuevos ataques.
¿Cómo pueden aprovechar la SSRF los actores de amenazas?
Las vulnerabilidades SSRF pueden darse en varios tipos de software, lenguajes de programación y plataformas, siempre que el software opere en un entorno de red. En pocas palabras, si los atacantes pueden controlar el destino de la solicitud del lado del servidor, se abre la puerta a una plétora de agujeros de seguridad, lo que potencialmente les permite:
- Eludir las listas blancas de IP
- Inyectar peticiones HTTP maliciosas en el sistema objetivo
- Eludir los controles de cortafuegos
- Ejecución remota de código (RCE)
- Pivotar a través de redes corporativas para explotar otras vulnerabilidades
- Secuestrar y redirigir peticiones HTTP legítimas a un servidor controlado por el atacante.
- Escanear redes vinculadas al servidor vulnerable, internas o externas.
- Leer archivos de configuración o datos confidenciales del servidor web.
- Iniciar un ataque DDoS (denegación de servicio distribuido) enviando peticiones a recursos externos.
- Acceder a páginas de estado e interactuar con APIs como el servidor web
- Recuperar información sensible, como contraseñas o claves API
- Abusar de la confianza entre el servidor vulnerable y otros sistemas
Los ataques SSRF son especialmente delicados porque a menudo se encadenan con otras vulnerabilidades. Esta combinación permite a los atacantes establecer un punto de apoyo en el servidor que sirve de base para su posterior explotación.
A menudo, el objetivo principal de un ataque SSRF es robar un tesoro de documentos o una base de datos de registros de la empresa. Esto puede provocar la pérdida de confianza de los clientes, la disminución de los ingresos, responsabilidades legales y sanciones económicas.
¿Cómo detectar la SSRF?
¿Qué podemos hacer exactamente para descubrir esta vulnerabilidad? En el contexto del SSRF, se deben seguir los siguientes pasos para detectar este tipo de vulnerabilidades:
- Identifique entradas potenciales para construir URLs o iniciar peticiones a servidores externos, como parámetros y cabeceras GET o POST.
- Pruebe cada entrada probando una serie de URL o direcciones IP diferentes como entradas. Esto debería incluir recursos internos, localhost y otros valores especiales.
- Examine cómo responde la aplicación a las distintas entradas, buscando específicamente indicios de vulnerabilidades SSRF. Compruebe si hay indicios como la capacidad de acceder a recursos internos o extraer datos.
- Registre cualquier vulnerabilidad descubierta, detallando la entrada que causó la vulnerabilidad, el tipo de vulnerabilidad y su impacto potencial.
Ejemplos de la vida real
Ahora que ya conocemos los fundamentos de los SSRF, vamos a explorar algunos incidentes de este tipo de ataques que tuvieron lugar en la vida real.
Capital One
Un buen ejemplo de ataque SSRF fue cuando Capital One fue pirateada y se filtraron en línea los datos de aproximadamente 106 millones de personas en Estados Unidos y Canadá. ¿Cómo se produjo la filtración?
El hacker consiguió recibir una respuesta que contenía credenciales debido a una mala configuración del cortafuegos de aplicaciones web. Eso permitió al pirata informático conectarse con el servidor donde Capital One almacenaba sus datos y acceder a los archivos de los clientes.
Microsoft Exchange
Más recientemente, se descubrió que el grupo de amenazas Hafnium infectaba el software de correo electrónico Microsoft Exchange Server. La brecha de Microsoft Exchange de 2021 afectaba a cuatro vulnerabilidades, pero en concreto, la vulnerabilidad SSRF permitía a entidades malintencionadas autenticarse como un servidor Exchange y ejecutar código remoto a través de PowerShell. Es otro ejemplo de cómo una fuente de confianza comprometida puede escalar los ataques.
El grupo, que operaba desde China, atacó los sistemas de correo electrónico utilizados por 30.000 bufetes de abogados estadounidenses, instituciones de enseñanza superior, investigadores de enfermedades infecciosas, grupos de reflexión política, contratistas de defensa y organizaciones no gubernamentales.
Servicios de Microsoft Azure
El 17 de enero de 2023, se descubrieron problemas de seguridad que exponían los servicios de Microsoft Azure a ataques SSRF. Dos vulnerabilidades no requerían autenticación, lo que permitía a los actores de amenazas explotarlas sin una cuenta de Azure. Tras identificar las vulnerabilidades en Azure API Management, Azure Functions, Azure Machine Learning y Azure Digital Twins, Microsoft abordó y resolvió rápidamente los problemas.
Afortunadamente, en ese caso, la validación de entrada adicional para las URL vulnerables se implementó de manera oportuna, y las vulnerabilidades no causaron ningún daño a los servicios o infraestructura de Azure. Sin embargo, la empresa se ha percatado realmente del riesgo de los ataques de falsificación de peticiones del lado del servidor.
Prevención y mitigación de la SSRF
Sin los procesos preventivos adecuados, la seguridad de sus aplicaciones es un gran interrogante. Como ocurre con la mayoría de las vulnerabilidades, la prevención es el mejor enfoque para aplastar los fallos SSRF.
- Valide los datos introducidos. No confíe ciegamente en las entradas: verifique siempre su autenticidad.
- Ponga en la lista blanca los nombres de dominio o direcciones IP a los que su aplicación necesita acceder. Minimice la superficie de ataque. En las redes internas, esto suele significar que un servidor debe permitir el paso de solicitudes que contengan URL de una lista preestablecida y rechazar todas las demás solicitudes.
- Utilice la codificación de URL. Una correcta codificación y descodificación de las entradas del usuario es un mecanismo adicional de defensa en profundidad que mitiga el riesgo de que el servidor procese URL maliciosas.
- Realice pruebas de penetración que incluyan un elemento humano para explotar vulnerabilidades. También puede utilizar herramientas de pruebas de seguridad para ejecutar pruebas de simulación.
- Deshabilite los esquemas de URL no utilizados. Este enfoque se aprovecha para permitir sólo aquellos esquemas de URL utilizados por su aplicación para realizar peticiones y, a su vez, limitar al atacante a realizar peticiones utilizando esquemas potencialmente peligrosos como file://, phar://, gopher://, data:// o dict://.
- Aplique el principio del menor privilegio, según el cual el sistema sólo concede acceso a los usuarios autorizados.
- Segregar la red. Al segmentar las redes internas de las externas, se reduce la superficie de ataque y se dificulta el acceso de los piratas informáticos a los sistemas internos.
- Como mejor práctica de seguridad, mitigue los errores de configuración.
- Eduque a los empleados sobre los riesgos asociados a la SSRF y las formas de eliminarlos.
- Documente y aprenda de las vulnerabilidades SSRF que haya descubierto para mejorar los procedimientos de prueba y prevenir futuras incidencias.
- La actualización periódica del software proporciona un nivel adicional de prevención.
Practicar la prevención es, en efecto, más inteligente que esperar a que los atacantes hostiles ataquen primero.
¿Cómo puede ayudar QAwerk?
Las pruebas de penetración son un paso esencial en el ciclo de vida de la gestión de vulnerabilidades destinado a mejorar la seguridad de sus sistemas. Con la ayuda de los probadores de penetración en QAwerk, puede vencer a las amenazas sofisticadas con facilidad y rapidez.
Estamos aquí para buscar a través de sus redes, servidores y aplicaciones para encontrar, analizar y reportar vulnerabilidades de hacking. Nuestros experimentados testers llevan a cabo pen tests de caja negra, gris y blanca para revelar fallos de seguridad. Aprovechando nuestra amplia experiencia, podemos identificar incluso las vulnerabilidades más escurridizas.
Conclusión
Las vulnerabilidades SSRF pueden aparecer inesperadamente, poniendo potencialmente en peligro la seguridad de su empresa. Para evitar que esto ocurra, las pruebas de penetración deben realizarse con regularidad. Dará a los actores de amenazas que intentan violar sus sistemas un momento más difícil.
Las pruebas de penetración son un proceso proactivo que no merece ser descuidado. Téngalo en cuenta y manténgase seguro con QAwerk.