Cómo piratear un servidor de Exchange sin parches con código PowerShell falso

Hace poco menos de dos meses, surgieron algunas noticias preocupantes sobre errores: se anunciaron un par de vulnerabilidades de día cero en Microsoft Exchange.

Como hemos aconsejado en el momento, estas vulnerabilidades, designadas oficialmente CVE-2022-41040 y CVE-2022-41082:

[eran] dos días cero que [podrían] encadenarse, con el primer error usado 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.

La primera vulnerabilidad recordaba a la problemática y ampliamente abusada Agujero de seguridad ProxyShell desde agosto de 2021, porque se basó en un comportamiento peligroso en la función de detección automática de Exchange, descrito por Microsoft como un protocolo que es "utilizado por los clientes de Outlook y EAS [Exchange ActiveSync] para buscar y conectarse a buzones de correo en Exchange".

Afortunadamente, la característica incorrecta de detección automática que podría ser explotada en el ataque ProxyShell por cualquier usuario remoto, ya sea que haya iniciado sesión o no, fue parcheado hace más de un año.

Desafortunadamente, los parches de ProxyShell no hicieron lo suficiente para cerrar el exploit a los usuarios autenticados, lo que llevó al nuevo día cero CVE-2022-40140, que pronto fue lacónicamente, aunque engañosamente, doblado ProxyNotShell.

No tan peligroso, pero peligroso sin embargo.

Claramente, ProxyNotShell no era tan peligroso como el ProxyShell original, dado que requería lo que se conoce como acceso autenticado, por lo que no estaba abierto al abuso por parte de cualquiera en cualquier lugar.

Pero rápidamente se supo que en muchos servidores de Exchange, conocer el nombre de inicio de sesión y la contraseña de cualquier usuario sería suficiente para pasar como autenticado y montar este ataque, incluso si ese usuario necesitaría usar autenticación de dos factores (2FA) para iniciar sesión correctamente para acceder su correo electrónico.

Como el experto de Sophos Chester Wisniewski ponlo en el momento:

Es una "vulnerabilidad de autenticación media", si quieres llamarlo así. Esa es una bendición mixta. Significa que un script de Python automatizado no puede simplemente escanear todo Internet y potencialmente explotar todos los servidores de Exchange en el mundo en cuestión de minutos u horas, como vimos que sucedió con ProxyLogon y ProxyShell en 2021. […]

Necesita una contraseña, pero encontrar una dirección de correo electrónico y una combinación de contraseña válidas en cualquier servidor de Exchange probablemente no sea demasiado difícil, desafortunadamente. Y es posible que no haya sido explotado hasta la fecha, porque para iniciar sesión con éxito en Outlook Web Access [OWA] se requiere su token FIDO, o su autenticador, o cualquier segundo factor que pueda estar usando.

Pero este ataque no requiere ese segundo factor. […] Solo adquirir una combinación de nombre de usuario y contraseña es una barrera bastante baja.

Como probablemente recuerde, muchos de nosotros asumimos (o al menos esperábamos) que Microsoft se apresuraría a solucionar los agujeros de ProxyNotShell, dado que todavía quedaban dos semanas hasta el martes de parches de octubre.

Pero nos decepcionó descubrir que aparentemente había una solución confiable. más complejo de lo esperado, y octubre vino y se fue con ProxyNotShell abordado solo por soluciones alternativas, no por parches adecuados.

Incluso el martes de parches de noviembre no proporcionó directamente las correcciones necesarias, aunque los parches sin embargo salió el mismo día como parte de una actualización de seguridad específica de Exchange que podría obtenerse e instalarse por separado:

Prueba de concepto revelada

Ahora que el polvo se ha asentado y todos han tenido tiempo de parchear sus servidores de Exchange (los que no han olvidado, al menos), los investigadores de Zero Day Initiative (ZDI), a los que originalmente se les revelaron estas vulnerabilidades de manera responsable para enviarlas a microsoft, ha explicado cómo se pueden explotar los errores.

La mala noticia, según su opinión sobre las revelaciones abiertas de exploits, es que el equipo de ZDI ahora ha proporcionado una prueba de concepto (PoC) que explica cómo atacar los servidores de Exchange.

