Incidente de acceso root de AWS en Rubygems.org – septiembre de 2025

• En septiembre de 2025, ocurrió un incidente de acceso no autorizado a la cuenta root de AWS de Rubygems.org
• La investigación pública confirmó que no hay evidencia de compromiso ni exposición de los datos de usuarios ni del entorno operativo
• La causa principal fue no cambiar de inmediato la contraseña de la cuenta root de AWS tras revocar los permisos de una persona que dejó el cargo, junto con una gestión deficiente de credenciales compartidas
• Después del incidente, se rotaron todas las credenciales y contraseñas, se reforzaron las auditorías de seguridad y se mejoraron los procesos de auditoría externa y cambio de permisos
• Se enfatizan repetidamente la ética corporativa, la privacidad de los datos y la comunicación transparente, dejando claro el esfuerzo por recuperar la confianza de la comunidad

---

Resumen y contexto

Ruby Central publicó un informe oficial de análisis posterior al incidente sobre la vulneración del acceso root de AWS de Rubygems.org ocurrida en septiembre de 2025. El documento organiza de forma transparente cómo ocurrió el incidente, los resultados de la investigación, qué se manejó incorrectamente y qué medidas se tomarán para reforzar la seguridad a futuro.

El incidente comenzó cuando, a través de un blog público, se reveló que el exadministrador André Arko aún podía acceder al entorno de producción de Rubygems.org y a las herramientas de monitoreo incluso después de que se le revocaran los permisos. Ruby Central se enfocó de inmediato en la integridad del servicio y en la protección de los datos de los usuarios, y expresó públicamente sus disculpas.

Línea de tiempo de respuesta al incidente

Flujo principal del 30 de septiembre de 2025

• 17:23 UTC: André Arko notificó por correo electrónico que todavía tenía acceso root
• 17:30 UTC: Una publicación de blog de un tercero hizo públicos el acceso a la cuenta root y capturas de pantalla
• 17:51 UTC: Ruby Central formó un equipo de investigación del incidente y comenzó a revisar todos los servicios y credenciales
• 18:20 UTC: Se confirmó que la contraseña anterior había sido invalidada
• 18:24 UTC: Se restableció la contraseña de la cuenta root de AWS y se recuperó la cuenta mediante autenticación MFA
• 18:30 UTC: Mediante la consulta de “Credentials Report” se confirmó que una persona no autorizada cambió la contraseña root el 19 de septiembre
• 20:45 UTC: Se revocaron todas las subcuentas y credenciales heredadas, se reemitió MFA y las nuevas credenciales se guardaron en una bóveda independiente

Desarrollo detallado del incidente

Toda la infraestructura de Ruby Central opera en AWS, y las credenciales de la cuenta root estaban guardadas en una bóveda compartida accesible solo por tres personas (dos actuales y una exintegrante).

18 de septiembre de 2025

• 18:40 UTC: Arko recibió por correo electrónico la notificación de revocación de su acceso a producción y de sus permisos de servicio on-call
• Se eliminaron las credenciales de AWS que usaba Arko, pero la contraseña de la cuenta root no fue rotada

19 de septiembre de 2025: inicio del ataque

• 04:34~04:39 UTC: Desde una IP de San Francisco, una persona no autorizada inició sesión como root, cambió la contraseña, se salió de grupos/políticas con privilegios y realizó una revisión completa de IAM

28 de septiembre de 2025

• 05:49 UTC: Se produjo una sesión no autorizada desde una IP de Tokio, y se revisaron metadatos de usuarios mediante la API de introspección de IAM
• (Coincidió en el tiempo con la conferencia Kaigi on Rails; se presume que fue la misma persona)

30 de septiembre de 2025

• 15:25~15:35 UTC: Acceso root desde una IP de Los Ángeles, con ejecución de comandos para obtener credenciales de usuario (coincide con las capturas compartidas en el blog)
• 18:24 UTC: Ruby Central recuperó el control root

Impacto del incidente y alcance del daño

• Tras una revisión minuciosa, no se encontró evidencia de afectación en datos de usuarios, cuentas, gems ni disponibilidad del servicio
• Rubygems.org operó con normalidad durante todo el incidente
• No hubo acceso ni filtración de información sensible como PII o datos financieros
• No hubo cambios en la base de datos de producción, S3 ni CI/CD
• Aun así, la falta de rotación de credenciales compartidas y la exposición prolongada del acceso constituyeron una falla grave de los procedimientos operativos

Proceso de resolución del incidente

• Revocación de todas las credenciales root e IAM y aplicación de nuevo MFA
• Rotación completa de tokens de integraciones externas relacionadas (DataDog, GitHub Actions, etc.)
• Refuerzo del monitoreo en tiempo real de cambios críticos mediante AWS CloudTrail, GuardDuty y DataDog
• Revisión de la estructura de permisos de IAM y revocación de privilegios innecesarios
• Inicio de una auditoría integral de seguridad con expertos externos
• Redacción de un nuevo runbook de seguridad (rotación inmediata de contraseñas ante cambios de personal, revisiones trimestrales y proceso de comunicación durante incidentes)

Análisis de causa raíz

• No se reconoció la posibilidad de replicación externa en la gestión de contraseñas compartidas
• Ante la salida de personal, no se rotaron la contraseña root de AWS ni MFA
• Estos dos factores permitieron la posibilidad de acceso no autorizado a la infraestructura de producción de Rubygems y de intentos de disputa por el control de acceso

Medidas para prevenir recurrencias

• Ampliar los procedimientos y listas de verificación de revocación de acceso para incluir también la gestión de bóvedas compartidas
• Rotar de inmediato las credenciales no federadas (en especial las compartidas) ante cualquier cambio de personal
• Delegar una auditoría de seguridad independiente a terceros
• Introducir un acuerdo claro para operadores y colaboradores sobre a quién se le otorgan permisos de producción y bajo qué condiciones

Por qué se trató como incidente de seguridad

• Se originó en un problema de control de sistemas críticos concentrado en una sola persona
• El Sr. Arko ofrecía un servicio secundario de on-call como consultoría pagada por USD 50,000 al año y, tras un cambio en la estructura presupuestaria, propuso ofrecer on-call sin costo a cambio de acceso a logs HTTP de producción (incluyendo PII) y oportunidades de monetización
• Ruby Central consideró que esta propuesta implicaba problemas esenciales de gobernanza, privacidad y conflicto de interés, y concluyó que no podía aceptarla, por lo que avanzó con una reestructuración operativa y de gobernanza
• La confirmación de que Arko seguía teniendo acceso a sistemas con PII fue un fundamento decisivo para clasificarlo como incidente de seguridad
• Hasta ahora no hay evidencia de que los datos de Rubygems se hayan extraído o almacenado fuera, y se promete recuperar la confianza de la comunidad y mejorar la transparencia

Conclusión

• Se agradece el apoyo de la comunidad y su supervisión constructiva
• Ruby Central seguirá garantizando la estabilidad y confiabilidad de Rubygems.org mediante una operación transparente, responsabilidad y un sistema de seguridad reforzado

Shan Cureton
Executive Director