A empresa Truffle Security publicou scripts de ataque sobre várias técnicas comuns de trabalho com repositórios no GitHub, permitindo extrair dados de repositórios remotos que têm forks públicos ou que foram criados como forks.
A possibilidade de acesso aos commits por hash em todos os repositórios relacionados através de forks é devida ao fato de que o GitHub, para otimização e eliminação de duplicatas, armazena todos os objetos do repositório principal e dos forks juntos, apenas separando logicamente a atribuição dos commits. Esse armazenamento permite visualizar no repositório principal qualquer commit de qualquer fork, especificando claramente seu hash na URL. Por exemplo, um usuário pode criar um fork do repositório '/torvalds/linux' e adicionar qualquer código, após o que esse código se tornará acessível por meio de um link direto de hash no repositório '/torvalds/linux'. No caso de exclusão do repositório, se houver pelo menos um fork público, os dados do repositório remoto permanecem acessíveis pelo hash do commit.
Três cenários que representam uma ameaça à segurança são propostos:
- O primeiro cenário envolve situações em que os desenvolvedores criam forks de repositórios públicos, fazem alterações nelas, experimentam e depois os excluem. Além da divulgação de código que não foi destinado à publicação, a situação se torna perigosa quando, durante os experimentos, chaves de acesso funcional ao API são adicionadas ao código dos arquivos de exemplo. Nesse caso, o atacante pode ter acesso às modificações por meio do hash do commit, dirigido após a exclusão do fork através do repositório principal. Por exemplo, de acordo com o método proposto, os pesquisadores conseguiram identificar 30 chaves de acesso funcionais ao API, analisando três repositórios relacionados ao aprendizado de máquina com um grande número de forks.
- O segundo cenário diz respeito à possibilidade de acesso a dados após a exclusão do repositório primário, se forks foram criados para esse repositório. Um exemplo é o caso em que chaves privadas de um funcionário foram acidentalmente publicadas em um repositório público de uma empresa, permitindo acesso total a todos os repositórios dessa empresa no GitHub. A empresa excluiu o repositório através do qual a informação vazou, mas as chaves ainda permanecem disponíveis para extração através de chamadas pelo hash do commit em repositórios com forks.
- O terceiro cenário está relacionado ao modelo de desenvolvimento de projetos que evoluem uma versão básica aberta em um repositório público e uma versão proprietária expandida em um privado. Se a empresa inicialmente desenvolveu o projeto em um repositório privado e, em seguida, após a abertura do código do projeto, o transferiu para o status público, mas continuou o desenvolvimento de uma versão interna ou ampliada fechada em um fork privado, há a possibilidade de acesso às alterações adicionadas no fork privado através dos hashes dos commits em um repositório público. O acesso é possível apenas para as alterações adicionadas ao fork privado antes que o repositório principal se tornasse público (os repositórios privados e públicos são separados, mas, quando dois repositórios eram privados, os commits eram armazenados juntos, portanto permaneceram no repositório após sua conversão em público).
O truque que permite acessar os commits em forks de um repositório através de um link para o repositório principal é conhecido há muitos anos e é periodicamente utilizado para diversas brincadeiras e para enganar desenvolvedores (por exemplo, brincalhões periodicamente criam a ilusão de inserção de backdoors em repositórios do núcleo Linux no GitHub dessa forma). Como uma medida para combater essas brincadeiras, o GitHub adicionou um aviso informando que o commit solicitado não pertence às branches do repositório atual e pode pertencer a um fork. Contudo, a própria possibilidade de acesso aos commits por hash em quaisquer repositórios relacionados a forks é considerada inofensiva, uma vez que o conhecimento do hash do commit é necessário para acessar dados em forks remotos e privados.
Encontrar um hash de commit gerado com base no algoritmo SHA-1 e que inclua 32 caracteres é impossível, mas parece que isso não é necessário. O GitHub suporta uma forma abreviada de referência a commits, permitindo endereçar alterações por alguns dos primeiros caracteres do hash, desde que não haja sobreposição com outros commits. O número mínimo de caracteres para uma referência abreviada de hash é 4, o que corresponde a todas as 65 mil combinações (16^4). Porém, a busca pode não ser necessária, já que a API do GitHub permite conectar manipuladores para interceptar eventos, usados por projetos de terceiros que mantêm um arquivo com um log completo de todas as operações, onde as informações sobre hashes de commits permanecem mesmo após a exclusão de repositórios.
Fonte: opennet.ru
