ChaosDB – Vulnerabilidade Crítica no Azure CosmosDB

Dados de todos os clientes do provedor de nuvem potencialmente acessíveis por usuários não autorizados

A WIZ publicou pesquisa documentando vulnerabilidade explorável na funcionalidade de Jupyter Notebooks lançado no Cosmos DB pela Microsoft em 30 de setembro de 2019. Sua exploração permitiria a um atacante ler, modificar e apagar dados de base de dados Cosmos DB às quais não teria acesso legítimo de quaisquer outras empresas na Azure.

É muito importante destacar que este recurso é habilitado por default em bases criadas a partir de 10 de fevereiro de de 2021.

Recomendamos a todas as organizações que utilizam Cosmos DB que se informem sobre esta vulnerabilidade e tomem as medidas corretivas descritas aqui para investigar e minimizar a materialização deste risco imediatamente.

Exploração da Vulnerabilidade

Analisando o material disponibilizado pelo grupo de pesquisadores, os passos necessários para a realização do ataquem foram os seguintes:

1. Acessaram o serviço Jupyter Notebook associado a uma base Cosmos DB de uma conta Azure sob seu controle.
2. Exploraram vulnerabilidades deste serviço e conseguiram acesso aos containers destes notebooks. Os tipos de vulnerabilidades não foram descritas no material.
3. A partir dos containers, obtiveram as “Primary Keys” dos Cosmos DBs de diversos outros clientes a cujas contas Azure eles não tinham acesso anteriormente.
4. Usando estas chaves de acesso, os pesquisadores obtiveram acesso de leitura e escrita a bases de dados de outras empresas.

Embora não esteja explicitamente descrito no material, entendemos que o acesso usando a Primary Key provavelmente só funciona em bases expostas à Internet ou ao range de IPs da Azure. Esta é uma configuração que foge às melhores práticas, mas que infelizmente encontramos com enorme freqüência durante trabalhos de assessment.

Impactos Potenciais e Mitigações já Aplicadas

O serviço vulnerável (Jupyter Notebook) foi desativado temporariamente pela Microsoft em todos os clientes após receber a notificação pelos pesquisadores.

Porém, sendo conservadores e trabalhando com a mentalidade de assume breach, organizações devem considerar que caso outros atacantes tenham descoberto independentemente e explorado estas vulnerabilidades, podem já ter extraído Primary Keys das bases Cosmos DB da sua organização.

A janela de exposição de cada empresa depende de quando as bases foram criadas. Aquelas criadas antes de 10 de fevereiro de 2021 estarão vulneráveis apenas se o Jupyter Notebook tiver sido habilitado explicitamente, o que só pode ter acontecido após o lançamento da funcionalidade em 30 de setembro de 2019. Mas deve-se supor que as bases criadas a partir de 10 de fevereiro de 2021 estavam vulneráveis desde sua criação.

É possível também que atacantes já tenham realizado exfiltração, adulteração ou remoção de dados usando chaves obtidas usando esta técnica, e que isto não tenha sido detectado pela monitoração de segurança da empresa. Ou pode ser que estejam com as chaves esperando por um momento adequado para utilizá-las.

Ações Imediatas Recomendadas a Todos os Usuários de Cosmos DB

Rotacionar imediatamente as chaves de suas contas. Adicionalmente, é importante estabelecer um processo regular de rotação destas chaves para mitigar riscos similares no futuro.

Restringir os acessos aos bancos de dados em geral, em especial aos Cosmos DB, para apenas aos IPs, redes e recursos necessários.

Idealmente, a geração de logs do Cosmos DB já deveriam estar habilitados. Caso este seja o caso, é fundamental verificar em todo o período de exposição das bases se existem registros de acessos indevidos ou inesperados que possam indicar ações de atacantes.

Após a rotação das chaves, recomendamos também criar regras de monitoração de acessos ao Cosmos DB usando chaves que não estejam mais ativas. Isso permitirá identificar aplicações legítimas que eventualmente não tenham tido as credenciais atualizadas durante a rotação, ou ainda identificar ações de potenciais atacantes tentando usar as chaves que obtiveram previamente.

Medidas Adicionais Recomendadas

Aproveite esta oportunidade para revisar quais usuários e aplicações possuem acesso às bases Cosmos DB e quais privilégios possuem. Aplicação de mínimo privilégio é sempre uma boa ideia para minimizar o impacto de vazamentos de chaves.

Vale também revisar a metodologia de acesso sendo atualmente utilizada para suas bases Cosmos DB:

• Primary/Secondary Keys são a forma mais simples e menos segura de concessão de acessos justamente porque é fixa e pode ser compartilhada em grande escala (ex.: outras aplicações, times de suporte e etc). Recomendamos que esta forma de acesso seja descontinuada, mas enquanto isso não for possível que a rotação regular de chaves seja implementada como controle mitigatório.
• Resource Tokens são usados de forma similar aos Primary/Secondary Keys, porém são mais seguros por tornarem possível estabelecer limites de tempo e privilégios granulares de acesso.
• RBAC é a forma mais recomendada de acesso a Cosmos DB, pois permite controlar a identidade (autenticação) de quem pode acessar o Cosmos DB e também o privilégio de acesso (autorização) que será permitido. Combinado com uso de MFA para acesso por colaboradores, oferece um nível de segurança bastante superior às demais alternativas acima.

Implemente acessos às suas bases apenas via private endpoints. Por padrão, novas contas do CosmosDB são acessíveis pela Internet – e neste caso, exploráveis através dessa vulnerabilidade. Existem diferentes formas de estruturar sua rede para deixá-la mais segura utilizando firewalls, service endpoints ou private endpoints e é importante implementá-las para reduzir a superfície de ataque de seus ambientes Azure.

Por fim, use o Azure Key Vault para implementar criptografia de dados em repouso com uma Customer Managed Key em suas bases CosmosDB. Quando esta técnica é utilizada, um atacante que tenha apenas chaves de acesso à base mas não tenha privilégios de uso da CMK não conseguiria ler ou escrever dados na base.

Temos Dados Pessoais em Cosmos DB, Preciso Notificar um Incidente pela LGPD?

Em um primeiro momento, recomendamos investigar os logs de seu ambiente buscando por indicadores de comprometimento, para confirmar se houve algum acesso indevido às suas chaves ou aos seus repositórios de dados.

Se sim, recomendamos seguir os procedimentos de análise e resposta a incidentes imediatamente. Caso negativo, sugerimos apenas guardar as evidências de análise e investigação juntamente com as ações tomadas para mitigar as vulnerabilidades expostas acima.

Caso precisem de algum apoio, nosso time de especialistas em segurança de nuvem está à disposição para ajudá-lo. Entre em contato conosco no e-mail contato@tenchisecurity.com.