Para sua informação: dados de repositórios GitHub excluídos podem não ser realmente excluídos

Pesquisadores da Truffle Security descobriram, ou possivelmente redescobriram, que dados de repositórios GitHub excluídos (públicos ou privados) e de cópias excluídas (forks) de repositórios não são necessariamente excluídos.

Joe Leon, um pesquisador de segurança da organização, disse em um aviso na quarta-feira que ser capaz de acessar dados de repositórios deletados – como chaves de APIs – representa um risco de segurança. E ele propôs um novo termo para descrever a suposta vulnerabilidade: Cross Fork Object Reference (CFOR).

“Uma vulnerabilidade CFOR ocorre quando uma bifurcação de repositório pode acessar dados confidenciais de outra bifurcação (incluindo dados de bifurcações privadas e excluídas)”, explicou Leon.

Por exemplo, a empresa mostrou como é possível bifurcar um repositório, enviar dados para ele, excluir a bifurcação e, então, acessar os dados de confirmação supostamente excluídos por meio do repositório original.

Os pesquisadores também criaram um repositório, bifurcaram-no e mostrou como dados não sincronizados com o fork continuam acessíveis através do fork após o repositório original ser deletado. Você pode assistir a essa demonstração específica abaixo.

Vídeo do youtube

De acordo com Leon, esse cenário surgiu na semana passada com o envio de um relatório de vulnerabilidade crítica para uma grande empresa de tecnologia envolvendo uma chave privada para uma conta GitHub de funcionário que tinha amplo acesso em toda a organização. A chave havia sido publicamente comprometida com um repositório GitHub. Ao saber do erro, a empresa de tecnologia destruiu o repositório pensando que isso cuidaria do vazamento.

“Eles imediatamente excluíram o repositório, mas como ele havia sido bifurcado, eu ainda pude acessar o commit contendo os dados confidenciais por meio de uma bifurcação, apesar da bifurcação nunca ter sincronizado com o repositório ‘upstream’ original”, explicou Leon.

Leon acrescentou que, após analisar três repositórios públicos amplamente bifurcados de grandes empresas de IA, os pesquisadores da Truffle Security encontraram 40 chaves de API válidas de bifurcações excluídas.

Você pode desembolsar

Claramente, isso é um problema. Mas não é tanto um problema que o GitHub considere o CFOR uma vulnerabilidade legítima. Na verdade, a gigante de hospedagem de código de propriedade da Microsoft considera isso um recurso, não um bug.

Quando informado da situação por meio de seu Programa de Divulgação de Vulnerabilidades, o GitHub respondeu: “Esta é uma decisão de design intencional e está funcionando conforme o esperado, conforme observado em nosso [documentation].”

Esta é uma decisão de design intencional e está funcionando conforme o esperado

Isto, evidentemente, é conhecido há anos. Um indivíduo reivindicações ter notificado o GitHub sobre a vulnerabilidade em 2018 e recebido uma resposta semelhante.

Em uma entrevista por telefone com O registroDylan Ayrey, cofundador e CEO da Truffle Security, explicou que o problema se resume a algo chamado de confirmação pendente.

“Um commit pendente é um primitivo git”, explicou Ayrey. “Não é um primitivo GitHub. Então um commit pendente pode existir em qualquer plataforma git – Bitbucket, GitLab, GitHub, etc. E um commit pendente está basicamente dentro de um repositório de código dado, você tem uma árvore e essa árvore representa o histórico para aquele projeto, então todas as versões antigas do código que estão vinculadas.”

Um commit do git captura um instantâneo do estado de um repositório em um ponto específico no tempo, incluindo alterações no código e nos dados. Cada commit é identificado exclusivamente por um hash criptográfico. Enquanto a exclusão de uma ramificação, por exemplo, remove a referência a uma cadeia de commits específica, os commits em si não são excluídos do banco de dados de objetos do repositório.

“Esses commits pendentes são como uma parte fundamental documentada do próprio git”, disse Ayrey, que explicou que a maneira como as plataformas git lidam com commits pendentes é uma decisão da plataforma e não uma especificação do git.

