Saltar a contenido

Server-Side Request Forgery: La Puerta Trasera que Puede Derribar tu Infraestructura

En el ámbito de la seguridad web, las vulnerabilidades Server-Side Request Forgery (SSRF) destacan como una de las amenazas más críticas y subestimadas. Permiten a los atacantes manipular servidores para realizar peticiones HTTP no autorizadas a sistemas internos, comprometiendo desde APIs y servicios en la nube hasta infraestructuras protegidas por firewalls.

Esta técnica de ataque, a menudo subestimada, puede transformar un servidor aparentemente seguro en una puerta de entrada para los ciberdelincuentes, permitiéndoles acceder a recursos internos, robar datos sensibles e incluso lanzar ataques contra terceros.

¿El resultado? Robo de datos, acceso a servicios internos, ejecución remota de código y, en última instancia, daño a la reputación, multas por incumplimiento de normativas como GDPR, y pérdidas financieras significativas. Un ataque SSRF exitoso puede paralizar operaciones críticas y comprometer la confianza de los clientes.

¿Qué es una vulnerabilidad SSRF?

Las vulnerabilidades de Server-Side Request Forgery (SSRF) se dan cuando un atacante puede manipular un servidor para que realice solicitudes no autorizadas. Imagina que un servidor web actúa como un mensajero que normalmente entrega mensajes (solicitudes) solo a destinatarios autorizados. Pues la explotación de un ataque SSRF sería el equivalente a que un extraño forzara al mensajero a mandar cartas a cualquier destinatario sin filtro, pudiendo mandar mensajes sin pasar por aduana y con remitente oficial.

Para ver un caso más concreto, consideremos una aplicación de compras que consulta el stock de productos mediante solicitudes a una API REST. La aplicación pasa la URL a consultar al endpoint de la API a través de una solicitud HTTP. Un atacante que notase esto, podría modificar esta URL para acceder a otros endpoints internos de la API, pudiendo llegar a obtener información no autorizada, como datos de otros usuarios.

Además, los ataques SSRF no se limitan al protocolo HTTP. En ciertos casos, un atacante podría intentar usar otros esquemas de URI, como file:// para acceder a archivos locales en el servidor, smb:// para forzar una autenticación y obtener un hash NTLM u otros protocolos de diversa índole.

Impacto de los ataques SSRF

Por lo general, un ataque SSRF puede resultar en el acceso no autorizado a recursos internos. Además, en algunas situaciones, la vulnerabilidad SSRF podría permitir a un atacante la ejecución de comandos arbitrarios mediante ciertas cadenas de vulnerabilidades.

Cuando un SSRF se puede utilizar para establecer conexiones con sistemas externos de terceros, un atacante puede emplearlo para llevar a cabo ataques de suplantación. Esto significa que los ataques parecerán originarse desde la organización que aloja la aplicación vulnerable. Por ejemplo, un atacante podría aprovechar un servidor con SSRF para escanear puertos en la red interna de otra empresa o incluso lanzar un ataque de denegación de servicio (DoS) contra un servicio externo, haciendo que parezca que la ofensiva proviene de la organización comprometida.

Otro posible escenario de explotación, es la exploración de redes internas (intranet), donde un atacante puede aprovechar el SSRF para enviar solicitudes a direcciones internas a través del servidor afectado. Esto le permitiría identificar puertos abiertos, mapear servicios internos y recopilar información sensible sobre la infraestructura de la red. La gravedad del ataque aumenta si el servidor comprometido posee acceso privilegiado a recursos internos que normalmente estarían protegidos contra accesos externos.

Tipos de Server-Side Request Forgery

Existen dos tipos principales de ataques Server-Side Request Forgery (SSRF):

  • SSRF estándar: En este tipo de ataque, la respuesta del servidor se muestra directamente al atacante. El servidor obtiene la URL solicitada por el atacante y envía el contenido (o parte de él) en la respuesta de vuelta.
  • SSRF a ciegas (Blind SSRF): En este caso, la respuesta no se envía de vuelta al atacante. El atacante debe idear formas de confirmar y explotar la vulnerabilidad sin ver directamente la respuesta del servidor.

