Amazon Web Services (AWS) es reconocido mundialmente por proveer infraestructura de nube segura y confiable. Sin embargo, incluso dentro de sus mejores esfuerzos para mejorar la seguridad, ocurren errores que pueden abrir puertas a riesgos significativos. Un claro ejemplo de esto fue el desarrollo de una herramienta llamada Account Assessment para AWS Organizations, diseñada para auditar políticas de acceso entre cuentas, que inesperadamente introdujo una vulnerabilidad grave de escalación de privilegios cruzados en ambientes empresariales que siguen sus indicaciones. Esta herramienta, publicada en la biblioteca oficial de soluciones de AWS, tiene el objetivo de centralizar la evaluación y gestión de cuentas dentro de una organización AWS Organizations. Facilita procesos complejos como auditorías de seguridad, fusiones y adquisiciones y transiciones de cuentas administrativas, proporcionando un solo punto de acceso para examinar dependencias de cuenta y políticas de acceso.
La arquitectura de la herramienta sigue un patrón hub-and-spoke: un rol central (hub) es desplegado para asumir roles en las demás cuentas (spokes), recopilando así datos de seguridad a nivel organizacional. El problema radica en una recomendación explícita en la guía oficial de despliegue que indicaba no instalar el rol hub en la cuenta de administración de AWS Organizations, sino en cualquier otra cuenta miembro dentro de la organización. Esta instrucción, aunque bien intencionada para evitar cargas de trabajo en la cuenta de administración, no advertía sobre las consecuencias de elegir cuentas con menores controles de seguridad. Esta omisión condujo a una práctica común donde el hub se desplegaba en cuentas de desarrollo, entornos sandbox o áreas menos críticas con políticas de seguridad más laxas. Esto creó un camino directo de confianza desde estas cuentas menos seguras hacia cuentas altamente sensibles, como las de producción o administración, facilitando un vector de ataque para escalar privilegios.
En casos extremos, un atacante que comprometiera una cuenta de desarrollo podía asumir roles privilegiados en producción o administración. El descubrimiento de esta vulnerabilidad surgió tras investigar un caso real de escalación de privilegios en un entorno AWS donde se evidenció la existencia de un rolcon extenso acceso a acciones críticas como listar roles IAM, políticas, secretos almacenados en Secrets Manager, buckets de S3 y claves de cifrado KMS. Lo peligroso era que las políticas concedían permisos globales sobre todos los recursos, aumentando exponencialmente el alcance del daño potencial. Una característica preocupante era que la cuenta de desarrollo, con controles más débiles, era la ubicación del rol hub, que a su vez podía asumir spoke roles en cuentas con datos sensibles. Además, los nombres predeterminados y predecibles de los roles utilizados por la herramienta facilitaban a posibles atacantes identificar y apuntar estos recursos durante un compromiso.
Este detalle operacional reducía la complejidad para realizar movimientos laterales o escalaciones de privilegios dentro de la organización. La obligación que AWS impuso de no usar la cuenta de administración para desplegar el hub viene motivada por la recomendación de no ejecutar cargas de trabajo en esta cuenta para evitar aumentar su superficie de ataque. No obstante, sin una alternativa claramente definida ni una orientación sobre seleccionar una cuenta igualmente segura para ubicar el hub, las organizaciones quedaron en una situación comprometida. Muchas tuvieron que implementar el hub en cuentas con niveles de seguridad menores, involuntariamente generando riesgos críticos. Tras detectar la vulnerabilidad, la organización responsable publicó un reporte detallado al equipo de seguridad de AWS.
La respuesta fue rápida y comprometida. AWS revisó la problemática, reconoció el potencial impacto en entornos reales y colaboró en mejorar y aclarar la documentación para evitar que otros usuarios replicaran la configuración insegura. Las modificaciones a la guía aconsejan ahora explícitamente ubicar el hub en cuentas con un nivel de seguridad equivalente al de la cuenta de administración, como podrían ser cuentas corporativas de DevOps o Infraestructura con controles estrictos. Así se cierra la brecha que permitía un camino inseguro entre cuentas, estabilizando la arquitectura de confianza del entorno organizacional. Para las organizaciones que hayan desplegado la herramienta antes de la actualización (enero de 2025), es prioritario identificar si el hub está en una cuenta insegura.
Existen formas de diagnosticar esta condición revisando los roles con nombres asociados a la herramienta, bien a través de la consola AWS o mediante comandos en la CLI, analizando fechas de creación para filtrar implementaciones previas a la corrección. Ante la detección de este riesgo, la recomendación es eliminar la implementación antigua, procediendo a desinstalar las pilas de CloudFormation correspondientes al hub, las spoke y al componente de gestión, para luego realizar un despliegue renovado siguiendo las nuevas directrices de seguridad. Este proceso es crítico para prevenir el uso malicioso del rol hub como puerta de entrada hacia la escalación de privilegios y el compromiso total de la organización. Este caso representa una lección fundamental sobre cómo incluso las soluciones diseñadas por el propio proveedor de la plataforma pueden introducir riesgos de seguridad si las instrucciones no consideran todos los factores operativos o no comunican claramente las implicaciones. Más allá de confiar ciegamente en la documentación oficial, las organizaciones deben aplicar procedimientos de auditoría, revisión y validación de arquitecturas de confianza y privilegios.
Además, la situación resalta la necesidad de contar con un enfoque proactivo y automatizado para identificar riesgos en las políticas de confianza y configuraciones IAM. Herramientas especializadas, como las que ofrece Token Security con su plataforma de seguridad basada en identidad, pueden detectar pólizas de confianza inseguras y configuraciones erróneas causadas tanto por errores humanos como por fallas en herramientas oficiales, ayudando a mitigar las vulnerabilidades antes de que sean explotadas. En resumen, el desarrollo y despliegue de la herramienta Account Assessment para AWS Organizations evidenció un riesgo inadvertido de escalación de privilegios debido a indicaciones imprecisas sobre dónde implementar el hub. Este fenómeno subraya la importancia de diseñar y mantener infraestructuras de nube con políticas de seguridad rigurosas, documentación clara y revisiones constantes, para reducir la superficie de ataque y evitar comprometer cuentas críticas dentro de una organización. La pronta respuesta de AWS para corregir la documentación muestra un compromiso positivo hacia la seguridad, pero también invita a los usuarios a estar siempre alertas y a verificar con rigor sus configuraciones de seguridad en la nube.
En un entorno tecnológico cada vez más complejo, entender cómo funcionan las políticas de confianza y las relaciones intercuentas es clave para garantizar una postura de seguridad sólida. Aprender de estos errores fomenta mejores prácticas, mayor concienciación y un diseño más robusto que protege a las organizaciones frente a amenazas avanzadas y persistentes en la nube.
