La cuenta fue comprometida después de la interrupción de AWS

Después de la interrupción de servicio ocurrida en AWS recientemente, un usuario experimentó un incidente en el que su cuenta de AWS fue secuestrada por un atacante externo

Ruta de intrusión y situación del problema

• Durante el período de la falla, se señaló que algunas políticas de seguridad podrían no haber funcionado correctamente
• El atacante dejó rastros de acceso anómalos en los logs de cuenta, y se observaron casos de creación/eliminación inesperada de algunos recursos
• El usuario manifestó preocupación por una posible modificación de permisos o exposición de credenciales de autenticación junto con la falla

Daños y respuesta

• Se produjeron daños concretos, como incremento de costos y filtración de datos
• Se contactó al soporte de AWS para consultar el registro del incidente y los métodos de respuesta
• En la comunidad se enfatizó la importancia de la prevención previa, como activar la autenticación de dos factores y la mínima concesión de acceso basada en roles

[GN⁺]

Opinión de Hacker News

• Normalmente uno pensaría que esto es simple coincidencia, pero también tuve un caso de cuenta de cliente comprometida. El cliente era una organización pequeña y de repente aparecieron inicios de sesión en consola y cambios de contraseña en dos cuentas viejas de IAM que no se usaban desde hacía más de cinco años. En la investigación, lo único que apareció fue que se habilitó acceso de producción de AWS SES y se dejó un ticket de soporte para subir el límite diario de correo a 50,000. Es muy raro que una cuenta con más de cinco años de inactividad se activara justo en este momento.

  • Huele a ataque de phishing. Por ejemplo, recibir un correo que imita un anuncio de incidente de AWS y llevarte a iniciar sesión en la consola; si autenticas con un wrapper malicioso, la cuenta queda comprometida.
  • Viví algo casi igual hace un año. Inicié sesión con una cuenta muy antigua, accedí a SES y luego pedí aumentar el límite de correo. Pudimos responder rápido porque el ticket de aumento era imprescindible. Si aún no lo han revisado, también conviene revisar los Roles recién creados. Nosotros limpiamos de inmediato la cuenta comprometida; revisé los Roles en general y eliminé los que tenían menos de un mes o permisos de admin. Además se confirmó que la intrusión realmente empezó desde mi clave. La primera vez que se creó el usuario fue casi un mes antes de la solicitud real de SES, así que tal vez el atacante ya nos tenía comprometidos y aprovechó que ocurriera la caída de AWS para aprovechar la oportunidad. Puede haberse mezclado con otros problemas de AWS y pasar desapercibido.

• Desde el punto de vista de alguien que ya obtuvo acceso, parece posible que esperara a que ocurriera un incidente de caos en la infraestructura de AWS y atacara en ese momento para esconderse en la confusión. Aunque un token se haya expuesto semanas o meses antes, una estrategia puede ser no actuar de inmediato y esperar hasta un gran incidente. Si yo fuera el atacante, querría probar esto.

  • Es totalmente posible. Como encargado de due diligence, también escuché casos reales. Los atacantes a veces preparan todo y esperan hasta que ocurra un evento clave como la venta de una compañía para moverse. Los atacantes más sofisticados se preparan con antelación para ese tipo de oportunidades.
  • Siendo del mismo equipo, de hecho recibí hace 2 años un correo de alerta sobre la clave explotada hoy de una persona al azar. Pero hasta ayer no hubo ningún abuso.
  • A mí me parece que esto podría ser un mal timing para atacar. Todos estamos enfocándonos en AWS y entrando mucho, así que si hay algo raro se notaría más. Si nuestra compañía usa AWS, en estas circunstancias vigilaríamos todo con aún más cuidado.

• Si yo fuera el atacante, al elegir cuándo atacar, una gran incidencia en la que ni siquiera se agregan bien los logs puede ser una buena oportunidad. Tal vez la explotaron en este punto habiendo ya intrusión previa, o quizá aprovecharon la caída de AWS para lanzar otro ataque con mis recursos.

