Update on the vulnerability in the Azure Cosmos DB Jupyter Notebook Feature

On August 12, 2021, a security researcher reported a vulnerability in the Azure Cosmos DB Jupyter Notebook feature that could potentially allow a user to gain access to another customer’s resources by using the account’s primary read-write key. We mitigated the vulnerability immediately.

Our investigation indicates that no customer data was accessed because of this vulnerability by third parties or security researchers. We’ve notified the customers whose keys may have been affected during the researcher activity to regenerate their keys.

Part of any robust security posture is working with researchers to help find vulnerabilities, so we can fix them before they can be used. Thank you to researchers Sagi Tzadik and Nir Ohfeld from Wiz who reported this vulnerability and worked with the Microsoft Security Response Center (MSRC) under Coordinated Vulnerability Disclosure (CVD).

Which Azure Cosmos DB accounts were potentially affected? Which Azure Cosmos DB accounts were potentially affected?

This vulnerability only affects a subset of customers who had the Jupyter Notebook feature enabled. Notifications have been sent to all customers that could be potentially affected due to researcher activity, advising they regenerate their primary read-write key. Other keys including the secondary read-write key, primary read-only key, and secondary read-only key were not vulnerable.

If you did not receive an email or in-portal notification, there is no evidence any other external parties had access to your primary read-write account key. If you have diagnostic logs enabled, you can also review the logs for unusual IP addresses. Our suggestion is to enable Diagnostic Logging and Azure Defender where available and periodically rotate your keys.

How to regenerate your primary read-write key How to regenerate your primary read-write key

Though no customer data was accessed, it is recommended you regenerate your primary read-write keys following the steps described in this technical documentation.

It is also recommended as a best practice:

1. All Azure Cosmos DB customers use a combination of firewall rules, vNet, and/or Azure Private Link on their account. These network protection mechanisms prevent access from outside your network and unexpected locations.
2. In addition to implementing network security controls, we encourage the use of Role Based Access Control. Role Based Access Control allows per user and security principal access control to Azure Cosmos DB – those identities can be audited in Azure Cosmos DB’s diagnostic logs.
3. If you cannot use Role Based Access Control, we recommend implementing regularly scheduled key rotations.
4. You can find additional security best practices in the Azure Cosmos DB security baseline documentation.

Actions Taken Actions Taken

We are taking this vulnerability seriously. Upon the issue being reported to Microsoft Security Response Center we followed our incident response process, which included the following:

• We immediately began our investigation and mitigated the issue by turning off the preview feature in scope of the vulnerability for all customers.
• We then began our forensic investigation. This is where we look at what the researcher reported and match it to our internal logs. We then expanded our search beyond the researcher’s activities to look for all possible activity for current and similar events in the past. Our investigation shows no unauthorized access other than the researcher activity.
• As part of our forensic investigation, we identified all customers for outreach and remediation, which comprised a subset of Azure Cosmos DB customers who were actively using the Notebook feature or created an Azure Cosmos DB account during the researcher activity period between August 7 and 13, 2021.
• We are actively exploring implementing additional safeguards including updating the threat model and adding additional monitoring to detect unintended data access.