0
0
Até agora, todos nós ouvimos notícias sobre chaves AWS vazadas por um desenvolvedor no GitHub. Embora isso possa causar manchetes prejudiciais para a empresa, felizmente o GitHub respondeu e agora pode invalidar automaticamente essas chaves de API quando elas acabam em repositórios públicos.
Isso é ótimo, mas limitado por dois fatores críticos:
- O GitHub não monitora todos os tipos de chaves e segredos da API e, especificamente, não se estende a várias lojas de banco de dados
- Esse tipo de monitoramento não ajuda se essas chaves forem expostas em outros repositórios de código ou sites de pasta
Durante um período de 30 dias, escaneamos mais de 150 milhões de entidades do GitHub, GitLab e Pastebin. Durante esse tempo, nossa tecnologia avaliou e categorizou quase 800.000 chaves de acesso e segredos. O que encontramos? Mais de 40% delas foram para lojas de banco de dados – a maioria não coberta pelo GitHub.
PORQUE AS CHAVES DE ACESSO VAZADAS IMPORTAM
Normalmente, quando pensamos em credenciais, a primeira coisa que vem à mente é um nome de usuário e senha amplamente utilizados por pessoas e outros sistemas para autenticar em sistemas. Mas no software, há um tipo adicional de credencial de segurança – uma chave de acesso. As chaves de acesso podem ser públicas ou privadas e, dependendo do tipo de serviços, fornecem autenticação do sistema para sistemas internos ou de terceiros. As chaves de acesso geralmente têm acesso mais amplo do que os indivíduos e menos verificações/restrições ao seu uso.
Infelizmente, essas chaves de acesso podem ser expostas por desenvolvedores de software interno ou contratantes, que podem não ter notado que as configurações de um repositório foram alteradas para público. De fato, este foi o caso com as manchetes recentes feitas pela Starbucks e pela AWS. Esta é uma ocorrência relativamente comum; pesquisas anteriores da Universidade Estadual da Carolina do Norte descobriram que mais de 100.000 repositórios do GitHub vazaram API ou chaves criptográficas.
O uso indevido dessas chaves não é hipotético. No ano passado, a Imperva esboçou como uma brecha resultou no roubo de uma chave AWS API. Mais recentemente, em agosto, pesquisadores descobriram malware roubando credenciais da AWS com o propósito de mineração de criptomoedas.
CAÇANDO CHAVES EXPOSTAS
A maioria das análises de chaves de acesso expostas se concentrou no GitHub e por uma boa razão. Há uma enorme quantidade de dados e vazamentos que vemos. No entanto, para esta pesquisa, também examinamos o GitLab e o Pastebin para fornecer uma ideia mais abrangente de quantas vezes as chaves são expostas. Durante um período de trinta dias (9 de agosto a 8 de setembro de 2020), pesquisamos em aproximadamente 150 milhões de entidades em GitHub, GitLab e Pastebin.
Das 800.000 chaves de acesso avaliadas neste período de tempo (que incluíam nosso arquivo histórico e novos compromissos), dividimos os 20 tipos-chave em quatro categorias: bancos de dados, serviços online, provedores de nuvem e chaves SSH. A divisão do número de chaves está prevista na Figura 1.
BANCO DE DADOS
O impacto potencial das chaves de acesso expostas é mais óbvio quando consideramos as lojas de banco de dados. Se expostos, esses tipos de credenciais podem permitir acesso não autorizado aos dados da empresa (incluindo o PII) com a permissão para expor, destruir ou manipular dados da empresa.
Por muitos anos, testemunhamos o alvo do MongoDB como parte de campanhas de ransomware (mais recentemente, houve 22.900 casos de MongoDB mantidos como resgate).
Mas os impactos vão além dessa tática. Dependendo da natureza dos dados, esse acesso não autorizado pode ter consequências regulatórias, interromper sistemas críticos de negócios e prejudicar a reputação da organização.
Pesquisamos 8 tipos de credenciais de API para os seguintes bancos de dados: IBM DB2, Microsoft SQL Server, MongoDB, MySQL, Oracle DB, PostgreSQL, RabbitMQ e Redis. No total, foram encontradas 129.550 credenciais para essas 8 lojas de banco de dados, com Redis (37,2%), MySQL (23,8%) e MongoDB (19,3%) o mais comum.
PROVEDORES DE NUVEM
A segunda área descrita nesta pesquisa concentrou uma análise de quase 300.000 chaves em quatro tipos de provedores de nuvem: AWS, Azure storage, Azure SAS e Google Cloud.
A autenticação bem-sucedida nesses tipos de ambientes poderia permitir o acesso à infraestrutura de nuvem associada, com permissão para expor, destruir e/ou manipular dados confidenciais. Os dados acessíveis dependem dos serviços utilizados e podem incluir informações da empresa ou informações de sistemas internos. O roubo desse tipo de informação pode ser altamente valioso para cibercriminosos. Além disso, como vimos com o recente direcionamento de chaves AWS para fins de mineração de criptomoedas,existem muitas maneiras de monetizar esse tipo de acesso.
SERVIÇOS ONLINE
A pesquisa se concentrou nos seguintes tipos-chave para serviços online: Google OAuth ID, Mailgun, Microsoft Nuget, Slack (Bot Token, User Token e Webhook URL) e Stripe. O Google OAuth era a maioria clara, com 95% das instâncias. Isso é um pouco preocupante, dado que isso pode ser usado para obter permissão dos usuários para armazenar arquivos em suas Unidades do Google.
Devido ao alto número de ID Google OAuth, estes foram omitidos da Figura 4, a fim de ilustrar melhor os outros tipos de serviços online.
Das mais de 4.000 chaves secretas ou API para serviços online, a maioria (56,9%) foram para Slack. Estes podem ser usados para enganar os usuários para clicar em links ou interromper as operações de negócios. Eles incluem:
- Uma URL webhook, que poderia ser usada para postar mensagens diretamente em um canal dentro da organização.
- Token Slack Bot, que daria acesso a informações confidenciais em canais e conversas para as quais o usuário do bot é convidado.
- Token do Usuário Slack, que daria acesso aos usuários O espaço de trabalho Slack, por exemplo, os canais, conversas, usuários e reações.
É mais do que o Slack, é claro. O acesso a uma chave de API do Microsoft Nuget, por exemplo, pode permitir que os atores carreguem pacotes maliciosos ou excluam pacotes existentes de um repositório de código.
Embora um número relativamente pequeno de segredos do Stripe tenham sido descobertos (274), ele pode ter um alto impacto. Neste caso, o acesso pode resultar na exposição de informações financeiras confidenciais e permitir que um invasor modifique e exclua informações dentro da conta.
Alternativamente, uma chave secreta mailgun poderia permitir o uso da API para enviar, receber e rastrear e-mails – um tipo incrivelmente útil de acesso para campanhas de phishing.
ENCONTRANDO SUAS PRÓPRIAS CHAVES
Para o GitHub, existem algumas opções para ganhar essa visibilidade:
- Trufflehog. Pesquisa através de repositórios git em busca de segredos, cavando fundo em cometer história e ramos. Isso é eficaz em encontrar segredos acidentalmente cometidos.
- GitRob. Ajuda a encontrar arquivos potencialmente sensíveis empurrados para repositórios públicos no Github
- Varredura secreta do GitHub. O GitHub fornece monitoramento para muitos dos principais tipos descritos neste blog. Embora isso não se estenda a muitas das lojas de banco de dados (Redis, Oracle, MySQL, IBM DB2 e PostgreSQL), é um ótimo começo.
Claro, isso é mais do que apenas o GitHub, e por isso vale a pena se referir à ajuda fornecida pelas próprias tecnologias. O Google, por exemplo, fornece orientação útil sobre as medidas a serem tomadas se você desenterrar uma chave de acesso exposta.
Entre em contato para saber mais sobre como ajudamos as organizações a detectar chaves de acesso expostas e outros tipos de vazamento técnico! Você pode ler mais sobre nossa capacidade técnica de vazamento aqui.
FONTE: DIGITAL SHADOWS