Incident d’accès root AWS sur Rubygems.org – septembre 2025

• En septembre 2025, le compte root AWS de Rubygems.org a fait l’objet d’un accès non autorisé
• Les résultats de l’enquête publique ont confirmé qu’il n’existe aucune preuve de compromission ni d’exposition des données utilisateurs ou de l’environnement d’exploitation
• La cause principale est l’absence de changement immédiat du mot de passe du compte root AWS après la révocation des droits d’un ancien employé, ainsi que des lacunes dans la gestion des identifiants partagés
• Après l’incident, tous les identifiants et mots de passe ont été renouvelés, les audits de sécurité renforcés, et les audits externes comme les processus de modification des droits ont été améliorés
• L’éthique d’entreprise, la confidentialité des données et une communication transparente sont soulignées à plusieurs reprises, avec un engagement clair pour rétablir la confiance de la communauté

---

Vue d’ensemble et contexte

Ruby Central a publié en septembre 2025 un rapport officiel d’analyse a posteriori concernant l’incident de compromission de l’accès root AWS de Rubygems.org. Le document présente de manière transparente le déroulement de l’incident, les résultats de l’enquête, les erreurs commises et les mesures prévues pour renforcer la sécurité à l’avenir.

L’incident a commencé lorsqu’un billet de blog public a révélé qu’André Arko, ancien administrateur, pouvait encore accéder à l’environnement de production de Rubygems.org ainsi qu’aux outils de supervision après la révocation de ses droits. Ruby Central a alors immédiatement concentré ses efforts sur l’intégrité du service et la protection des données utilisateurs, tout en présentant publiquement ses excuses.

Chronologie de la réponse à l’incident

Principales étapes du 30 septembre 2025

• 17:23 UTC : André Arko signale par e-mail qu’il dispose toujours d’un accès root
• 17:30 UTC : un billet de blog tiers rend publics l’accès au compte root et des captures d’écran
• 17:51 UTC : Ruby Central constitue une équipe d’enquête et commence l’examen complet des services et des identifiants
• 18:20 UTC : confirmation que l’ancien mot de passe a été invalidé
• 18:24 UTC : réinitialisation du mot de passe du compte root AWS et récupération du compte via authentification MFA
• 18:30 UTC : consultation du « Credentials Report », confirmant qu’une personne non autorisée avait changé le mot de passe root le 19 septembre
• 20:45 UTC : suppression de tous les sous-comptes et identifiants legacy, réémission du MFA et stockage des nouveaux identifiants dans un coffre-fort séparé

Détails du déroulement de l’incident

L’ensemble de l’infrastructure de Ruby Central fonctionne sur AWS, et les identifiants du compte root étaient stockés dans un coffre-fort partagé accessible uniquement à trois personnes (deux actuelles, une ancienne).

18 septembre 2025

• 18:40 UTC : Arko reçoit par e-mail la notification de la révocation de son accès à la production et de ses droits de service d’astreinte
• Les identifiants AWS qu’utilisait Arko ont été supprimés, mais le mot de passe du compte root n’a pas été renouvelé

19 septembre 2025 : début de l’attaque

• 04:34~04:39 UTC : depuis une IP de San Francisco, connexion root non autorisée, changement de mot de passe, retrait des groupes/politiques d’autorisations, et activité d’inventaire complète sur IAM

28 septembre 2025

• 05:49 UTC : session non autorisée depuis une IP de Tokyo, inspection des métadonnées utilisateurs via l’API d’introspection IAM
• (période coïncidant avec la conférence Kaigi on Rails, ce qui laisse penser à la même personne)

30 septembre 2025

• 15:25~15:35 UTC : accès root depuis une IP de Los Angeles, exécution de commandes visant à obtenir les identifiants utilisateurs (correspondant aux captures d’écran partagées sur le blog)
• 18:24 UTC : Ruby Central reprend le contrôle du compte root

Impact et étendue des dommages

• Après examen approfondi, aucune preuve d’atteinte aux données utilisateurs, aux comptes, aux gems ou à la disponibilité du service n’a été trouvée
• Rubygems.org est resté opérationnel pendant toute la durée de l’incident
• Aucune donnée sensible, comme des PII ou des données financières, n’a été consultée ni exfiltrée
• Aucun changement n’a été constaté dans la base de données de production, S3 ou la CI/CD
• En revanche, l’absence de rotation des identifiants partagés et l’exposition prolongée des accès constituaient une défaillance grave des procédures opérationnelles

Processus de résolution

• Révocation de tous les identifiants root et IAM et mise en place d’un nouveau MFA
• Rotation complète des tokens liés aux intégrations externes concernées (Datadog, GitHub Actions, etc.)
• Renforcement de la supervision en temps réel des changements critiques via AWS CloudTrail, GuardDuty et DataDog
• Réexamen de la structure des autorisations IAM et suppression des privilèges inutiles
• Lancement d’un audit de sécurité complet incluant des experts externes
• Rédaction d’un nouveau runbook de sécurité (rotation immédiate des mots de passe en cas de changement d’effectif, contrôles trimestriels, processus de communication en cas d’incident inclus)

Analyse de la cause racine

• Absence de prise en compte du fait que la gestion partagée des mots de passe pouvait avoir été copiée à l’extérieur
• En cas de départ d’un collaborateur, le mot de passe root AWS et le MFA n’ont pas été renouvelés
• Ces deux facteurs ont créé la possibilité pour une personne non autorisée d’accéder à l’infrastructure de production de Rubygems et de tenter de contester le contrôle des accès

Mesures de prévention contre une récidive

• Extension de la procédure et de la checklist de révocation d’accès à la gestion des coffres-forts partagés
• Rotation immédiate des identifiants non fédérés, en particulier les identifiants partagés, lors de tout changement de personnel
• Délégation d’un audit de sécurité indépendant à un prestataire externe
• Mise en place d’un accord clair pour les opérateurs et contributeurs définissant qui peut obtenir des droits de production et à quelles conditions

Pourquoi cela a été traité comme un incident de sécurité

• L’origine réside dans un problème de contrôle de systèmes critiques par une seule personne
• M. Arko fournissait un service d’astreinte secondaire en tant que conseil rémunéré à hauteur de 50 000 dollars par an ; après modification de la structure budgétaire, il a proposé, en échange d’une astreinte non rémunérée, un accès aux logs HTTP de production (incluant des Pll) ainsi que des possibilités de monétisation
• Cette proposition soulevait des problèmes fondamentaux de gouvernance, de confidentialité et de conflit d’intérêts, que Ruby Central a jugés inacceptables, ce qui a conduit à une refonte de la structure d’exploitation et de la gouvernance
• La confirmation qu’Arko conservait un accès à des systèmes contenant des PII a constitué l’élément déterminant pour classer l’affaire comme incident de sécurité
• À ce jour, aucune preuve n’indique que des données Rubygems aient été extraites ou conservées à l’extérieur, et un engagement est pris en faveur du rétablissement de la confiance de la communauté et d’une transparence accrue

Conclusion

• Remerciements à la communauté pour son soutien et sa vigilance constructive
• Ruby Central continuera d’assurer la stabilité et la fiabilité de Rubygems.org grâce à une gouvernance transparente, un sens des responsabilités affirmé et un dispositif de sécurité renforcé

Shan Cureton
Executive Director