Para caçadores de bugs, os repositórios do GitHub podem revelar uma variedade de informações potencialmente úteis. Pode haver problemas com destinos que nem sempre são de código aberto. Às vezes, informações que podem ser usadas contra a empresa-alvo são reveladas por engano por membros da organização e suas iniciativas de código aberto. Darei a você uma visão geral rápida neste artigo que deve ajudar você a começar a verificar os repositórios do GitHub em busca de vulnerabilidades e realizar o reconhecimento geral.

1-Clonagem em massa

Você pode apenas conduzir sua pesquisa no github.com, no entanto, para permitir o teste local, aconselho a clonagem de todos os repositórios de destino. O GitHubCloner de @mazen160 é um produto fantástico. Tudo o que você precisa fazer é executar o script para estar pronto para começar.

$ python githubcloner.py --org organization -o /tmp/output

      
                

                    
                    
                
            

É crucial realmente compreender o projeto que você está buscando antes de iniciar uma análise estática. Use os recursos principais durante a execução do projeto. A razão pela qual me refiro a isso como “etapa Jobert” é porque ouvi dizer que, antes de começar cada caçada, Jobert usa o projeto e obtém um bom entendimento do alvo antes de procurar pontos fracos.

3- Análise manual

O ditado “aprenda a fazer e depois quebre” se aplica a essa situação. Se você pode aprender uma linguagem de programação, deve ser capaz de entender os meandros das precauções de segurança a serem tomadas e evitadas.

Você pode começar o grep assim que estiver familiarizado com o destino e sua arquitetura. Procure palavras-chave nas quais você esteja interessado, com as quais esteja familiarizado ou que você saiba que os desenvolvedores erram com frequência.

Aqui está uma lista básica de alguns dos termos de pesquisa que usarei durante uma primeira avaliação ampla:

• API e chave. (Obtenha mais alguns endpoints e encontre chaves de API.)
• símbolo
• segredo
• PENDÊNCIA
• senha
• vulnerável
• http:// & https://

• CSRF
• aleatório
• cerquilha
• MD5, SHA-1, SHA-2, etc.
• HMAC

Outra etapa crítica é revisar o histórico de confirmação. Você ficará surpreso com a quantidade de informações que pode obter dos commits. Já vi contribuidores acreditarem erroneamente que removeram as credenciais enquanto permaneciam no histórico de commits. Por causa do histórico do git, descobri pontos de extremidade antigos que ainda operam. Além das preocupações atuais, você pode encontrar problemas históricos que podem ser evitados devido a commits antigos.

4- Ferramentas

Às vezes, automatizar as tarefas chatas pode ajudar a fornecer uma visão geral básica do que procurar. É crucial lembrar que você nunca deve copiar e colar resultados de verificação em relatórios. Você obterá muitos falsos positivos, portanto, sempre investigue cuidadosamente quaisquer possíveis problemas para garantir que eles possam ser explorados.

A principal ferramenta que utilizo ao realizar projetos Python é o Bandit .

O Bandit identificará problemas comuns, mas freqüentemente retornará falsos positivos ou resultados fáceis. Portanto, use-o com cautela. Sem dúvida, não deve ser invocado.

$ bandit -r path/to/your/code -ll

Snyk.io é uma ferramenta maravilhosa para verificar dependências. A plataforma suporta uma ampla variedade de idiomas.

Para reconhecimento, muitos pesquisadores sugerem o uso do Gitrob . Essa ferramenta procurará informações confidenciais em repositórios GitHub públicos.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

Para aplicativos Ruby on Rails, recomendo Brakeman . Brakeman é um scanner de segurança de análise estática que pode encontrar uma tonelada de vários problemas de segurança no código.

Use o LinkFinder de Gerben Javado para encontrar terminais nos arquivos JS do repositório.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

OK, sério, não faça engenharia social dos proprietários do projeto.

Relatando suas descobertas

Como sempre, quando se trata de caçar recompensas por bugs, leia a política do programa com atenção. Muito raramente um programa aceita relatórios por meio do GitHub. Entre em contato com a equipe de segurança ou, se possível, use uma plataforma de recompensas por bugs, como HackerOne ou Bugcrowd

Por outro lado, uma coisa interessante sobre o teste de caixa branca é que, como você tem acesso ao código, pode ser mais fácil sugerir uma correção ou enviar um patch.

OBRIGADO POR LER ISSO!