Proxytoken: bypass de autenticación en Microsoft Exchange Server

 Está siendo un año especialmente duro para Microsoft en cuanto a vulnerabilidades en sus productos y Exchange es sin duda uno de los principales focos. Si a principios de marzo se publicó Proxylogon, cuatro vulnerabilidades (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) que encadenadas daban lugar a un RCE sin autenticación previa, a principios de agosto nos topamos con Proxyshell, tres vulnerabilidades (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) que nos conseguían lo propio, otro bonito RCE.

Serie de ataques a MS Exchange descubiertos por Orange Tsai(aka @orange_8361):

• A New Attack Surface on MS Exchange Part 1 - ProxyLogon!
• A New Attack Surface on MS Exchange Part 2 - ProxyOracle!
• A New Attack Surface on MS Exchange Part 3 - ProxyShell!
• A New Attack Surface on MS Exchange Part 4 (coming soon...)

Pues bien, hoy traemos ProxyToken descubierta por Le Xuan Tuyen de VNPT ISC en marzo de 2021 y solucionada por Microsoft en los parches acumulativos de julio, esta vez una sola vulnerabilidad con CVE-2021-33766 y por la que "un atacante no autenticado puede realizar acciones de configuración en los buzones de correo que pertenecen a usuarios arbitrarios". Y lo peor, su explotación es trivial.

Microsoft Exchange crea dos sitios en IIS:

• Uno es el sitio web predeterminado, que escucha en los puertos 80 para HTTP y 443 para HTTPS. Este es el sitio al que se conectan todos los clientes para acceder a la web (OWA, ECP) y para servicios web externos. Es decir, es el front-end.
• El otro sitio se llama "Exchange Back End" y escucha en los puertos 81 para HTTP y 444 para HTTPS.

El sitio web de front-end es principalmente un proxy para el back-end. Para permitir el acceso que requiere autenticación de formularios, la interfaz sirve páginas como /owa/auth/logon.aspx. Para todas las solicitudes posteriores a la autenticación, la función principal del front-end es volver a empaquetar las solicitudes y enviarlas a los end-points correspondientes en el back-end. Luego, recopila las respuestas de dicho back-end y las reenvía al cliente.

Vemos rápidamente un ejemplo en el que el front-end nos responde con un '440 Login time out' porque no le hemos pasado las credenciales/cookies correspondientes:

Sin embargo, Exchange admite una función llamada "Autenticación delegada" que admite topologías entre bosques. En tales implementaciones, el front-end no puede tomar decisiones de autenticación por sí solo. En cambio, el front-end pasa las peticiones directamente al back-end, confiando en el back-end para determinar si la solicitud está correctamente autenticada. Estas solicitudes que deben autenticarse mediante la lógica de back-end se identifican mediante la presencia de una cookie SecurityToken. En resumen, si está cookie en la petición la autenticación se delegará al back-end.

Pero, ¿qué pasa si el back-end no ha sido configurado con esa función/módulo "DelegatedAuthModule"?

Pues que las peticiones pueden ir de un front-end a un back-end obviando la autenticación. Sin embargo, si incluimos la cookie DelegatedAuthModule recibimos un error 500:

Hay otro pequeño obstáculo, cada solicitud a una página /ecp debe tener un ticket conocido como "ECP canary". Sin un canario, la petición devolverá ese 500. Sin embargo "la vida puede ser maravillosa" porque, si os fijáis en la imagen anterior, la respuesta del error 500 va acompañada de un canario válido.

Así que solo debemos usar ese canario y construir la petición adecuada, en el ejemplo para crear una regla que reenvíe al atacante todos los correos enviados a la víctima (el atacante debe tener el control de otro buzón en el servidor Exchange vulnerable):

Como se la regla se ha creado correspondiente:

Y si se envía cualquier correo irá directo "al pozo":

Fuente: SeguInfo