GTSC confirmó que otros sistemas también estaban siendo atacados con esta vulnerabilidad de día cero. Para ayudar a la comunidad a detener temporalmente el ataque antes de que esté disponible un parche oficial de Microsoft, publicaron este artículo dirigido a aquellas organizaciones que utilizan el sistema de correo electrónico de Microsoft Exchange.

 Información de vulnerabilidad

 

Para explotar esta vulnerabilidad se necesita un usuario autenticado. Inicialmente se detectan solicitudes de explotación en los registros de IIS con el mismo formato que la vulnerabilidad de ProxyShell. Incluso a esta vulnerabilidad Kevin Beaumont la está llamando ProxyNOTShell. 

autodiscover/autodiscover.json?@evil.com/&Email=autodiscover/autodiscover.json%3f@evil.com

 Luego, el atacante puede ejecutar comandos en el sistema atacado, acceder a un componente en el backend de Exchange y ejecutar un RCE. Aún NO se han publicado detalles técnicos de la vulnerabilidad. 

Las mitigaciones son similares a ProxyShell

Prevención y mitigación

Como medida temporal (confirmada por Microsoft), y mientras se espera por el parche oficial por parte de Microsoft, se recomienda añadir una regla de bloqueo en el módulo URL Rewrite Rule de IIS.

NOTA: En SO menores a Windows Server 2016, es necesario instalar KB2999226 para que el IIS Rewrite Module 2.1 funcione.

1. En «Autodiscover» en «FrontEnd» seleccione la pestaña «URL Rewrite» y luego «Request Blocking».
2. Agregue la siguiente cadena en «URL Path»: ".*autodiscover\.json.*\@.*Powershell.*" (sin comillas)
3. Actualización 04/10: agregue la siguiente cadena en «URL Path»: ".*autodiscover\.json.*Powershell.*" (sin comillas)
4. En «Condition» cambie {URL} por  {REQUEST_URI}. {UrlDecode:{REQUEST_URI}}
5. En «Using» marcar «Regular Expressions».

La publicación de Microsoft sobre Web Shell Threat Hunting con Microsoft Sentinel también proporciona una guía válida para buscar web shells en general.

• Exchange OAB Virtual Directory Attribute Containing Potential Webshell
• Web Shell Activity
• Malicious web application requests linked with Microsoft Defender for Endpoint alerts
• exchange-iis-worker-dropping-webshell
• Web shell Detection
• Exchange-ProxyShell

Para ayudar a las organizaciones a verificar si sus servidores Exchange ya han sido explotados por este error, GTSC ha publicado una guía y una herramienta para escanear archivos de registro de IIS (almacenados de manera predeterminada en la carpeta %SystemDrive%\inetpub\logs\LogFiles):

Usar powershell:

Get-ChildItem -Recurse -Path  -Filter "*.log" |
    Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200

O, se puede ejecutar la herramienta desarrollada para la detección de esta vulnerabilidad: https://github.com/ncsgroupvn/NCSE0Scanner.

Los clientes de Microsoft Exchange Online no necesitan realizar ninguna acción. Los clientes locales de Microsoft Exchange deben revisar y aplicar las instrucciones de reescritura de URL previas. Microsoft ha publicado un script para aplicar estas mitigaciones contra la vulnerabilidad SSRF CVE-2022-41040. Este script requiere PowerShell 3+ y permisos de Administrador sobre IIS 7.5+.

La empresa también ha confirmado que las instrucciones de reescritura de URL discutidas públicamente pueden romper las cadenas de ataque actuales.

Como medidas de prevención adicionales, la compañía insta a las empresas a aplicar la autenticación multifactor (MFA ), deshabilitar la autenticación heredada y educar a los usuarios sobre cómo no aceptar solicitudes inesperadas de autenticación de dos factores (2FA).

De acuerdo a Shodan (otro), actualmente puede haber más de 200.000 servidores potencialmente expuestos. Se puede realizar la búsqueda como http.component:"outlook web app" y filtrar por ORG:"nombre_empresa" o por SSL:"*nombre*".

Actualización 02/10

• Recomendamos enfáticamente a los clientes de Exchange Server que deshabiliten el acceso remoto a PowerShell para usuarios que no sean administradores en su organización. La guía sobre cómo hacer esto para un solo usuario o múltiples usuarios está aquí.
• Se actualizó la sección detección de las las vulnerabilidades de Exchange CVE-2022-41040 y CVE-2022-41082.
• Germán Fernández (aka @1ZRR4H) ha publicado un script NMAP para la detección de la vulnerabilidades.

El investigador de seguridad Jang en un tweet  muestra que la solución temporal de Microsoft para prevenir la explotación de CVE-2022-41040 y CVE-2022-41082 no es eficiente y se puede eludir con poco esfuerzo. Will Dormann, analista senior de vulnerabilidades de ANALYGENCE, está de acuerdo (video) con el hallazgo y dice que la '@' en el bloque de URL de Microsoft "parece innecesariamente preciso y, por lo tanto, insuficiente". Por eso la cadena original se ha modificado a .*autodiscover\.json.*Powershell.*

Muchas organizaciones tienen una configuración híbrida que combina la implementación local con la nube de Microsoft Exchange y deben comprender que también son vulnerables.

En un video de hoy, el investigador de seguridad Kevin Beaumont advierte que mientras haya una implementación de Exchange Server en las instalaciones, la organización está en riesgo.

Más información:

• Hilo de Kevin Beaumont: https://twitter.com/GossiTheDog/status/1575762721353916417
• Mitigación: https://microsoft.github.io/CSS-Exchange/Security/EOMTv2/
• SSRF: https://github.com/GossiTheDog/ThreatHunting/blob/master/AzureSentinel/Exchange-CVE-2021-34473-SSRF
• RCE: https://github.com/GossiTheDog/ThreatHunting/blob/master/AzureSentinel/Exchange-Powershell-via-SSRF
• https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9
• Informacióin de Microsoft: 1 y 2
• Bleeping Computer
• Reglas Sigma: proc_creation_win_webshell_chopper.yml | file_event_win_exchange_webshell_drop.yml

Fuentes:

https://unaaldia.hispasec.com/2022/10/atacantes-explotan-una-nueva-vulnerabilidad-de-microsoft-exchange.html

https://blog.segu-info.com.ar/2022/09/vulnerabilidad-zero-day-en-exchange.html