Um invasor acessou contas da AWS de vários clientes da Qubole entre 14 e 26 de outubro e roubou segredos e dados armazenados, segundo a empresa de segurança em cloud Wiz.
O invasor usou credenciais de uma conta da AWS que a plataforma da Qubole utiliza para acessar os ambientes dos clientes. Não foi divulgado como essas credenciais foram obtidas.
A Qubole, plataforma de data lake pertencente à Idera, opera dentro das contas da AWS de seus clientes. Para permitir esse acesso, o cliente cria uma função do IAM, uma identidade da AWS com um conjunto próprio de permissões.
A política de confiança da função permite que a conta da AWS da Qubole a assuma, concedendo essas permissões. Cada solicitação para isso, chamada `AssumeRole`, precisa incluir um código associado à Qubole, conhecido como identificador externo.
Segundo os pesquisadores da Wiz, a maioria das funções assumidas pelo invasor não era usada. Ainda assim, todas continuavam confiando na conta da Qubole, por isso as solicitações do invasor foram aceitas.
Qualquer organização que tenha conectado a Qubole à AWS, mesmo que já não use a plataforma, deve verificar os registros do CloudTrail desde 1º de outubro. O sinal a procurar é uma solicitação `AssumeRole` originada da conta usada pela plataforma da Qubole, `805246085872`, mas enviada de um endereço fora da AWS.
Os pesquisadores não informaram se as credenciais foram desativadas ou se a atividade foi interrompida. Segundo o The Hacker News, quando o veículo verificou os sites da Qubole e da Idera, nenhuma das empresas havia publicado um comunicado sobre o ataque.
Por que as funções permitiram o acesso
Segundo a análise técnica dos pesquisadores, todas as solicitações `AssumeRole` associadas ao invasor continham um identificador externo e foram aceitas.
A AWS aceita uma solicitação `AssumeRole` para esse tipo de função quando ela vem da conta confiável e inclui o identificador externo correto. De acordo com as orientações da AWS, esse código não é considerado um segredo e pode ser consultado por qualquer pessoa com acesso à função.
A Sentra identificou a atividade nos ambientes de vários clientes e alertou os pesquisadores.
Nas contas examinadas, o invasor procurou credenciais armazenadas. Ele leu variáveis de ambiente de funções do Lambda, extraiu segredos do Secrets Manager e consultou valores no SSM Parameter Store.
Em seguida, testou as credenciais encontradas com o TruffleHog. Entre elas estavam chaves de acesso da AWS das próprias vítimas, segredos de cliente do Entra ID e credenciais de cliente da Okta.
O invasor também copiou dados do S3. Em vez de procurar informações específicas, extraiu dados de qualquer bucket ao qual a função tinha acesso. Em alguns casos, baixou um bucket inteiro em uma única sessão.
Os pesquisadores não relacionaram a campanha a outras atividades divulgadas publicamente. Segundo eles, os alvos não correspondem ao padrão habitual de grupos patrocinados por Estados.
A Qubole também permite que clientes se conectem à AWS usando chaves de acesso, em vez de uma função. Entre 8 e 11 de outubro, um invasor usou chaves de acesso da AWS dos próprios clientes, que, segundo os pesquisadores, teriam sido configuradas para a Qubole.
Esse invasor comprometeu depois alguns ambientes de cloud das vítimas. A atividade não foi relacionada ao abuso do `AssumeRole`.
Como verificar suas contas
As orientações de busca da Wiz abrangem os registros do CloudTrail desde 1º de outubro em todas as contas da AWS que tenham uma função da Qubole. Procure por:
• **Conta:** solicitações `AssumeRole` em que `userIdentity.accountId` seja `805246085872` e `sourceIPAddress` não corresponda a um endereço da AWS. Os pesquisadores observaram que o tráfego legítimo da Qubole vinha apenas da AWS.
• **ID da identidade do IAM:** `AIDA3W7DIFLYOLTK63SFS`. Toda atividade dessa identidade deve ser investigada, pois, nas contas examinadas, somente o invasor a utilizou.
• **ID da identidade do IAM:** `AIDAJYRRH5Y3A7AAJM2HW`, quando o endereço de origem estiver fora da AWS. O invasor usou essa identidade a partir de 18 de outubro, mas o tráfego normal da Qubole também passa por ela.
• **Endereços IP:** `57.129.54[.]120` e `2001:41d0:70d[:]7800::`, hospedados pela OVH e usados pelo invasor.
• **Endereços IP:** `45.83.220[.]211`, `185.209.199[.]73` e `89.37.63[.]175`, associados à VPN Mullvad. Como outros usuários da VPN compartilham esses endereços, uma correspondência, por si só, não comprova uma invasão.
• **Nome da sessão:** sessões de função iniciadas por `quiam-`, como `quiam-enum`.
• **Agente do usuário:** chamadas do TruffleHog a `GetCallerIdentity` feitas a partir de um dos endereços IP mencionados. Procure o mesmo agente do usuário nos registros de acesso do provedor de identidade.
Para cada sessão suspeita, analise todas as ações realizadas em seguida, sobretudo no Secrets Manager, no SSM Parameter Store, no Lambda e no S3.
Os eventos de gerenciamento do CloudTrail registram cada solicitação `AssumeRole` e a listagem de buckets, mas não mostram quais objetos do S3 foram lidos. Para isso, são necessários eventos de dados do S3 ou registros de acesso do servidor S3. Várias vítimas não tinham esses registros habilitados, o que impediu as equipes de resposta de determinar quais objetos foram lidos pelo invasor.
Como fechar o caminho de acesso
Os pesquisadores recomendam as seguintes medidas:
• Se o invasor assumiu uma função da Qubole, rotacione todos os segredos, parâmetros e variáveis de ambiente do Lambda aos quais ela tinha acesso e revogue as sessões ativas da função. A rotação de uma credencial não encerra sessões já emitidas.
• Remova as funções da Qubole que não são mais necessárias ou retire a conta da Qubole da política de confiança.
• Quando houver suporte da Qubole, substitua o principal `:root`, válido para toda a conta, na política de confiança pela identidade específica do IAM usada pela empresa.
• Adicione uma condição `aws:SourceIp` ou `aws:SourceVpce` para restringir as solicitações `AssumeRole` às faixas de rede documentadas pelo fornecedor. Segundo os pesquisadores, “uma condição de IP de origem, sozinha, teria bloqueado todas as tentativas de assumir funções que observamos”.
• Considere que outras pessoas podem ver o identificador externo. Ele aparece em texto simples nos registros do CloudTrail e costuma ser armazenado por fornecedores e em arquivos de infraestrutura como código. Por isso, não o use como único controle. Após um incidente como este, altere o identificador externo da Qubole e, sempre que possível, use um valor diferente para cada função.
• Revise o alcance de cada função de fornecedor. O guia de configuração da Qubole inclui uma política de exemplo para o S3 que permite à função ler todos os buckets da conta. Segundo os pesquisadores, funções de fornecedores costumam receber, por conveniência, acesso às configurações do Lambda, ao Secrets Manager, aos parâmetros do SSM e permissões amplas de leitura no S3.
• Configure alertas para solicitações `AssumeRole` provenientes de uma conta de fornecedor e feitas por meio de uma VPN ou de uma empresa de hospedagem que o fornecedor não tenha usado antes.
• Registre todas as contas e regiões com uma trilha organizacional e habilite eventos de dados do S3 ou registros de acesso do servidor nos buckets que armazenam informações sensíveis.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...