Researchers with the Microsoft Security Response Center (MSRC) and Orca Security drew the covers back this week on a newly fixed critical vulnerability in Microsoft Azure Cosmos DB that impacted its Cosmos DB Jupyter Notebooks feature. The remote code execution (RCE) no longer poses a danger to customers — and no evidence could be found of any incidents stemming from it when it was exploitable.
The public disclosure provides a portrait into how weaknesses in the authentication architecture of cloud-native and machine learning-friendly environments could be used by attackers. Dubbed CosMiss by Orca’s research team, the vulnerability boiled down to a misconfiguration in how authorization headers are handled that let unauthenticated users gain read and write access to Azure Cosmos DB Notebooks, and inject and overwrite code.
“In short, if an attacker had knowledge of a Notebook’s ‘forwardingId’, which is the UUID of the Notebook Workspace, they would have had full permissions on the Notebook, including read and write access, and the ability to modify the file system of the container running the notebook,” wrote Lidor Ben Shitrit and Roee Sagi of Orca in a technical run-down of the vulnerability. “By modifying the container file system — aka dedicated workspace for temporary notebook hosting — we were able to obtain RCE in the notebook container.”
A distributed NoSQL database, Azure Cosmos DB is designed for supporting scalable, high-performance apps with high availability and low latency. Among its uses are for IoT device telemetry and analytics; real-time retail services to run things like product catalogs and AI-driven personalized recommendations; and globally distributed applications such as streaming services, pick-up and delivery services, and the like.
Meantime, Jupyter Notebooks is an open source interactive developer environment (IDE) used by developers, data scientists, engineers, and business analysts to do everything from data exploration and data cleaning to statistical modeling, data visualization, and machine learning. It’s a powerful environment built for creating, executing, and sharing documents with live code, equations, visualizations, and narrative text.
Orca researchers say that this functionality makes a flaw in authentication within Cosmos DB Notebooks particularly risky, since they’re “used by developers to create code and often contain highly sensitive information such as secrets and private keys embedded in the code.”
Not the First Vulnerability Found in Cosmos
The built-in integration of Jupyter Notebooks into Azure Cosmos DB is still a feature in preview mode, but this is definitely not the first publicized flaw found within it. Last year researchers with Wiz.io discovered a chain of flaws in the feature that gave any Azure user full admin access to other customers’ Cosmos DB instances without authorization. At the time, researchers reported big brands like Coca-Cola, Kohler, Rolls-Royce, Siemens, and Symantec all had database keys exposed.
The risk and impacts of this latest flaw are arguable more limited in scope than the previous one due to a number of factors MSRC laid out in a blog published today. The flaw was disclosed to Microsoft by Orca in early October and fixed within two days, requiring no action from customers to roll out due to the distributed architecture of Cosmos DB. According to the MSRC blog, the exploitable bug was exposed for approximately two months after an update this summer in a backend API resulted in requests not being authenticated properly.
The security team conducted a thorough investigation of activity during that time and didn’t find any signs of attackers leveraging the flaw.
“Microsoft conducted an investigation of log data from August 12th to Oct 6th and did not identify any brute force requests that would indicate malicious activity,” wrote an MSRC spokesperson, who also noted that 99.8% of Azure Cosmos DB customers do not yet use Jupyter Notebooks.
Further mitigating the risk is the fact that the forwardingId utilized in the Orca proof-of-concept has a very short lifespan. Notebooks are run in a temporary notebook workspace that has a maximum lifetime of one hour, after which all the data in that workspace is deleted.
“The potential impact is limited to read/write access of the victim’s notebooks during the time their temporary notebooks workspace is active,” explained Microsoft. “The vulnerability, even with knowledge of the forwardingId, did not give the ability to execute notebooks, automatically save notebooks in the victim’s (optional) connected GitHub repository, or access to data in the Azure Cosmos DB account.”