En lugar de discutir las vulnerabilidades individuales, concéntrese en cómo afectan a un inquilino
Me gusta y respeto el trabajo de los investigadores de seguridad. Con la conciencia persistente de la industria de TI, los investigadores de seguridad hacen un buen trabajo al hacer que las grandes empresas de tecnología rindan cuentas cuando esas empresas no protegen bien los datos de los clientes. El papel de los investigadores es sumamente valioso y su actividad suele prestar un gran servicio a la comunidad.
Sin embargo, en 2023, agradecería que los investigadores de seguridad prestaran un poco más de atención al panorama general cuando se apresuran a revelar fallas que creen que existen en Microsoft 365. No niego que existen fallas en Microsoft 365. Las hay. Ese es un estado natural (pero problemático) para un servicio de software tan grande compuesto por múltiples cargas de trabajo que se ejecutan a escala global. Una cantidad colosal de servidores se ejecutan dentro de Microsoft 365 para procesar datos de más de 345 millones de usuarios pagos de Office 365 (el último número proporcionado por Microsoft en abril de 2022). Solo Exchange Online ejecuta 300.000 servidores de buzones de correo físicos para procesar 9.200 millones de mensajes al día. No hay excusa para una falla de software obvia, pero puede apreciar que la escala y las demandas de un servicio que cambia constantemente pueden revelar problemas de vez en cuando.
Publicar y ser condenado
El problema que noté en 2022 es que algunos investigadores de seguridad no consideran los aspectos prácticos de cómo una falla podría afectar las operaciones de Microsoft 365 cuando informan detalles de una posible vulnerabilidad. En cambio, se apresuran a revelar sus hallazgos con una prisa casi indecente. Tanto es así que la sospecha de que la revelación se trata más de llamar la atención que de ayudar a la comunidad. O, en algunos casos, la necesidad de que la empresa de seguridad impulse las ventas, asegure la inversión o, de otro modo, obtenga alguna ventaja.
Algunos ejemplos de lo que quiero decir son:
- El ataque GIFShell contra Teams pretendía demostrar que es posible que un hacker envíe un archivo GIF infectado a un usuario en otra organización de Teams. La técnica funciona, pero depende de que el atacante pueda infectar una PC primero. También es muy fácil para una organización bloquear el chat entrante de organizaciones que no son de confianza, un hecho destacado que el investigador no sabía o no mencionó.
- Otra ráfaga de interés de investigación se centró en el hecho de que Teams almacena tokens de acceso en texto claro. No estoy en desacuerdo con que esta sea una mala práctica, pero no es la «grave vulnerabilidad de seguridad» que el investigador promocionó. Una vez más, un atacante tuvo que comprometer una PC antes de poder escanear el sistema en busca de tokens de acceso, y seguramente el atacante tiene objetivos más lucrativos si puede penetrar una PC.
- Los investigadores de seguridad se preocuparon por el cifrado de mensajes de Office 365 en octubre. Es malo que Microsoft no use una mejor protección para los archivos de Office aquí, pero la probabilidad de que los datos se comprometan con el método descrito por los investigadores es infinitesimal.
Otro ejemplo es la «Gran fuga de credenciales» de detección automática en octubre de 2021. Este era un problema antiguo, pero es un problema del lado del cliente que los proveedores de dispositivos móviles solucionaron hace mucho tiempo.
Falsificando como si fuera 1995
Todo lo cual me lleva a un informe del 22 de mayo de 2022 de Black Hills Information Security titulado «Spoofing Microsoft 365 Like It’s 1995» escrito por Steve Borosh. El punto que se destaca es que los inquilinos de Microsoft 365 deben asegurarse de que Exchange Online no esté abierto a intentos de phishing. Es un buen consejo que apoyo firmemente.
Borosh se centra en la función de envío directo de Exchange Online que permite que las aplicaciones y los dispositivos envíen correos electrónicos a los destinatarios de la misma organización (inquilino). Él dice que: “Con el envío directo de Microsoft, podemos enviar correos electrónicos en nombre de usuarios externos o internos a otros usuarios internos dentro de las empresas que usan Microsoft 365; en esencia, falsificar correos electrónicos en muchas organizaciones”. Y afirma además que existe una vulnerabilidad porque «Microsoft utiliza «hosts inteligentes» para Exchange que normalmente se encuentran en una dirección como company-com.mail.protection.outlook.com que permite retransmisiones SMTP no autenticadas a usuarios internos».
Como probablemente sepa, Microsoft está haciendo todo lo posible para eliminar la autenticación básica de los protocolos de conexión de Exchange Online. SMTP AUTH tiene una exención actual, pero desaparecerá en el futuro y las organizaciones deberán usar un método diferente para enviar mensajes a través de Exchange Online. El envío directo es uno. Reemplazar SMTP AUTH con API basadas en gráficos es otra. Usar un conector es un tercero. El problema con los dispositivos y aplicaciones multifunción es que puede ser difícil actualizarlos para usar un método diferente. Direct Send elimina parte del dolor del proceso, por lo que supongo que existe.
En cualquier caso, Borosh señala correctamente que Direct Send puede enviar mensajes desde fuera de una organización, que es el propósito básico del correo electrónico. Exchange Online Protection procesa estos mensajes como cualquier otro correo electrónico entrante para garantizar que cumplan con los requisitos de aceptación de la organización y para eliminar el malware y el spam.
Borosh presenta un caso de que los atacantes podrían explotar Direct Send para entregar mensajes de phishing a los buzones de correo objetivo y describe el uso de una regla de flujo de correo para desactivar el filtrado de correo no deseado de Exchange Online Protection al establecer el valor de Nivel de confianza de correo no deseado (SCL) para los mensajes generados por un dominio específico para -1 (que significa derivación). En otras palabras, debido a que se omite el SCL, Exchange lo considera un mensaje libre de spam y malware y lo entrega al destino. Demuestra cómo enviar un mensaje a través de Direct Send con PowerShell (Windows, Linux y Azure Cloud Shell).
Todo esto es cierto, y es posible que algunos administradores de inquilinos hayan tomado la ruta de crear una regla de flujo de correo para establecer el valor de SCL en cero para los mensajes de dominios específicos. Sin embargo, es una idea terrible. Las reglas de flujo de correo nunca deben interferir con el valor de SCL asignado a los mensajes a menos que exista una buena y válida razón para que esto suceda. Y si una ejecución de flujo de correo necesita establecer un SCL específico para los mensajes, asegúrese de que las condiciones cuando esto suceda sean lo más estrictas posible. Por ejemplo, el SCL solo se configura para mensajes provenientes de un remitente específico.
Establecer un valor SCL para probar un punto no es una razón válida. Exchange Online Protection existe por una razón en cada inquilino de Microsoft 365 que usa Exchange Online. ¿Por qué querrías quitar esa protección?
Un agujero potencial pero improbable
La conclusión es que Direct Send es un agujero potencial. Pero es un agujero que los administradores de inquilinos competentes cierran usando Exchange Online Protection para bloquear los mensajes maliciosos en la forma en que está diseñado para funcionar. No considero que esto sea una vulnerabilidad del producto. En cambio, es una debilidad explotable si las personas son lo suficientemente imprudentes como para eliminar las protecciones.
El informe no cita ningún ejemplo de ataques de phishing realizados con Direct Send cuando los inquilinos bajaron la guardia. El phishing ocurre todo el tiempo, y debido a que los atacantes varían y evolucionan sus técnicas, algo de phishing logra pasar. Lo último que llegó a mi buzón fue una oportunidad de pagar una suscripción para recibir apoyo de Geek Squad. Exchange Online envió este mensaje a mi bandeja de entrada después de que Exchange Online Protection lo marcara con un consejo de seguridad porque normalmente no recibo correos electrónicos del remitente.
Usé el complemento de mensaje de informe de Outlook para informar el mensaje de phishing a Microsoft, pero al ver su contenido (Figura 1), me pregunto cómo superó Exchange Online Protection. A la luz de este tipo de amenazas, no tenemos que complicarnos la vida deshabilitando parcialmente el filtrado de spam.
Figura 1: Un mensaje de phishing que superó Exchange Online Protection
Hay valor a considerar en el informe de Borosh, pero también creo que es otro ejemplo de un investigador de seguridad que publica sin pensar en el panorama completo. Claro, si existe un conjunto específico de circunstancias, los mensajes de phishing se transmitirán. Pero, ¿qué tan probable es que esto suceda? Tengo mis dudas. Sería bueno en 2023 si los investigadores de seguridad preguntaran qué tan probable es que alguien pueda explotar una falla antes de publicarla.
