- La intrusión en Microsoft es más grave que una simple toma de cuenta, porque una antigua cuenta de prueba sin MFA derivó en acceso a correos de altos ejecutivos y de los equipos de seguridad y legal
- El grupo vinculado al Estado ruso Midnight Blizzard explotó credenciales débiles mediante password spraying para iniciar sesión en una “legacy non-production test tenant account”
- Los atacantes usaron permisos de aplicaciones OAuth desde el tenant de prueba comprometido para obtener el rol
full_access_as_appen Office 365 Exchange Online - Como otorgar
full_access_as_apprequiere privilegios de administrador, surgieron críticas de que la cuenta de prueba tenía una configuración errónea con permisos excesivos en el entorno de producción - Una cuenta de prueba fuera del principio de mínimo privilegio y el password spraying basado en proxies residenciales dificultaron la detección tradicional centrada en indicadores de compromiso
De una cuenta de prueba al acceso al correo
- Hackers estatales rusos explotaron credenciales débiles mediante password spraying para iniciar sesión en una “legacy non-production test tenant account”
- Esa cuenta de prueba no estaba protegida con autenticación multifactor
- Después, se obtuvieron permisos que permitieron acceder a las cuentas de correo de altos ejecutivos de Microsoft y de empleados de los equipos de seguridad y legal
- El grupo atacante Midnight Blizzard abusó del protocolo de autenticación OAuth para mantener acceso persistente a cuentas de correo con privilegios
- Creó una aplicación maliciosa en el tenant de prueba comprometido
- Le otorgó a la app permisos para acceder a todas las direcciones de correo del servicio de email de Microsoft Office 365
- Usó una aplicación OAuth de prueba existente para asignar el rol
full_access_as_appde Office 365 Exchange Online
Una cuenta de prueba legacy con privilegios de administrador
- La actualización de Microsoft incluyó que una “legacy test OAuth application” tenía acceso elevado dentro del entorno corporativo de Microsoft
- Según Kevin Beaumont, para asignar el rol
full_access_as_appa una app OAuth, la cuenta debe tener privilegios de administrador - Beaumont calificó esta configuración como “un error de configuración bastante grande en producción”
- También surgieron críticas de que es difícil imaginar una razón válida para otorgar y mantener permisos tan amplios a una antigua cuenta de prueba legacy
- Microsoft se negó a explicar por qué la cuenta de prueba fue configurada así desde el principio y por qué se mantuvo de ese modo incluso después de quedar como legacy
Una configuración fuera del principio de mínimo privilegio
- Esta configuración rompe el principio de mínimo privilegio, según el cual una cuenta solo debe tener los permisos mínimos necesarios para realizar su trabajo
- El problema central es que resulta difícil entender por qué una cuenta de prueba legacy tendría que contar con privilegios de administrador
- Beaumont lo comparó con tener un usuario Domain Admin de un sistema de producción dentro de un dominio de pruebas sin seguridad, MFA, firewall ni monitoreo
- Un usuario Domain Admin tiene privilegios totales de administrador sobre los dispositivos conectados a la red, incluidos los controladores de dominio y Active Directory
- Como es la cuenta más poderosa de la red, debe estar aislada y rara vez debería formar parte de sistemas de producción
- Si una cuenta así queda expuesta sin una contraseña fuerte ni medidas de seguridad estándar, el daño puede ser enorme
Otras intrusiones organizacionales y password spraying sigiloso
- Microsoft detectó que Midnight Blizzard también comprometió a otras organizaciones y notificó a las afectadas
- Hewlett-Packard Enterprises también informó que su red fue hackeada por Midnight Blizzard
- La intrusión ocurrió en mayo
- No fue detectada ni bloqueada sino hasta diciembre
- El password spraying usado para acceder a la cuenta de prueba se realizó contra un número limitado de cuentas y con pocos intentos por cuenta
- Los atacantes usaron una infraestructura distribuida de proxies residenciales para hacer menos visible la actividad maliciosa
- Se conectaban desde direcciones IP con buena reputación
- Usaban direcciones IP ubicadas en regiones esperadas
- Hacían que el tráfico pareciera mezclarse con el de usuarios legítimos
Los límites de la detección tradicional basada en indicadores de compromiso
- El uso de proxies residenciales no es una técnica nueva, y también se utilizó en el ataque a la cadena de suministro de SolarWinds de 2020
- Ese ataque a SolarWinds también ha sido vinculado a Midnight Blizzard
- Como los proxies residenciales enrutan tráfico a través de una gran cantidad de IP de usuarios legítimos, la detección tradicional basada en indicadores de compromiso se vuelve prácticamente difícil
- Midnight Blizzard es el grupo que los gobiernos de Estados Unidos y Reino Unido han dicho que opera para el servicio de inteligencia exterior ruso, el SVR
- Otros nombres usados para rastrear al mismo grupo incluyen APT29, the Dukes, Cloaked Ursa, UNC2452 y Dark Halo
1 comentarios
Opiniones en Hacker News
Me recuerda a un viejo hackeo de Roblox del que escuché hace tiempo. Había un sitio de staging no productivo donde los usuarios podían registrarse, con un banner que decía “lo que está aquí no es permanente”.
Se agregó una nueva cuenta de administrador en el entorno de producción, y alguien se registró en el sitio de staging con el mismo nombre de usuario; luego usó esa cookie y esos tokens para apoderarse de la cuenta de producción y comprometer el sitio.
Si se generan tokens criptográficos basados en el nombre de usuario o el ID de usuario sin usar secretos distintos para producción y staging, o si el sitio de staging se comunica con servicios externos y se mezcla con la autorización de producción, no creo que este tipo de problema sea tan raro.
En cuanto nos dimos cuenta, lo informamos de inmediato y con honestidad.
En las grandes empresas, la frontera entre desarrollo y producción tiene muchos más agujeros de los que a la gente le gusta pensar.
Pensemos en un día típico: inicias sesión en la PC, revisas el correo y luego entras al portal de Azure con las mismas credenciales. Al final, todo está atado al mismo tenant, y la cuenta también está conectada a GitHub y a cuentas de nube.
Se crean Groups y Teams por todos lados, y cosas que nacieron para usar Teams o OneDrive, con permisos sospechosos, quedan dentro del directorio corporativo casi indistinguibles de los grupos de seguridad.
De vez en cuando llega un correo automático de “¿todavía necesitas esto?”, pero el mensaje es opaco, y en una empresa muy grande ni siquiera hay alguien claro a quién preguntarle. La mesa de ayuda responde recién dos días después, y tampoco puedes preguntarle a John Savill por Twitter, así que terminas haciendo clic en confirmar y sigues adelante.
Al final, el tejido de la organización empieza a rasgarse, y el atacante entra con suerte por un punto débil, hace movimiento lateral dentro del tenant y se lleva lo que quiere.
Como dijo un CISO inteligente, los hackers no irrumpen: inician sesión.
Claro, parte de que todos usan cosas como Microsoft Cloud, Skype, Twitter y OneDrive, e incluso suelta un nombre de persona para que suene verosímil.
Sobre la frase de Kevin Beaumont: “Solo una cuenta con permisos de administrador puede otorgarle a una app OAuth el rol full_access_as_app, que es casi de acceso total. Alguien cometió un error de configuración bastante grande en producción”; visto sin conocer los detalles del sistema, eso no parece el problema central.
No debería existir forma de cometer ese error. Quienes lo diseñaron y quienes lo operan deberían haberlo hecho imposible, y ahí está la responsabilidad.
Si construyes y operas una fábrica con un botón que electrocuta a todos los de adentro, y alguien lo presiona por accidente, está claro dónde está el problema.
Durante años recibí varias veces solicitudes para ignorar todas las políticas, procedimientos, regulaciones y leyes, y darle permisos de superadministrador/root a algún VIP que no necesitaba en absoluto esos permisos.
Hoy todo empeora porque todo funciona como puestos cruzados, tiempo parcial, doble rol, triple rol.
También he visto control de acceso basado en roles con más roles que permisos reales asignables. Eso hace que el propósito del RBAC se derrumbe por sí solo. Asignar permisos individualmente era más rápido, pero no lo permitían porque entonces el rol no aparecía en el reporte.
Esto no viene del personal técnico, sino de un mal liderazgo.
Una vez diseñé una extensión para mitigar este problema en el sistema de permisos RBAC del ERP interno. Agregué un tipo llamado “excepción de permisos”, de modo que a quienes necesitaran permisos fuera de su rol se les asignaran de esa forma, y así se pudiera generar un reporte con la lista de personas capaces de realizar tareas fuera de su función laboral.
Al final solo fue agregar una bandera a los permisos, pero funcionó bien. RR. HH. revisaba cada trimestre las excepciones de permisos para considerar eliminarlas, y en vez de que la mesa de ayuda de medio tiempo abriera permisos a prueba y error, alguien con autoridad y conocimiento real podía controlarlos.
Es gracioso que haya montones de elegantes certificaciones de seguridad que dicen proteger empresas e industrias con riesgos cuantificables, mientras se ignoran por completo las mejores prácticas sensatas y reflexivas escritas en un libro de 36 dólares en Amazon.
La seguridad parece una campaña de listones.
Quien vende seguridad como producto está estafando.
A los empleados comunes casi no les interesa la seguridad como tal; simplemente hacen su trabajo.
Hay tantos servidores, aplicaciones y configuraciones que no alcanza con que los empleados con conciencia de seguridad lo revisen todo.
Si miras el tiempo suficiente, en cualquier empresa tarde o temprano habrá algo abierto que no debería estarlo. Eso es exactamente lo que hacen los grupos de hackers: buscar grietas constantemente.
Como la empresa, mientras opera, tiene que seguir creando nuevos servidores y nuevas configuraciones, no es un problema de configurarlo una vez y olvidarse.
Odio cuando llego a un nuevo trabajo y alguien me da un montón de permisos porque “así es más fácil”. No deberían hacerlo.
No solo expone a la empresa a una intrusión, también me pasa a mí una responsabilidad que no quiero. Podría arruinar algo importante por accidente, y si algo es hackeado, la gente podría sospechar de mí solo porque tenía esos permisos.
En la práctica, estamos viviendo algo parecido a los pop-ups de seguridad de Windows XP a nivel de servicios. En cada paso de una tarea te piden autenticarte en otra cosa, y conseguir las credenciales correctas con los permisos adecuados puede tardar días.
Humanamente, se entiende que el equipo de soporte se rinda y le tire al nuevo empleado todas las cuentas y permisos de una vez.
Lo que falta en este texto es cómo definen los autores “producción” si una cuenta no productiva tiene permisos de administrador del dominio de producción.
Por eso no ayuda mucho enfocarse en el ángulo de que “en una empresa de 220 mil personas, alguien se equivocó en algún momento”.
Pero en la mayoría de las empresas suele haber una línea firme y gruesa entre los sistemas de producción y los de prueba. Darle acceso de producción a una cuenta de prueba debería ser prácticamente imposible, así que el foco de la investigación debería ser cómo pudo ocurrir algo así.
He visto casos peores. Trabajé en un despacho de abogados donde les daban a los administradores y socios acceso de administrador a todo.
Después de restablecer una contraseña, la contraseña predeterminada era “passme”, porque la original era demasiado larga y difícil de recordar. Se suponía que debían cambiarla después de iniciar sesión en el servidor.
Un hacker comprometió varias de esas cuentas, tocó varias cosas y robó datos. Algunas cuentas de prueba también tenían permisos de administrador.
Me alegra ya no trabajar ahí. Yo era analista programador y solo tenía permisos de administrador sobre mi PC para poder hacer funcionar Visual BASIC 6.0.
Este patrón, en todo el ecosistema de Microsoft, es más la regla que la excepción, pero que Microsoft mismo lo haya hecho es especialmente vergonzoso.
El equipo de seguridad de Microsoft ha dedicado bastante esfuerzo a herramientas y documentación de buenas prácticas para evitar incidentes grandes como este.
M365 es bastante malo para hacer obligatoria la autenticación multifactor. Está diseñado para que tengas que pagar.
El problema más grande es que la gente se olvida. Creas cinco cuentas de prueba con permisos de administrador y no salen a la luz hasta que alguien hace una auditoría de permisos de usuarios en toda la empresa.
Una empresa donde trabajé antes tenía todas las contraseñas de servidores y bases de datos de producción en archivos de texto dentro del repositorio de código. La razón era que al arquitecto principal no le gustaba recordar contraseñas.
Cuando le dije al CTO lo estúpido que era eso, me respondió: “confiamos en nuestros empleados” y “pasamos la auditoría de seguridad”.
Todavía me duele la cara de tanto darme un facepalm.
Son solo una molestia, no una función de seguridad. No uso contraseñas tipo “c00lz500”; más bien uso algo como una cadena vacía.
En su lugar, uso firewalls y redes internas.