tl;dr Se divulgar um segredo, altere-o imediatamente. Apagar um ficheiro, reescrever o histórico de commits do Git ou apagar o seu repositório não o protegerá. Os atacantes procuram regularmente na Internet por secrets, por isso, parta do princípio de que já têm uma cópia. Utilize Betterleaks ou Aikido Secrets Detection para encontrar secrets que tenham sido divulgados nos teus repositórios e Aikido Device Protection para os detetar nos computadores dos programadores.
Em maio, os programadores do LiteLLM submeteram acidentalmente uma chave administrativa a um repositório público do GitHub. Meses mais tarde, os atacantes utilizaram essa credencial para comprometer a infraestrutura da empresa.
O relatório pós-incidente da LiteLLM documenta a cronologia das medidas tomadas para resolver a fuga de dados. Uma frase do relatório chamou-me a atenção:
«Cerca de três horas depois, um commit subsequente eliminou o ficheiro [que revelou o segredo] e as chaves foram assinaladas como necessitando de revogação, mas o commit original permaneceu no histórico público do repositório até 22 de outubro.»
A LiteLLM detetou a fuga de informação em menos de 3 horas. A sua primeira medida corretiva foi este Pull Request, que se limitou a eliminar o ficheiro. Meses mais tarde, a 22 de outubro, reescreveram o histórico do Git para remover os commits que tinham causado a fuga das credenciais.
Essas duas ações, embora comuns, refletem equívocos generalizados entre os programadores relativamente à fuga de informações confidenciais no histórico do Git. Nenhuma das medidas tomadas pela LiteLLM impede, na verdade, que alguém veja os dados que vazaram. Na realidade, o commit que revelou a credencial ainda está visível hoje (não se preocupem, já a substituíram!).
A única forma de resolver completamente o problema de uma credencial que foi divulgada é substituir essa credencial. Uma vez que se torna pública, deixa de ser um segredo e nunca mais voltará a sê-lo.
Equívocos comuns sobre o « Secrets » que vazou no Git
As experiências abaixo testam, cada uma, uma «solução» comum para a fuga de « secrets » em repositórios Git:
Nenhuma destas medidas o protege totalmente contra a possibilidade de os autores de ameaças descobrirem e utilizarem um segredo que você venha a revelar. Mesmo que este fique disponível ao público apenas durante alguns minutos.
Equívoco n.º 1: Apagar o ficheiro
A LiteLLM adotou esta abordagem imediatamente após descobrir a fuga de informação, e esta é provavelmente a reação mais comum. O programador reconheceu um erro no seu código e, por isso, «corrigiu-o» eliminando o ficheiro em questão num novo commit. Como veremos abaixo, os scanners de informações confidenciais analisam o histórico do Git e verificam os ficheiros eliminados.
- Cria um novo repositório Git local. Faz um commit de um ficheiro README. Em seguida, faz um commit de um ficheiro que contenha um segredo.
mkdir tmp_repo
cd tmp_repo
git init
echo "# README" > README.md
git add README.md
git commit -m "commit inicial"
# chave falsa divulgada
echo "secret_token=ZQ5Cl16U8kmc4uOxS581xDWr" > file.txt
git add file.txt
git commit -m "revelação do segredo no ficheiro file.txt"- Apaga esse ficheiro. Faz o commit novamente.
rm file.txt
git add .
git commit -m "removido segredo exposto no ficheiro.txt"- Faça uma análise com o Betterleaks. Verá que este deteta um segredo no histórico do Git. (Instruções para configurar o Betterleaks na página do GitHub.)
repositório Git do betterleaks.
Equívoco n.º 2: Reescrever o histórico do Git
O instinto seguinte é, normalmente, «apagar» a fuga de informação do histórico do Git. A LiteLLM tentou fazê-lo a 22 de outubro, enviando à força um histórico reescrito que exclui os commits relevantes. À primeira vista, isto parece funcionar, uma vez que esses commits não estão acessíveis a partir de nenhum ramo. Infelizmente, o GitHub continua a disponibilizar os commits «eliminados» a qualquer pessoa que tenha o seu hash SHA-1.
- Registe o hash SHA-1 do commit em que revelou o segredo.
git log --format=%H --grep="revelação de segredo no ficheiro.txt" -1Nota: Os hashes SHA-1 têm 40 caracteres, o que é demasiado longo para se adivinhar. No entanto, o GitHub permite que os utilizadores forneçam uma versão curta na sua interface de utilizador, que corresponde aos 40 caracteres completos. A versão curta pode ter apenas 4 caracteres (0-9a-f), o que torna estes hashes mais fáceis de descobrir.
- Envie o repositório local acima para o GitHub. (Crie o repositório no site do GitHub se o primeiro comando não funcionar.)
git remote add origin https://github.com/<github-username>/tmp_repo.git
git branch -M main
git push -u origin main- Redefina o ponto de referência do Git para o primeiro commit. Efetue um push forçado para o GitHub.
git reset HEAD~2 --hard
git push --forceNota: Existem várias formas de reescrever o histórico de commits. Trata-se de uma demonstração simples, pelo que tudo o que vamos fazer é repor o nosso repositório ao primeiro commit inicial e, em seguida, efetuar um push forçado.
- Elimine o seu repositório local.
cd ..
# rm -r tmp_repo # verifica bem o nome do teu diretório antes de executares isto- Clona o comando.
git clone https://github.com/<user>/tmp_repo.git
cd tmp_repo- Analisa o histórico do Git na versão clonada. Só irá aparecer um commit.
git log- Recupere o seu commit «eliminado» diretamente do GitHub. Veja o ficheiro «eliminado».
git fetch origin <sha1_hash_from_step_1>
git checkout <sha1_hash_from_step_1>
cat file.txtSe acederes ao commit «eliminado» no navegador, verás um banner na parte superior que diz «Este commit não pertence a nenhum ramo deste repositório…», mas mesmo assim ainda o conseguimos ver.
https://github.com/<user>/tmp_repo/commit/<sha1_hash_from_step_1>
Equívoco n.º 3: Apagar o repositório
Como último recurso, os programadores costumam eliminar todo o repositório. Infelizmente, isso também não é suficiente. Em primeiro lugar, não se tem qualquer visibilidade sobre quem clonou o seu repositório. Em segundo lugar, se alguém tiver feito um fork do seu repositório, o GitHub manterá uma cópia do seu commit «eliminado» indefinidamente.
- Pede a um amigo para fazer um fork do repositório que criámos acima.
- Elimine o seu repositório.
- Visita o commit eliminado (através do hash) na versão bifurcada do teu amigo.
https://github.com/<friend>/tmp_repo/commit/<sha1_hash_from_step_1>O commit que contém os teus dados divulgados permanecerá indefinidamente no GitHub até que o último fork seja eliminado.
E se ninguém tivesse visto?
Se essas experiências não foram suficientes para o convencer de que é necessário alternar uma credencial que está exposta publicamente, veja o nosso colega Mackenzie a divulgar uma chave em direto numa conferência e, em seguida, verifique quantos atacantes analisaram a sua chave em apenas alguns minutos. Investigadores, plataformas SaaS/Cloud e atacantes estão constantemente à procura de secrets . Parta do princípio de que, assim que for tornada pública, alguém já a viu.
Gire as chaves expostas
A eliminação de um ficheiro, a reescrita do histórico e a eliminação de um repositório deixam, em todos os casos, um segredo que tenha sido divulgado acessível. A única medida que protege totalmente a sua conta é a rotação de credenciais:
- revogar o que foi divulgado
- emitir um novo
- atualizar em todos os locais onde a versão antiga foi utilizada
Embora a rotação de credenciais impeça a utilização indevida no futuro, não resolve o problema da utilização indevida que já ocorreu, e uma chave que tenha sido alvo de uma fuga de informação pode permanecer ativa durante meses antes de alguém a descobrir. A chave do LiteLLM esteve ativa durante mais de quatro meses antes de um atacante a utilizar para obter um token do GitHub e lançar uma versão maliciosa.
Depois de rodar a chave, verifique se há sinais de que a chave antiga já foi utilizada:
- Os registos de utilização e acesso da própria chave ou token
- Commits recentes no ramo principal e em quaisquer ramos protegidos
- Alterações na configuração da CI e do fluxo de trabalho, e execuções recentes do pipeline
Se não for possível excluir a possibilidade de utilização indevida, trate o caso como um incidente.
Como o « Aikido » ajuda
Aikido ajuda-o a verificar se tem fugas de secrets. Os clientes têm acesso à deteção de secrets integrada na plataforma Aikido , e qualquer pessoa pode utilizar o Betterleaks, o motor gratuito de código aberto que está na base desta funcionalidade.
Aikido Secrets Detecção e proteção de dispositivos
Ligue os seus repositórios do GitHub, GitLab, Bitbucket ou Azure DevOps, públicos ou privados, e oAikido Secrets Detection verifica se contêm chaves de API, palavras-passe, tokens e outras credenciais expostas. Por predefinição, analisa o código atual, mas pode ativar verificações completas do histórico do Git para detetar secrets que tenham sido adicionados e posteriormente removidos, como o ficheiro eliminado do equívoco n.º 1.
O motor Betterleaks associa padrões conhecidos de credenciais a técnicas para detetar « secrets » genéricos. Para os tipos de credenciais suportados, a «Live Secret Detection» verifica se um segredo que vazou ainda está ativo e ajusta a gravidade do problema em conformidade. Secrets O «AutoTriage» utiliza o contexto para distinguir credenciais reais de valores de exemplo ou de teste.
Aikido também sinaliza secrets numa fase inicial do desenvolvimento. As extensões do IDE e um hook de pré-commit alertam os programadores antes de um segredo chegar a um commit. Na CI/CD, Aikido pode bloquear uma compilação ou um PR que contenha um segredo.
Aikido A Proteção de Dispositivos adiciona uma camada de segurança aos computadores dos programadores. O seu agente analisa os ficheiros locais no dispositivo, tais como o histórico do shell, à procura de valores codificados de forma rígida secrets. O conteúdo dos ficheiros permanece no dispositivo. Quando o agente encontra um segredo, Aikido recebe o tipo de segredo e alguns caracteres do valor, suficientes para reconhecer a descoberta.
Betterleaks
Qualquer pessoa pode utilizar o Betterleaks de forma independente. O site Aikido patrocina o projeto, que é gratuito ao abrigo da licença MIT. O autor original do Gitleaks criou-o como um substituto direto do Gitleaks.
Lembrete: Seja qual for a ferramenta que detetar um segredo que tenha sido divulgado, proceda à sua rotação. O Aikido identifica credenciais ativas e recomenda a sua rotação; revogue e substitua a credencial junto do serviço que a emitiu. Apagar o segredo do seu último commit deixa-o no histórico do Git, como demonstram as experiências acima.
