Microsoft has released additional guidance to mitigate the cloud vulnerability in the Azure Cosmos DB Jupyter Notebook feature, but reaffirms that only a “subset” of customers who had the feature enabled were vulnerable.
Further, no customer data was accessed because of this vulnerability, and impacted customers who’s primary read-write keys may have been impacted were notified, the Microsoft Security Response Center (MSRC) said in a blog post.
The flaw, called ChaosDB, could allow an attacker to gain full admin access to a customer’s Cosmos DB instances without authorization and without previous access to the target environment.
According to Microsoft, the vulnerability impacted only a “subset” of customers who had this particular feature enabled, and all have been notified and advised to regenerate their primary read-write key. The secondar read-write key, primary read-only key and secondary read-only keys were not impacted, the company says.
Read Next: Azure Cosmos DB Flaw Exposed Customer Data
“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,” the MSRC said.
However, organizations with diagnostic logs enabled can review the logs for unusual activity and foreign IP addresses. The company also advises to enable Diagnostic Logging in Azure Defender and periodically rotate keys.
Microsoft again directed system administrators to rotate and regenerate keys via this technical document.
The company also suggests that all Azure Cosmos DB customers use a combination of firewall rules, vNet and/or Azure Private Link on their account to help prevent access to accounts from outside the network or from unexpected locations.
Administrators should also implement Role Based Access Controls to allow per user and security principal access control to Azure Cosmos DB. Identities can be audited in Azure Cosmos DB’s diagnostic logs. Those unable to use this tool should regularly rotate keys.
Leave a Reply