This post is also available in: Português Español
Hace unas semanas, investigadores informaron a Microsoft, a través de Zero Day Initiative, de dos nuevas vulnerabilidades de día cero en Microsoft Exchange Server. Y ahora, estas dos vulnerabilidades están siendo explotadas por ciberdelincuentes.
Zero Day Initiative (ZDI) es una iniciativa internacional para identificar vulnerabilidades en el software que surgió en 2005 por TippingPoint, una división de 3Com que fue adquirida por Trend Micro en 2015.
El descubrimiento de la vulnerabilidad
A principios de agosto de este año, los investigadores de GTSC identificaron ataques que explotaban la falla de día cero para la ejecución remota de código mientras realizaban servicios de monitoreo de seguridad y respuesta a incidentes.
Mientras realizaban una investigación, los expertos del GTSC Blue Team (profesionales de seguridad defensiva) determinaron que en el ataque se utilizó una vulnerabilidad de seguridad de Exchange no publicada. Es decir, una vulnerabilidad de día cero.
El Blue Team ideó un plan de contención temporal, mientras que el Red Team investigó y depuró el código Exchange descompilado para encontrar la vulnerabilidad y explotar el código.
La falla descubierta es tan grave que permite al atacante RCE el sistema comprometido. GTSC envió la vulnerabilidad a ZDI para que Microsoft pudiera lanzar un parche lo antes posible.
ZDI está rastreando bugs como ZDI-CAN-18802 y ZDI-CAN-1833. Mientras que CVE los rastrea como CVE-2022-41040 y CVE-2022-41082, con puntuaciones 8,8 y 6,3.
Explotación de fallas
GTSC solo ha publicado algunos detalles relacionados con las fallas de día cero. Prefiriendo no revelar detalles técnicos por el momento.
Blue Team reveló que las solicitudes utilizadas en la cadena de explotación son similares a las utilizadas en los ataques dirigidos a fallas de ProxyShell.
autodiscover/autodiscover.json?@evil.com/&Email=autodiscover/autodiscover.json%3f@evil.com.
Al revisar otros registros, Blue Team notó que el atacante podía ejecutar comandos en el sistema atacado.
Según los investigadores, ya se había instalado la última versión de Exchange, por lo que era imposible realizar un exploit utilizando la vulnerabilidad ProxyShell. Con eso, el Blue Team pudo confirmar que se trataba de una nueva vulnerabilidad RCE de día cero.
Después de la explotación
Los investigadores notaron que los atacantes encadenaron las fallas de día cero para contaminar los servidores, lo que permitió el robo de datos y el movimiento lateral para comprometer otros sistemas en las redes.
Según los investigadores, un grupo de amenazas chino está detrás de estos ataques recientes. La sospecha está motivada por el hecho de que la codificación de caracteres de la página webshell es 936, una codificación de Microsoft para chino simplificado.
Además, el agente empleado para instalar los webshells pertenece a una herramienta de administración de código abierto con sede en China con soporte para la gestión de webshells, identificada como Antsword.
Mitigación
Hasta que se publiquen actualizaciones y parches de seguridad para abordar los dos días cero, Microsoft ha compartido algunos consejos para mitigarlos.
Los clientes de Exchange Server deben completar la mitigación de la regla de reescritura de URL para CVE-2022-41040 y la mitigación de deshabilitar PowerShell remoto para no administradores para CVE-2022-41082 que se describe a continuación.
Los clientes de Exchange Online no necesitan realizar ninguna acción.
Regla de reescritura de URL
La mitigación actual de Exchange Server consiste en agregar una regla de bloqueo en “IIS Manager > Default Web Site > URL Rewrite > Actions” para bloquear patrones de ataque conocidos.
Los clientes de Exchange Server deben revisar y usar una de estas opciones.
- Opción 1:
- Opción 2:
- Opción 3:
- 1. Abra el «Administrador de IIS»;
- 2. Seleccione el «Sitio predeterminado»;
- 3. En la vista «Recurso», haga clic en «Reescribir URL»;
- 4. En el “panel de acciones”, en el lado derecho, haga clic en “agregar reglas…”;
- 5. Seleccione «solicitar bloqueo» y haga clic en Aceptar;
- 6. Adicione a string “(?=.*autodiscover)(?=.*powershell)”;
- 7. Seleccione «Expresión regular» en «Uso»;
- 8. Seleccione «cancelar solicitud» en «cómo bloquear» y haga clic en Aceptar;
- 9. Expanda la regla y seleccione la regla con el patrón: (?=.*autodiscover)(?=.*powershell) y haga clic en «Editar» en «Condiciones»;
- 10. Cambie la entrada de condición de {URL} a {UrlDecode:{REQUEST_URI}} y haga clic en OK.
Para los clientes que tienen habilitado el Servicio de mitigación de emergencia de Exchange (EEMS), Microsoft ha lanzado la Mitigación de reescritura de URL para Exchange Server 2016 y Exchange Server 2019.
La mitigación se habilita y actualiza automáticamente para incluir mejoras en las reglas de reescritura de URL.
Microsoft creó el script EOMTv2 para los pasos de mitigación de reescritura de URL y lo actualizó para incluir las mejoras de la regla de reescritura de URL.
El script EOMTv2 se actualizará automáticamente en las máquinas conectadas a Internet y la versión actualizada se mostrará como 22.10.07.2029. Debe volver a ejecutarse en cualquier Exchange Server sin EEMS habilitado.
Os clientes podem seguir as seguintes instruções:
Si necesita cambiar alguna regla, es mejor eliminarla y volver a crearla.
Microsoft informa que no hay ningún efecto conocido en la funcionalidad de Exchange si se instala la reescritura de URL como se recomienda.
Deshabilitar el acceso remoto de PowerShell
Los clientes de Exchange Server deben deshabilitar el acceso remoto a PowerShell para usuarios que no sean administradores en su organización.
Al acceder a este enlace desde el sitio web de Microsoft, encontrará las pautas necesarias sobre cómo hacerlo.
Microsoft y los investigadores recomiendan que todas las organizaciones de todo el mundo que utilicen Microsoft Exchange Serve comprueben, revisen y apliquen soluciones alternativas lo antes posible para evitar posibles daños graves.
Fuentes: Zero Day Initiative, GTSC, Microsoft.
This post is also available in: Português Español