La buena noticia, por supuesto, es que:

• Ahora podemos estudiar y comprender los errores nosotros mismos. Esto no solo nos ayuda a todos a asegurarnos de que las precauciones generales que hemos tomado (no solo limitadas a la aplicación de parches) puedan proporcionar la protección que esperamos, sino que también nos informa sobre las prácticas de programación que queremos evitar en el futuro, por lo que no No quede atrapado en la apertura de errores de este tipo en nuestro propio código del lado del servidor.
• Ya no nos quedan excusas para no aplicar los parches. Si nos hemos demorado en actualizar, la explicación de ZDI de por qué funciona el ataque deja en claro que la cura es definitivamente preferible a la enfermedad.

Cómo funciona

ZDI explicación de esta vulnerabilidad lo convierte en una historia fascinante de lo complejo que puede ser encadenar todas las partes que se necesitan para convertir una vulnerabilidad en un exploit viable.

También vale la pena leerlo para ayudarlo a comprender por qué profundizar en un exploit existente puede ayudar a revelar otras formas en que una vulnerabilidad podría usarse indebidamente, lo que podría generar parches adicionales, instar a cambios de configuración y promover nuevas prácticas de programación que podrían no haber sido obvias solo con la reparación. el agujero original.

La explicación es, por necesidad, complicada y bastante técnica, y lo guía a través de una larga serie de pasos para lograr la ejecución remota de código (RCE) al final.

Con la esperanza de ayudarlo a seguir los detalles de alto nivel más fácilmente si decide leer el informe ZDI, aquí hay un resumen, que esperamos no sea demasiado simplificado, con los pasos enumerados al revés...

…para que sepas de antemano por qué la historia toma las direcciones que toma:

• PASO 4. Engañe de forma remota a Exchange para que cree una instancia de un objeto .NET de su elección, con un parámetro de inicialización de su elección.

En la codificación moderna, un objeto instanciado es la palabra de la jerga para un fragmento de memoria asignado, inicializado automáticamente con los datos y recursos que necesitará mientras está en uso, y vinculado a un conjunto específico de funciones que pueden operar en él. (Instanciar es solo una palabra elegante para Para crear.)

Los objetos pueden ser administrados y controlados por el propio sistema operativo, para ayudar a evitar el tipo de errores de mala administración de memoria comunes en un lenguaje como C, donde normalmente necesita asignar memoria usted mismo, completar los campos de datos relevantes a mano y recordar libere la memoria y los recursos que está utilizando, como sockets de red o archivos de disco, cuando haya terminado.

Los objetos generalmente tienen una función programática asociada con ellos llamada constructor, que se ejecuta automáticamente cuando se crea un nuevo objeto para asignar la cantidad correcta de memoria y el conjunto correcto de recursos del sistema.

Por lo general, debe pasar uno o más parámetros como argumentos al constructor, para indicar cómo desea que se configure el objeto cuando comience.

En pocas palabras, si instancias, digamos, un TextString objeto (estamos inventando estos nombres, pero entiendes la idea) usando un parámetro que es en sí mismo una cadena de texto como example.com:8888...

… probablemente terminará con un búfer de memoria asignado para contener su texto, inicializado para que contenga el mismo valor que pasó, es decir, el texto sin formato example.com:8888.

En ese contexto, la cadena de texto que se pasa como datos al constructor del objeto no representa de inmediato ninguna amenaza de seguridad cibernética obvia cuando activa el constructor de forma remota, aparte de una posible denegación de servicio (DoS) al solicitar cadenas cada vez más grandes para tratar de agotar la memoria.

Pero si fueras a instanciar, digamos, un ConnectedTCPClient objeto utilizando el mismo parámetro de cadena de texto de example.com:8888, puede terminar con un búfer de memoria listo para almacenar datos temporales, junto con un socket de red asignado por el sistema operativo que está listo para intercambiar datos con el servidor example.com sobre el puerto TCP 8888.

Puede ver el riesgo de ejecución remota de código allí, incluso si nunca puede enviar ningún dato al socket abierto, dado que ha engañado al servidor para que llame a casa a una ubicación que usted controla.

