#ChaosDB is in the running for worst cloud bug ever.
“Another day, another Microsoft security vulnerability.” That’s what one of my editors said when I proposed this blog on the Cosmos DB bugs detected in the Microsoft Azure cloud platform.
I get it. Few other companies have Patch Tuesdays, with so many new patches every week.
Last year, the FBI alerted Microsoft in public that “Windows 10 Has a Security Flaw So Severe the NSA Disclosed It,” as a Wired headline put it. The flaw, a critical spoofing vulnerability in certificate-of-trust validation software, could be used to fake certificates for executable malware or to decrypt confidential information.
But that wasn’t just another Patch Tuesday flaw. Neither is #ChaosDB, named by its discoverers at Wiz. Ami Luttwak, CTO of the security research company, called it “the worst cloud vulnerability you can imagine” in an interview with Ars Technica. Added Luttwak: “This is the central database of Azure, and we were able to get access to any customer database that we wanted.”
What’s so bad about #ChaosDB? It allows attackers to gain “complete unrestricted access” to not only to corporate accounts and databases — like yours, for example — but accounts and databases at several thousand other organizations that use Cosmos DB, including Fortune 500 companies and public utilities. “Exploiting it was trivial and required no other credentials,” Wiz noted in a blog post.
Jupyter by default
There’s more. A set of multiple flaws lets any user “download, delete or manipulate a massive collection of commercial databases, as well as [gain] read/write access to the underlying architecture of Cosmos DB,” Wiz said. That’s been theoretically possible since mid-2019, when Microsoft added a Jupyter Notebook feature containing the vulnerability to Cosmos DB.
Originally, the feature was turned off by default. If a company activated and used the feature in its Cosmos DB account, they might be at risk. But in February 2021, Microsoft turned on the notebook feature by default.
A new Cosmos DB account created then or later, even if the notebook feature was never used, would place unsuspecting users at risk. If unused during the first three days after account activation, the feature is automatically disabled. Still, that’s enough time for an alert attacker to access an account’s exposed primary read-write key, which Wiz considers the Holy Grail for attackers.
An attacker’s ability to modify and delete data is a major risk, and the primary key gives full access, according to Jon Jarboe, developer advocate for Accurics. Each organization can have more than one account for its cloud provider, Jarboe said in an interview.
“Within an organization’s Microsoft Azure accounts, there can be several Cosmos DB accounts. Each of those Cosmos DB accounts contains a database and a primary read-write key, which could be accessible to the development team, and broadly to others within the organization.”
The havoc attackers could wreak after gaining access to primary keys is potentially immense. “Criminals could alter the recipe for a drug made in a pharmaceutical factory, or on the industrial side it could affect manufacturing plants, or energy producers like power plants” Jarboe said.
Then there’s always malware and ransomware. “If the database is part of a web application used directly by consumers — such as for accessing their bank account — attackers could insert ransomware or other malware in it, such as malware that installs a keylogger to capture user passwords,” he added.
While that gives attackers another avenue for injecting malware on user machines, it also raises the central security issue of trust. “Since this attack vector is coming through a believable channel — your bank in this example — you trust it, perhaps more than you would trust an email asking you to click on a link,” Jarboe said. “But it’s not actually the bank — it’s the cloud service provider that’s the attack avenue.”
Trust and responsibility
Who can cloud users trust? And who is responsible for mitigating cloud vulnerabilities according to the Cloud Shared Responsibility model?
Where that line is drawn isn’t always clear, and there’s nuance. “The fact that this database is managed by the cloud provider, not by enterprise owners of the data, is certainly a source of confusion,” said Jarboe. “Protecting access to keys is typically the responsibility of the user, but how does an enterprise protect against threats like this?”
Since organizations often assume data is secure in the database, they’re likely to sanitize it only when it comes out, said Jarboe. But the best practice would be cleaning it in both directions. “This Cosmos DB vulnerability is a case in which an attacker can change the stored data and you’d have no opportunity to stop it, and may not even know it happened,” he added.
“That’s especially likely in the cloud, where enterprises have less control and visibility at the physical layer.”
Even if data was being sanitized both ways, the #ChaosDB vulnerability means it could still be exposed. “Security is about not just doing the right thing but verifying your assumptions about what others are doing — not leaving visibility gaps where problems can creep into the system,” he said. “Here, Microsoft made some bad assumptions about what was safe.”
The vulnerability “seems to at least be in the class of the worst,” Jarboe agreed, and could kill if used, for example, to change the recipe of a commercial food product. “In theory, exploits could cause mayhem in the energy grid or financial markets, since they, too, leverage cloud services.”
Microsoft said its investigation showed no customer data was accessed by third parties due to the vulnerability. In a separate blog post, the company explained how to secure access to Cosmos DB and regenerate keys.
Wiz credited Microsoft for responding quickly and taking immediate action: disabling the feature until it undergoes a security redesign while notifying affected customers covered during Wiz’s research period.
Since the vulnerability may have been present for months or years, however, Wiz warned all Cosmos DB customers are at risk and should take immediate steps to protect their data.
This article was originally published on EE Times.
Ann R. Thryft has written about manufacturing- and electronics-related technologies for Design News, Test & Measurement World, EDN, RTC Magazine, COTS Journal, Nikkei Electronics Asia, Computer Design, and Electronic Buyers’ News. Sheâ€™s introduced readers to several emerging trends: industrial cybersecurity for operational technology, industrial-strength metals 3D printing, RFID, software-defined radio, early mobile phone architectures, open network server and switch/router architectures, and set-top box system design. At EBN Ann won two independently judged Editorial Excellence awards for Best Technology Feature. Currently, she is the industrial control & automation designline editor at EE Times. She holds a BA in Cultural Anthropology from Stanford University and a Certified Business Communicator certificate from the Business Marketing Association (formerly B/PAA).