Ataque de Billion Laughs: El XML que Derriba Servidores

Cómo un pequeño archivo XML de menos de 1 KB puede consumir gigabytes de memoria y hacer fallar tus servidores mediante expansión exponencial de entidades.

Introducción: Cuando la Risa se Convierte en Arma

En el mundo de la ciberseguridad, algunos de los ataques más devastadores provienen de los lugares más inesperados. El ataque de Billion Laughs —también conocido como bomba XML o ataque de expansión exponencial de entidades— es un ejemplo perfecto de cómo un documento XML aparentemente inofensivo puede derribar servidores empresariales. Este ataque de denegación de servicio (DoS) explota una característica fundamental de los analizadores XML, convirtiendo su útil capacidad de expansión de entidades en un arma destructiva.

Primero reportado en 2002 y con atención generalizada en 2008, esta vulnerabilidad sigue afectando aplicaciones modernas. CVEs recientes en 2024 y 2025, incluyendo vulnerabilidades en las librerías LangChain (CVE-2024-1455) y analizadores de sitemap (CVE-2025-3225), demuestran que este vector de ataque sigue siendo relevante más de dos décadas después de su descubrimiento.

Entendiendo las Entidades XML y DTDs

Antes de profundizar en la mecánica del ataque, es esencial entender cómo funcionan las entidades XML. XML (Lenguaje de Marcado Extensible) permite a los desarrolladores definir entidades—piezas reutilizables de contenido—dentro de una Definición de Tipo de Documento (DTD). Estas entidades actúan como variables o constantes que pueden ser referenciadas en todo un documento XML.

Existen dos tipos de DTDs:

DTD Interno: Definido directamente dentro del documento XML, incrustado entre la declaración c!DOCTYPEe y el corchete de cierre.

DTD Externo: Declarado en un archivo separado y enlazado al documento XML mediante una referencia URI.

Las entidades cumplen funciones legítimas, como definir cadenas de texto frecuentes o referenciar archivos externos. Sin embargo, esta flexibilidad crea una superficie de ataque peligrosa cuando se combina con definiciones recursivas de entidades.

La Anatomía de un Ataque de Billion Laughs

El payload clásico de Billion Laughs es elegantemente destructivo en su simplicidad. Aquí la estructura del ataque:

