Un grupo de investigadores de seguridad ha descubierto una vulnerabilidad en .NET que podría afectar a numerosos productos empresariales, y Microsoft ha indicado que no la corregirá. El aviso se hizo público durante Black Hat Europe, cuando Piotr Bazydło de watchTowr presentó los hallazgos ante la comunidad de seguridad.
El fallo se centra en SoapHttpClientProtocol, una clase de proxy SOAP muy utilizada en entornos .NET. Esta clase se usa para crear clientes SOAP y definir métodos de servicio, pero el problema surge cuando un atacante puede manipular la URL de destino del proxy.
Si la URL apunta a un recurso del sistema de archivos en lugar de una dirección HTTP, el proxy puede escribir la solicitud SOAP en un archivo, lo que abre la puerta a diversos ataques como escritura de archivos o incluso NTLM relay en ciertas condiciones.
En un análisis publicado por watchTowr, Bazydło indicó que la vulnerabilidad permite cargar un WSDL malicioso para generar proxies HTTP y ejecutar código remoto. El atacante puede colocar archivos ASPX webshell o payloads como PowerShell scripts a través del espacio de nombres del cuerpo SOAP, y utilizarlos para entregar código en los sistemas vulnerables.
watchTowr señaló varios productos que ya figuran como afectados, entre ellos Ivanti Endpoint Manager y Barracuda Service Center. Sin embargo, el equipo reconoció que la lista es anecdótica y que podrían existir muchos más productos en riesgo.
Microsoft respondió que los desarrolladores deben validar inputs y que en teoría este comportamiento debería considerarse una característica, no una vulnerabilidad. Algunos informes señalan que la respuesta de Microsoft terminó culpando a los usuarios y a la propia implementación de .NET, en lugar de corregir el fallo.
Como respuesta de seguridad, los investigadores presentaron el caso a través del Zero Day Initiative y luego comunicaron a Microsoft en múltiples ocasiones. Aunque el issue se relaciona con el comportamiento de la aplicación, la recomendación general es evitar inputs no confiables que puedan generar código, revisar la configuración de proxies SOAP y evitar exponer servicios SOAP a datos controlados por usuarios.
Conclusión: el incidente expone una tensión entre herramientas críticas y la responsabilidad de desarrollo. A día de hoy, la llamada a la acción es revisar configuraciones de SOAP, vigilar el uso de WSDL externos, aplicar parches cuando aparezcan y, de forma general, practicar defensas en profundidad para evitar que vulnerabilidades de este tipo se conviertan en vectores de ataque.
