Researchers on Tuesday reported what they called a “highly important” vulnerability within Azure Cosmos DB, a Microsoft-owned NoSQL database used for app development, in which authentication checks were missing from Cosmos DB Notebooks.
In a blog post, researchers at Orca Security said the vulnerability - called "CosMiss" - would have let an attacker with knowledge of a notebook’s forwardingID --the universally unique identifier of the Notebook Workspace -- to have full permissions on the notebook without having to authenticate. This included read and write access, as well as the ability to modify the file system of the container running the notebook.
By modifying the container file system the Orca researchers said they were able to obtain a Remote Code Execution (RCE) in the notebook container. Once they found the flaw, Orca reported it to the Microsoft Security Response Center (MSRC), which fixed the critical issue in two days. The researchers said the two-day fix was “impressive” and a “much faster response” than a previously vulnerability, SynLapse, that they discovered in Azure Synapse.
"The fact that there were no authentication checks in Cosmos DB Jupyter Notebooks was especially risky since Cosmos DB Notebooks are used by developers to create code and often contain highly-sensitive information, such as secrets and private keys embedded in the code,” said Avi Shua, co-founder and CEO at Orca Security.
In a blog posted this morning, Microsoft said the bug was first introduced on Aug. 12 and patched worldwide on Oct. 6, and that an investigation of log data between the two dates indicated no evidence of any brute force attacks looking to leverage the vulnerability.
The tech giant downplayed the potential impact, saying the bug is difficult to exploit, the overwhelming majority of Azure Cosmos DB users do not use Jupyter notebooks and that such notebooks automatically delete workspaces and data every hour. It also appears to dispute claims by Orca Security researchers that it provides an attacker with remote code execution capabilities.
"The potential impact is limited to read/write access of the victim’s notebooks during the time (1 hour maximum) their temporary notebooks workspace is active," Microsoft wrote. "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."
Microsoft has a history of disputes with third-party researchers over the potential reach and impact of vulnerabilities found in their products, and some security experts reached by SC Media worried the affects could be felt more deeply.
Craig Burland, chief information security officer at Inversion6, said based on the usage of Cosmos DB Notebooks, the CosMiss could have had significant impacts on numerous organizations. Burland said the vulnerability could have generated rounds and rounds of supply chain attacks if hackers could have gained access and modify code or steal secrets stored in the notebooks prior to code deployment. Given the prevalence of stolen credentials available on the dark web, the potential to exploit this flaw seems quite high, Burland added.
“The speed of Microsoft’s response seems to validate the threat,” Burland said. “Preventing situations like this comes back to really embracing ‘secure by design concepts and zero-trust,” said Burland. “One of the fundamental requirements for integrating Jupyter and Cosmos DB should have been ‘only authenticated users can access the notebook.’ That requirement should have been sitting alongside all the functional requirements that made the project worthwhile.”
Ratan Tipirneni, president and CEO at Tigera, said if CosMiss vulnerability does allow for RCE, it has the potential to cause serious damage depending on how mission-critical the applications are that use Cosmos DB. If data stored in the Cosmos DB notebooks can be discovered by exploiting this vulnerability, that could also give hackers wide access to sensitive and confidential information.
“While it’s unlikely that an external hacker can get access to the UUID of the Notebook Workspace, it still leaves open the possibility of an irate ex-employee exploiting this vulnerability to cause damage,” said Tipirneni.
