Microsoft actualizó las mitigaciones para las últimas vulnerabilidades de día cero de Exchange rastreadas como CVE-2022-41040 y CVE-2022-41082, también denominadas ProxyNotShell.
Las recomendaciones iniciales fueron insuficientes ya que los investigadores demostraron que se pueden pasar por alto fácilmente para permitir nuevos ataques que exploten los dos errores.
La segunda mejora aún no fue suficiente, ya que la mitigación propuesta aún podría permitir ataques ProxyNotShell.
Regla de reescritura de URL mejorada
Informado de forma privada a Microsoft hace tres semanas, CVE-2022-41040 es una falsificación de solicitud del lado del servidor (SSRF) que permite la escalada de privilegios y funciona con CVE-2022-41082 para activar la ejecución remota de código en implementaciones de servidor de Exchange en las instalaciones.
Ambos problemas de seguridad vienen con una puntuación de gravedad alta principalmente porque explotarlos requiere autenticación.
Se detectó un actor de amenazas explotando la cadena de errores en agosto para instalar webshells de China Chopper y participar en el reconocimiento de Active Directory y la exfiltración de datos.
El 3 de octubre, Microsoft lanzó mitigaciones para prevenir estos ataques conocidos. Dado que la regla de bloqueo de URL propuesta era demasiado específica, los adversarios aún podrían explotar las vulnerabilidades de Exchange en nuevos ataques.
Múltiples investigadores de seguridad señalaron esto y recomendaron una solución temporal menos restrictiva hasta que los parches estén disponibles.
Microsoft revisó la sugerencia y la adoptó en las mitigaciones actualizadas . A continuación se muestra la principal diferencia entre la recomendación mejorada (verde) y la inicial (roja).
Sin embargo, los investigadores de seguridad descubrieron que la condición ‘ {URL} a {REQUEST_URI} ‘ en la regla de reescritura de URL aún permite a los atacantes eludir la mitigación.
El pirata informático independiente Pieter Hiele notó que la condición para filtrar cadenas en el URI no tenía en cuenta la codificación de caracteres, lo que hace que la regla sea ineficiente:
Will Dormann , exanalista de CERT/CC, confirmó que el bypass de Hiele funciona y explicó que {REQUEST_URI} es inútil cuando los caracteres están codificados.
La mejor variante es {UrlDecode:{REQUEST_URI}} que decodifica la cadena de entrada codificada en URL, lo que permite una coincidencia con un patrón proporcionado, que en este caso es .*autodiscover.json.*Powershell.*
El investigador de seguridad Kevin Beamont, quien nombró a las dos vulnerabilidades ProxyNotShell, señala que es suficiente codificar una letra en el patrón de filtrado para evitar la mitigación mejorada inicial de Microsoft.
Actualización: Microsoft actualizó la mitigación para considerar escenarios codificados en URL y cambió a la condición {UrlDecode:{REQUEST_URI}}.
Beaumont también monitorea los ataques de ProxyNotShell y notó que los actores de amenazas usaron tanto el bypass anterior como el actual para las variantes de mitigación de Microsoft.
Además, la empresa de investigación GreyNoise observó escaneos del sistema vulnerable ProxyNotShell de 24 direcciones IP, 22 de ellas marcadas como maliciosas.
Tres opciones de mitigación
El martes, Microsoft anunció que actualizó sus avisos con la regla de reescritura de URL mejorada, recomendando a los clientes de Exchange Server que la revisen y adopten una de las tres opciones de mitigación proporcionadas.
Los clientes con el Servicio de mitigación de emergencia de Exchange (EEMS) habilitado se benefician automáticamente de la mitigación de reescritura de URL actualizada para Exchange Server 2016 y Exchange Server 2019.
El script EOMTv2 (versión 22.10.03.1829) ahora incluye la mejora de la regla de reescritura de URL. Se actualiza automáticamente en las máquinas conectadas a Internet y debe ejecutarse nuevamente en cualquier Exchange Server sin EEMS habilitado.
La tercera opción es eliminar manualmente la regla creada anteriormente y agregar la mejorada siguiendo las instrucciones a continuación:
- Administrador de IIS abierto
- Seleccionar sitio web predeterminado
- En la Vista de características , haga clic en Reescritura de URL
- En el panel Acciones en el lado derecho, haga clic en Agregar regla(s)…
- Seleccione Solicitar bloqueo y haga clic en Aceptar
- Agregue la cadena “ .*autodiscover.json.*Powershell.* ” (excluyendo las comillas).
- Seleccione Expresión regular en Uso.
- Seleccione Cancelar solicitud en Cómo bloquear y luego haga clic en Aceptar.
- Expanda la regla y seleccione la regla con el patrón: .*autodiscover.json.*Powershell.* y haga clic en Editar en Condiciones.
- Cambie la entrada de condición de {URL} a {UrlDecode:{REQUEST_URI}}
Además, Microsoft recomienda deshabilitar el acceso remoto a PowerShell para usuarios que no sean administradores. La operación debe tomar menos de cinco minutos y la restricción se puede aplicar solo para uno o varios usuarios.
Vale la pena señalar que Microsoft proporciona estas mitigaciones para los clientes con servidores de Exchange en las instalaciones, lo que significa que las empresas con una implementación híbrida también están en riesgo.
Además, las organizaciones que exponen el servidor de Exchange en la web pública enfrentan un mayor riesgo de ataques. Algunos de ellos pertenecen a los sectores gubernamental, financiero y educativo, lo que los convierte en un objetivo atractivo tanto para los piratas informáticos como para los ciberdelincuentes.
