El 28 de septiembre de 2022, la empresa de ciberseguridad GTSC publicó un blog que detalla un intento de explotación en un sistema que estaban monitoreando . Después del análisis, pudieron localizar y enviar dos errores a Microsoft a través de Zero Day Initiative (ZDI-CAN-18333 (CVSS 8.8) y ZDI-CAN-18802 (CVSS 6.3)). Microsoft validó los hallazgos y se asignaron CVE-2022-41040 y CVE-2022-41082 a las vulnerabilidades.

CVE-2022-41040 es una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF) y CVE-2022-41082 permite la ejecución remota de código (RCE) donde PowerShell está disponible.

Este blog describe lo que necesita saber acerca de estas vulnerabilidades.

Plataformas afectadas: Microsoft Exchange Server 2013, 2016 y 2019 en
las instalaciones Usuarios afectados: cualquier organización que utilice una versión vulnerable de Microsoft Exchange
Impacto: los atacantes remotos obtienen el control de los sistemas vulnerables
Nivel de gravedad: alto

¿Qué es Microsoft Exchange?

Exchange es el servidor de calendario y correo electrónico de Microsoft. Lanzado por primera vez en 1996 (como Exchange 4.0), su versión más reciente es Exchange 2019. Está disponible para su instalación local o en línea mediante un modelo de software como servicio (SaaS).

¿Qué versiones de Microsoft Exchange son vulnerables?

• Microsoft Exchange Server 2013 local
• Microsoft Exchange Server 2016 local
• Microsoft Exchange Server 2019 local

¿Cómo se explotan las vulnerabilidades?

Parece que las medidas utilizadas para resolver las vulnerabilidades de ProxyShell (un nombre colectivo para tres vulnerabilidades de Microsoft Exchange relacionadas: CVE-2021-34473, CVE-2021-34523 y CVE-2021-31207) no fueron del todo exitosas.

Al igual que con esa colección, estas nuevas vulnerabilidades deben estar encadenadas para que funcionen. CVE-2022-41040 se puede explotar mediante una consulta GET de forma muy parecida a ProxyShell.

Por ejemplo:

OBTENER autodiscover/autodiscover.json?@evilinc.com/<Exchange-backend-
endpoint>&Email=autodiscover/autodiscover.json%3f@evilinc.com

La principal diferencia entre los dos conjuntos de vulnerabilidades es que se necesita acceso autenticado al servidor Exchange vulnerable para explotar con éxito el dispositivo. Esto puede parecer trivial al principio, pero las credenciales se pueden comprar de manera fácil y relativamente económica en la web oscura.

Importancia de las vulnerabilidades de Microsoft Exchange

Microsoft Exchange se usa ampliamente en entornos empresariales y una vulnerabilidad sin parches que podría permitir la ejecución remota de código por parte de un atacante representaría un riesgo significativo para cualquier organización expuesta.

¿Se han observado intentos de explotación de CVE-2022-41040 y CVE-2022-41082 en la naturaleza?

Sí. Microsoft ha informado que ambas vulnerabilidades se están utilizando en ataques "limitados y dirigidos". Además, como se mencionó, GTSC inicialmente descubrió las vulnerabilidades a través de la observación directa de una intrusión.

¿Se han parcheado estas vulnerabilidades?

Al momento de escribir este artículo (30 de septiembre de 2022), no se ha lanzado un parche. Microsoft ha declarado que se está desarrollando uno en una línea de tiempo acelerada.

¿El proveedor ha proporcionado mitigaciones?

Sí, Microsoft ha publicado el siguiente procedimiento de mitigación:

"La mitigación actual consiste en agregar una regla de bloqueo en "Administrador de IIS -> Sitio web predeterminado -> Detección automática -> Reescritura de URL -> Acciones" para bloquear los patrones de ataque conocidos".

Para realizar esta acción:

1. Abra el Administrador de IIS.
2. Expanda el sitio web predeterminado.
3. Seleccione Detección automática.
4. En la Vista de características, haga clic en Reescritura de URL.
5. En el panel Acciones en el lado derecho, haga clic en Agregar reglas.
6. Seleccione Solicitar bloqueo y haga clic en Aceptar.
7. Agregue la cadena “.*autodiscover\.json.*\@.*Powershell.*” (excluyendo las comillas) y haga clic en Aceptar.
8. Expanda la regla y seleccione la regla con el Patrón ".*autodiscover\.json.*\@.*Powershell.*" y haga clic en Editar en Condiciones.
9. Cambie la entrada de condición de {URL} a {REQUEST_URI}

• HTTP: 5985
• HTTPS: 5986

Conclusión

A pesar de que existen medidas de mitigación disponibles y el requisito de autenticación, no sería prudente subestimar la gravedad de estas vulnerabilidades. La fácil disponibilidad de herramientas que pueden escanear automáticamente Internet en busca de servidores vulnerables significa que las máquinas afectadas se convierten en un objetivo muy visible.