Pesquisadores descobriram que um dos mais populares repositórios de código fonte do mundo ainda abriga milhares de chaves de criptografia acessíveis ao público.

Mais de 100.000 repositórios de código no site GitHub contêm chaves de acesso secreto que podem dar aos invasores acesso privilegiado a esses repositórios ou aos serviços dos provedores de serviços on-line.

Pesquisadores da North Carolina State University (NCSU) examinaram quase 13% dos repositórios públicos do GitHub durante quase seis meses. Em um artigo revelando as descobertas, eles disseram:

Descobrimos que não apenas o vazamento secreto é pervasivo – afetando mais de 100.000 repositórios – mas que milhares de novos e únicos segredos são vazados todos os dias.

As credenciais que os desenvolvedores publicam diariamente em seus repositórios do GitHub se enquadram em várias categorias. Estas incluem chaves SSH: certificados digitais que desbloqueiam automaticamente recursos online.

Outra é a interface de programação de aplicativos (API) (também conhecida como tokens). São chaves digitais que permitem aos desenvolvedores acessar serviços on-line, desde o Twitter até a Pesquisa do Google, diretamente de seus programas.

Os pesquisadores encontraram uma mistura dessas chaves para serviços como Google, Twitter, Amazon Web Services, Facebook, MailChimp, serviço de telefonia on-line Twilio e empresas de processamento de cartões de crédito Stripe, Square e Braintree.

Esses vazamentos comprometem alvos de alto valor. Os pesquisadores encontraram as credenciais do Amazon Web Service (AWS) para um grande site que atende a milhões de candidatos a faculdades dos EUA. Eles também encontraram credenciais da AWS para o site de uma grande agência governamental em um país da Europa Ocidental.

Como isso acontece?

Normalmente, os desenvolvedores ficam descuidados ao atualizar o código em suas máquinas e, em seguida, enviá-lo para o GitHub, o que eles normalmente fazem usando instruções de linha de comando conhecidas como commits e pushes.

Outras vezes, os codificadores armazenam chaves SSH e chaves de API nos mesmos diretórios que seu código-fonte, para que sejam capturados no processo de confirmação e envio. É um erro fácil de fazer com chaves SSH, que os desenvolvedores costumam gerar a partir da linha de comando. Alguns outros percalços são ainda mais dignos de facepalm, como incorporar chaves de API diretamente no código-fonte.

Uma maneira de impedir que chaves privadas sejam confirmadas é informar a um arquivo .gitignore onde elas estão. Este é um arquivo que impede que determinadas informações sejam enviadas para um repositório do GitHub. Em vez disso, alguns desenvolvedores armazenaram seus segredos diretamente no arquivo .gitignore, o que significa que ele foi incluído em seus repositórios.

Alguns serviços on-line, como o OAuth, exigem vários segredos para acesso, como uma chave digital e um ID. No entanto, isso não ofereceu muita segurança extra, porque quatro em cada cinco dos repositórios que haviam esses segredos continham as outras informações necessárias para acessar o serviço de terceiros.

Muitos desenvolvedores não fizeram nada quando notificados do problema, de acordo com o jornal. Aqueles que tentaram consertar o problema, imediatamente criaram novos commits para seus repositórios que removiam os segredos. Isso não funciona, porque o GitHub é um sistema de controle de versão e armazena informações armazenadas em confirmações anteriores.

O que os desenvolvedores realmente precisam fazer é reescrever seu histórico para remover o commit incorreto, ou deletar o repositório inteiro e começar de novo sem armazenar a senha, disseram os pesquisadores. A maioria dos desenvolvedores não fizeram nada disso.

Como os pesquisadores encontraram essas chaves? Foi através de algum corte nefasto ou lacuna no site? Não – eles apenas procuraram por isso. O GitHub tem uma API de pesquisa que pode ser usada para pesquisar em todos os seus repositórios, e entrega alegremente os dados da chave secreta.

O co-autor do artigo Brad Reaves nos disse:

Embora tenhamos usado a API de pesquisa, que requer uma chave de API, podendo ser obtida gratuitamente por qualquer usuário do GitHub, as chaves também podem ser encontradas com a função de pesquisa on-line.

Isso tem sido um problema desde pelo menos 2013, quando o GitHub encerrou seu serviço de busca por um tempo depois de encontrar chaves secretas aparecendo nas buscas. Ele adicionou:

Depois que isso foi divulgado, o GitHub retirou a ferramenta Code Search, alegando motivos não relacionados, mas logo relançou a ferramenta com a mesma funcionalidade.

Então, tudo isso é culpa do GitHub?

Dificilmente. Como Reaves apontou:

A pesquisa de código é uma ótima ferramenta, mas seria muito difícil para o GitHub criar uma ferramenta que pode censurar todos os possíveis segredos; o erro vêm dos desenvolvedores que divulgam segredos aos repositórios públicos.

Para seu crédito, o GitHub, que a Microsoft adquiriu por US $ 7,5 bilhões em outubro de 2018, está tentando melhorar as coisas. Ele introduziu limites de taxa para sua ferramenta de pesquisa, embora o documento possa apontar que um invasor poderia superar isso pesquisando em várias contas.

Ele também analisa os repositórios há vários anos para encontrar tokens OAuth do GitHub e tokens de acesso pessoal, que podem ser usados ​​para acessar os repositórios do GitHub das pessoas.

Em outubro de 2018, o GitHub também anunciou parcerias com serviços on-line de terceiros como parte de um novo recurso chamado Token Scanning. Isso verifica novos commits ou repositórios privados que se tornaram públicos para chaves de API com provedores de serviços, notificando o apropriado quando eles são encontrados.

Esse provedor pode então optar por revogar as credenciais, que é a etapa recomendada pelo GitHub, de acordo com um porta-voz da empresa. Ela também nos disse que compartilhou informações sobre mais de 100 milhões de tokens comprometidos até agora.

É um começo, disse Reaves, mas o trabalho do GitHub só pode resolver o problema até um ponto:

Acho que esforços como o projeto Token Scanning do GitHub devem ser aplaudidos, mas eles só são eficazes depois que um vazamento já ocorreu. Este problema provavelmente não está isolado no GitHub – ele afetará qualquer código publicamente disponível. Precisamos de mais pesquisas para desenvolver sistemas que ajudem os desenvolvedores a evitar esse erro em primeiro lugar.

Parabéns ao GitHub por tentar o seu melhor para resolver o problema, mas cabe aos desenvolvedores usar serviços como esse – e as ferramentas associadas, como o Git – corretamente.

Leia também: