O relatório do incidente de invasão do repositório do Gentoo já está disponível. Em detalhes na Wiki (fonte) que traduzimos aqui, podemos ter uma ideia da extensão do que aconteceu.

 

 

Sumário

Uma entidade desconhecida ganhou controle de uma conta admin da Organização Gentoo no Github e removeu acesso de todos os desenvolvedores. Esta efetuou várias alterações de conteúdo. Os Desenvolvedores e responsáveis pela Infraestrutura do Gentoo escalaram o incidente para a equipe do Github que congelou a Organização Gentoo. O Gentoo readquiriu controle a sua Organização no Github e então reverteu os commits ruins e conteúdo alterado.

Impacto

• Aproximadamente 5 dias de repositório indisponível no Github.
• Pull requests CI fora; apenas branch master disponível para novos incidentes.
• O Projeto Gentoo Proxy Maintainers foi impactado já que diversos contribuidores do proxy-maint utilizam o GitHub para criar PRs.
• A entidade tentou deletar conteúdo adicionando “rm -fr” a vários repositórios; contudo, o código não foi executado devido a diversos gatilhos de proteção.
• Desenvolvimento que não dependia do proxy-maint continuou normalmente; mais de 700 commits foram feitos durante o incidente.

Conteúdo malicioso

Clones dos seguintes repositórios podem possuir conteúdo malicioso. O Gentoo recomenda recriar estes de um novo clone caso você tenha utilizado estes durante o período do ataque.

• gentoo/gentoo: (2018-06-28 20:38 – 2018-06-29 06:58)
• gentoo/musl: (2018-06-28 20:56 – 2018-06-29 06:59)
• gentoo/systemd: (2018-06-28 21:07 – 2018-06-29 06:57)

Causa Raiz

O atacante obteve acesso a uma senha de administrador de organização. Evidencias coletadas sugerem que um schema de senhas vazados do site tornou fácil a descoberta de senhas de páginas não relacionadas.

Lições aprendidas

Parte boa

• Time do Gentoo reportou rapidamente os problemas.
• GitHub respondeu rapidamente ocultando a organização impactada.
• Gentoo removeu rapidamente o acesso da conta invasora após localizado o acesso.
• GitHub forneceu logs de auditoria que auxiliaram a mapear o incidente.

Parte ruim

• Comunicação inicial não foi clara e teve falta de detalhe em duas áreas.
  • Como os usuários poderão verificar suas árvores para garantir uma cópia limpa?
  • Plano de ação prevendo que, mesmo recebendo commits maliciosos tais comimts não executem no usuário.
• A comunicação veio por 3 vias (www.gentoo.org, infra-status.gentoo.org e listas de email. Mais tarde a wiki foi adicionada e o cenário ficou inconsistente quando a fonte primária de atualizações.
• GitHub falhou em bloquear os repositórios através do git, resultando em commits maliciosos acessíveis externamente. O Gentoo teve que executar um force-push assim que descobriu o problema.
• Procedimentos de revogação de credenciais foram incompletos.
• Não havia um backup dos detalhes da Organização Gentoo no GitHub.
• O repositório systemd não é espelhado do Gentoo, armazenado diretamente no GitHub.

Itens de sorte

• Diversos Desenvolvedores Gentoo possuem contatos pessoais no GitHub, e na indústria da segurança isto pode ser de grande valia para a rápida resolução de um incidente.
• O ataque foi barulhento; remover todos os desenvolvedores causou notificações por email. Por conta da credencial adquirida no repositório, um ataque mais quieto teria provocado uma janela de oportunidade maior.
• O método usado pelos atacantes para enviar os commits (push forçado) fez o consumo downstream saltar aos olhos em notoriedade; isto também fez com que o git não agisse silenciosamente durante pulls em checkouts já existentes.

Fonte: wiki/Github/2018-06-28