Incluso podrías encontrar un objeto llamado, por ejemplo, RunCmdAndReadOutput, donde la cadena de texto que envía como parámetro es, literalmente, un comando que desea ejecutar automáticamente tan pronto como se crea el objeto, para que pueda recopilar su salida más adelante.

Incluso si nunca logra recuperar la salida del comando, simplemente crear una instancia de dicho objeto le permitiría elegir un comando para ejecutar, lo que le brinda una ejecución de código remota genérica y presenta un riesgo limitado solo por los derechos de acceso del propio proceso del servidor. .

Por supuesto, el ataque solo es así de fácil una vez que llega a la última etapa, lo que se supone que no puede hacer, porque Exchange tiene una lista de permitidos estricta que le impide elegir cualquier objeto antiguo para instanciar.

En teoría, solo los objetos seguros o de bajo riesgo se pueden crear de forma remota a través de PowerShell, por lo que instanciar nuestro imaginario TextString arriba, o un SimpleIntegerValue, podría considerarse aceptable, mientras que un ConnectedTCPClient o un RunCmdAndReadOutput definitivamente no lo sería.

Pero los investigadores de ZDI notaron que antes de activar el último paso, podían hacer esto:

• PASO 3. Engañe remotamente a Exchange para que piense que un objeto de bajo riesgo que pasó la prueba de seguridad es, de hecho, algún otro objeto de su elección.

Aun así, puede esperar que Exchange impida la creación remota incluso de objetos de bajo riesgo, para minimizar aún más la amenaza.

Pero los investigadores descubrieron que podían:

• PASO 2. Engañar remotamente a Exchange para que use su PowerShell Remoting característica para crear un objeto basado en parámetros de inicialización controlados externamente.

Y eso fue posible gracias al agujero tipo ProxyShell que solo estaba parcialmente parcheado:

• PASO 1. Engañe de forma remota a Exchange para que acepte y procese una solicitud web con código empaquetando un username:password campo en la solicitud también.

Incluso si el usuario nombrado en la solicitud en realidad no inició sesión y necesitaría pasar por algún tipo de proceso 2FA para acceder a su propio buzón, un atacante que conocía su username:password La combinación tendría suficiente información de autenticación para engañar a Exchange para que acepte una conexión web que podría usarse para iniciar la cadena de ataque descrita en los pasos 2 a 4 anteriores.

En términos generales, cualquier válido username:password La combinación funcionaría, dado que la "autenticación" era necesaria simplemente para evitar que Exchange rechazara la solicitud HTTP por adelantado.

¿Qué hacer?

Tenga en cuenta que este ataque solo funciona:

• Si tiene servidores de Exchange locales. Microsoft afirma haber bloqueado sus propios servicios en la nube rápidamente, por lo que Exchange Online no se ve afectado. Asegúrese sepa dónde están sus servidores de Exchange. Incluso si ahora usa Exchange Online, es posible que aún tenga servidores locales ejecutándose, tal vez sobrantes por error de su proceso de migración.
• Si sus servidores no están parcheados. Asegúrese de que dispone aplicó la actualización de software de Exchange del 2022-11-08 a cerrar las vulnerabilidades que requiere el exploit.
• Si sus servidores aún aceptan la autenticación básica, también conocida como autenticación heredada. Asegúrese de que dispone bloqueó todos los aspectos de la autenticación heredada para que sus servidores no acepten el username:password encabezados mencionados anteriormente, y no aceptará solicitudes riesgosas del protocolo Autodiscover en primer lugar. Este detiene a los atacantes engañar a un servidor para que acepte sus trucos de creación de instancias de objetos con trampas explosivas, incluso si ese servidor no está parcheado.

solicite hacer un seguimiento de nuestros consejos oficiales de prevención, reparación y respuesta, y los clientes de Sophos pueden realizar un seguimiento de los nombres de detección de amenazas utilizados por nuestros productos, a través del feed de Twitter de Sophos X-Ops (@SophosXOps).

Se ha publicado nueva información sobre CVE-2022-41040 y CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 de noviembre.

---

MÁS INFORMACIÓN SOBRE AUTENTICACIÓN DE INTERCAMBIO Y OAUTH2

Con Paul Ducklin y Chester Wisniewski
Música de introducción y final de Edith Mudge.

---