Investigadores de la firma Wiz han confirmado que un atacante logró comprometer varias cuentas de AWS pertenecientes a clientes de Qubole y extrajo secretos y datos almacenados. Según el análisis, el intruso utilizó credenciales asociadas a la cuenta de AWS que Qubole emplea para acceder a los entornos de sus clientes, lo que le permitió realizar llamadas AssumeRole y actuar con los permisos de los roles confiados.
Qué ocurrió y cómo funcionó la intrusión
Qubole es una plataforma de data lake que, para operar dentro de las cuentas de sus clientes en AWS, requiere que estos creen un rol de IAM cuya política de confianza permita a la cuenta de Qubole asumirlo. Cada petición de tipo AssumeRole debe incluir un código conocido como External ID. En los incidentes analizados, el atacante presentó dicho External ID en las solicitudes y AWS las aceptó porque provenían de la cuenta que el rol tenía marcada como de confianza.
Los investigadores señalan que muchos de los roles que el atacante asumió estaban inactivos (no se usaban habitualmente), pero aun así confiaban en la cuenta de Qubole, por lo que las solicitudes funcionaron. No se ha divulgado cómo consiguió el atacante las credenciales de la cuenta de Qubole ni si estas fueron deshabilitadas después del incidente.
Qué hizo el atacante dentro de las cuentas
- Buscó y leyó credenciales almacenadas: variables de entorno de funciones Lambda, secretos en AWS Secrets Manager y parámetros en SSM Parameter Store.
- Probó las credenciales encontradas con herramientas automáticas (por ejemplo, TruffleHog) para comprobar si eran válidas, usando claves de acceso de AWS, secretos de Entra ID y credenciales de Okta detectadas en los entornos víctimas.
- Copió datos almacenados en S3: en algunos casos descargó buckets enteros accesibles con los roles comprometidos en una sola sesión.
Los investigadores no han relacionado esta campaña con otras actividades publicadas y consideran que su patrón de selección de objetivos no coincide con el perfil habitual de grupos patrocinados por Estados.
Actividad previa con claves de acceso
Además del abuso de AssumeRole, los analistas detectaron otro periodo (del 8 al 11 de octubre) en el que un atacante distinto empleó claves de acceso de clientes que aparentemente habían sido configuradas para Qubole. Esa actividad afectó a algunos entornos y no se ha establecido si está vinculada al abuso posterior del rol de confianza.
Indicadores y recomendaciones para administradores
Wiz recomienda revisar los registros de CloudTrail desde el 1 de octubre en todas las cuentas de AWS que tengan un rol que confíe en la cuenta de Qubole (el análisis cita la cuenta 805246085872 asociada a la plataforma) y buscar solicitudes AssumeRole procedentes de esa cuenta que se originaron desde direcciones fuera de AWS.
Para cada sesión sospechosa, aconsejan revisar las acciones realizadas posteriormente, prestando atención a Secrets Manager, SSM Parameter Store, Lambda y S3. AWS registra en CloudTrail las llamadas AssumeRole y los listados de buckets, pero no registra qué objetos S3 fueron leídos; para eso hacen falta eventos de datos de S3 o los registros de acceso al servidor S3. Varios casos analizados carecían de esos registros, lo que impidió determinar exactamente qué objetos fueron exfiltrados.
Qué deben hacer los responsables de sitios y administradores
- Auditar roles de IAM que otorguen confianza a la cuenta de Qubole y desactivar roles que no se usen.
- Revisar CloudTrail desde el 1 de octubre y buscar AssumeRole desde la cuenta asociada a Qubole procedentes de orígenes externos a AWS.
- Habilitar eventos de datos de S3 o registros de acceso a objetos para poder rastrear lecturas y descargas en buckets.
- Comprobar Secrets Manager, SSM y variables de entorno en Lambda por posibles filtraciones de credenciales y rotar secretos comprometidos.
- Verificar y limitar el uso de External ID como única barrera; entender que ese código no se trata como un secreto y puede ser visible para cualquiera con acceso al rol.
El informe de Wiz pone de manifiesto una brecha en la visibilidad de identidades y la necesidad de controles adicionales cuando plataformas de terceros acceden a cuentas cloud mediante roles. No se ha publicado por el momento una declaración oficial de Qubole o del grupo Idera sobre este incidente.
Lee también:
- Francia atribuye al Cuerpo de la Guardia Revolucionaria de Irán un ciberataque que dañó sistemas de refrigeración en unos 700 supermercados
- Tailscale lanza OAuth apps GA para conectar agentes AI a redes privadas sin exponerlas
Fuente: The Hacker News
