¿Culpables los «usuarios cavernícolas»? Microsoft se negó a corregir una RCE en .NET descubierta en Black Ha

Especialistas en seguridad informática informaron sobre una vulnerabilidad en .NET, que puede afectar a numerosos productos corporativos y conducir a la ejecución remota de código. El problema está relacionado con la forma en que las aplicaciones basadas en Microsoft .NET procesan mensajes SOAP, y Microsoft, según los investigadores, se niega a corregirla, trasladando la responsabilidad a desarrolladores y usuarios.

Sobre el hallazgo en la conferencia Black Hat Europe informó Piotr Bazydło de la empresa watchTowr. Según él, una serie de soluciones comerciales e internas son vulnerables a ataques de ejecución remota de código (RCE) debido a errores en el procesamiento de mensajes SOAP en aplicaciones construidas sobre .NET.

El problema clave fue la clase SoapHttpClientProtocol. El investigador explicó que puede ser utilizada por atacantes de diferentes maneras, según sus objetivos. Esta clase hereda de HttpWebClientProtocol, al igual que otros proxies cliente, pero precisamente SoapHttpClientProtocol aparece con más frecuencia en las bases de código, por lo que watchTowr centró su atención en ella.

En teoría todo parece inofensivo: tanto el nombre de la clase como la documentación oficial indican que debe trabajar con mensajes SOAP por HTTP. «Un escenario simple, predecible y seguro», señala irónicamente Bazydło. En la práctica todo es más complejo.

La clase se encarga de establecer la URL objetivo del servicio SOAP y de invocar el método SOAP. La vulnerabilidad surge cuando un atacante puede influir en esa URL y en cómo SoapHttpClientProtocol crea el cliente. Aunque en teoría debería trabajar con solicitudes HTTP, internamente se utiliza un mecanismo genérico que admite varios protocolos a la vez: HTTP/HTTPS, FTP e incluso FILE.

Si un atacante sustituye la dirección web por una URL que apunte al sistema de archivos, la clase no generará un error, sino que simplemente escribirá la solicitud SOAP (enviada por POST) directamente en un archivo. «¿Por qué un proxy SOAP debería "enviar" solicitudes a un archivo local? Nadie en su sano juicio espera obtener una respuesta SOAP válida desde el sistema de archivos», comenta el investigador.

Este comportamiento puede abusarse para la escritura arbitraria de archivos, incluidos los datos XML de la solicitud SOAP. Un escenario menos destructivo, pero también molesto, son los ataques de tipo NTLM relay.

Inicialmente Bazydło informó de este problema a Microsoft a través del programa Zero Day Initiative (ZDI). Según él, la empresa respondió que no corregirían el fallo, porque los desarrolladores no deben permitir el uso de datos de entrada no confiables.

«Predeciblemente, Microsoft consideró esto una "característica", y no una vulnerabilidad, — escribe él. — En la respuesta culparon a los desarrolladores y a los usuarios. Según Microsoft, la URL que se pasa a SoapHttpClientProtocol nunca debería ser controlada por el usuario, y la validación de los datos de entrada es totalmente responsabilidad del desarrollador».

Bazydło añade con sorna que, por supuesto, «todos los desarrolladores descompilan regularmente los ensamblados de .NET Framework y estudian la implementación interna, sabiendo perfectamente que al "proxy cliente HTTP" se le puede convencer de escribir datos en el disco. ¿Y cómo no?».

Un año después, el equipo de watchTowr analizó Barracuda Service Center — «una plataforma RMM de amplio uso» — que, como se descubrió, también es vulnerable a la técnica descrita. Los investigadores encontraron que su API SOAP podía invocarse sin autenticación, y luego encontraron una vía alternativa de explotación — mediante la importación de archivos WSDL (Web Services Description Language).

La esencia es que un atacante puede proporcionar a la aplicación una URL que apunte a un archivo WSDL bajo su control. La aplicación vulnerable, a partir de esa descripción, genera un proxy cliente HTTP, tras lo cual a Bazydło le fue posible lograr la ejecución remota de código de dos maneras: cargando un web shell ASPX en el servidor y colocando la carga útil (un web shell CSHTML o un script de PowerShell) en el espacio de nombres (namespace) del cuerpo de la solicitud SOAP.

Según él, esta técnica con el namespace permitió explotar con éxito Ivanti Endpoint Manager y el CMS Umbraco 8. En el informe de watchTowr esos productos se nombran de forma explícita, pero los investigadores subrayan que la lista real de soluciones afectadas es mucho más amplia.

«Teniendo en cuenta la extensión del uso de .NET y que el día tiene solo 24 horas, nuestra lista de productos afectados debe considerarse más bien una ilustración. Es prácticamente seguro que también son vulnerables muchas otras soluciones comerciales e internas», constata Bazydło.

El equipo informó a Microsoft en julio sobre el segundo vector de explotación, a través de WSDL. La respuesta, según ellos, fue casi la misma que un año antes: la compañía volvió a afirmar que la culpa recae en los usuarios que consumen datos no confiables.

Los investigadores recibieron una reacción similar a los informes posteriores —esta vez sobre productos de la propia Microsoft— en los que se manifestaba el mismo problema. En un comentario oficial la compañía declaró que, aunque se trata del comportamiento de la aplicación, «los usuarios deben evitar consumir datos no confiables que puedan llevar a la generación y ejecución de código».

Bazydło no oculta la ironía: «Primero culpamos a la aplicación. Si eso no sirve —porque implicaría corregir el código de Microsoft— culpamos al usuario. El usuario prehistórico debería haber comprobado manualmente el archivo WSDL y deducido que este puede hacer que las solicitudes SOAP se escriban en archivos en lugar de enviarlas por HTTP. Eh».