• En entornos cloud, si se crea un recurso extraño (EC2, etc.), se puede ver en CloudTrail qué evento lo originó, típicamente mirando el evento RunInstances.

  • No uso AWS mucho últimamente, así que no puedo revisar la consola directamente, pero si les pasa algo parecido recomiendo estos pasos aproximados:
    1. Revisar la cuenta/sujeto que creó el EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. Rastrear acciones posteriores por userIdentity
    3. Verificar historial de inicios de sesión en consola (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Revisar solicitudes de autenticación a Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. Verificar si se usó AssumeRole con una sesión STS (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. Verificar intentos de persistencia como creación de IAM Role/Account (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. Verificar si un Role/Account existente se modificó a permisos más altos (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Revisar historial de creación/eliminación de Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. Revisar el cambio de IAMInstanceProfile en EC2 de producción para ver posible backdoor (como referencia, ver la muestra de AWS Docs) Si se sospecha una intrusión más profunda, se recomienda contratar una revisión y auditoría profesional del entorno.
  • Es información útil, así que voy a revisar los logs. Además, algunos puntos adicionales que observé:
    1. Se crearon 20 organizaciones bajo la cuenta raíz y todas usan direcciones del mismo dominio de correo (co.jp)
    2. El atacante dejó múltiples plantillas de fargate
    3. Se crearon recursos en 16 y 17 regiones de AWS
    4. Solicitudes innecesarias de aumento de recursos: SES, aumento de cuota de recursos WS Fargate, solicitudes de mantenimiento de notebooks de SageMaker, etc. (recibí varios correos de alerta por esto)
    5. En algunos correos encontré la adición de nuevos nombres ([e-mail])
  • El evento RunInstances era justo ese evento.

• Algunos usuarios de Reddit dijeron que, durante la caída de AWS, al refrescar vieron que entraban por un instante como un usuario totalmente diferente.

  • En una compañía donde trabajé antes hubo algo parecido. Los clientes llegaban a datos de otros clientes, y la causa fue un empleado que intentó hacer live debugging en producción (sí, era alguien a quien en la entrevista yo había dicho que no debería haber sido contratado). Ese tipo de problemas era muy difícil de rastrear y resolver.
  • Me pregunto si durante la caída DynamoDB entró en un estado de inconsistencia temporal y eso también desordenó credenciales de IAM. Si fuera cierto, sería un problema serio. Me gustaría saber si hay un enlace de caso similar.
  • Si tienen evidencia de eso, compártanla. Es realmente impactante.
  • Me recordó a si hubo un issue similar con ChatGPT hace poco. Suena parecido.
  • Este incidente de seguridad es mucho más grave que un simple problema de indisponibilidad temporal del servicio.

• En condiciones normales, este tipo de incidente sería coincidencia, pero en general suele deberse a una access key expuesta. También hay casos de contraseñas expuestas en cuentas de consola sin MFA, aunque eso es algo menos común.

• En estados de pánico, la gente es más vulnerable al phishing. Hay que cambiar las contraseñas de manera amplia y avisar al equipo de AWS de la situación. Normalmente, confían y ayudan bien.

• La región us-east-1 es más grande de lo imaginado. Según la información pública reciente, hay 159 centros de datos. Podrían concentrarse allí cientos de miles o millones de cuentas. Este fenómeno podría estar conectado con la caída de AWS, pero personalmente creo que es más probable que sea coincidencia.

  • 159 es una locura. Si tienen una fuente para eso, sería bueno que la compartan.

• Suena raro, pero pensé que quizá si envían una API key podría comprobar si está en una lista de fuga.

  • Sé que suena como broma, pero aun así quiero advertir algo importante: aunque sea una broma, eviten mencionar o compartir API keys o credenciales. Alguien podría tomarlo en serio, así que hay que tener cuidado.