Como as credenciais compartilhadas abrem as portas para violações
Sumário
Introdução
Seja por meio de um portal de login bancário, um software de código aberto ou até mesmo pelo próprio sistema operacional, a dependência moderna da tecnologia fez com que tanto os profissionais de tecnologia quanto o público em geral ficassem à mercê do código de outras pessoas. A necessidade de consistência e praticidade nos trouxe recursos como bibliotecas de código, já que escrever códigos do zero não é dimensionável.
Quanto mais complexos os ambientes se tornam, mais importante é encontrar locais onde seja possível automatizar e reutilizar ferramentas já disponíveis para você.
No entanto, o uso de código por parte de um desenvolvedor dessas bibliotecas pré-estabelecidas como base para seu próprio código gera "problemas de confiança"; ou seja, requer um nível de confiança que um profissional de segurança pode considerar arriscado. Quanto mais fundo no código-fonte uma vulnerabilidade se esconde, mais difícil é encontrá-la (considerando que você saiba que deve procurar essa agulha no palheiro digital desde o princípio).
Encontramos um exemplo desses chamados problemas de confiança em nosso próprio processo de desenvolvimento. Um uso aparentemente rotineiro de um de nossos serviços externos levou à descoberta de várias oportunidades de ataque graves. Depois de divulgar as informações ao fornecedor, os problemas identificados foram resolvidos. Nesta publicação do blog, compartilhamos nossas descobertas, detalhamos o processo de investigação e discutimos como os invasores podem usar isso em benefício próprio.
Análise geral
Durante um teste de otimização de rotina, um de nossos engenheiros de DevOps criou um contêiner para uma ferramenta de teste de terceiros. Ele executou o comando muito familiar: apt get update && apt get install XXXX -y.
Depois de inserir o comando, queríamos ver o que estava sendo executado em nosso ponto de extremidade enquanto o processo de criação estava em execução. Para isso, executamos o comando de processo de lista simples ps em nosso ponto de extremidade e nos deparamos com esta linha muito interessante:
Conseguimos usar as credenciais identificadas para autenticar um site que continha centenas de compilações de clientes.
O fato de haver uma chave de texto não criptografado foi alarmante, mas poderia ser explicado/contido pelo controle adequado do usuário, por exemplo, se o token estivesse de acordo com o uso da aplicação. Bem, claramente não foi o caso aqui. O nome de usuário fornecido continha a string "padrão", que nunca é um bom sinal.
Decidimos investigar um pouco mais e tentamos usar as credenciais para autenticar a API, o que nos permitiu consultar informações potencialmente confidenciais (muitas delas). Isso revelou que o usuário "padrão" era realmente muito padrão: o usuário não era dedicado ao uso da Akamai, mas era usado por toda a base de clientes da aplicação.
Armado com esse segredo de texto sem formatação, qualquer invasor poderia usá-lo para obter dados confidenciais (como resultados de execução de teste interno, gravações de vídeo, capturas de tela e fluxos de execução de script interno) da maioria dos clientes da aplicação (Figura 1).
Fig. 1: Example of improperly accessed sensitive customer data
A extraordinária quantidade de dados que foi exposta e o fato de a vulnerabilidade estar visivelmente acessível despertou nosso interesse em investigar mais a fundo a base de códigos e ver o que mais encontraríamos.
Nem tudo deve ser compartilhado
Depois de identificar um segredo compartilhado que estava sendo usado indevidamente pela aplicação, decidimos tentar identificar outros segredos semelhantes. Depois de algumas pesquisas estratégicas (e uma boa arrumada) no código-fonte das aplicações, encontramos três segredos adicionais:
- Uma chave privada do Coralogix
- Uma chave de API do Google
- Um token do ngrok
Vamos analisar cada um desses segredos e seu potencial de abuso.
Coralogix: uma chave privada (muito pública)
Um dos segredos que identificamos na base de código de nossas aplicações foi uma chave privada, o que despertou nosso interesse, então procuramos um nome de usuário que pudesse estar vinculado a ela. Conseguimos encontrar um nome de usuário algumas linhas abaixo da chave como parte de uma função de registro. Usamos outras pistas que foram deixadas para trás e descobrimos que a chave privada pertence à estrutura de registro do Coralogix.
As credenciais foram codificadas, o que significa que elas também estavam sendo compartilhadas por diferentes clientes. Isso poderia significar outro vazamento de dados em potencial, mas felizmente esse usuário/invasor tinha privilégios baixos e só tinha permissão para gravar mensagens de log na estrutura.
Embora não seja tão forte quanto a primitiva anterior, uma primitiva de gravação ainda pode permitir alguns vetores interessantes no próprio fornecedor: um invasor pode inserir mensagens de log falsificadas no ambiente do fornecedor ou tentar injetar logs mal-intencionados para executar ataques como XSS (cross-site scripting) ou injeção de SQL (Structured Query Language).
Chave de API do Google
O OAuth é um mecanismo de autorização usado por todas as operações do Google. Aplicações e sites podem oferecer aos usuários a possibilidade de fazer login em suas aplicações ou sites com a conta do Google facilitada pelo OAuth. Para habilitar essa opção por meio de código, os desenvolvedores precisam de vários parâmetros que podem obter da conta do Google, ou seja, a chave de API: o google_name e o google_secret.
Ao navegar pelo código, encontramos uma referência à API do Google. Normalmente vemos apenas uma chave "google api", mas desta vez foi diferente. Desta vez, também encontramos a chave "google api", o identificador exclusivo google_client e (mais surpreendente!) o identificador google_secret. Com os três elementos, os invasores podem solicitar um link de autenticação do Google como fornecedor. Esse link pode ser usado como parte de uma campanha de phishing para induzir as vítimas a dar permissão ao seu Workspace para os invasores.
Potencial exploração de phishing
Os invasores podem criar um e-mail de phishing contendo um link para um site idêntico ao site do fornecedor com uma alteração crucial: o link para fazer login com o Google é o link que o invasor obteve usando as informações da API do Google do fornecedor (Figura 2).
Fig. 2: Malicious Google login page appears to be legitimate
Ao efetuar login, a vítima concede ao invasor permissão para toda a conta do Google Workspace. O acesso a algo tão confidencial quanto uma identidade do Google dá aos invasores inúmeras possibilidades. A exploração bem-sucedida permitiria que um invasor manipulasse qualquer aspecto da conta do Google Workspace da vítima, incluindo comprometimento de e-mail, download de arquivos e muito mais. Isso pode ser muito útil como parte de um ataque de engenharia social às organizações.
ngrok
O tunelamento de rede é uma solução quase universal para a transferência segura de dados, mas, se comprometido, pode fornecer a um invasor um arsenal de oportunidades para ações mal-intencionadas. Descobrimos muitos parâmetros relacionados ao tunelamento na instalação da aplicação comprometida, incluindo uma configuração do ngrok, o que nos levou a investigar mais detalhadamente. Os mesmos recursos que promovem uma melhor colaboração entre desenvolvedores são exatamente o que torna o ngrok atraente para agentes de ameaças.
O ngrok é um serviço especializado em fornecer uma plataforma para informações de tunelamento por meio de servidores. Ele simplifica a exposição de serviços à Internet, permitindo uma depuração mais rápida e loops de feedback de desenvolvimento mais eficientes. Infelizmente, se um invasor tiver tomado o controle do túnel, essa simplicidade estará disponível para ele também.
Com um simples comando ps, um invasor consegue acessar o ID exclusivo da empresa e o token de autenticação. Esse ID exclusivo não pode ser alterado; ele permanecerá o mesmo em todos os outros usos da aplicação em outros pontos de extremidade. Os invasores podem usar esses parâmetros para enviar o ID e o token ao servidor online de um fornecedor para receber as informações do ngrok da empresa (Figura 3).
Fig. 3: Ngrok token received from the vendor’s server
Isso significa que, após o acesso inicial, os invasores podem copiar o ID e o token exclusivos da vítima e usá-los para ler os dados que estão sendo enviados/recebidos pela aplicação da vítima (Figura 4).
Fig. 4: Example of data being read from ngrok tunnel
Conclusão
As ameaças não são exclusivamente externas. Na verdade, aceitamos voluntariamente algumas ameaças internamente. Muitas pessoas acham que o software de código aberto é o maior perigo devido à confiança que damos a ele, mas ferramentas de terceiros podem representar um desafio maior para as empresas do que o código aberto.
Após nossas descobertas, divulgamos os problemas destacados neste blog ao fornecedor afetado e eles foram corrigidos. Apesar disso, novas falhas de segurança estão sempre surgindo.
Acreditamos que, nesse caso (e em muitos outros), a supervisão de segurança é tão importante quanto o treinamento de desenvolvedores para que tenham uma mentalidade de segurança. Essas duas abordagens podem ajudar a garantir que os serviços gerenciados não causem problemas às empresas.