Toutes les vulnérabilités
CRITICALInfracurated

CLOUD-CHAOSDB-2021

Cloud · Azure · Azure Cosmos DB

Résumé

ChaosDB, disclosed in 2021, was the kind of cloud vulnerability that is supposed to be impossible: a flaw in Microsoft Azure's Cosmos DB database service that let any customer steal the access keys to thousands of other customers' databases. Cloud platforms promise that tenants are isolated from each other; ChaosDB broke that wall. Researchers found that a built-in notebook feature, enabled by default, could be escalated to grab Microsoft's own internal certificates, which in turn unlocked the keys to every Cosmos DB account on the platform. It is a stark reminder that even in the cloud, the isolation between tenants is itself a piece of software that can have bugs, and one you cannot patch yourself.

How it happened

The Wiz researchers Nir Ohfeld and Sagi Tzadik chained several steps into a cross-tenant break. Cosmos DB's built-in Jupyter Notebook feature, auto-enabled for new accounts since February 2021, ran customer code, and a notebook could run attacker C# code as root (while Python ran unprivileged), giving the attacker root on the container. With root, they removed the iptables firewall rules blocking access to internal Azure endpoints, a server-side request forgery to internal-only services, and reached the WireServer (168.63.129.16) and instance metadata services. Querying the WireServer handed back 25 Microsoft certificates and private keys, including ones for the internal Cosmos DB and notebook services.

Those certificates were the master keys. They let the attacker authenticate to internal Service Fabric clusters, enumerate every customer's Cosmos DB instance, and decrypt each one's stored primary access key and notebook auth tokens, granting full read, write, and delete access across several thousand customers' databases. Crucially, this was a provider-side flaw: under the cloud shared-responsibility model, it was Microsoft's infrastructure that was broken, and customers could not patch it themselves. It was found by researchers, who were paid a $40,000 bounty, with no evidence of malicious exploitation in the wild.

The damage

Several thousand Azure Cosmos DB customers had their primary database keys exposed, which is to say full access to their data. Because the flaw was on the provider side, customers could not fix it; they could only rotate their keys and wait for Microsoft, which mitigated the issue within days and notified affected customers, though only about 30% of them (those it judged at highest risk), a scope Wiz disputed as too narrow given the keys are long-lived and never expire. Microsoft said it had "no indication" that anyone outside the researchers had accessed the keys. ChaosDB became the defining "cross-tenant cloud isolation" case and a landmark in cloud-security research, precisely because it showed that the wall between tenants is software, and software has bugs.

Why ChaosDB still matters

It punctures the comfortable assumption that "the cloud is someone else's problem." The shared-responsibility model means the provider secures the underlying infrastructure, but if the tenant-isolation layer has a flaw, your data is exposed through no fault of your own, and you cannot patch it. The lessons are about defence in depth even on managed services: minimise attack surface by disabling unused features (the notebooks were the entry point), rotate keys regularly and after any provider advisory, restrict access with private endpoints and IP firewalls rather than relying on the key alone, encrypt sensitive data so a stolen key yields less, and isolate sensitive workloads into separate subscriptions. It shares the cloud-key-theft theme with the customer-side Capital One breach.

Comment le corriger

  • Rotate Cosmos DB primary and secondary keys immediately (the only customer-side action against a provider-side key exposure), and rotate again after the provider confirms the fix.
  • Disable unused features like Jupyter Notebooks, and restrict access with private endpoints and IP firewall rules.
  • Audit access logs for anomalous cross-tenant or key-based access.

Comment l’éviter

  • Regenerate Cosmos DB primary and secondary keys, especially after any provider advisory.
  • Disable unused Cosmos DB features such as Jupyter Notebooks to shrink attack surface.
  • Restrict access with private endpoints and IP firewall rules; avoid public exposure.
  • Enable Microsoft Defender for Cloud and audit Cosmos DB access logs for anomalies.
  • Isolate sensitive workloads into separate subscriptions to limit blast radius.

Références

Vulnérabilités liées

Tout Infra →