Una nueva investigación ha descubierto primitivas de explotación en .NET Framework que podrían aprovecharse en aplicaciones de nivel empresarial para lograr la ejecución remota de código.
WatchTowr Labs, que ha denominado en código «vulnerabilidad de conversión no válida» SOAPwn, dicho el problema afecta a Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM) y Umbraco 8. Pero es probable que el número de proveedores afectados sea mayor dado el uso generalizado de .NET.
Los hallazgos fueron presentado hoy por el investigador de seguridad de WatchTowr, Piotr Bazydlo, en la conferencia de seguridad Black Hat Europe, que se celebra en Londres.
Básicamente, SOAPwn permite a los atacantes abusar de las importaciones del lenguaje de descripción de servicios web (WSDL) y de los servidores proxy de clientes HTTP para ejecutar código arbitrario en productos creados sobre la base de .NET debido a errores en la forma en que manejan el protocolo simple de acceso a objetos (JABÓN) mensajes.
«Por lo general, se puede abusar de él a través de clientes SOAP, especialmente si se crean dinámicamente a partir del WSDL controlado por el atacante», dijo Bazydlo.
Como resultado, .NET Framework servidores proxy de cliente HTTP se puede manipular para utilizar controladores del sistema de archivos y lograr una escritura de archivos arbitraria pasando como URL algo como «archivo://
En un escenario de ataque hipotético, un actor de amenazas podría aprovechar este comportamiento para proporcionar una convención de nomenclatura universal (UNC) ruta (por ejemplo, «archivo://attacker.server/poc/poc») y hacer que la solicitud SOAP se escriba en un recurso compartido SMB bajo su control. Esto, a su vez, puede permitir a un atacante capturar el desafío NTLM y descifrarlo.
Eso no es todo. La investigación también encontró que se puede utilizar un vector de explotación más poderoso como arma en aplicaciones que generan servidores proxy de cliente HTTP a partir de archivos WSDL utilizando el ServicioDescripciónImportador clase aprovechando el hecho de que no valida la URL utilizada por el proxy del cliente HTTP generado.
En esta técnica, un atacante puede proporcionar una URL que apunte a un archivo WSDL que controla para aplicaciones vulnerables y obtener la ejecución remota de código colocando un shell web ASPX completamente funcional o cargas útiles adicionales como shells web CSHTML o scripts de PowerShell.
Tras la divulgación responsable en marzo de 2024 y julio de 2025, Microsoft optó por no solucionar la vulnerabilidad, afirmando que el problema se debe a un problema o comportamiento de la aplicación, y que «los usuarios no deben consumir entradas que no sean de confianza y que puedan generar y ejecutar código».
Los hallazgos ilustran cómo el comportamiento esperado en un marco popular puede convertirse en una ruta potencial de explotación que conduzca a la retransmisión NTLM o escrituras arbitrarias de archivos. Desde entonces, el problema se ha abordado en el Centro de Servicio Barracuda RMM. versión 2025.1.1 (CVE-2025-34392puntuación CVSS: 9,8) e Ivanti EPM versión 2024 SU4 SR1 (CVE-2025-13659puntuación CVSS: 8,8).
«Es posible hacer que los servidores proxy SOAP escriban solicitudes SOAP en archivos en lugar de enviarlos a través de HTTP», dijo Bazydlo. «En muchos casos, esto conduce a la ejecución remota de código a través de cargas de webshell o cargas de scripts de PowerShell. El impacto exacto depende de la aplicación que utiliza las clases de proxy».
Fuente