Los ataques de inyección de entidades XML externas (o también conocidos como ataques XXE) son uno de los problemas de seguridad más comunes en aplicaciones web, APIs y microservicio. Aunque la familia de vulnerabilidades XXE no es tan popular como lo es la inyección SQL y/o los ataques XSS, está presente en el ranking TOP 10 OWASP, en la apartado 2017:A4 de la lista.
La esencia de este riesgo está en una mala configuración en los endpoints del servidor que aceptan XML como entrada de clientes no confiables, particularmente cuando el cliente puede proporcionar una definición de documento personalizada (DTD). Los atacantes abusan de este aspecto para inyectar cargas útiles XML personalizadas para extraer datos, construir una falsificación de petición del lado del servidor (SSRF) o impulsar un intento de denegación de servicio (DoS). Con frecuencia, las vulnerabilidades de entidades externas XML se esconden como una dependencia en el código de terceros.
¿Qué son los ataques XXE?
Las vulnerabilidades de entidades externas XML afectan a los servicios que se basan en XML, como formato de mensajería, en contraposición al formato web clásico basado en HTML legible por humanos.
Una vulnerabilidad de entidad externa XML se produce cuando el servicio que analiza (o en palabras más sencillas, lee y procesa) los mensajes XML enviados por el cliente, acepta una definición externa del propio mensaje XML. Esta definición del mensaje, conocida como DTD externa, permite una extraordinaria flexibilidad para que el emisor y el receptor puedan acordar nuevos formatos de mensaje durante el tiempo de ejecución. El DTD externo está diseñado para ser utilizado cuando ambas partes son de confianza.
Sin embargo, si se permite a los clientes que no son de confianza proporcionar su propio DTD personalizado, pueden explotar esta flexibilidad y preparar peticiones que se salten los controles del servidor en última instancia, dando lugar a graves infracciones como:
- Problemas de confidencialidad: por ejemplo, el acceso al sistema de archivos del servidor.
- Problemas de integridad: ejecución de código externo inyectado como parte del ataque.
- Problemas de disponibilidad: Ataques DoS como Billion Laughs.
Como resultado de la popularidad de los formatos de comunicación basados en XML, el impacto de las vulnerabilidades XXE ha ido aumentando constantemente. Una simple búsqueda del término «xxe» en la base de datos Common Vulnerabilities and Exposures (CVE) devuelve más de 500 vulnerabilidades distintas que implican este riesgo.
Los equipos de desarrolladores no son conscientes de que sus propias de que aplicaciones incluyen funciones de procesamiento XML, esto ocurre porque una de las fuentes de este riesgo está oculta en el código de terceros que incluye funciones de procesamiento XML. Este código de terceros puede ser de código abierto, incluyendo marcos de desarrollo web (Spring, Struts, etc) y/o paquetes compilados internos auxiliares. Las dependencias de procesamiento XML pueden estar profundamente anidadas bajo dos o más niveles en la jerarquía, lo que hace muy difícil su identificación manual.
Ejemplos de un ataque XXE
La estructura básica implica la redefinición de una entidad XML. El siguiente es un ejemplo:
En el código anterior corresponde a un documento XML que responde a una entidad personalizada llamada «mensaje» que puede ser referenciada en el cuerpo utilizando la sintaxis «&message», que efectivamente inserta un «Hola Mundo».
Este enfoque básico puede organizarse de diferentes maneras, dando lugar a cada uno de los tres tipos de violaciones principales mencionados anteriormente.
En el caso de acceder a un archivo privado del servidor (una violación de la confidencialidad) el ataque se ve así:
En el caso de la ejecución externa, como el monitoreo de los recursos de la red local, sigue el ataque correspondiente:
Para realizar un ataque DoS, uno puede simplemente construir una jerarquía compleja basada en el ejemplo inicial, lo que resulta en un tiempo de procesamiento exponencial:
El ejemplo anterior es una variante del popular ataque «Billion Laughs». En este ejemplo se puede observar que una vez completada la definición de la entidad para definir las 128 entidades «ha», la ejecución del documento produciría 2^128 impresiones del mensaje «¡Ha!». Unas pocas de estas peticiones concurrentes, o incluso una sola, pueden hacer caer fácilmente un servidor.
¿Cómo evitar los ataques XXE?
Prevención manual de XXE:
Para evitar una vulnerabilidad de entidad externa XML, los equipos deben configurar sus analizadores XML para que no acepten definiciones de documentos personalizados (DTD). Hay muy pocos casos en los que una aplicación requiere realmente un DTD personalizado, por lo que la compensación de funcionalidad es pequeña. Sin embargo, la dificultad radica en que cada analizador sintáctico, en cada lenguaje de programación, tiene su propia forma de establecer este parámetro de configuración. Por lo tanto, si un proyecto incluye múltiples parsers, cada parser tendrá que ser configurado adecuada y manualmente.
Generalmente, utilizando las características de definición del proyecto XML de Apache, la configuración debería ser algo así:
Y de nuevo, cada análisis tendrá diferentes nombres y características, lo que significa que se debe revisar la documentación pertinente. Esta hoja de trucos OWASP XXE es un buen lugar para empezar.
Detección de vulnerabilidades XXE:
Las herramientas estáticas de seguridad de aplicaciones (SAST) se utilizan a menudo para detectar las vulnerabilidades XXE. Sin embargo, este enfoque no es el ideal porque las vulnerabilidades XXE no siguen un patrón claro, lo que dificulta que las herramientas SAST señalen correctamente las vulnerabilidades reales, dando lugar a falsos positivos.
A menudo vemos un enfoque basado en marcar todos los analizadores XML en el código, pero con este enfoque no hay una manera fácil para que la herramienta encuentre específicamente las instancias mal configuradas y las distinga. Como resultado, será necesario un proceso de revisión manual del código, lo que abre la puerta al error humano.
Las herramientas de comprobación dinámica de la seguridad de las aplicaciones (DAST, por sus siglas en inglés) sondean las aplicaciones enviando cargas útiles y comprobando los resultados del ataque. Las DAST son capaces de identificar algunas vulnerabilidades XXE, pero como requisito deben ser capaces de identificar todos los puntos finales expuestos. A medida que las API se vuelven más dinámicas y evolucionan gradualmente con el tiempo, resulta cada vez más difícil hacer un seguimiento de todas ellas.
Los WAF son fáciles de eludir:
Las defensas externas como los cortafuegos de aplicaciones web (WAF) tienen dificultades para detener los ataques de entidades externas XML. Los múltiples niveles de codificación atípica, como UTF-16 y UTF-32, además del cifrado, dificultan enormemente la visibilidad del tráfico por parte de los WAF.
Además, los WAFs tendrían que analizar y reconstruir completamente las cargas útiles para identificar los ataques XXE, lo que tiene importantes implicaciones en el rendimiento, y en sí mismo, constituye la base de una vulnerabilidad DoS.
Cómo la instrumentación evita los ataques de entidades externas XML (XXE)
La instrumentación del servidor de aplicaciones es una técnica utilizada para insertar puntos de control en determinadas partes del código para supervisar el flujo de ejecución durante el tiempo de ejecución. Añadir sensores de seguridad instrumentados a su servidor proporciona una excelente visibilidad en tiempo real de la arquitectura de la aplicación y de los datos de cada solicitud. Las categorías de productos RASP e IAST aprovechan la instrumentación del código para resolver los problemas de seguridad de las aplicaciones con facilidad.
La instrumentación es muy valiosa para prevenir los ataques XXE, ya que permite la supervisión automática de ciertas clases clave relacionadas con todo el procesamiento XML y valida cualquier actividad relativa a los DTD externos. Como hemos descrito anteriormente, los parsers XML pueden formar parte de código de terceros en su aplicación. Es muy fácil pasar por alto algunos de los parsers y endpoints en su aplicación haciendo que un proceso de configuración manual sea inherentemente peligroso. La instrumentación elimina este proceso de verificación manual automatizando la prevención de ataques de entidades externas XML.
La instrumentación también garantiza la contención de algunos de los exploits más perniciosos. Por ejemplo, la instrumentación puede prevenir la ejecución de código externo limitando el tiempo de ejecución de una solicitud concreta, lo que resulta en una reducción significativa de los ataques DoS como Billion Laughs.
Ingeniero en Ciberseguridad por la Universidad Tecnológica de Chile, Speaker, Analista de Ciberinteligencia, Investigador y Redactor para CronUp Ciberseguridad.
