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