XXE Injection Vulnerability
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio “Exploiting XXE Vulnerability to retrieve data by repurposing a local DTD” de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.
ANÁLISIS DE RIESGO
CWE-611 | Improper Restriction of XML External Entity Reference |
IMPACTO | CRÍTICO |
CVSS BASE SCORE | 8.2 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H |
COMPONENTES AFECTADOS | https://LAB-ID.web-security-academy.net/product?productId=number |
EXPLICACIÓN | La vulnerabilidad de entidad XML o “XXE Injection Vulnerability” permite el uso de entidades “ENTITY” del lenguaje XML en la aplicación. Este fallo de seguridad permite incluir archivos locales del sistema y, a su vez, existe la posibilidad de generar un ataque de denegación de servicio (DoS) a través del mismo. |
RECOMENDACIONES
1) Deshabilitar entidades externas: Se recomienda deshabilitar la resolución de entidades externas (como las DTD) y el soporte para XInclude. Esto se puede hacer mediante las opciones de configuración. Por ejemplo en el archivo httpd.conf o .htacces se podría colocar la siguiente línea:
# Deshabilitar la resolución de entidades externas LibXMLDisableEntityLoader On |
Sumado a esto, para el caso de Node.js con Express, se puede configurar la deshabilitación de la resolución de entidades externas en el middleware XML (por ejemplo, body-parser-xml).Por ejemplo:
const express = require(‘express’); const bodyParser = require(‘body-parser’); const xmlParser = require(‘body-parser-xml’); const app = express(); // Deshabilitar la resolución de entidades externas xmlParser(bodyParser, { resolveEntity: false }); app.use(bodyParser.xml()); // Resto de la configuración y rutas del servidor aquí const PORT = 3000; app.listen(PORT, () => { console.log(`Servidor escuchando en el puerto ${PORT}`); }); |
2) Variar Lenguajes: Usar otros lenguajes como “Json” (JavaScript Object Notation) para codificación de datos.
3) Implementar configuraciones de seguridad: Configurar de manera adecuada el WAF (Web Application Firewall) para detectar y bloquear ataques XXE. Por ejemplo se podría utilizar la siguiente regla de Iptables:
# Bloquear tráfico XML externo iptables -A INPUT -p tcp –dport 80 -m string –string «DOCTYPE» –algo bm -j DROP iptables -A OUTPUT -p tcp –dport 80 -m string –string «DOCTYPE» –algo bm -j DROP |
4) Bloquear tráfico por cantidad de conexiones: La idea aquí sería desarrollar una regla, mediante iptables, que bloquee cualquier intento de DOS. Por ejemplo, si un host en Internet establece 85 conexiones contra el puerto 80 de nuestro servidor web, seguramente sea un tipo de ataque, y podemos bloquearlo con algo como esto:
# Bloquear posibles ataque DOS iptables -A INPUT -p tcp -m connlimit –connlimit-above 85 -j REJECT –reject-with tcp-reset |
5) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se procedió a estudiar la forma en la que se transmiten los datos cuando un usuario ingresa a un artículo.
Como se puede observar, el botón “Check stock” permite conocer la cantidad de productos disponibles en dicha ciudad. Por tanto, se procedió a utilizar la herramienta Burpsuit para estudiar más a fondo esta transmisión de datos.
Se pudo comprobar que la aplicación utiliza XML para codificación e intercambio de datos entre sistemas. Por tanto, se procedió a comprobar si vulnerable a un ataque de Entidad externa XXE a través del siguiente código:
<!DOCTYPE test [<!ENTITY xxe SYSTEM «file:///etc/passwd»> ]> <example> %xxe; </example> |
De esta manera, se coloca la entidad “xxe” de forma externa dentro del campo productid para ser ejecutada, y como se puede observar, el mismo devuelve un mensaje de error ya que no reconoce el “id” del producto.
No obstante, se procedió a colocar la entidad dentro del documento de la siguiente manera:
<!DOCTYPE test [<!ENTITY % xxe SYSTEM «file:///etc/passwd»> %xxe; ]> |
De la misma forma se procedió a colocar un archivo inexistente «example-file» para generar otro tipo de error.
Con las dos capturas anteriores, no solo se puede comprobar la existencia del archivo “/etc/passwd”, sino que el mensaje de error del mismo refiere a un problema con la declaración del tipo de documento utilizada (DTD). Por lo tanto, dicha vulnerabilidad existe y se la considera “error-based”.
Teniendo esto en cuenta, a través de la herramienta Burpsuit, se procedió a enumerar diferentes tipos de archivos DTD para saber cuales son válidos en el sistema. Para ello se utilizó archivos perteneciente al repositorio “GoSecure” (el enlace del mismo se encuentra en la sección de Referencias de esta vulnerabilidad).
En la captura anterior se puede observar que se obtuvo un código de estado 200 con 5 archivos específicos. Probando cada uno de ellos, solo se tuvo éxito con el marcado con: /usr/share/yelp/dtd/docbookx.dtd . Esto se puede comprobar ya que, utilizando el siguiente código, se pudo filtrar la información del archivo /etc/passwd.
<!DOCTYPE message [ <!ENTITY % local_dtd SYSTEM «file:///usr/share/yelp/dtd/docbookx.dtd»> <!ENTITY % ISOamso ‘ <!ENTITY % file SYSTEM «file:///etc/passwd»> <!ENTITY % eval «<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>«> %eval; %error; ‘> %local_dtd; ]> |
Cabe mencionar que el archivo docbook.dtd contiene la entidad ISOamso. La cual contiene otras entidades que se utilizarán para el ataque.
A continuación se detalla una breve descripción del código anterior:
Cuando XML analice la sintaxis “ENTITY % local_dtd SYSTEM “file:///usr/share/yelp/dtd/docbookx.dtd” asignará el valor del archivo docbook.dtd a la entidad de la variable local_dtd.
Se vuelca el contenido del archivo /etc/passwd dentro de la entidad variable file. Cabe mencionar que se utiliza “ENTITY % file SYSTEM “file:///etc/passwd” para codificar el caracter %. De esta manera, se busca evitar confusiones durante dicho proceso.
Se procede a generar un error mediante la línea “ENTITY % eval ENTITY % error SYSTEM ‘file:///nonexistent/%file;’”. De esta manera, se busca poder leer el archivo /etc/passwd solicitando dinámicamente la variable %file (file:///nonexistent/%file;).
En resumen, el payload aprovecha las entidades externas y las entidades de parámetros en XML para intentar acceder y exponer el contenido del archivo /etc/passwd. La entidad local_dtd carga un archivo DTD externo, y la entidad ISOamso define una cadena de entidades que, cuando se procesan, acceden al archivo sensible del sistema.
Como se ve en dicha captura, y filtrando la salida con “/bin/bash”, se encontraron los usuarios activos peter, carlos, user, academy y elmer. Sumado a esto, se procedió a incluir el archivo group para conocer los grupos a los que pertenecen los mismos.
De esta forma se pudo comprobar que el usuario academy posee privilegios elevados ya que se encuentra dentro del grupo sudo.
Cabe mencionar que, no solo se puede filtrar información mediante un ataque de entidad externa XML o “XXE Vulnerability”, sino también se puede denegar los servicios de dicha aplicación consumiendo de forma cíclica recursos del CPU.
El siguiente payload es un ejemplo de una variante de ataque conocida como «Billion Laughs Attack» o «XXE Expansion Vulnerability». El mismo utiliza entidades XML para crear una explosión exponencial de texto, que puede agotar la memoria y otros recursos del sistema que procesa el XML, causando un Denial of Service (DoS).
<!DOCTYPE root [ <!ENTITY ha1 “HA!”> <!ENTITY ha2 “&ha1 ; &ha;”> <!ENTITY ha3 “&ha2 ; &ha2;”> <!ENTITY ha4 “&ha3 ; &ha3;”> …. <!ENTITY ha130 “&ha129 ; &ha129;”>]> <root>&ha130;</root> |
Se debe tener en cuenta que el archivo docbook.dtd es una definición de tipo de documento para DocBook, que es un formato XML para documentación técnica. Si el docbook.dtd permite la inclusión y definición de entidades de manera similar, un atacante podría intentar incluir una secuencia de definiciones de entidades que causen una explosión exponencial, o también llamado «XXE Vulnerability via Billion Laughs Attack».
Como conclusión, es posible generar un payload malicioso utilizando docbook.dtd o cualquier otro DTD si no se toman las precauciones adecuadas. Para mitigar este riesgo, es fundamental deshabilitar la expansión de entidades y utilizar parsers XML configurados de manera segura. Como así también realizar las mitigaciones pertinentes explicadas anteriormente.