c?xml version="1.0"?e
c!DOCTYPE lolz [
  c!ENTITY lol "lol"e
  c!ELEMENT lolz (#PCDATA)e
  c!ENTITY lol1 "6lol;6lol;6lol;6lol;6lol;6lol;6lol;6lol;6lol;6lol;6lol;"e
  c!ENTITY lol2 "6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;6lol1;"e
  c!ENTITY lol3 "6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;6lol2;"e
  c!ENTITY lol4 "6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;6lol3;"e
  c!ENTITY lol5 "6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;6lol4;"e
  c!ENTITY lol6 "6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;6lol5;"e
  c!ENTITY lol7 "6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;6lol6;"e
  c!ENTITY lol8 "6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;6lol7;"e
  c!ENTITY lol9 "6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;6lol8;"e
]e
clolze6lol9;c/lolze

Cómo Funciona la Expansión Exponencial

El ataque define 10 entidades, desde lol hasta lol9. La primera entidad simplemente contiene la cadena “lol.” Cada entidad subsiguiente referencia la anterior diez veces. Cuando un analizador XML procesa este documento, encuentra 6lol9; en el cuerpo del documento.

Aquí es donde las matemáticas se vuelven aterradoras:

• 6lol9; se expande a 10 instancias de 6lol8;
• Cada 6lol8; se expande a 10 instancias de 6lol7;
• Esto continúa recursivamente hasta 6lol;

¿El resultado? Un documento que contiene 10^9 (mil millones) de copias de la cadena “lol.” Este pequeño archivo XML—menos de 1 kilobyte—se expande a aproximadamente 3 gigabytes en memoria. El nombre “Billion Laughs” proviene directamente de esta repetición milmillonaria de “lol.”.

La Variante de Explosión Cuadrática

Investigadores de seguridad y atacantes han desarrollado variantes para evadir las contramedidas defensivas. La variante de explosión cuadrática adopta un enfoque diferente que evade la detección de entidades profundamente anidadas.

En lugar de usar anidamiento recursivo, esta variante define una sola entidad grande que contiene miles de caracteres, y luego referencia esa entidad miles de veces. Una carga útil de aproximadamente 200 KB puede expandirse a 2.5 GB al analizarse. Este método evita activar las contramedidas del analizador que verifican estructuras de entidades profundamente anidadas.

Impacto en el Mundo Real e Incidentes Históricos

Vulnerabilidad en WordPress y Drupal (2014)

Uno de los incidentes más importantes ocurrió en 2014, cuando millones de instalaciones de WordPress y Drupal fueron vulnerables a ataques de explosión cuadrática XML. La vulnerabilidad en el procesador XML de PHP, utilizado por implementaciones XMLRPC, permitía a los atacantes causar agotamiento de CPU y memoria, pudiendo dejar sitios fuera de línea y sobrecargar bases de datos con solicitudes de conexión.

Vulnerabilidades en MediaWiki (2015)

Versiones de MediaWiki anteriores a 1.24.2 eran susceptibles a ataques de Billion Laughs mediante cargas SVG y análisis de metadatos XMP, demostrando cómo el ataque puede propagarse a través de cargas de archivos aparentemente inocentes.

Vulnerabilidades en Frameworks de IA Modernos (2024-2025)

Incluso tecnologías de vanguardia siguen siendo vulnerables. CVE-2024-1455 afectó a la popular librería LangChain para IA, donde el análisis XML en ciertos componentes podía ser explotado para ataques de Billion Laughs. Esto resalta cómo la vulnerabilidad trasciende las aplicaciones web tradicionales y afecta infraestructuras modernas de IA.

Más Allá del XML: Vectores de Ataque en Otros Formatos

Aunque originalmente dirigido a XML, el concepto de Billion Laughs aplica a cualquier formato que soporte macro o expansión de entidades.

Analizadores YAML

Los analizadores YAML enfrentan riesgos similares mediante anclajes (6) y alias (*), que permiten referencias recursivas causando expansión exponencial de datos durante la deserialización. La librería PyYAML, por ejemplo, tiene vulnerabilidades documentadas relacionadas con este patrón de ataque.

Metadatos en SVG e Imágenes

Los archivos SVG, al ser basados en XML, pueden portar cargas de Billion Laughs. De manera similar, los metadatos XMP en formatos como PDF o JPEG pueden contener bombas XML que explotan la extracción de metadatos.

Consideraciones sobre JSON

Aunque JSON no soporta entidades nativas, ataques de denegación de servicio análogos ocurren mediante estructuras profundamente anidadas o recursivas. La librería Jackson en Java, por ejemplo, sufrió CVE-2020-36518, donde la anidación ilimitada provocaba excepciones de desbordamiento de pila.

Escenarios Comunes de Ataque

Los atacantes pueden entregar cargas de Billion Laughs a través de múltiples vectores:

Solicitudes POST en Aplicaciones Web: Enviando XML malicioso directamente a endpoints que aceptan entrada XML, como servicios SOAP o APIs REST.

Cargas de Archivos: Subiendo imágenes SVG, documentos Office (DOCX, XLSX) u otros archivos que contienen XML y activan el análisis en el servidor.

Mensajes SOAP: Los servicios web empresariales que usan SOAP son particularmente vulnerables al procesar cargas XML no confiables.

Archivos de Configuración: Aplicaciones que aceptan archivos de configuración XML de usuarios pueden procesar entidades maliciosas inadvertidamente.

Estrategias de Prevención y Mitigación

Proteger las aplicaciones contra ataques de Billion Laughs requiere un enfoque de defensa en múltiples capas.

1. Desactivar el Procesamiento de DTD Completamente

La defensa más efectiva es desactivar completamente el procesamiento de DTD (Definición de Tipo de Documento). Cuando los DTDs están deshabilitados, casi todos los ataques de entidades XML se vuelven imposibles. Según las directrices de OWASP, esta debe ser la principal medida de defensa.

2. Limitar la Expansión de Entidades

Si no se puede desactivar el procesamiento de DTD, configura límites estrictos en la expansión de entidades. Para aplicaciones en .NET, la propiedad MaxCharactersFromEntities restringe cuánto puede expandirse el contenido de las entidades. En Java, se puede usar XMLConstants.FEATURE_SECURE_PROCESSING para habilitar restricciones de seguridad.

3. Usar Configuraciones Seguras del Analizador

Diferentes lenguajes de programación requieren configuraciones específicas:

Java: Establece la característica http://apache.org/xml/features/disallow-doctype-decl en DocumentBuilderFactory o SAXParserFactory.

Python: Usa la librería defusedxml o configura los analizadores con resolve_entities=False.

PHP: En versiones anteriores a 8.0, deshabilita explícitamente la carga de entidades externas. PHP 8.0 y versiones posteriores previenen XXE por defecto.

.NET: Las versiones 4.5.2 y posteriores incluyen protecciones integradas, pero las versiones antiguas requieren configurar explícitamente DtdProcessing a Prohibit o Ignore.

4. Implementar Expansión Perezosa de Entidades

En lugar de expandir todas las entidades inmediatamente, configura los analizadores para expandir solo cuando y en la medida en que su contenido sea realmente necesario. Esto limita el impacto de la expansión exponencial.

5. Considerar Formatos Alternativos

JSON se ha convertido en la alternativa preferida a XML para el intercambio de datos en muchos escenarios. Dado que JSON no soporta referencias a entidades externas ni expansión de entidades, elimina toda esta clase de vulnerabilidades.

6. Validación y Sanitización de Entrada

Antes de procesar cualquier entrada XML, valida y sanitiza el contenido. Bloquea o escapa metacaracteres XML como c, e, ", y 6 cuando aparecen en contenido proporcionado por el usuario que será insertado en documentos XML.

Pruebas de Vulnerabilidades

Los equipos de seguridad deben probar regularmente las aplicaciones en busca de vulnerabilidades de bombas XML usando herramientas como:

• OWASP ZAP: Incluye verificaciones para vulnerabilidades de expansión exponencial de entidades
• Burp Suite: Puede inyectar cargas XML maliciosas para probar el comportamiento del analizador
• Nikto: Identifica vulnerabilidades XXE y relacionadas en aplicaciones web

Técnicas de fuzzing que inyectan entidades maliciosas en cargas XML pueden revelar debilidades del analizador antes de que los atacantes las exploten.

Guía Específica por Framework

Framework .NET

Las aplicaciones que usan .NET Framework 4.5.1 y anteriores son vulnerables por defecto. Las clases XmlDocument, XPathNavigator, y XMLReader requieren configuración explícita para desactivar DTD:

XmlReaderSettings settings = new XmlReaderSettings()
{
    DtdProcessing = DtdProcessing.Prohibit,
    MaxCharactersFromEntities = 1024
};

Aplicaciones Java

Las aplicaciones Java deben configurar las fábricas de analizadores para prohibir declaraciones doctype:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setXIncludeAware(false);

Aplicaciones Python

Los módulos XML de la biblioteca estándar tienen diferentes niveles de vulnerabilidad. La documentación oficial de Python recomienda usar defusedxml para procesar XML no confiable.

Conclusión: Una Vulnerabilidad Persistente

El ataque de Billion Laughs representa una intersección fascinante entre ingeniería inteligente e impacto devastador. Un concepto documentado hace más de dos décadas sigue afectando aplicaciones modernas, desde sistemas de gestión de contenido hasta frameworks de IA de vanguardia.

La persistencia de esta vulnerabilidad subraya varias lecciones importantes para la comunidad de seguridad. Primero, fallos de diseño fundamentales en tecnologías ampliamente usadas pueden tener vidas útiles sorprendentemente largas. Segundo, la seguridad debe integrarse en las configuraciones del analizador por defecto, no dejarse a la suerte de los desarrolladores. Tercero, incluso las vulnerabilidades bien entendidas requieren vigilancia constante a medida que aparecen en nuevos contextos y tecnologías.

Para desarrolladores y profesionales de seguridad, el camino a seguir es claro: desactivar el procesamiento de DTD donde sea posible, implementar límites estrictos en la expansión de entidades cuando los DTD sean necesarios, auditar regularmente las aplicaciones en busca de vulnerabilidades en el análisis XML, y considerar migrar a formatos de datos más seguros donde las características de XML no sean esenciales.

El ataque de Billion Laughs puede tener un nombre humorístico, pero no hay nada gracioso en un servidor de producción caído. Comprendiendo la mecánica de este ataque e implementando defensas adecuadas, las organizaciones pueden asegurarse de que la última risa sea para ellas, no para los atacantes.