Access Data From Deleted Forks
Exposição de Dados em Repositórios Eliminados do GitHub
GitHub, uma das plataformas mais utilizadas para hospedagem de código fonte, permite o acesso a dados de repositórios eliminados e privados de forma indefinida. Esta característica, conhecida pelo GitHub e intencionalmente projetada dessa maneira, representa um vetor de ataque significativo para as organizações que utilizam a plataforma.
Vulnerabilidade de Referência de Objetos entre Forks (CFOR)
Apresentamos um novo termo: Cross Fork Object Reference (CFOR). Uma vulnerabilidade CFOR ocorre quando um fork de um repositório pode acessar dados sensíveis de outro fork, incluindo dados de forks privados e eliminados. Assim como uma referência direta de objeto insegura (IDOR), na CFOR os usuários fornecem hashes de commits para acessar diretamente dados de commits que de outra forma não seriam visíveis para eles.
Vejamos alguns exemplos.
Acesso a Dados de Forks Eliminados
Considere este fluxo de trabalho comum no GitHub:
1. Faça um fork de um repositório público.
2. Realize commits no seu fork.
3. Elimine seu fork.
Esses commits ainda são acessíveis? A resposta é sim. Embora você elimine seu fork, os dados continuam acessíveis indefinidamente.
Em um vídeo, demonstramos como, ao fazer um fork de um repositório, realizar commits, eliminar o fork e depois acessar os dados do commit "eliminado" através do repositório original, os dados permanecem acessíveis.
VIDEO: https://www.youtube.com/watch?v=eF-_mTvk7TQ
Acesso a Dados de Repositórios Eliminados
Outra situação é:
1. Você tem um repositório público no GitHub.
2. Um usuário faz um fork do seu repositório.
3. Você faz commits depois que o usuário fez o fork (e nunca sincroniza o fork dele com suas atualizações).
4. Você elimina o repositório completo.
Os commits realizados após o fork são acessíveis?
A resposta, novamente, é sim. O GitHub armazena repositórios e forks em uma rede de repositórios, com o repositório "upstream" original como o nó raiz. Quando um repositório público "upstream" que foi forkeado é "eliminado", o GitHub reatribui o papel de nó raiz a um dos forks downstream. No entanto, todos os commits do repositório "upstream" ainda existem e são acessíveis através de qualquer fork.
Acesso a Dados de Repositórios Privados
Considere este fluxo de trabalho para open-source:
1. Crie um repositório privado que eventualmente será público.
2. Crie uma versão privada interna desse repositório (através de um fork) e faça commits adicionais com características que você não vai tornar públicas.
3. Torne seu repositório "upstream" público e mantenha seu fork privado.
Os dados privados (do passo 2) são visíveis para o público?
Sim. Qualquer commit realizado entre o momento em que você criou um fork interno e quando tornou público o repositório, esses commits são acessíveis no repositório público.
Como Acessar os Dados
As ações destrutivas na rede de repositórios do GitHub (como os cenários mencionados) eliminam as referências a dados de commits da interface padrão do GitHub e das operações normais de git. No entanto, esses dados ainda existem e são acessíveis se você conhecer o hash do commit. Os hashes de commits são valores SHA-1.
Se um usuário conhece o hash SHA-1 de um commit específico que deseja ver, pode navegar diretamente para esse commit na URL:
https://github.com/<usuario/org>/<repo>/commit/<commit_hash>.
Verão um banner amarelo explicando que "este commit não pertence a nenhum branch deste repositório, e pode pertencer a um fork fora do repositório."
Políticas do GitHub
O GitHub projetou os repositórios para funcionar dessa maneira.
Implicações
As conclusões são:
- Enquanto existir um fork, qualquer commit nessa rede de repositórios existirá para sempre.
- A única maneira segura de remediar uma chave vazada em um repositório público do GitHub é através da rotação de chaves.
- A arquitetura de repositórios do GitHub requer esses defeitos de design e, infelizmente, a maioria dos usuários do GitHub nunca entenderá como funciona realmente uma rede de repositórios e serão menos seguros devido a isso.
À medida que a varredura de segredos evolui, é importante considerar que esses problemas também podem existir em outros produtos de sistemas de controle de versões.
Este artigo destaca a necessidade de maior diligência e consciência sobre como os dados são gerenciados e protegidos em plataformas de desenvolvimento colaborativo como o GitHub.
Fonte: https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
Comentários