A Mozilla está tentando proteger seus repositórios no GitHub contra alterações maliciosas. Como o recente incidente do Gentoo mostrou, esses ataques são reais.


A Mozilla originalmente usou o GitHub como uma hospedagem de backup. Como o Gentoo, os repositórios originais foram armazenados em sua própria infraestrutura. Embora a maior parte do código do Firefox ainda seja distribuída com sua própria infraestrutura, muitos projetos existem apenas no GitHub. Alguns são apenas experimentos, enquanto outros são usados ​​na produção (por exemplo, Contas do Firefox ). Esses repositórios "sensíveis" precisam ser protegidos contra edições maliciosas, sem complicar as confirmações para pessoas normais.

Etapas reais são descritas aqui em relação à distribuição (ou implantação) de código de um repositório comprometido. Compartilhamos experiência e algumas ferramentas de auditoria. Essa proteção quase não interfere nos fluxos de trabalho normais no GitHub.

Aqui consideramos o risco de invadir uma conta do GitHub através dos mecanismos exclusivos deste site. Como o caso do Gentoo e outros incidentes mostraram, no caso de um hack, todo o código ao qual o usuário tem acesso está comprometido.

A essência do problema

O GitHub é um ótimo ecossistema com muitas extensões ou "aplicativos" para simplificar fluxos de trabalho específicos. Os aplicativos recebem permissão do usuário para executar ações em seu nome. Eles podem solicitar permissões, incluindo alterar ou adicionar contas adicionais. O GitHub mostra claramente essas solicitações: o usuário deve aprová-las através da interface da web, mas nem todos estão familiarizados com as consequências. Muitos não entendem que a permissão para acessar um repositório pessoal oferece o mesmo acesso a qualquer repositório no GitHub em nome do usuário.

Permissões em excesso colocam em risco os repositórios com informações confidenciais, enquanto o administrador do repositório não vê nada. A melhor coisa que ele pode fazer é notar um commit malicioso após o fato. Nem o GitHub nem o Git podem ser configurados para impedir ou marcar esse tipo de confirmação maliciosa. Apenas monitoramento externo.

Implementação

As recomendações a seguir foram tiradas do nosso sistema de segurança , apenas para este artigo os recursos específicos do Mozilla foram removidos. Na medida do possível, emprestamos as melhores práticas da Internet, usamos as funções do GitHub e tentamos não complicar demais a vida dos desenvolvedores.

Recomendações para organizações

• 2FA obrigatório para todos os funcionários.
• Para todos ou pelo menos usuários com permissões mais altas:
  
  • Forneça contato (email, MI) à organização ou administrador (o GitHub permite ocultar as informações de contato para privacidade).
  • Informe a organização ou o administrador sobre o possível comprometimento da sua conta (por exemplo, sobre o roubo de um laptop).

Diretrizes para Repositórios

• Repositórios importantes devem ser hospedados apenas em uma organização que segue as recomendações acima.
• Defina e configure ramificações de produção:
  
  • Ban forçado a empurrar.
  • Permissão para confirmar apenas para um pequeno número de usuários.
  • Aplique essas restrições também a administradores e proprietários.
  • Assine todas as confirmações com chaves GPG conhecidas anteriormente.

Recomendações de fluxo de trabalho

• Implantações, lançamentos e outros eventos dignos de uma auditoria devem ser observados com uma tag assinada com uma chave GPG conhecida anteriormente.
• Todas as implantações e liberações devem ser emitidas somente após uma auditoria de todas as confirmações e tags assinadas para as chaves corretas.

A implementação dessas medidas de proteção envolve certos custos, principalmente em relação à assinatura de confirmações. Desenvolvemos ferramentas para auditoria de configurações e planejamos lançar ferramentas para auditoria de confirmações. Todos eles estão em nosso repositório .



Aqui está um exemplo de auditoria. Primeiro, obtemos uma cópia local dos dados para a organização octo_org e, em seguida, um relatório é compilado para cada repositório:

 $ ./get_branch_protections.py octo_org 2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat 2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992). 2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992). 2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947). 

Agora, com dados armazenados em cache localmente, você pode gerar quaisquer relatórios. Por exemplo, um relatório mostra conformidade com as recomendações acima:

 $ ./report_branch_status.py --header octo_org.db.json name,protected,restricted,enforcement,signed,team_used octo_org/react-starter,True,False,False,False,False octo_org/node-starter,False,False,False,False,False 

Como você pode ver, apenas o octo_org/react-starter incluiu proteção contra empurrões forçados no ramo de produção. O resultado está no formato CSV para inserir facilmente em uma planilha.

Como você pode ajudar

Ainda estamos implementando essas recomendações e aprendendo ao longo do caminho. Se você acha que nossas recomendações de segurança de repositório são adequadas para você, ajude a simplificar a implementação. Compartilhe sua experiência na página de dicas ou abra um ticket no repositório GitHub-Audit .