Microsoft ha confirmado que dos nuevas vulnerabilidades de día cero en Microsoft Exchange Server (CVE-2022-41040 y CVE-2022-41082) están siendo explotadas en «ataques dirigidos limitados». En ausencia de un parche oficial, las organizaciones deben verificar sus entornos en busca de signos de explotación y luego aplicar los pasos de mitigación de emergencia.
- CVE-2022-41040: falsificación de solicitudes del lado del servidor, lo que permite a los atacantes autenticados realizar solicitudes haciéndose pasar por la máquina afectada
- CVE-2022-41082: ejecución remota de código, que permite a los atacantes autenticados ejecutar PowerShell arbitrario.
«Actualmente, no se conocen scripts de prueba de concepto o herramientas de explotación disponibles en la naturaleza», escribió John Hammond, un cazador de amenazas de Huntress. Sin embargo, eso solo significa que el tiempo corre. Con un enfoque renovado en la vulnerabilidad, es solo cuestión de tiempo antes de que estén disponibles nuevos exploits o scripts de prueba de concepto.
Pasos para detectar la explotación
La primera vulnerabilidad, la falla de falsificación de solicitud del lado del servidor, se puede usar para lograr la segunda, la vulnerabilidad de ejecución remota de código, pero el vector de ataque requiere que el adversario ya esté autenticado en el servidor.
Según GTSC, las organizaciones pueden verificar si sus servidores Exchange ya han sido explotados ejecutando el siguiente comando de PowerShell:
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter «*.log» | Select-String -Pattern ‘powershell.*Autodiscover.json.*@.*200
GTSC también desarrolló una herramienta para buscar signos de explotación y la lanzó en GitHub. Esta lista se actualizará a medida que otras empresas lancen sus herramientas.
Herramientas específicas de Microsoft
- Según Microsoft, hay consultas en Microsoft Sentinel que podrían usarse para buscar esta amenaza específica. Una de estas consultas es la detección ProxyShell de detección automática de SSRF de Exchange, que se creó en respuesta a ProxyShell. La nueva consulta Descargas de archivos sospechosos de Exchange Server busca específicamente descargas sospechosas en los registros de IIS.
- Las alertas de Microsoft Defender para Endpoint con respecto a la posible instalación de shell web, posible shell web de IIS, ejecución de proceso de Exchange sospechosa, posible explotación de vulnerabilidades de Exchange Server, procesos sospechosos que indican un shell web y posible compromiso de IIS también pueden ser señales de que Exchange Server ha sido comprometida a través de las dos vulnerabilidades.
- Microsoft Defender detectará los intentos posteriores a la explotación como Puerta trasera: ASP/Webshell.Y y Puerta trasera: Win32/RewriteHttp.A.
Varios proveedores de seguridad también han anunciado actualizaciones de sus productos para detectar la explotación.
Huntress dijo que monitorea aproximadamente 4.500 servidores de Exchange y actualmente está investigando esos servidores en busca de posibles signos de explotación en estos servidores. «Por el momento, Huntress no ha visto signos de explotación o indicadores de compromiso en los dispositivos de nuestros socios», escribió Hammond.
Pasos de mitigación a tomar
Microsoft prometió que está acelerando una solución. Hasta entonces, las organizaciones deben aplicar las siguientes mitigaciones a Exchange Server para proteger sus redes.
Según Microsoft, los clientes locales de Microsoft Exchange deben aplicar nuevas reglas a través del módulo Regla de reescritura de URL en el servidor IIS.
- En el Administrador de IIS -> Sitio web predeterminado -> Detección automática -> Reescritura de URL -> Acciones, seleccione Solicitar bloqueo y agregue la siguiente cadena a la ruta de URL:
.*autodiscover.json.*@.*Powershell.*
La entrada de condición debe establecerse en {REQUEST_URI}
- Bloquee los puertos 5985 (HTTP) y 5986 (HTTPS) ya que se usan para Remote PowerShell.
Si está utilizando Exchange Online:
Microsoft dijo que los clientes de Exchange Online no se ven afectados y no necesitan tomar ninguna medida. Sin embargo, es probable que las organizaciones que usan Exchange Online tengan entornos de Exchange híbridos, con una combinación de sistemas locales y en la nube. Deben seguir la guía anterior para proteger los servidores locales.