A continuación, veremos las características y métodos de explotación propios de cada tipo de SSRF. Además de posibles enfoques para la detección y mitigación de estas vulnerabilidades.

SSRF Estándar

El ataque de SSRF estándar es la forma más directa de realizar este ataque. En este escenario, el atacante puede observar directamente la respuesta del servidor a la solicitud manipulada. Esto puede permitir al atacante recopilar información detallada sobre la red interna, identificar servicios accesibles y recuperar datos potencialmente sensibles.

Metodología de explotación

La explotación de este tipo de SSRF se divide en 3 fases:

  1. Inyección: El atacante introduce una URL maliciosa en un campo de entrada de la aplicación.
  2. Solicitud: El servidor, sin validar la URL, realiza una solicitud al recurso especificado por el atacante.
  3. Revelación: La respuesta del servidor se devuelve al atacante, permitiéndole acceder a información interna.

En el siguiente ejemplo tenemos una aplicación web que permite consultar el stock de los productos que oferta. Para poder ver las peticiones de manera más clara usaremos un proxy de aplicación como es el caso de BurpSuite, así veremos la solicitud que se realiza al consultar el stock de los productos:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=stockApi=http://internal-stock-api/check?productId=123

Esta solicitud hace que el cliente reciba el stock del producto indicado mediante el productId. Sin embargo, un atacante podría modificar la petición a la URL que se especifica, como por ejemplo:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

Al mandar esta solicitud, si existe el directorio /admin en la máquina atacada y es procesada sin más validación, el atacante podría llegar a acceder al panel de administración interno.

Ejemplo de explotación para obtener acceso a metadatos de Amazon EC2

Un caso común de explotación de SSRF es en el que al atacante accede a metadatos internos de una instancia de EC2 en AWS: 

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://169.254.169.254/latest/meta-data/
El acceso a esta API podría revelar información sensible como claves de acceso, roles IAM u otra información sensible.

Podemos encontrar contramedidas especificas en la documentacion de AWS.

Ejemplo de explotación para la lectura de archivos locales:

Si la aplicación habilita el uso del esquema file://, un atacante podría intentar leer archivos del sistema de la siguiente manera:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=file:///etc/shadow

SSRF a ciegas

El caso del ataque SSRF a ciegas representa un desafío mayor, ya que no se recibe la respuesta del servidor directamente, En este tipo de ataque, el atacanted debe inferir el éxito de su intrusión a través de cambios observables en el comportamiento de la aplicación o mediante la interacción con un servidor externo. Un atacante podría usar este tipo de SSRF para abusar de funciones internas que normalmente no están expuestas o para atacar un servicio de terceros.

Metodología de explotación

Imaginemos una aplicación web que permite a los usuarios subir imágenes de perfil. La aplicación verifica que la imagen sea válida haciendo una solicitud a la URL proporcionada, pero no muestra el resultado de esta verificación al usuario.

Una implementación rudimentaria sería la siguiente:

import requests
def verify_image(url):
  try:
    response = requests.get(url, timeout=5)
    if response.headers.get('content-type', '').startswith('image/'):
      return True
  except:
    pass
    return False

  user_provided_url = "https://example.com/image.jpg"
  if verify_image(user_provided_url):
    print("Valid image")
  else:
    print("Rejected URL")

En este caso, el servidor recibe una URL, en este caso es https://example.com/image.jpg y luego realiza una solicitud HTTP a esa URL para verificar si contiene una imagen. Finalmente, si la URL proporcionada devuelve un recurso, con Content-Type: image/* se dará como válida.

El problema radica en que el servidor confía ciegamente en las URLs proporcionadas por los usuarios, permitiendo que se realicen solicitudes HTTP arbitrarias.

Si un atacante suministra una URL controlada por él mismo o que apunte a un recurso interno del servidor, como http://internal-server/sensitive-data, el atacante no verá directamente la respuesta del servidor, pero podrá deducir si la solicitud fue exitosa observando ciertos comportamientos:

  • Tiempo de respuesta: Un recurso interno que tarda más en responder podría indicar que el servidor accedió al recurso.
  • Mensajes de error: Diferencias en los errores devueltos por el servidor pueden confirmar la existencia del recurso.

