Dos vulnerabilidades de Exchange Server se acercan peligrosamente a ProxyShell

Aunque el martes de parches para el 11 de octubre todavía está tomando forma en Microsoft, Exchange podría ser un punto de atención importante ese día, si no antes. Un par de vulnerabilidades web-shell encadenadas que afectan a las versiones 2013, 2016 y 2019 de Exchange Server, con la ayuda del frecuentemente abusado PowerShell, parece ser una combinación de ataque válida. Después de la divulgación pública del exploit por parte de la firma de seguridad GTSC, Microsoft emitió una guía sobre el problema (que describen como limitado y dirigido, pero real) antes de emitir las actualizaciones en su cadencia habitual.

Los clientes de Sophos ya están protegidos. Para complementar las protecciones proactivas en tiempo de ejecución existentes, también hemos lanzado nuevas firmas IPS de red y detecciones antimalware para endpoints: la firma IPS sid:2307757 para Sophos Endpoint IPS y Sophos XG Firewall, así como Troj/WebShel-EC y Troj/WebShel-ED para detectar las “web shells” asociadas a los ataques denunciados. (Consulta el cuadro al final de este artículo para ver la lista completa de actualizaciones). Además, según los informes públicos, la regla de detección de comportamiento Exec_30a fue diseñada para detener el abuso de PowerShell desde IIS, mientras que la regla Lateral_1b bloquea las líneas de comando de descarga certutil, ambas tácticas supuestamente asociadas a estos ataques.

La investigación de Sophos X-Ops ha determinado que Microsoft identifica correctamente este hecho como dirigido a un conjunto específico y reducido de víctimas, hasta el punto  que no encontramos pruebas de estos ataques en nuestra propia base de datos hasta ahora. Sin embargo, el ataque es ahora de conocimiento público, lo que significa que otros atacantes intentarán adoptarlo y utilizarlo. Por lo tanto, aconsejamos a los clientes que sigan los consejos de mitigación proporcionados, y que apliquen el parche de Microsoft tan pronto como esté disponible.

Para ayudar a los administradores, el equipo de Exchange ha publicado un script de PowerShell para aplicar las correcciones sugeridas de forma automática. Para los clientes que tienen habilitado el Servicio de Mitigación de Emergencia de Exchange (EEMS) de la compañía, Microsoft también ha publicado la mitigación de Reescritura de URL para Exchange Server 2016 y Exchange Server 2019, que, según la compañía, se habilitará automáticamente. Por último, Microsoft recomienda a las empresas que deshabiliten los derechos de acceso no administrativos para PowerShell si es posible.

En concreto, Microsoft dice que las dos vulnerabilidades implicadas son CVE-2022-41040, una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF), y CVE-2022-41082, una vulnerabilidad que permite la ejecución remota de código (RCE) cuando PowerShell es accesible para el atacante.

Una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF) puede permitir a un atacante hacer que el servidor vulnerable acceda o manipule información o servicios que el servidor normalmente no debería poder, a través de una URL maliciosa. Por ejemplo, un atacante podría utilizar una vulnerabilidad SSRF para ordenar a un servidor que acceda a un archivo en un servidor web al que normalmente no podría acceder. Es notable que otra vulnerabilidad SSRF de Exchange, CVE-2021-26855, fue el punto de entrada clave para los ataques contra Exchange en 2021. En estos últimos ataques reportados, parece que la nueva vulnerabilidad SSRF, CVE-2022-41040, tiene el mismo propósito: actuar como puerta de entrada para el ataque.

Al igual que el ProxyShell del año pasado, el nuevo ataque parece llevarse a cabo encadenando un exploit contra la vulnerabilidad SSRF con otro que utiliza otra vulnerabilidad. En los ataques del año pasado, la vulnerabilidad SSRF CVE-2021-26855 se encadenó con CVE-2021-26857 para elevar los privilegios, tras lo cual se utilizó CVE-2021-26858 o CVE-2021-27065 para ejecutar código en el sistema. En este caso, la vulnerabilidad SSRF CVE-2022-41040 se encadena con CVE-2022-41082, que, como se ha descrito anteriormente, permite la ejecución remota de código a través de PowerShell si está disponible para el atacante. Curiosamente, esta cadena de ataque en particular no requiere una vulnerabilidad adicional de elevación de privilegios, presumiblemente porque CVE-2022-41082 puede ejecutarse con privilegios de SYSTEM.

Según el informe de GTSC, una vez ejecutada la cadena de ataque de CVE-2022-41040 + CVE-2022-41082, los atacantes utilizan esta cadena para cargar web shells en los sistemas comprometidos, lo que les da el control total del servidor y un punto de apoyo en la red.

Mientras que CVE-2022-41040 requiere que un usuario se autentique, en términos prácticos para muchas instalaciones de Exchange esto es una barrera baja, especialmente aquellas que ejecutan Outlook Web Access (OWA).

La noticia no tan buena, es que los atacantes tienen una ventaja en la utilización, y es posible que Microsoft lo supiera o no. En Twitter, el hilo de Kevin Beaumont en el que se discuten los informes de ataques señala una inmersión en agosto de 2022 en estas vulnerabilidades publicadas por investigadores afiliados a GTSC, que a su vez informaron de los problemas al programa de recompensas por errores ZDI. Los fallos se comunicaron a Microsoft de la forma habitual, pero GTSC, al ver que más clientes de su SOC se veían afectados por el ataque, y sin noticias de un próximo parche, decidió presentar lo que sabía al público en general.

El propio descubrimiento de GTSC se produjo cuando los analistas del SOC detectaron en los registros de IIS solicitudes de exploits con un formato idéntico al de las dejadas por la vulnerabilidad ProxyShell. Desde que surgieron los informes iniciales sobre las dos vulnerabilidades, los servicios de detección y respuesta gestionados de todo el mundo (incluido el propio MTR de Sophos) se han apresurado a comprobar sus registros más de cerca que nunca en busca de rastros de problemas, una de las razones por las que consideramos que la afirmación de Microsoft de que se trata de ataques “limitados y selectivos” puede ser exacta hasta ahora.

En su propia declaración, Microsoft afirma que las correcciones necesarias están en un “calendario acelerado”, lo que normalmente significa que la compañía de Redmond se está apresurando a sacar un parche o parches lo antes posible, quizás antes del lanzamiento programado para el martes de parches del 11 de octubre.

Es posible que, pase lo que pase con estos dos fallos, siga habiendo mucha actividad de intercambio en el recorrido regular de los martes de parches durante los próximos meses. Aunque no recibió ningún parche en septiembre, Exchange vio seis correcciones en agosto (incluyendo dos vulneraciones de elevación de privilegios de clase crítica encontradas por investigadores externos y un día cero de divulgación de información), precisamente la mitad de los 12 parches del producto en lo que va de año. 2021 también fue un año difícil para Exchange Server, hasta el punto de que Microsoft se vio obligado a retrasar el lanzamiento de la próxima versión del producto, prevista para ese año, hasta la segunda mitad de 2025. Este año, el número de vulnerabilidades en Exchange se ha visto empequeñecido por el volumen en Windows (o incluso en Azure), pero Exchange es más difícil de parchear, lo que deja un alto porcentaje de servidores expuestos a los fallos más antiguos (incluido el fallo ProxyShell, que se parcheó a mediados de 2021).

Los sigpacks de XG y SG se han actualizado de la siguiente manera para dar cobertura a las vulnerabilidades de Exchange Server CVE-2022-41040 y CVE-2022-41082: