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 →- CRITICALCLOUD-BUCKET-MONOPOLY-2024
In research disclosed to AWS on February 16, 2024 and presented at Black Hat USA and DEF CON 32 in August 2024, Aqua Security's Nautilus team described a class of S3 bucket-name takeover attacks they called Bucket Monopoly, affecting CloudFormation, Glue, EMR, SageMaker, Service Catalog, and CodeStar. These services auto-created S3 buckets with predictable names built from static prefixes plus the account ID and region, such as cf-templates-{hash}-{region}, aws-glue-assets-{account-id}-{region}, and sagemaker-{region}-{account-id}, where account IDs are discoverable from ARNs, access keys, and public repos. Because S3 bucket names are globally unique, an attacker could pre-create a victim's predictably named bucket in a region the victim had not yet used (a Shadow Resource), then the victim's service would later read attacker-controlled content from it. This enabled data tampering, information disclosure, remote code execution by injecting malicious Glue or CloudFormation content, and in some cases full account takeover via planted admin roles; AWS remediated by adding randomized suffixes to bucket names and enforcing aws:ResourceAccount conditions. The class also covers reuse of abandoned or dangling bucket names that a victim configuration still references.
- CRITICALCONTAINER-EXPOSED-DOCKER-API
Exposed Docker API is a recurring misconfiguration class in which the Docker remote API (default TCP 2375 plaintext, 2376 TLS) is published to untrusted networks without TLS or authentication, granting anyone who reaches it full control of the daemon. Because dockerd runs as root and the unauthenticated API permits arbitrary container creation, an attacker can launch a privileged container that bind-mounts the host root filesystem and then chroots into it to escape to the host. The Commando Cat campaign, reported in 2024 by Cado Security and analyzed by Trend Micro (advisory dated 13 June 2024), abused exactly this exposure: it deployed a benign image (cmd.cat/chattr) generated by the open-source Commando project, then used chroot and volume binding of the host's root directory into the container to break out and run host-level payloads. The delivered payloads installed cryptocurrency miners, registered persistence and a stealthy backdoor (including DropBear SSH on TCP 3022), and exfiltrated host and cloud-service-provider credentials. Shell-script and command-and-control infrastructure overlapped with the TeamTNT cryptojacking group.
- HIGHCVE-2024-21626
Leaky Vessels was a set of container-escape vulnerabilities disclosed on 31 January 2024 by Rory McNamara of Snyk Security Labs, the headline flaw being CVE-2024-21626 (CVSS 8.6, runc 1.1.11 and earlier). It was an order-of-operations file-descriptor leak in runc's handling of the process working directory (WORKDIR / process.cwd). During container setup runc left an internal file descriptor referencing the host filesystem namespace open before all privileged descriptors were closed, so a malicious image or a build using a malicious Dockerfile or upstream FROM could set the working directory to that leaked descriptor via a path like /proc/self/fd/7. Because chdir occurred before the descriptor was closed, the container process gained a working directory in the host filesystem and could read and write host files, breaking container isolation and escaping to the underlying host. Related Docker BuildKit issues were disclosed alongside it: CVE-2024-23651 (mount cache race), CVE-2024-23652 (build-time arbitrary delete), and CVE-2024-23653 (GRPC SecurityMode privilege check bypass). The flaw was fixed in runc 1.1.12.
- CRITICALCLOUD-AZURESCAPE-2021
On 9 September 2021 Palo Alto Unit 42 researcher Yuval Avrahami disclosed Azurescape, described as the first cross-account container takeover in a public cloud, in which a malicious container on Azure Container Instances could escape and gain control over other customers' containers running on the shared multitenant Kubernetes cluster. ACI ran an outdated container runtime, runC v1.0.0-rc2, which was vulnerable to CVE-2019-5736, letting the attacker break out of the container and execute code as root on the underlying Kubernetes node. From the node the researcher found the bridge pod, which serviced az container exec calls, sent a Kubernetes service-account token in the Authorization header to a Kubelet that also allowed anonymous access; decoding that token (related to CVE-2018-1002102) granted pods/exec rights across all namespaces and control of the api-server, and thus the whole multitenant cluster. This was a provider-side flaw under shared responsibility that customers could not patch; Unit 42 found it and reported it with no knowledge of exploitation in the wild.
- CRITICALK8S-EXPOSED-ETCD
Exposed etcd is a misconfiguration class in which the etcd key-value store backing the Kubernetes API server is reachable on its client port (TCP 2379, with 2380 used for peer traffic) without client-certificate authentication. etcd is the single source of truth for a cluster and stores the entire cluster state, including all Secrets, service-account tokens, credentials, ConfigMaps, and RBAC rules, so reading it bypasses Kubernetes RBAC entirely and writing to it lets an attacker alter cluster state and take over the cluster. etcd shipped insecure by default: it had no authentication before version 2.1 (July 2015) and client-certificate authentication remained off by default for backward compatibility, and its authorization model is effectively all-or-nothing once access is granted. In March 2018, researcher Giovanni Collazo demonstrated the scale by querying Shodan and finding 2,284 etcd servers exposed to the internet without authentication; a short script then harvested roughly 750 MB of data including thousands of passwords, hundreds of AWS access keys, and private keys. The root cause is an etcd endpoint listening on a network-reachable interface without TLS client-certificate authentication enforced.
- HIGHINFRA-USBLITER8-2026
usbliter8, published on 18 June 2026 by a research group called Paradigm Shift, is an unpatchable BootROM exploit for Apple's A12 and A13 chips, the silicon inside the iPhone XS, XR and 11 families plus the Apple Watch Series 4 and 5. It is the long-awaited successor to checkm8, the 2019 exploit that broke every Apple chip from the A5 to the A11 and was assumed to be the end of that road. The bug lives in the SecureROM, the very first code an Apple device runs at power on, which is etched into the silicon at the factory and can never be altered by any software update. usbliter8 abuses a hardware flaw in the Synopsys DWC2 USB controller: a mismatch in how the controller tracks its DMA memory while buffering USB Setup packets lets an attacker walk a write pointer backwards through memory and overwrite arbitrary SRAM, ending in full code execution inside the most trusted code on the chip. From there it can boot unsigned firmware and step outside Apple's chain of trust entirely, stamping the string PWND into the device's USB serial number as proof of control. The catch is that it is not a remote attack: it needs physical possession of the device, DFU recovery mode, a USB connection and a small RP2350 microcontroller board, and nothing it changes survives a reboot. It also does not break the Secure Enclave, so a device protected by a strong passcode keeps its user data encrypted even after the boot chain has been taken over. Apple cannot repair the affected chips; the only real remedy is newer hardware, because the A14 and later configure the controller correctly and are out of reach.