CosmosEscape: uma consulta de grafo devolveu a chave de todos os bancos do Azure Cosmos DB

O ponto de partida foi uma exceção .NET aparecendo onde não deveria. A maioria das implementações de Gremlin, a linguagem de consulta de grafos do Apache TinkerPop, roda sobre JVM. Ver um erro de .NET indicava que a Microsoft tinha escrito o próprio motor, e motores de Gremlin costumam compilar a consulta em código executável antes de rodá-la em ambiente restrito.

Sandbox construído para conter código gerado a partir de entrada do usuário tem histórico ruim. Este também tinha.

Da consulta ao gateway

O motor traduzia a consulta Gremlin em código .NET e aplicava um conjunto de restrições para impedir que a consulta fizesse qualquer coisa além de operações de grafo. As restrições não cobriam reflexão em .NET de forma suficiente. A partir daí os pesquisadores montaram primitivas de leitura de arquivo, escrita e, por fim, execução arbitrária de código, tudo por meio de consultas contra o banco de dados deles mesmos.

O código passou a rodar no DB Gateway, o serviço que executa as consultas dos clientes em clusters Service Fabric compartilhados entre inquilinos. Os bancos dos clientes não ficam nesses clusters, mas o gateway precisa alcançá-los de alguma forma. Ele faz isso como qualquer cliente do Cosmos DB faria: usando a chave primária da conta de destino, que dá acesso total de leitura e escrita.

Restava a pergunta que define o tamanho do problema. Como o gateway obtém essa chave primária?

A chave que não estava presa a ninguém

Por credenciais disponíveis no cluster, o gateway alcançava uma chave de assinatura capaz de recuperar a chave primária da conta solicitada. Essa chave de assinatura não era escopada por conta. Funcionava entre inquilinos, entre regiões e entre sabores de API, incluindo SQL, MongoDB, Cassandra e Gremlin. Os pesquisadores a batizaram de Cosmos Master Key.

A mesma chave abria o Config Store, um registro regional com nome de conta, ID de assinatura, ID de inquilino, configuração de rede e etiquetas de todas as contas Cosmos DB daquela região. O Config Store é, ele próprio, um banco Cosmos DB, o que significa que podia ser consultado com a flexibilidade do motor SQL do serviço.

Juntando as duas peças, a cadeia fica curta e direta: consultar o Config Store filtrando por inquilino para achar os bancos de uma organização específica, e usar a Master Key para pegar a chave primária. Duas etapas, a partir de endpoints públicos.

Rede privada não protegia

Contas com isolamento de rede também estavam expostas, e a razão é estrutural. Quem aplica a regra de isolamento é o próprio DB Gateway. Comprometer o gateway significa passar por cima do controle. Os pesquisadores registram ainda que o acesso de escrita ao Config Store sugeria a possibilidade de reescrever as configurações de rede de uma conta alheia.

O Cosmos DB sustenta serviços da própria Microsoft. Entra ID, Teams e Copilot armazenam dados nele. Os bancos internos estavam sujeitos à mesma cadeia. A Microsoft afirma ter revisado logs de acesso e não encontrado atividade não autorizada fora dos testes da Wiz, e diz que nenhum dado de cliente foi acessado.

Linha do tempo

Data	Evento
20/11/2025	Wiz Research reporta a falha à Microsoft, que confirma o recebimento no mesmo dia.
22/11/2025	Microsoft implanta mitigação bloqueando o ponto de entrada na API Gremlin e inicia a correção arquitetural.
Julho de 2026	Conclusão da migração em todas as regiões, com eliminação da chave de escopo global.
30/07/2026	Divulgação pública. Sem CVE e sem pontuação CVSS, por se tratar de falha em serviço gerenciado.
Agosto de 2026	Cadeia completa de exploração será apresentada na Black Hat USA.

Leitura LATAMSEC

Oito meses entre a mitigação emergencial e o fim da correção. Esse intervalo não é crítica ao processo da Microsoft, que respondeu em 48 horas. É a medida realista de quanto tempo leva para reconstruir a arquitetura de autenticação de um serviço que sustenta outros serviços. E é tempo que o cliente passa sem saber de nada.

A frase "nenhuma ação é necessária" é verdadeira e insuficiente ao mesmo tempo. Verdadeira porque não há patch a aplicar. Insuficiente porque o cliente que quisesse verificar de forma independente se alguém usou a Master Key contra os bancos dele precisaria de log de plano de dados retido desde novembro de 2025. Poucas operações no Brasil têm isso. A maioria mantém log de plano de controle, que registra quem criou ou apagou recurso, e não quem leu documento.

Há uma pergunta prática que vale levar para a próxima reunião de arquitetura: quais dos nossos dados estão em serviço gerenciado onde a única fronteira de isolamento entre nós e outro inquilino é código do provedor que não podemos auditar? A resposta não implica sair da nuvem. Implica saber onde o risco é herdado, para que a decisão sobre criptografia com chave gerenciada pelo cliente, segregação de assinatura e retenção de log de acesso seja tomada por escrito, e não por omissão.

Vale um registro sobre o método. A Wiz informa que a pesquisa contou com auxílio de uma versão inicial do Atlas, o pesquisador de vulnerabilidades com IA da empresa. A mesma tecnologia que aparece do lado ofensivo em outras análises desta semana está encurtando o ciclo de descoberta do lado defensivo. A assimetria segue existindo, mas mudou de lugar.