Blog

¿Qué son y cómo prevenir los ataques XXE?

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.

¿Cómo Hdiv puede ayudarte?

Hdiv Protection RASP se basa en la técnica de instrumentación en tiempo de ejecución descrita en este post para mantener sus aplicaciones seguras y protegidas de los ataques de entidades externas XML. Añadir el agente Hdiv a sus instancias de servidor elimina la necesidad de localizar y configurar manualmente los analizadores XML empaquetados en su aplicación. La protección Hdiv evitará la explotación de las vulnerabilidades XXE, incluyendo los ejemplos citados anteriormente.

La protección Hdiv cubre no sólo su propio código fuente, sino también el código de terceros incluido en su binario (incluso las dependencias proporcionadas como binarios) y también las posibles vulnerabilidades XXE en el marco de desarrollo web que utiliza su aplicación, como Spring MVC o Struts.

Share on facebook
Share on linkedin
Share on twitter
Share on whatsapp

Artículos Relacionados

Protege tus aplicaciones Web y API

Accede a una evaluación completamente funciona

La primera solución completa que cubre los errores de seguridad y fallas de la lógica empresarial en todo el SDLC
Ir al Demo
Alterta Temprana de Riesgos
Reduce tu ventana de exposición al riesgo a las amenazas externas, mejorando la eficiencia en la detección y respuesta ante ciberamenazas.
Más Info
Hdiv - Protege tus aplicaciones Web y API
La primera solución completa que cubre los errores de seguridad y fallas de la lógica empresarial en todo el SDLC
Accede al Demo Gratuito
Protección de Dominios - Sendmarc
Evita y protege activamente los dominios de tu organización contra los ataques de suplantación de identidad y phishing
Más Info
Endpoint - Panda Security
Endpoint Protection Platform, EDR y Servicios de 100% Atestación y Threat Hunting integrado
Más Info

Últimos Artículos

Hablemos

Si tienes alguna duda o pregunta con nuestros servicios, puedes comunicarte directamente con nosotros o completar el formulario, y nos pondremos en contacto contigo en breve.

Email

contacto@cronup.com

Ubicación

Providencia, Santiago de Chile

Twitter

@Cronup_CyberSec

Linkedin

Cronup Ciberseguridad