Recordando un antiguo caso de hackeo de Roblox, en un sitio de staging no productivo los usuarios podían registrarse y había un banner que decía: "Nada de aquí es permanente". Cuando se agregó una nueva cuenta de administrador a una cuenta de producción, alguien se registró en el sitio de staging con el mismo nombre de usuario y usó cookies y tokens para secuestrar la cuenta de producción y poner en riesgo el sitio. No es difícil imaginar que este tipo de problema no sea raro: cuando se generan tokens cifrados basados en el nombre o ID de usuario, si no hay secretos distintos para producción/staging, o si el sitio de staging se comunica con servicios externos que confunden los privilegios de producción.
La frontera entre desarrollo y producción en las grandes empresas es mucho más permeable de lo que la gente cree. Si se piensa en un día normal, inicias sesión en tu PC, revisas el correo y luego entras al portal de Azure usando las mismas credenciales (todo respaldado por el mismo tenant). La cuenta está conectada a GitHub y a las cuentas de la nube.
Para poder trabajar en Teams o OneDrive, se crean por todas partes grupos y equipos con permisos difíciles de entender, y estos quedan en el directorio de la empresa como grupos de seguridad casi indistinguibles.
A veces llegan correos automáticos preguntando si todavía usas algo que necesitas, pero los mensajes son opacos, y en una empresa realmente grande no hay a quién preguntarle (la mesa de ayuda tarda dos días en responder y tampoco puedes contactar a John Savill por Twitter, así que solo presionas confirmar y sigues adelante).
Al final, la estructura se desgarra y un atacante tiene suerte en un punto débil, logrando obtener lo que quiere a través de tenants.
Como dijo una vez un CISO sabio, los hackers no irrumpen: inician sesión.
En la industria de la ciberseguridad, esto se conoce comúnmente como un "whoopsie".
El investigador y experto en seguridad Kevin Beaumont señaló en Mastodon que una cuenta capaz de asignar el rol 'full_access_as_app' a aplicaciones OAuth debería requerir privilegios de administrador. Dijo que "alguien" cometió un error de configuración bastante grande en producción.
No conozco los detalles del sistema, pero no parece que ese sea el problema, y me sorprende que un experto diga que sí lo es. No debería existir forma de cometer ese error. Los diseñadores y administradores deberían hacer que fuera imposible, y ellos deberían rendir cuentas por ello.
A pesar de las elegantes certificaciones de seguridad, parece que se están ignorando por completo buenas prácticas bien pensadas de un libro de $36 en Amazon.
Lo que falta en esta publicación: cómo definen los autores "producción" y en qué caso una cuenta "no productiva" puede tener privilegios administrativos sobre un dominio de producción.
Este patrón es la regla, no la excepción, en todo el ecosistema de MS, pero que la propia Microsoft lo haga resulta especialmente vergonzoso.
En una empresa, guardaban las contraseñas de todos los servidores y bases de datos de producción en un archivo de texto dentro del repositorio de código, porque el arquitecto principal no quería recordarlas. Cuando le señalé al CTO lo absurdo que era, me respondió: "Confiamos en nuestros empleados" y también "Pasamos la auditoría de seguridad".
Cuando llego a un nuevo trabajo, odio que alguien me asigne muchos privilegios "porque es más fácil". No deberían hacerlo. No solo expone a la empresa, sino que además te deja con responsabilidades que no quieres. Podrías arruinar algo importante por accidente y, si te hackean, podrían sospechar que fuiste tú porque tenías los permisos.
¿Por qué esto se considera un "error"? También podría ser la acción de un espía que trabaja como administrador en Microsoft.
1 comentarios
Opinión de Hacker News