Underc0de - La Casa de los Informáticos

Nuevas investigaciones de seguridad han sacudido el ecosistema empresarial de Microsoft tras revelarse primitivas de explotación inéditas en .NET Framework, capaces de comprometer aplicaciones críticas y permitir ejecución remota de código (RCE). El hallazgo, bautizado como SOAPwn, fue presentado en Black Hat Europe por Piotr Bazydlo, investigador de WatchTowr Labs, y plantea un vector de ataque altamente peligroso debido al amplio uso de .NET en entornos corporativos.

Según WatchTowr, SOAPwn afecta inicialmente a Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM) y Umbraco 8, aunque se estima que la lista de productos vulnerables podría ser considerablemente mayor. Su alcance potencial reside en que la vulnerabilidad se basa en el manejo inseguro de SOAP, WSDL y los proxies HTTP generados dinámicamente, componentes ampliamente utilizados en la arquitectura de servicios empresariales.

¿Qué es SOAPwn y por qué es tan peligrosa?

El núcleo del problema radica en un fallo de manejo de tipos —denominado por los investigadores como la "vulnerabilidad de elenco inválido"— que permite a los atacantes manipular la forma en que las aplicaciones .NET consumen y procesan servicios web basados en SOAP. Esta manipulación abre la puerta a:

• Escritura arbitraria de archivos.
• Sobrescritura de archivos existentes.
• Despliegue de webshells ASPX o CSHTML.
• Ejecución remota de código sin autenticación.
• Relés NTLM mediante rutas UNC controladas por atacantes.

Lo que hace a SOAPwn especialmente preocupante es que no explota un fallo típico de memoria o lógica en el framework, sino que abusa de un comportamiento esperado y permitido por .NET, lo que dificulta su corrección sin afectar la compatibilidad hacia atrás.

El origen del fallo: WSDL, SOAP y los proxies generados dinámicamente

Las aplicaciones .NET que consumen servicios SOAP suelen generar proxies cliente a partir de archivos WSDL (Web Services Description Language). El problema aparece cuando esos WSDL pueden ser controlados por un atacante.

CitarSegún Bazydlo:

"SOAPwn es abusable a través de clientes SOAP, especialmente si se crean dinámicamente a partir de un WSDL controlado por el atacante."

Al manipular el WSDL, los atacantes pueden instruir al proxy generado por .NET para interpretar una URL del tipo:

file://<ruta-controlada-por-el-atacante>


Esto lleva al sistema a tratar rutas de archivos como destinos de solicitudes SOAP, permitiendo que los datos se escriban en cualquier ubicación accesible del sistema. Dado que el atacante controla la ruta completa de escritura, es posible sobrescribir archivos críticos o cargar webshells directamente en el entorno de la aplicación.

Escenario de ataque: del SOAP manipulado al control del sistema

En un ataque realista, un actor malicioso podría:

• Proveer una ruta UNC (por ejemplo, file://attacker.server/poc/poc).
• Hacer que la aplicación realice la solicitud SOAP hacia un recurso SMB del atacante.
• Capturar el desafío NTLM que el cliente envía durante la conexión.
• Descifrar o reutilizar ese desafío para comprometer más infraestructuras.

Esto convierte SOAPwn en un vector apto tanto para ejecución remota de código como para ataques de relay NTLM, dos de las técnicas más empleadas por grupos APT y operadores de ransomware.

Una variante más poderosa: ServiceDescriptionImporter

El equipo de WatchTowr encontró un vector aún más potente en aplicaciones que generan proxies HTTP mediante la clase ServiceDescriptionImporter. Esta clase no valida las URLs utilizadas por el proxy generado, lo que significa que el atacante puede:

• Proporcionar un WSDL malicioso.
• Introducir instrucciones peligrosas directamente en el proceso de generación del proxy.
• Lograr la ejecución de código.
• Subir webshells listos para usar (ASPX, CSHTML).
• Ejecutar scripts PowerShell sin restricciones.

Esta técnica convierte a SOAPwn en un arma totalmente automatizable, capaz de comprometer aplicaciones .NET en las que los desarrolladores no consideraron el riesgo de consumir entradas WSDL controladas externamente.

Microsoft no emitirá parche para .NET Framework

Aunque WatchTowr reportó la vulnerabilidad en marzo de 2024 y nuevamente en julio de 2025, Microsoft decidió no corregirla, argumentando que:

Citar"Los usuarios no deberían consumir entradas no confiables que puedan generar y ejecutar código."

En otras palabras, el gigante tecnológico considera que el problema no reside en .NET, sino en cómo las aplicaciones utilizan SOAP y WSDL, trasladando la mitigación directamente a desarrolladores y proveedores afectados.

Proveedores que ya han corregido SOAPwn

A pesar de la postura de Microsoft, algunos fabricantes sí han abordado el problema:

Barracuda Service Center RMM 2025.1.1

• CVE-2025-34392
• CVSS: 9.8 (Crítico)

Ivanti EPM 2024 SU4 SR1

• CVE-2025-13659
• CVSS: 8.8 (Alta severidad)

Para Umbraco 8 y otros productos basados en .NET que procesan WSDL externos, la recomendación es deshabilitar la creación dinámica de proxies o restringir estrictamente las fuentes WSDL.

Un riesgo sistémico en .NET que trasciende productos específicos

SOAPwn expone una realidad alarmante: comportamientos esperados dentro de .NET pueden convertirse en vectores de explotación críticos cuando interactúan con entradas manipuladas como WSDL. Los ataques derivados pueden resultar en:

• Relés NTLM
• Escritas arbitrarias y sobrescritura de archivos
• Despliegue de webshells persistentes
• Ejecución remota de código crítica

El impacto depende de cómo cada aplicación implemente y consuma proxies SOAP, lo que significa que miles de aplicaciones empresariales podrían estar expuestas sin saberlo.

Fuente: https://thehackernews.com/