Tecnología

El error de Microsoft Exchange ProxyToken puede permitir que los piratas informáticos roben el correo electrónico del usuario

Exchange-ProxyToken-puede-permitir-que-los.jpg» width=»1600″/>

Han surgido detalles técnicos sobre una vulnerabilidad grave en Microsoft Exchange Server denominada ProxyToken que no requiere autenticación para acceder a los correos electrónicos desde una cuenta de destino.

Un atacante puede aprovechar la vulnerabilidad creando una solicitud a los servicios web dentro de la aplicación del Panel de control de Exchange (ECP) y robar mensajes de la bandeja de entrada de la víctima.

Confusión de la delegación

Con seguimiento como CVE-2021-33766, ProxyToken brinda a los atacantes no autenticados acceso a las opciones de configuración de los buzones de correo de los usuarios, donde pueden definir una regla de reenvío de correo electrónico.

Como resultado, los mensajes de correo electrónico destinados a un usuario objetivo también se pueden enviar a una cuenta que controla el atacante.

El error fue descubierto por Le Xuan Tuyen, investigador del Centro de Seguridad de la Información del Grupo de Correos y Telecomunicaciones de Vietnam (VNPT-ISC) e informado a través del Iniciativa de día cero (ZDI) en marzo.

Descubrió que el sitio frontend de Microsoft Exchange (Outlook Web Access, Panel de control de Exchange) funciona en gran medida como un proxy para el sitio backend (Exchange Back End), al que pasa las solicitudes de autenticación.

En las implementaciones de Microsoft Exchange donde la función «Autenticación delegada» está activa, el frontend reenvía las solicitudes que necesitan autenticación al backend, que las identifica por la presencia de una cookie «SecurityToken».

Cookie 'SecurityToken' necesaria para explotar la vulnerabilidad de ProxyToken en Microsoft Exchange Server
fuente: ZDI

Cuando hay una cookie ‘SecurityToken’ no vacía en una solicitud dentro de ‘/ ecp’, el frontend delega la decisión de autenticación al backend.

Sin embargo, la configuración predeterminada de Microsoft Exchange no carga para el sitio ECP backend el módulo responsable de delegar el proceso de validación (DelegatedAuthModule).

“En resumen, cuando el front-end ve la cookie SecurityToken, sabe que solo el back-end es responsable de autenticar esta solicitud. Mientras tanto, el back-end desconoce por completo que necesita autenticar algunas solicitudes entrantes basadas en la cookie SecurityToken ya que DelegatedAuthModule no se carga en instalaciones que no han sido configuradas para usar la función especial de autenticación delegada ”- Iniciativa de día cero

La explotación de la vulnerabilidad de ProxyToken no está completa sin otro problema, aunque sea menor: las solicitudes de la página / ecp necesitan un ticket conocido como «ECP canary», que se puede obtener cuando se activa un error HTTP 500.

Resulta que las solicitudes sin el ticket desencadenan el error HTTP 500 que contiene la cadena válida necesaria para emitir con éxito una solicitud no autenticada.

Cadena canary ECP para aprovechar la vulnerabilidad ProxyToken en Microsoft Exchange Server
fuente: ZDI

Un parche ha estado disponible de Microsoft desde julio, según el aviso público de la compañía. Rapid7’s Notas de Tom Sellers Sin embargo, los números de versión y las fechas indican que los parches se lanzaron en abril.

La vulnerabilidad no es crítica. NIST calculó su puntuación de gravedad en 7,5 sobre 10. Esto se debe a que un atacante necesita una cuenta en el mismo servidor de Exchange que la víctima.

Como ejemplo, una solicitud de un atacante se ve así:

Solicitud HTTP para activar la vulnerabilidad de ProxyToken en Microsoft Exchange Server
Subtítulo

en un entrada en el blog Hoy, Zero-Day Initiative señala que algunos administradores de servidores Exchange establecen un valor de configuración global que permite crear una regla de reenvío de correo electrónico a un destino arbitrario. En tales casos, el atacante no necesita credenciales.

Intentos de explotación

Aunque los detalles técnicos de ProxyToken solo se han publicado hoy, los intentos de explotación se registraron hace tres semanas.

De acuerdo a Rich Warren, equipo rojo de NCC Group, vio un mayor número de intentos de explotación el 10 de agosto.

Como en el caso de las vulnerabilidades de ProxyShell, si los administradores de los servidores de Microsoft Exchange no han instalado los parches para ProxyToken, deben priorizar la tarea.

Leave a Comment

You may also like

Más