Incidente de acesso root da AWS no Rubygems.org – setembro de 2025

• Em setembro de 2025, ocorreu um incidente de acesso não autorizado à conta root da AWS do Rubygems.org
• Os resultados da investigação pública confirmaram que não há evidência de comprometimento ou exposição de dados de usuários nem do ambiente operacional
• A principal causa foi não ter alterado imediatamente a senha da conta root da AWS após a revogação de acesso de um ex-integrante, além de falhas no gerenciamento de credenciais compartilhadas
• Após o incidente, todas as credenciais e senhas foram rotacionadas, as auditorias de segurança foram reforçadas, e a auditoria externa e os processos de alteração de permissões foram aprimorados
• Ética corporativa, privacidade de dados e comunicação transparente são enfatizadas repetidamente, deixando claro o esforço para restaurar a confiança da comunidade

---

Visão geral e contexto

A Ruby Central publicou, em setembro de 2025, um relatório oficial de análise pós-incidente sobre a violação de acesso root da AWS no Rubygems.org. O documento organiza de forma transparente como o incidente ocorreu, os resultados da investigação, o que foi tratado de forma inadequada e as medidas futuras para reforçar a segurança.

O incidente começou quando foi revelado, por meio de um blog público, que o ex-administrador André Arko ainda conseguia acessar o ambiente de produção e as ferramentas de monitoramento do Rubygems.org mesmo após a revogação de suas permissões. A Ruby Central passou imediatamente a focar na integridade do serviço e na proteção dos dados dos usuários, além de apresentar um pedido público de desculpas.

Linha do tempo da resposta ao incidente

Principais acontecimentos em 30 de setembro de 2025

• 17:23 UTC: André Arko informou por e-mail que ainda tinha acesso root
• 17:30 UTC: um post de blog de um terceiro tornou público o acesso à conta root e capturas de tela
• 17:51 UTC: a Ruby Central montou uma equipe de investigação do incidente e iniciou uma revisão de todo o serviço e das credenciais
• 18:20 UTC: foi confirmado que a senha anterior havia sido invalidada
• 18:24 UTC: redefinição da senha da conta root da AWS e recuperação da conta com autenticação MFA
• 18:30 UTC: por meio da consulta ao “Credentials Report”, foi confirmado que um agente não autorizado havia alterado a senha root em 19 de setembro
• 20:45 UTC: revogação de todas as subcontas e credenciais legadas, reemissão de MFA e armazenamento das novas credenciais em um cofre independente

Detalhes do desenrolar do incidente

Toda a infraestrutura da Ruby Central opera na AWS, e as credenciais da conta root estavam armazenadas em um cofre compartilhado acessível apenas por três pessoas (duas atuais e uma ex-integrante).

18 de setembro de 2025

• 18:40 UTC: Arko recebeu por e-mail o aviso de revogação de acesso à produção e das permissões do serviço de plantão
• As credenciais da AWS usadas por Arko foram excluídas, mas a senha da conta root não foi rotacionada

19 de setembro de 2025: início do ataque

• 04:34~04:39 UTC: um agente não autorizado, a partir de um IP de San Francisco, fez login root, alterou a senha, removeu grupos/políticas de autorizados e realizou atividades de varredura completa do IAM

28 de setembro de 2025

• 05:49 UTC: ocorreu uma sessão não autorizada a partir de um IP de Tóquio, com verificação de metadados de usuários via API de introspecção do IAM
• (coincidindo com a conferência Kaigi on Rails, presumivelmente a mesma pessoa)

30 de setembro de 2025

• 15:25~15:35 UTC: acesso root a partir de um IP de Los Angeles, com execução de comandos para obtenção de credenciais de usuários (correspondendo às capturas de tela compartilhadas no blog)
• 18:24 UTC: a Ruby Central recuperou o controle root

Impacto do incidente e escopo dos danos

• Após revisão minuciosa, não há evidência de comprometimento de dados de usuários, contas, gems ou disponibilidade do serviço
• O Rubygems.org operou normalmente durante todo o incidente
• Não houve acesso nem vazamento de informações sensíveis, como PII e dados financeiros
• Não houve mudanças no banco de dados de produção, no S3 nem no CI/CD
• Ainda assim, a não rotação de credenciais compartilhadas e a exposição prolongada de acesso constituíram uma falha grave de procedimento operacional

Processo de resolução do incidente

• Revogação de todas as credenciais root e IAM e aplicação de novo MFA
• Rotação completa dos tokens de integrações externas relacionadas (Datadog, GitHub Actions etc.)
• Reforço do monitoramento em tempo real de mudanças críticas com AWS CloudTrail, GuardDuty e DataDog
• Revisão da estrutura de permissões do IAM e revogação de acessos desnecessários
• Início de uma auditoria de segurança abrangente com participação de especialistas externos
• Criação de novos runbooks de segurança (incluindo rotação imediata de senhas em caso de mudanças de pessoal, revisões trimestrais e processo de comunicação em incidentes)

Análise da causa raiz

• Falha em reconhecer a possibilidade de cópias externas do gerenciamento de senhas compartilhadas
• Não rotacionar a senha root da AWS e o MFA quando houve desligamento de pessoal
• Esses dois fatores criaram a possibilidade de um agente não autorizado acessar a infraestrutura de produção do Rubygems e tentar disputar o controle de acesso

Medidas de prevenção contra recorrência

• Expansão dos procedimentos e checklists de revogação de acesso para incluir também o gerenciamento de cofres compartilhados
• Rotação imediata de credenciais não federadas (especialmente credenciais compartilhadas) sempre que houver mudanças de pessoal
• Delegação externa de auditoria de segurança independente
• Introdução de um acordo claro para operadores/contribuidores definindo a quem e sob quais condições é concedido acesso à produção

Por que isso foi tratado como incidente de segurança

• O problema teve origem na questão de controle individual sobre sistemas centrais
• O Sr. Arko, que prestava o serviço secundário de plantão como consultoria paga de US$ 50 mil por ano, após uma mudança na estrutura orçamentária propôs fornecer o plantão sem custo em troca de acesso aos logs HTTP de produção (incluindo PII) e oportunidades de monetização
• A Ruby Central entendeu que essa proposta envolvia problemas fundamentais de governança, privacidade e conflito de interesses, e que não poderia aceitá-la, dando andamento à reformulação da estrutura operacional e da governança
• A confirmação de que o acesso de Arko a sistemas contendo PII continuava ativo foi o fator decisivo para classificar o caso como incidente de segurança
• Até o momento, não há evidência de que dados do Rubygems tenham sido expostos ou armazenados externamente, e a organização promete restaurar a confiança da comunidade e aumentar a transparência

Conclusão

• Agradecimento pelo apoio da comunidade e pela fiscalização saudável
• A Ruby Central continuará garantindo a estabilidade e a confiabilidade do Rubygems.org com operação transparente, responsabilidade e um sistema de segurança mais rigoroso

Shan Cureton
Diretor Executivo