Justo cuando esperaba que la semana se calmara y le diera tiempo de inactividad de SecOps durante el fin de semana…
…¡y llega un nuevo agujero de día cero en Microsoft Exchange!
Más precisamente, dos días cero que aparentemente pueden encadenarse, con el primer error utilizado de forma remota para abrir un agujero suficiente para activar el segundo error, que potencialmente permite la ejecución remota de código (RCE) en el propio servidor de Exchange.
Microsoft publicó rápidamente una guía oficial sobre estas vulnerabilidades, resumiendo la situación de la siguiente manera:
Microsoft está investigando dos vulnerabilidades de día cero informadas que afectan a Microsoft Exchange Server 2013, 2016 y 2019. La primera vulnerabilidad, identificada como CVE-2022-41040 , es una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF), mientras que la segunda, identificada como CVE-2022-41082 , permite la ejecución remota de código (RCE) cuando el atacante puede acceder a PowerShell.
En este momento, Microsoft tiene conocimiento de ataques dirigidos limitados que usan las dos vulnerabilidades para ingresar a los sistemas de los usuarios. En estos ataques, CVE-2022-41040 puede permitir que un atacante autenticado active de forma remota CVE-2022-41082. Cabe señalar que el acceso autenticado al servidor Exchange vulnerable es necesario para explotar con éxito cualquiera de las dos vulnerabilidades.
Por lo que podemos ver, hay dos aspectos positivos aquí:
- Los errores no pueden ser activados por cualquiera. Claro, cualquier usuario remoto que ya haya iniciado sesión en su cuenta de correo electrónico a través de Internet y cuya computadora esté infectada por malware, en teoría podría tener su cuenta subvertida para lanzar un ataque que aproveche estos errores. Pero solo tener su servidor de Exchange accesible a través de Internet no es suficiente por sí solo para exponerlo a un ataque, porque la llamada invocación no autenticada de estos errores no es posible.
- El bloqueo de PowerShell Remoting puede limitar los ataques. Según Microsoft, el bloqueo de los puertos TCP 5985 y 5986 en su servidor Exchange limitará (si no evitará) que los atacantes se encadenen desde la primera vulnerabilidad a la segunda. Aunque los ataques pueden ser posibles sin depender de la activación de los comandos de PowerShell, los informes de intrusión hasta ahora parecen sugerir que la ejecución de PowerShell fue una parte necesaria del ataque.
Memorias de ProxyShell
Si este ataque le recuerda la vulnerabilidad ProxyShell de hace aproximadamente un año, no es el único que piensa eso.
Según GTSC, la empresa de ciberseguridad vietnamita que primero investigó e informó estos nuevos agujeros, los investigadores “detectaron solicitudes de explotación en los registros de IIS con el mismo formato que [la] vulnerabilidad ProxyShell”.
En particular, el tipo de consulta de búsqueda de amenazas que recomendamos para la búsqueda de exploits de ProxyShell en 2021 parece funcionar también para detectar el abuso de estos nuevos días cero:
| 1 2 3 4 5 6 | SELECT grep.*FROM fileCROSS JOIN grep ON (grep.path = file.path)WHEREfile.path LIKE 'C:\inetpub\logs\LogFiles\W3SVC%\u_ex210[89]%'AND grep.pattern = 'autodiscover.json' |
Microsoft también señala que “[la detección que] creamos en respuesta a ProxyShell se puede usar para consultas, ya que hay similitudes en la función con esta amenaza”.
Por supuesto, aún no sabemos si el nuevo ataque se puede llevar a cabo sin dejar este signo revelador específico en sus registros.
En otras palabras, si encuentra signos desencadenantes similares a los que dejan las vulnerabilidades de PowerShell, probablemente tenga evidencia de un ataque, pero la ausencia de estos signos no es evidencia de ausencia.
Según GTSC, en los ataques que han investigado hasta ahora, los ciberdelincuentes usaron sus poderes RCE no autorizados para implantar y ejecutar una variedad de malware de seguimiento, que incluye:
- Webshells implantados para abrir una puerta trasera basada en la web para más adelante. Webshells generalmente permite ataques de seguimiento para incrustar comandos de sistema arbitrarios, con argumentos de comando arbitrarios, en solicitudes HTTP de apariencia regular. El webshell luego ejecuta directamente el comando deseado con los privilegios del propio servidor web.
- Malware de volcado de credenciales. Los ladrones de credenciales suelen husmear en el disco y en la memoria (si tienen suficientes privilegios) en busca de contraseñas de texto sin formato, cookies de sesión y tokens de autenticación que podrían permitir lo que se conoce como movimiento lateral a otras computadoras en la red.
- Malware zombi en forma de archivos DLL cargados en procesos que parecen legítimos . Una muestra de DLL que los investigadores de GTSC analizaron podría alimentarse de forma remota con instrucciones cifradas para volcar información del sistema, ejecutar comandos arbitrarios, iniciar módulos C# y modificar archivos y carpetas en el sistema infectado.
¿Qué hacer?
Las mitigaciones incluyen:
- Bloquee PowerShell Remoting para reducir el riesgo de RCE. Como se mencionó anteriormente, el bloqueo de los puertos TCP 5985 y 5986 limitará los ataques a su servidor Exchange, según Microsoft.
- Utilice una regla de reescritura de URL para bloquear los desencadenantes de ataques conocidos. GTSC y Microsoft tienen explicaciones sobre cómo usar las reglas de reescritura de URL del servidor IIS para detectar y neutralizar formas comunes de este ataque.
- Asegúrese de que la detección de amenazas de punto final de comportamiento esté habilitada, incluso en servidores. Como se mencionó anteriormente, GTSC informa que los ataques vistos hasta ahora incluyen la implantación de webshells y DLL de malware para ejecutar comandos arbitrarios, manipular archivos y extraer información del sistema. Esto le brinda numerosos indicadores potenciales de detección y respuesta para controlar un ataque exitoso.
- Considere anular la autenticación de los usuarios de correo electrónico que iniciaron sesión. Si puede realizar algún tipo de evaluación de seguridad de punto final en el dispositivo de cada usuario antes de permitirles volver a autenticarse, reducirá (aunque no eliminará) el riesgo de que los dispositivos ya comprometidos sean cooptados para lanzar ataques. También reducirá lo que se conoce como su superficie de ataque no tener usuarios autenticados dando vueltas que no necesitan iniciar sesión, o que ni siquiera recuerdan que alguna vez iniciaron sesión en primer lugar.
- Aplique los parches tan pronto como estén disponibles. Hasta el momento, solo se han informado ataques limitados, principalmente en el sudeste asiático, y GTSC está ocultando deliberadamente detalles de las vulnerabilidades hasta que salgan los parches. Pero recuerde que una vez que se publiquen los parches, los ciberdelincuentes inmediatamente comenzarán a trabajar hacia atrás para trabajar con exploits con la esperanza de atrapar a aquellos que tardan en aplicar las actualizaciones.
Hasta ahora [2022-09-30T13:30Z], parece que las cosas más importantes a tener en cuenta son: [a] los consejos y técnicas que aprendió para cazar ataques de ProxyShell seguramente serán útiles aquí, si no son las únicas herramientas que puede necesitar; [b] a pesar de las similitudes (y de todo lo que haya visto en línea), esto no es ProxyShell, por lo que sus parches de ProxyShell no lo protegerán; y [c] cuando lleguen los parches, suponga que se les aplicará ingeniería inversa para que vuelvan a funcionar muy rápidamente, así que no se demore en aplicarlos.
