Encontre a Chave AWS Vazada: Por Que Ocultar o Arquivo Não Resolve
O desafio
Uma equipe afirma ter removido um segredo do repositório público. Abra as fontes e correlacione-as: o arquivo de configuração atual parece limpo, mas o histórico de commits e um backup antigo contam outra história. Encontre o ID da chave de acesso AWS ainda exposto e envie-o.
O que você vai aprender
- Reconhecer que ocultar um arquivo em um novo commit não remove o segredo do histórico
- Usar git log para encontrar revisões anteriores de um arquivo
- Visualizar um arquivo em um commit específico para recuperar um valor removido
- Correlacionar um backup público em paste com o histórico do repositório
- Entender que rotacionar a credencial, e não ocultar o arquivo, é a remediação real
Habilidades testadas
Pré-requisitos
- Conceitos básicos de git (commits, log, revisões de arquivos)
- Familiaridade com a aparência de um AWS access key id
Como funciona
Controle de versão é append-only por design: cada mudança é um novo commit em cima dos anteriores, e o conteúdo antigo continua acessível. É por isso que apagar um segredo de um arquivo e commitar essa exclusão quase não ajuda na segurança - o commit anterior, com o segredo em texto puro, continua no histórico que qualquer pessoa que clonar o repositório recebe. Tanto atacantes quanto scanners de segurança sabem que devem olhar o histórico primeiro.
Aqui o config.yml atual mostra valores REDACTED e um comentário afirmando que os segredos foram movidos para variáveis de ambiente no commit 4f1a. O git log expõe a limpeza e aponta de volta para o commit inicial d33a5f1. Rodar git show d33a5f1:config.yml imprime o arquivo original, onde o access key id AKIA5TQQ3NLEAKED1 está hardcoded em texto puro. Um Pastebin público chamado 'prod env backup' confirma de forma independente o mesmo key id e ainda está indexado pelos mecanismos de busca, então o vazamento existe em dois lugares ao mesmo tempo.
O painel de OSINT te dá cada artefato como um cartão. O arquivo atual é uma isca - ele está genuinamente limpo. A resposta só aparece quando você lê a revisão antiga e a corrobora com o paste, ambos mostrando AKIA5TQQ3NLEAKED1.
Erros comuns
- Confiar no arquivo atual. O
config.ymlatual está oculto; o segredo está no histórico, não na working tree. - Acreditar no comentário 'movido para variáveis de ambiente'. O comentário descreve o commit mais recente, não o que ainda está em commits antigos.
- Pular o git log. Sem listar commits anteriores, você nunca encontra a revisão inicial que guarda a chave.
- Enviar a secret key em vez do access key id. A pergunta pede o access key id
AKIA....
Como se proteger
A única resposta segura para um segredo commitado é assumir que ele está comprometido e rotacioná-lo imediatamente - ocultar o arquivo não ajuda, porque o commit antigo e qualquer paste ou mirror ainda guardam o valor. Trate a exposição, não a exclusão, como o evento que importa.
- Rotacione e revogue a chave vazada no AWS IAM assim que ela for encontrada.
- Remova o segredo do histórico (filter-repo / BFG) e faça force-push, mas rotacione antes: reescritas de histórico não alcançam clones, forks ou pastes.
- Adicione um scanner de segredos no pre-commit e no CI para que chaves nunca sejam commitadas.
- Use credenciais de curta duração ou um secrets manager em vez de hardcodear chaves.