Bitbucket, GitLab e GitHub, disse Ayrey, têm esses commits mesmo quando a conexão com a árvore de código é cortada. Se você tiver o identificador para acessá-los diretamente, ainda poderá baixar os dados associados.

Ayrey disse que isso é amplamente conhecido. Mas há um problema adjacente relacionado a forks – repositórios copiados – que é mais específico do GitHub. Forks, ele explicou, não fazem parte da especificação do git, então cada plataforma tem sua própria implementação.

Ayrey disse que, para o GitHub, os commits pendentes podem ser baixados por meio de um fork se você tiver o hash de identificação ou alguma parte dele.

“Se você tiver o identificador, você pode baixá-los do repositório para o qual eles foram originalmente enviados”, ele explicou. “Acontece que você também pode baixá-los por meio de qualquer fork desse repositório. E funciona bidirecionalmente. Então, do pai, você pode baixar aquele commit pendente do fork e do fork você pode baixar aquele commit pendente do pai.”

“O que descobrimos é que, mesmo que você exclua o pai e o commit tenha sido enviado para o pai, esse commit pendente não apenas continua vivo, mas você pode baixá-lo por meio do filho, mesmo que ele tenha sido enviado para o pai, ele nunca foi puxado para o filho e o pai tenha sido excluído, agora você pode acessar esse commit pendente.”

Esse commit pendente não apenas continua vivo, como você pode baixá-lo por meio do filho, mesmo que tenha sido enviado ao pai

Além disso, Ayrey explicou que você nem precisa do hash de identificação completo para acessar o commit. “Se você souber os quatro primeiros caracteres do identificador, o GitHub quase completará automaticamente o restante do identificador para você”, disse ele, observando que com apenas sessenta e cinco mil combinações possíveis para esses caracteres, esse é um número pequeno o suficiente para testar todas as possibilidades.

Questionado sobre os riscos que isso representa, Ayrey disse que há uma Arquivo de eventos do GitHub que registra todas as ações públicas do GitHub. E ele disse que, assim como o arquivo de tweets da Sunlight Foundation pode ser usado para pesquisar declarações públicas de mídia social, o arquivo de eventos do GitHub pode ser usado para investigação forense sobre o que as empresas de tecnologia têm feito.

“Se [tech companies] delete code, se eles estão saindo do seu caminho para deletar algo, isso nem sempre significa alguma coisa”, ele explicou. “Mas muitas vezes significa alguma coisa. Pode significar uma chave ou senha [was exposed]. Pode significar que eles acidentalmente empurraram um conjunto de dados de aprendizado de máquina. Já vimos isso antes. Ou pode significar – e isso é raro – [that] O invasor realmente fez um backdoor no projeto deles e eles ficaram um pouco envergonhados com isso… então eles simplesmente excluíram o backdoor.”

Questionado sobre como o GitHub deveria responder, Ayrey refletiu: “Se uma plataforma cria uma vulnerabilidade, documenta e explica que isso é algo que você deve estar ciente e que é um risco conhecido, isso a torna menos uma vulnerabilidade?

“O que eu provavelmente defenderia, se trabalhasse lá, é que esse pool de forks não seja compartilhado entre forks, que os commits que você envia para um fork não possam ser baixados por outro fork. A outra coisa que eu provavelmente defenderia é um novo recurso a ser criado que permita que você realmente exclua commits permanentemente e não apenas os deixe pendurados.”

A Truffle Security argumenta que o GitHub deveria reconsiderar sua posição porque o usuário médio espera que haja uma distinção entre repositórios públicos e privados em termos de segurança de dados, o que nem sempre é verdade. E há também a expectativa de que o ato de exclusão remova os dados de commit, o que novamente foi demonstrado que nem sempre é o caso.

Um porta-voz do GitHub disse O registro“O GitHub está comprometido em investigar os problemas de segurança relatados. Estamos cientes deste relatório e validamos que isso é esperado e documentado comportamento inerente ao funcionamento das redes fork. Você pode ler mais sobre como a exclusão ou alteração da visibilidade afeta os forks do repositório em nosso documentação.” ®