Microsoft recomienda estas formas de mitigar las vulnerabilidades de día cero de Exchange de ProxyNotShell

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 las dos vulnerabilidades.

Desafortunadamente, las recomendaciones actuales aún no son suficientes y la mitigación propuesta aún puede 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.

Ambas vulnerabilidades 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 vulnerabilidades 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).

Mejora del patrón de URL para mitigar la
fuente de explotación de ProxyNotShell

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 hacker 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 usar  {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 de Microsoft.

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.

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.

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.