Para verificar si se realiza la solicitud a la URL suministrada, se emplean técnicas de fuera de banda (OOB), como el monitoreo de solicitudes DNS o HTTP hacia dominios controlados por el atacante. Por ejemplo, podría ser la siguiente URL http://internal-server.sensitive-data.attacker-domain.com. Aquí, attacker-domain es un dominio controlado por el atacante. Si el servidor vulnerable procesa esta URL, intentará resolver el dominio y realizar una solicitud HTTP hacia él. Esto permite al atacante detectar la actividad monitoreando su propio servidor DNS o web. Esta funcionalidad está integrada mediante el Colaborator en la versión profesional de BurpSuite.

Como prevenir los ataques SSRF

Como hemos visto anteriormente, este tipo de ataques son particularmente peligrosos facilitando la explotación de recursos internos. Para protegerse contra este tipo de vulnerabilidad, es fundamental implementar una combinación de medidas de seguridad robustas. A continuación, se detallan las estrategias más efectivas:

Validar estrictamente la entrada

Para protegernos ante un ataque de SSRF, podemos hacer uso de:

  • Whitelists: Podemos permitir que el servidor acceda a URLs específicas y que sean confiables para el correcto uso de la aplicación. En lugar de permitir cualquier URL, define una lista blanca de dominios y rutas a las que el servidor puede acceder. Cualquier solicitud que no coincida con esta lista blanca debe ser rechazada. Ejemplo: permitidos = ["api.ejemplo.com/productos", "imagenes.ejemplo.com"].
  • Bloqueo de direcciones internas: Podemos bloquear solicitudes a URLs internas, con el fin de que no se puedan acceder a recursos internos del servidor (localhost o cualquier IP del estilo 192.168.x.x). Configura el servidor para rechazar cualquier solicitud a direcciones IP privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y a localhost (127.0.0.1). Esto previene el acceso no autorizado a recursos internos de la red, impidiendo que un atacante manipule el servidor para acceder a servicios o datos que deberían estar protegidos.
  • Restringir protocolos: Podemos bloquear protocolos como smb://, file://, entre otros. Limitar los protocolos a HTTP(S) reduce la superficie de ataque, evitando que se utilicen otros protocolos potencialmente inseguros para acceder a recursos internos o externos.

Uso de Web Application Firewalls (WAFs)

Podemos configurar un WAF con reglas específicas puede ayudar a detectar y bloquear patrones sospechosos relacionados con SSRF. Los WAFs pueden actuar como una capa adicional de defensa al monitorear y filtrar el tráfico saliente del servidor.

Segmentación de Red

Podemos dividir la red en segmentos y limitar el acceso entre ellos. Por ejemplo, si el servidor web no debería tener acceso directo a la base de datos, por que hace uso de una API. Entonces, debería limitarse la capacidad de mandar tráfico directamente al servidor de bases de datos. De manera general el host no deberia poder acceder a mas servicios internos de los estrictamente necesarios para su funcionamiento, minimizando la superficie de ataque.Este enfoque debe adaptarse a la situación concreta de cada servicio.

Implementar monitorización

Aunque el SSRF a ciegas no muestra respuestas directamente al atacante, las técnicas fuera de banda dejan trazas que pueden ayudar a detectar intentos maliciosos. A fin de detectar estas técnicas es crucial configurar la monitorización de las requests DNS emitidas por los servidores de aplicación a fin de identificar solicitudes inesperadas hacia dominios externos.

Pruebas periódicas de seguridad

Realizar auditorías de seguridad periódicas, para proteger tus aplicativos web contra esta y otras amenazas.

Conclusión

La prevención de ataques SSRF requiere un enfoque de seguridad en capas, combinando validación de entrada, uso de WAFs, actualizaciones regulares, segmentación de red y pruebas de seguridad. Al implementar estas medidas, podemos reducir significativamente el riesgo de que nuestra infraestructura sea comprometida por esta vulnerabilidad. Recuerda que la seguridad es un proceso continuo, y es importante mantenerse actualizado sobre las últimas vulnerabilidades y técnicas de ataque.

Stay safe. Stay smart. Stay secure.