Ataques SSRF explicados: cómo se explota el DNS

La falsificación de solicitudes del lado del servidor (SSRF) ocurre cuando un atacante consigue que un servidor haga una solicitud HTTP (u otra solicitud de red) en su nombre, a un destino elegido por el atacante y no por el desarrollador de la aplicación. Un vector clásico: una función que obtiene una URL proporcionada por el usuario (una importación de imágenes, el destino de un webhook, una vista previa de enlaces) y el atacante aporta una URL que apunta a la infraestructura interna en lugar de a un recurso público.

Dónde entra el DNS en el ataque

La defensa ingenua consiste en comprobar si el nombre de host de la URL proporcionada parece una dirección interna. Eso se esquiva con una facilidad trivial: un atacante registra un dominio público, apunta su registro DNS a una IP interna y entrega a tu servidor un nombre de host de aspecto perfectamente normal. Tu validación ve un dominio, no una IP: la parte peligrosa solo aparece después de que ocurre la resolución DNS, que a menudo sucede en lo más profundo de la biblioteca de cliente HTTP que hace la solicitud real, mucho más allá de cualquier paso de validación inicial.

Cómo es una protección real

• Resuelve tú mismo el nombre de host, de forma explícita, antes de hacer ninguna solicitud: no dejes que un cliente HTTP lo resuelva de forma invisible en tu nombre.
• Comprueba cada dirección resuelta (todas: un dominio puede devolver varias) con una lista de bloqueo de rangos privados, de bucle local, de enlace local y de metadatos de la nube.
• Rechaza la solicitud si alguna dirección resuelta no está permitida, en lugar de comprobar solo la primera que se devuelve.
• Vuelve a validar en el momento de la solicitud, no solo al recibir la entrada, para cerrar la brecha del DNS rebinding que se describe por separado: en la práctica, el SSRF y el rebinding se combinan con frecuencia.

Los endpoints de metadatos de la nube merecen una mención especial: en la mayoría de los proveedores de nube, una solicitud desde dentro de una máquina virtual a una dirección de enlace local concreta puede devolver credenciales, metadatos de la instancia o configuración que nunca debió ser accesible desde fuera de la máquina. El SSRF combinado con un endpoint de metadatos como objetivo es una de las cadenas de explotación más comunes y de mayor impacto en el mundo real, y empieza, siempre, con un nombre de dominio de aspecto corriente.

Los filtros que comprueban la cadena de texto, no la dirección, no funcionan

Una dirección IP tiene más representaciones textuales válidas de las que contempla la mayoría del código de validación. Un filtro escrito como una coincidencia de cadena con «127.0.0.1» o «localhost» deja pasar sin tocar todas y cada una de las formas alternativas que figuran a continuación, porque ninguna se parece a la cadena que se busca.

La única defensa fiable es analizar primero la dirección para obtener su valor numérico real y evaluar la lista de bloqueo con ese valor, exactamente el enfoque que sigue el propio resolvedor de esta herramienta, en lugar de buscar patrones en la forma en que se haya escrito la dirección. Un resolvedor devuelve una dirección normalizada con independencia de cómo codificara el registro del nombre de host original, y precisamente por eso resolver primero y validar el resultado resuelto es más robusto que intentar validar una cadena en bruto en todas las formas en que un atacante pueda elegir escribirla.

Las redirecciones son la otra vía habitual de elusión

Incluso un sistema que resuelve y valida correctamente la URL inicial puede caer por una redirección HTTP. Una solicitud a una URL pública aprobada puede responder con un 302 que apunte a una dirección interna, y un cliente HTTP que sigue las redirecciones automáticamente (el comportamiento predeterminado en la mayoría de las bibliotecas) hará con gusto esa segunda solicitud sin volver a ejecutar la validación que superó la primera vez. Cualquier defensa contra SSRF que valida una sola vez, al principio, y luego deja que el cliente HTTP subyacente gestione las redirecciones por su cuenta tiene una brecha con exactamente la misma forma que la que crea la resolución DNS, y la solución también es la misma: volver a validar, de forma explícita, antes de seguir cualquier redirección, en lugar de confiar en que una URL que superó la comprobación una vez seguirá apuntando a un lugar seguro.