Introducción
La Falsificación de Solicitudes del Lado del Servidor (SSRF, por sus siglas en inglés) es una vulnerabilidad de seguridad web que permite a un atacante inducir a una aplicación del lado del servidor a realizar solicitudes HTTP hacia un dominio arbitrario elegido por el atacante.
El punto crucial es que el servidor realiza la solicitud, no el atacante directamente. Esto significa que la solicitud hereda la posición de red del servidor, sus relaciones de confianza y su acceso a destinos internos.
En un ataque SSRF típico, el atacante puede hacer que el servidor se conecte a servicios internos dentro de la infraestructura de la organización. En otros casos, puede forzar al servidor a conectarse a sistemas externos arbitrarios, lo que podría filtrar datos confidenciales, como credenciales de autorización.
En este laboratorio, interactuarás con una aplicación web vulnerable simulada. Aprenderás a identificar la vulnerabilidad SSRF, observarás cómo los filtros de seguridad básicos intentan bloquear solicitudes maliciosas, cómo eludir dichos filtros y, finalmente, cómo extraer datos internos confidenciales y metadatos simulados de la nube. Para mantener el ejercicio compatible con entornos de laboratorio compartidos, el servicio de metadatos simulado utiliza un puerto alto no privilegiado en lugar del puerto 80.
Identificar parámetros de URL
En este paso, aprenderás a identificar posibles vulnerabilidades SSRF buscando funciones de la aplicación que obtengan datos de URLs externas.
Muchas aplicaciones web necesitan obtener recursos de otros servidores. Por ejemplo, una aplicación podría obtener una foto de perfil de un sitio de redes sociales o recuperar datos de una API de terceros. Si la aplicación toma una URL como entrada del usuario y la obtiene sin la validación adecuada, puede ser vulnerable a SSRF.
Es por esto que el SSRF a menudo aparece en funciones de "obtención de URL" que parecen legítimas. El comportamiento peligroso se oculta dentro de un flujo de trabajo que parece normal desde la perspectiva del producto.
Se ha iniciado una aplicación web vulnerable para ti en el puerto 8080. Esta aplicación tiene un endpoint /check que acepta un parámetro url. Está diseñada para verificar el estado de sitios web externos.
Puedes probar esta funcionalidad pidiendo a la aplicación que obtenga un sitio web externo benigno, como http://example.com. Usa el comando curl en tu terminal para enviar una solicitud HTTP GET a la aplicación vulnerable. Si no estás familiarizado con curl, piénsalo como un navegador web de línea de comandos simple que envía solicitudes e imprime la respuesta del servidor en la terminal.
curl "http://localhost:8080/check?url=http://example.com"
Cuando ejecutas este comando, la aplicación vulnerable que se ejecuta en el puerto 8080 recibe tu solicitud, extrae el parámetro url y realiza su propia solicitud HTTP a http://example.com. Luego, te devuelve la respuesta HTML.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
Al observar que el servidor obtuvo y devolvió correctamente el contenido de la URL solicitada, has confirmado que el parámetro url se está procesando activamente y se utiliza para realizar solicitudes del lado del servidor. Este es el primer indicador de una vulnerabilidad SSRF.
Probar SSRF contra Localhost (127.0.0.1)
En este paso, intentarás explotar la vulnerabilidad SSRF para acceder a un servicio interno que se ejecuta en el servidor.
El peligro principal del SSRF es que el servidor que realiza la solicitud a menudo tiene una posición privilegiada en la red. Puede acceder a servicios internos que no están expuestos a la internet pública. En nuestro escenario, hay un panel de administración interno ejecutándose en el puerto 5000. Este panel de administración está vinculado a 127.0.0.1 (localhost), lo que significa que solo se puede acceder a él desde el propio servidor, no desde otra máquina. Puedes pensar en 127.0.0.1 como la computadora hablando consigo misma.
Como atacante, puedes usar la vulnerabilidad SSRF en el puerto 8080 para engañar al servidor y hacer que acceda al panel de administración en el puerto 5000 en tu nombre.
Intenta acceder al panel de administración interno pasando su URL local al endpoint vulnerable /check.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
Cuando ejecutes este comando, notarás que la solicitud no tiene éxito. En su lugar, recibirás un mensaje de error.
Error: Localhost access is blocked by WAF!
Los desarrolladores a menudo implementan Firewalls de Aplicaciones Web (WAF) o filtros de entrada para prevenir ataques SSRF. En este caso, la aplicación verifica si la URL proporcionada contiene la cadena 127.0.0.1 o localhost. Debido a que tu entrada coincidió con este filtro, la aplicación bloqueó la solicitud.
Los filtros de cadena simples son frágiles porque los destinos de red tienen múltiples representaciones equivalentes. Los defensores necesitan una validación que comprenda el significado de red canónico, no solo el texto literal.
Comprender cómo la aplicación filtra la entrada es un paso crucial para explotar el SSRF, ya que te indica qué restricciones necesitas eludir.
Eludir filtros de entrada
En este paso, aprenderás a eludir el filtro de entrada básico que encontraste en el paso anterior.
Las técnicas de elusión funcionan aquí porque el análisis de URL, la resolución de nombres de host y el filtrado de entrada no siempre utilizan las mismas reglas de interpretación.
Los filtros de entrada que dependen de una simple coincidencia de cadenas (como bloquear 127.0.0.1) a menudo son defectuosos porque las direcciones IP pueden representarse de varias maneras. La pila de red del sistema operativo seguirá resolviendo estas representaciones alternativas al mismo destino, pero el filtro de texto de la aplicación podría no reconocerlas.
Aquí hay algunas formas comunes de representar la dirección IP de localhost (127.0.0.1) que podrían eludir un filtro mal implementado. Puedes usar una IP abreviada como 127.1, una IP decimal como 2130706433, una IP octal como 0177.000.000.001 o una IP hexadecimal como 0x7f000001.
Dado que la aplicación solo bloquea las cadenas exactas 127.0.0.1 y localhost, puedes usar la representación IP abreviada 127.1 para eludir el filtro y acceder al panel de administración interno.
Ejecuta el siguiente comando para probar la técnica de elusión:
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Debido a que 127.1 no coincide con las cadenas bloqueadas, la aplicación permite que la solicitud continúe. La pila de red del servidor resuelve 127.1 a 127.0.0.1 y obtiene con éxito la página de administración interna.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
Has eludido con éxito el filtro de entrada y explotado la vulnerabilidad SSRF para acceder a un servicio interno restringido.
Acceder a metadatos internos
En este paso, utilizarás la vulnerabilidad SSRF para acceder a metadatos confidenciales de la nube.
Cuando las aplicaciones se alojan en entornos de nube (como AWS, Google Cloud o Azure), a menudo tienen acceso a una dirección IP especial no enrutable: 169.254.169.254. Esta dirección aloja el Servicio de Metadatos de Instancia (IMDS), que proporciona información sobre la instancia de nube en ejecución, incluidas credenciales temporales altamente confidenciales de IAM (Gestión de Identidad y Acceso). "No enrutable" significa que la dirección está destinada a la infraestructura local de la nube en lugar de al acceso público general a internet.
Si un atacante encuentra una vulnerabilidad SSRF en una aplicación alojada en la nube, consultar este endpoint de metadatos suele ser su objetivo principal, ya que puede llevar al compromiso total del entorno de nube.
En este entorno de laboratorio, un servicio de metadatos de nube simulado se ejecuta en 169.254.169.254:8000. El servicio de metadatos real de la nube suele utilizar el puerto 80, pero este laboratorio utiliza intencionalmente el puerto 8000 para que el servicio pueda iniciarse sin privilegios especiales y sin entrar en conflicto con otro software. Primero, utiliza la vulnerabilidad SSRF para listar los directorios de metadatos disponibles.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
El servidor obtendrá el listado del directorio de metadatos y te lo devolverá.
iam/security-credentials/admin-role
La salida revela un rol de IAM llamado admin-role. Ahora puedes añadir esta ruta a tu carga útil (payload) de SSRF para extraer las credenciales de seguridad reales asociadas con este rol.
Ejecuta el siguiente comando para recuperar las credenciales confidenciales:
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
El servicio de metadatos simulado devolverá las credenciales en formato JSON.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
Si esta solicitud no devuelve datos en tu entorno, verifica brevemente /tmp/meta.log y confirma que hay un servicio escuchando en 169.254.169.254:8000.
Al extraer con éxito estas credenciales, has demostrado el grave impacto de una vulnerabilidad SSRF en un entorno de nube.
Resumen
En este laboratorio, exploraste y explotaste con éxito una vulnerabilidad de Falsificación de Solicitudes del Lado del Servidor (SSRF). Aprendiste a identificar parámetros de URL vulnerables observando el comportamiento de obtención del lado del servidor. Luego, encontraste un filtro de entrada básico diseñado para bloquear el acceso local y lo eludiste con éxito utilizando representaciones alternativas de direcciones IP. Finalmente, demostraste el impacto crítico del SSRF al extraer credenciales de metadatos de nube simuladas y confidenciales. Comprender estas técnicas es esencial tanto para identificar vulnerabilidades durante las evaluaciones de seguridad como para implementar defensas sólidas en las aplicaciones web.
