Miles de claves de AWS expuestas públicamente siguieron funcionando durante años

Que una credencial aparezca en un repositorio público no significa necesariamente que continúe siendo peligrosa. El riesgo se vuelve activo cuando la clave no ha sido revocada, todavía permite autenticarse y conserva permisos relevantes. En esta investigación, las tres condiciones coincidieron con frecuencia.

Cientos de claves corporativas ofrecían control administrativo total

De las claves activas vinculadas a cuentas corporativas, 817 fueron atribuidas a empresas. El grupo incluía:

• 526 claves de cuentas raíz de AWS.
• 242 claves de usuarios de IAM asociadas a la política AdministratorAccess de AWS.
• 768 claves en total que ofrecían control administrativo completo sobre una cuenta corporativa de AWS.

Las credenciales raíz representan el nivel de control más alto disponible para un cliente de AWS. Por su parte, una identidad de IAM con AdministratorAccess puede operar en los servicios de AWS con permisos muy amplios. Una clave válida con cualquiera de estos niveles puede abrir la puerta a la toma de control de una cuenta, al acceso no autorizado a datos, a la creación de recursos o al uso fraudulento de la facturación en la nube.

Por eso, el problema no es solo de higiene del código fuente, sino también de permisos y gestión del ciclo de vida de las credenciales. Borrar una clave de un archivo visible no protege una cuenta si alguien ya la ha copiado: hay que revocarla o sustituirla.

Hugging Face fue la mayor fuente individual

Hugging Face concentró 8.482 exposiciones de credenciales de AWS, la cifra más alta entre las fuentes identificadas. Truffle Security informó de que el 17,9 % de esas credenciales eran claves raíz.

El hallazgo se enmarca en un análisis más amplio de datos públicos de Hugging Face. Truffle Security afirmó haber examinado 7,6 petabytes de conjuntos de datos públicos y haber encontrado credenciales activas en miles de ellos. El resultado muestra cómo los secretos pueden sobrevivir fuera de los repositorios de software convencionales y acabar integrados en datos distribuidos públicamente.

Para los equipos de seguridad, la conclusión es clara: revisar únicamente los repositorios actuales no basta. Los historiales de Git, artefactos de compilación, imágenes de contenedores, registros, conjuntos de datos publicados y salidas de CI pueden conservar credenciales incluso después de que los desarrolladores crean haberlas eliminado.

Muchas claves tenían años y apenas se habían rotado

La antigüedad mediana de las credenciales era de aproximadamente 1.831 días, es decir, unos cinco años. La clave más antigua tenía 17,4 años. Solo el 13,7 % de las entradas tenía asociada una clave más reciente, lo que sugiere que la mayoría no se había sustituido mediante un proceso normal de rotación.

Las claves de larga duración amplían el tiempo disponible para un uso no autorizado y dificultan determinar quién es responsable de ellas. También pueden sobrevivir a cambios de personal, migraciones de aplicaciones, limpiezas de repositorios y traspasos de responsabilidades operativas.

La antigüedad debe tratarse como una señal de riesgo. Una clave expuesta hace varios años no debe darse por obsoleta sin comprobarlo: hay que verificarla, revocarla e investigarla, salvo que su propietario pueda demostrar que ya no es válida.

Pocas cuentas tenían alertas presupuestarias

Truffle Security pudo consultar información de 2.754 cuentas, pero solo 262 tenían activadas las alertas presupuestarias de AWS.

Las alertas de presupuesto no sustituyen la revocación de credenciales ni la detección de amenazas, pero pueden advertir de que se están creando recursos costosos con una clave expuesta, por ejemplo, para minar criptomonedas o realizar otro tipo de abuso de la nube. Sin un sistema de notificaciones que llegue a alguien con capacidad de respuesta, un gasto anómalo puede continuar después de que una cuenta haya sido comprometida.

Qué resuelven —y qué no— las notificaciones de AWS

El informe describe mecanismos de AWS capaces de detectar claves de acceso divulgadas, avisar a los clientes afectados y aplicar restricciones o medidas de cuarentena. Sin embargo, la validez continuada de tantas claves probadas indica que la detección o la notificación no siempre condujeron a una revocación y rotación rápidas por parte de los clientes.

Detectar una filtración es solo el primer paso. Una respuesta completa debe identificar al propietario, determinar qué recursos puede alcanzar la credencial, comprobar si se ha utilizado de forma indebida e invalidarla.

Truffle Security caracteriza sus comprobaciones como de solo lectura: verificó la autenticación y consultó metadatos de permisos o de las cuentas, sin modificar recursos de los clientes. Esta descripción procede de Truffle Security y no está respaldada de forma independiente por todas las fuentes disponibles.

Qué hacer después de una filtración de claves de AWS

1. Revocar o rotar la clave de inmediato

Elimina o desactiva cualquier credencial expuesta públicamente y emite una nueva solo si el acceso sigue siendo necesario. Quitar el secreto de un repositorio, borrar un archivo o reescribir el historial de Git no invalida las copias que ya puedan existir.

2. Eliminar las claves de acceso raíz

Las claves del usuario raíz de AWS no deben utilizarse para el acceso programático habitual. Elimina las claves raíz y traslada las cargas de trabajo a identidades controladas con permisos estrictamente definidos.

3. Revisar permisos y responsables

Determina a qué cuenta, usuario, servicio y recursos pertenecía la credencial. Da prioridad a las claves con privilegios raíz, AdministratorAccess, acceso amplio a datos o capacidad para crear infraestructura.

4. Investigar antes y después de revocar

Revisa la actividad de autenticación, los registros de CloudTrail, los cambios en IAM, los recursos creados recientemente y la facturación en busca de indicios sospechosos. Revocar la clave impide nuevos usos, pero no demuestra si ya había sido utilizada.

5. Sustituir las claves permanentes por identidades temporales

Cuando sea posible, utiliza roles de IAM de corta duración e identidades de carga de trabajo en lugar de claves de acceso permanentes. Los permisos de mínimo privilegio reducen el impacto potencial de una filtración.

6. Activar alertas de presupuesto y establecer un canal de respuesta

Configura alertas de AWS Budgets y monitorización de anomalías de costes. Dirige las notificaciones a contactos capaces de actuar con rapidez. La supervisión financiera es una red de seguridad, no un sustituto del escaneo de secretos, la rotación de credenciales y la revisión de accesos.

La lección de fondo

El hallazgo más importante no fue solo el número bruto de secretos. Fue la combinación de exposición pública, validez continuada, privilegios elevados, antigüedad extrema y supervisión insuficiente. Los repositorios y almacenes de datos públicos pueden conservar credenciales mucho después de que una organización haya olvidado dónde se utilizaban, mientras que una clave copiada puede seguir funcionando hasta que alguien la revoque expresamente.

Para los equipos que gestionan servicios en la nube, la premisa más segura es sencilla: tratar toda credencial de AWS expuesta como comprometida, comprobar a qué puede acceder, revocarla o rotarla de inmediato y sustituir las identidades de larga duración por accesos temporales y con los mínimos privilegios necesarios.