0
0
Um dia chato durante a pandemia, o pesquisador de segurança Craig Hays decidiu fazer um experimento. Ele queria vazar um nome de usuário e senha SSH para um repositório GitHub e ver se algum invasor poderia encontrá-lo. Hays pensou que teria que esperar alguns dias, talvez uma semana, antes que alguém percebesse. A realidade se mostrou mais brutal. O primeiro login não autorizado aconteceu em 34 minutos. “O maior abridor de olhos para mim foi a rapidez com que foi explorado”, diz ele à CSO.
Nas primeiras 24 horas, seis endereços IP diferentes conectados ao seu honeypot um total de nove vezes. Um invasor tentou instalar um cliente botnet, enquanto outro tentou usar o servidor para iniciar um ataque de negação de serviço. Hays também viu alguém que queria roubar informações confidenciais do servidor e outra pessoa que estava apenas olhando ao redor.
O experimento mostrou a ele que os atores de ameaças estão constantemente digitalizando o GitHub e outros repositórios de código público que procuram desenvolvedores de dados confidenciais para deixar para trás. O volume de segredos, incluindo nomes de usuário, senhas, chaves do Google, ferramentas de desenvolvimento ou chaves privadas, continua aumentando à medida que as empresas fazem a transição do software local para a nuvem e mais desenvolvedores trabalham em casa. Somente este ano, haverá pelo menos um aumento de 20% nos segredos expostos em comparação com o ano anterior, diz Eric Fourrier, cofundador da startup de segurança GitGuardian, com sede na França, que verifica repositórios públicos para identificar que atacantes de dados podem aproveitar.
Como hackers encontram segredos do GitHub
Os desenvolvedores deixam o histórico de comandos do shell, arquivos de ambiente e conteúdo protegido por direitos autorais. Às vezes, eles cometem erros porque tentam agilizar seus processos. Por exemplo, eles podem incluir suas credenciais quando escrevem o código, porque é mais fácil depurar. Então, eles podem esquecer de removê-lo e se comprometer. Mesmo que eles façam um commit de exclusão mais tarde ou uma força push para apagar os segredos, essas informações privadas geralmente ainda podem ser acessadas no histórico do Git.
“Encontro muitas senhas em versões antigas de arquivos que foram substituídas por versões mais recentes e limpas sem as senhas”, diz Hays. “O histórico de commits do Git lembra tudo, a menos que você o exclua deliberada e explicitamente.”
Desenvolvedores juniores e seniores podem cometer erros. “Mesmo que você seja um ótimo desenvolvedor e seja educado sobre o assunto, em algum momento, enquanto codifica tarde da noite, você pode cometer um erro, e coisas acontecem”, disse Fourrier. “Evagar segredos é um erro humano.”
Embora qualquer desenvolvedor seja propenso a erros, aqueles que estão apenas entrando no mercado de trabalho geralmente vazam a maioria dos segredos. Muitos anos atrás, quando ela era estudante de engenharia de software, Crina Catalina Bucur criou uma conta AWS para fins de desenvolvimento e recebeu uma conta de US$ 2.000 da qual apenas US$ 0,01 eram legitimamente dela para pagar.
“Meu projeto era uma plataforma agregada de gerenciamento de arquivos para cerca de dez serviços de armazenamento em nuvem, incluindo o S3 da Amazon”, disse ela. “Isso foi antes do GitHub oferecer repositórios privados gratuitos, então minha chave de acesso AWS e a chave secreta correspondente foram publicadas junto com o código para meu repositório público. Eu não parei para pensar nisso, mas mesmo que tivesse, acho que não teria dado muita consideração.”
Alguns dias depois, ela começou a receber e-mails da AWS avisando que sua conta estava comprometida, mas não os leu com atenção – até receber a conta. Felizmente para ela, o suporte da AWS renunciou às cobranças extras. Bucur cometeu vários erros que foram explorados por hackers, incluindo codificar as chaves por conveniência e publicá-las em um repositório de código público.
Hoje, hackers que querem encontrar erros como esses precisam de poucos recursos, diz Hays. Ele é um caçador de recompensas de bugs em seu tempo livre e muitas vezes depende de inteligência de código aberto (OSINT) – informações que qualquer pessoa pode encontrar na web se souber onde procurá-las. “Meu método de escolha é pesquisar manualmente usando a interface padrão do Github.com”, disse ele. “Eu uso operadores de pesquisa para restringir a tipos de arquivos, palavras-chave, usuários e organizações específicos, dependendo de quais empresas estou segmentando.”
Algumas ferramentas podem tornar o processo mais rápido e eficiente. “Os atacantes executam bots automatizados que raspam o conteúdo do GitHub e extraem informações confidenciais”, diz o pesquisador de segurança Gabriel Cirlig, da HUMAN. Esses bots podem ser deixados funcionando o tempo todo, o que significa que hackers podem detectar erros em questão de segundos ou minutos.
Uma vez que um segredo é encontrado, os atacantes podem explorá-lo facilmente. “Por exemplo, se você encontrar uma chave AWS, terá acesso a toda a infraestrutura em nuvem da empresa”, diz Fourrier. “É super simples segmentar desenvolvedores que trabalham para uma empresa específica e tentar analisar alguns dos ativos da empresa.” Dependendo da natureza dos segredos, os hackers podem fazer muitas coisas, incluindo lançar ataques na cadeia de suprimentos e comprometer a segurança dos clientes de uma empresa.
Como as empresas podem proteger segredos contra vazamentos no GitHub
À medida que o volume de segredos aumenta, as empresas precisam se tornar melhores em detectá-los antes que seja tarde demais. O GitHub tem seu próprio “programa secreto de parceiros de varredura”, que encontra sequências de texto que se parecem com senhas, chaves SSH ou tokens de API. O GitHub fez uma parceria com mais de 40 provedores de serviços em nuvem para corrigir chaves de API expostas em repositórios públicos automaticamente.
“Estamos continuamente procurando expandir essas parcerias para proteger melhor o ecossistema”, disse um porta-voz do GitHub à CSO. “Atualmente, revogamos mais de 100 chaves expostas da API do GitHub todos os dias, muitas vezes apresentando com segurança aos novos desenvolvedores a importância da segurança de credenciais à medida que o fazemos.”
Hays disse que o “Programa secreto de parceiros de varredura” é um passo na direção certa, pois torna mais difícil para os atacantes encontrar credenciais válidas. Ele diz, no entanto, que a iniciativa não é perfeita. “Ainda deixa uma lacuna para quando as pessoas acidentalmente verificam suas próprias chaves SSH, senhas, tokens ou qualquer outra coisa que seja sensível”, diz ele. “Isso é muito mais difícil de detectar e gerenciar, pois não há provedores de credenciais em parceria para fazer perguntas como ‘Isso é real? Você quer revogá-lo? Um de nós deveria contar ao proprietário sobre isso?'”
Enquanto isso, ele aconselha os desenvolvedores a estarem conscientes de como estão escrevendo e implantando seu código. “Uma das primeiras coisas a acertar é adicionar as configurações corretas a um arquivo .gitignore”, disse ele. “Este arquivo diz ao Git e, portanto, ao GitHub.com quais arquivos não devem ser rastreados e carregados na internet.”
Algumas startups de segurança também estão tentando preencher a lacuna. GittyLeaks, SecretOps, gitLeaks e GitGuardian visam oferecer mais algumas camadas de proteção para usuários corporativos e profissionais independentes. Alguns detectam segredos vazados em segundos, permitindo que desenvolvedores e empresas tomem medidas imediatas. “Nós digitalizamos todo o seu código em seu software durante todo o ciclo de vida de desenvolvimento, o contêiner Docker, diferentes tipos de dados”, diz Fourrier. “Encontramos os segredos e tentamos revogá-los.”
Idealmente, no entanto, a melhor estratégia é não vazar segredos ou vazar o menor número possível e aumentar a conscientização sobre esse assunto pode ajudar com isso. “Educar desenvolvedores para escrever código seguro e parar bots proativamente é sempre melhor do que jogar whack-a-mole com segredos vazados”, diz Cirlig.
FONTE: CSO ONLINE