Qualquer pessoa pode acessar dados de repositórios deletados ou privados no GitHub

• No GitHub, é possível acessar dados de forks deletados, repositórios deletados e até repositórios privados
• Isso é conhecido pelo GitHub e funciona assim por design
  • Como isso representa um enorme vetor de ataque para qualquer organização que usa GitHub, foi introduzido o novo termo "Cross Fork Object Reference (CFOR)"
• A vulnerabilidade CFOR ocorre quando um fork de repositório consegue acessar dados sensíveis de outro fork, incluindo dados de forks privados e deletados

Acessando dados de forks deletados

• Considerando um fluxo de trabalho comum no GitHub, há casos em que alguém faz fork de um repositório público, faz commits no fork e depois apaga o fork
• O código commitado no fork continua acessível e continuará acessível para sempre
• Pode parecer que saber o hash do commit oferece proteção, mas esses hashes podem ser descobertos
• Encontrar dados em forks deletados acontece com bastante frequência

Acessando dados de repositórios deletados

• Considere um cenário em que há um repositório público no GitHub, um usuário faz fork desse repositório, faz commits de dados após o fork e depois apaga o repositório inteiro
• O código commitado após o fork continua acessível
• O GitHub armazena repositórios e forks em uma rede de repositórios, na qual o repositório "upstream" original atua como nó raiz
• Quando o repositório público "upstream" que foi forkado é "deletado", o GitHub reatribui o papel de nó raiz a um dos forks downstream
• Porém, todos os commits do repositório "upstream" continuam existindo e podem ser acessados por meio de qualquer fork

Acessando dados de repositórios privados

• Considerando um fluxo de trabalho comum no GitHub para open source de uma nova ferramenta,
• pode acontecer de se criar um repositório privado que será tornado público no futuro, criar uma versão interna privada desse repositório (via fork), fazer commits de código adicional para funcionalidades que não serão publicadas, publicar o repositório "upstream" e manter o fork privado
• Se funcionalidades privadas e o código relacionado (da etapa 2) ficam visíveis publicamente depende do que pode ser acessado a partir do repositório público
• Tudo o que for commitado no fork privado depois que o repositório "upstream" se tornar público não poderá ser visto

Como os dados são acessados na prática?

• Acessando diretamente os commits
• Em operações destrutivas na rede de repositórios do GitHub (como os 3 cenários mencionados acima), as referências aos dados de commit são removidas da UI padrão do GitHub e das operações normais de git
• No entanto, esses dados continuam existindo e podem ser acessados se o hash do commit for conhecido
• O hash do commit é um valor SHA-1, e se o usuário souber o hash SHA-1 do commit específico que deseja ver, pode ir diretamente para esse commit pelo endpoint https://github.com/<user/org>/…;
• Os hashes de commit podem ser obtidos por força bruta via UI do GitHub
• Também é possível consultar hashes de commit pelo endpoint de public events API do GitHub

Política do GitHub

• Esses resultados foram enviados recentemente ao programa VDP do GitHub, e o GitHub deixou claro que os repositórios foram projetados para funcionar dessa forma
• Ao revisar a documentação, fica claro que o GitHub documenta explicitamente o que os usuários devem esperar nos casos descritos acima

Impacto

• Enquanto existir ao menos um fork, todos os commits dessa rede de repositórios (do repositório "upstream" ou de forks "downstream") continuarão existindo para sempre
• A arquitetura de repositórios do GitHub exige esse defeito de design, e a maioria dos usuários do GitHub não entende como a rede de repositórios realmente funciona, ficando menos protegida
• À medida que o secret scanning evoluir para conseguir escanear todos os commits de uma rede de repositórios, será possível receber alertas sobre segredos que nem são seus
• Esses 3 cenários são chocantes, mas não cobrem todas as formas pelas quais o GitHub pode armazenar dados removidos de um repositório

Opinião do GN⁺

• Este artigo levanta uma questão de segurança importante para organizações que usam GitHub. O fato de que dados de repositórios deletados ou privados ainda possam ser acessados é chocante. Isso parece ser uma falha fundamental de design causada pela arquitetura da rede de repositórios do GitHub
• Desenvolvedores devem estar cientes desse problema e ter cuidado ao commitar dados sensíveis ou segredos no GitHub. Depois que algo é enviado para um repositório público, ele pode permanecer acessível para sempre. Se um segredo crítico vazar, a única forma de remediação completa é por meio de rotação de chaves
• O GitHub divulga e documenta esse comportamento com transparência, mas a maioria dos usuários provavelmente não entende completamente como a rede de repositórios funciona. O GitHub deveria fazer mais para aumentar a conscientização sobre esse problema e educar os usuários
• Problemas semelhantes podem existir em outros sistemas de controle de versão. Desenvolvedores e organizações precisam entender bem a arquitetura e as limitações das ferramentas que usam ao gerenciar dados sensíveis
• Para evitar vazamento de dados críticos, são necessárias medidas de segurança em várias frentes, como controle de acesso rigoroso, aplicação do princípio do menor privilégio, secret scanning regular e monitoramento contínuo. Acima de tudo, é essencial ter alta conscientização de segurança entre os desenvolvedores

[GN⁺]

Comentários do Hacker News

• Foi reportado ao HackerOne em 2018, mas o GitHub não corrigiu porque disse que era o comportamento esperado. Conclusão: em vez de usar forks privados, faça uma cópia do repositório para usar
• O GitHub tem obsessão por tornar tudo público e imutável. Por exemplo, para apagar um comentário, é preciso enviar por e-mail um documento de identidade real ao dono do repositório
• Os usuários não deveriam precisar saber desse tipo de problema na funcionalidade "privada", e o fato de o GitHub tratar isso como recurso em vez de bug mostra descaso com segurança. Seria mais adequado chamar repositórios privados de repositórios "não listados"
• Se você usa repositórios privados e forks privados e depois muda o repositório para público, os forks também se tornam públicos. O GitHub pode alegar que esse é o comportamento esperado, mas deveria exigir que repositório e fork fossem tornados públicos ao mesmo tempo
• Esse comportamento parece um dark pattern, e o GitHub não se importa mesmo quando o sustento das pessoas está em jogo. Isso porque a negação plausível intencional e termos de uso ambíguos valem mais do que a perda de reputação
• Surpreende ver comentários minimizando esse problema. Uso o GitHub há muito tempo, mas não teria previsto esse resultado e isso me deixa desconfortável. Recomendo ler o artigo diretamente
• Esse problema não é novo. Muitas pessoas já tinham identificado isso antes
• O OSPO do GitHub está desenvolvendo um GitHub App de código aberto para manter espelhos privados de forks públicos. O lançamento beta está previsto para esta semana
• O verdadeiro problema é a forma como o arquivo GitHub Events expõe o hash SHA1 de repositórios vulneráveis. É possível vasculhar toda a rede e acessar repositórios privados apagados
• O problema está em como dados privados podem depender de dados públicos. Por exemplo, se um commit privado depende do commit público C e C for apagado do repositório público, o GitHub precisa mantê-lo. Caso contrário, o commit privado quebra
• Todos os commits sobrevivem para sempre no GitHub depois de serem enviados, e qualquer commit que já tenha sido público continua sempre acessível pelo hash do commit