Recon de GitHub: achar segredos vazados no seu escopo

Desenvolvedor vaza. Uma chave fixa num commit, um arquivo de config empurrado sem querer, um hostname interno num comentario: codigo publico guarda valor de recon para um escopo seu ou um programa em que voce entrou. O trabalho e achar os repos e usuarios ligados ao alvo e depois escanear com ferramentas feitas para segredos. Mantenha no escopo. Voce le codigo publico e nunca faz login com nada que achar.

#Ache os repos e usuarios

Comece pela organizacao e pelo dominio. A busca de codigo web do GitHub, com login, aceita qualificadores que voce combina.

"example.com" org:example-inc
"api_key" "example.com"
filename:.env "example.com"

O github-search automatiza a mesma ideia com um token, puxando usuarios, repos e trechos de codigo para um termo. O script github-subdomains dele acha hostnames citados em qualquer canto do codigo publico, uma fonte que as ferramentas de DNS perdem.

github-subdomains -d example.com -t $GITHUB_TOKEN -o gh-subs.txt

Alargue a rede para as pessoas ao redor da org. Funcionarios listam o trabalho no perfil, entao uma busca pelo nome da empresa entre usuarios traz contas cujos repos pessoais as vezes citam ferramentas internas. Guarde essas pistas, mas lembre de quem e o dado e trate uma conta pessoal com mais cuidado do que uma da empresa.

#Escaneie clones em busca de segredos

Com os repos em maos, clone os que estao no escopo e escaneie local. O gitleaks le todo o historico do git, nao so os arquivos atuais, entao um segredo removido depois ainda aparece.

gitleaks detect --source ./example-repo --report-path leaks.json

O trufflehog vai alem e verifica muitos tipos de segredo testando se a credencial ainda funciona, o que corta falso positivo com forca.

trufflehog git https://github.com/example-inc/example-repo --only-verified

Um acerto verificado e uma credencial viva. Nao use. Registre, com o commit e o arquivo, para o relatorio, e deixe o dono rotacionar. Escanear um monorepo grande leva tempo, entao comece pelos repos que seus dorks ja ligaram ao alvo, nao por todo fork e espelho.

#Escreva boas queries com a chat

Dorking no GitHub e um problema de linguagem: o qualificador certo acha o vazamento, o errado enterra. Peca a chat da NotHoly para expandir uma semente num conjunto de queries.

Minhas raizes de escopo sao example.com e example.net, org example-inc.
Escreva 15 queries de busca de codigo no GitHub para achar segredos
vazados, hostnames internos e arquivos de config ligados a elas. Varie
os qualificadores (org, filename, path, language). Uma por linha.

Voce mesmo cola as queries de volta na busca do GitHub, nao numa ferramenta que as roda por voce. O modelo tambem le bem um relatorio do gitleaks: cole o JSON e peca para agrupar os acertos por tipo de segredo e ordenar por quao provavel cada um e real e no escopo.

#Escopo e privacidade

Codigo publico costuma ser de individuos, nao da empresa alvo. O repo pessoal de um funcionario e dado de uma pessoa, e o projeto paralelo antigo dele nao esta no seu escopo. Fique nos repos da org ou claramente ligados a infraestrutura do alvo. Nunca autentique com credencial vazada, nunca empurre um commit e reporte segredos pelo canal do programa para serem rotacionados.

#Perguntas frequentes

#Ler um segredo achado e problema?

Ler codigo publico e uma coisa; usar uma credencial que voce achou e outra, e pode cruzar uma linha de uso indevido de computador ate dentro de um programa de bug bounty. Reporte e nao teste fazendo login.

#E os commits antigos que foram apagados?

O git guarda historico. Um segredo removido num commit posterior ainda fica no anterior, que e justo por isso que gitleaks e trufflehog varrem todo o historico, nao a arvore atual.

Busca de codigo fecha suas fontes automaticas. A seguir, afie a parte manual em dorking de buscadores que funciona. Volte para certificate transparency e historico de DNS.