Azure Cosmos DB Vulnerability
What Happened?
Cloud security researchers recently discovered a critical vulnerability that exploits the Azure Cosmos DB Jupyter notebook feature to escalate access into other customer notebooks, harvest the Cosmos DB keys and access their data. Microsoft has since disabled this feature for all customers and sent out notification emails to customers that could be potentially impacted.
How does it Impact Customers?
This vulnerability allows any Azure user with a working exploit to access, update and delete data in affected Cosmos DB databases without proper mitigations. It could also allow access to read and modify the metadata of the affected Cosmos DB account.
How Can Prisma Cloud help?
If you are a Cosmos DB user, it is a good practice to rotate your keys as soon as possible even if you have not been notified by Microsoft as an impacted user. What can you do if you’ve had the affected feature enabled in the past apart from urgently regenerating your CosmosDB account keys? If you are a Prisma Cloud user, you can investigate your Azure Logs for suspicious activities and ensure that you have mitigation measures in place to protect yourself against future cross-tenant vulnerabilities. Below are a set of recommendations.
Investigate with Prisma Cloud
1. Identify Cosmos DB databases across all your Azure subscriptions that could be vulnerable to this. If you are a Prisma Cloud user, use the query below to investigate this.
Evaluate with RQL: config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db'
2. Verify that your Cosmos DB keys have been recently regenerated. You can use the query highlighted below to quickly verify this in Prisma Cloud. Anomalies will also be highlighted by the built-in ML threat detection capabilities if the action was performed unusually.
Evaluate with RQL: event from cloud.audit_logs where cloud.type = 'azure' AND cloud.service = 'microsoft.documentdb' AND json.rule = $.status.value = 'Succeeded' AND $.properties.message = 'Microsoft.DocumentDB/databaseAccounts/regenerateKey/action'
3. Review Cosmos DB key access events by non-user identities. The vulnerability in this case allowed a Jupyter notebook (non-user identity) to read the access keys of Cosmos DB databases with the impacted feature enabled. Prisma Cloud users can evaluate this using the query below:
Evaluate with RQL: event from cloud.audit_logs where cloud.type = 'azure' AND cloud.service = 'microsoft.documentdb' AND json.rule = $.status.value = 'Succeeded' AND $.properties.message = 'Microsoft.DocumentDB/databaseAccounts/readonlykeys/action'
Mitigate the Risks by Improving Your Cosmos DB Security Posture
1. Implement CosmosDB firewall at a minimum OR preferably virtual network integration.
This ensures that network access is only possible from trusted public IP addresses or from your private virtual network in Azure. Let me be very clear on this - There is no reason to allow UNRESTRICTED network access to your platform databases! This is standard best practice that in my experience, many organizations do not implement. If for no reason, use this as an additional level of protection in situations like this!! This way, even if an attacker gets their hands on a CosmosDB access key, they will still need to compromise a trusted network to use the key for authentication.
Evaluate using RQL: config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db'AND json.rule = properties.ipRangeFilter is empty and properties.virtualNetworkRules[*] does not exist and properties.privateEndpointConnections[*] does not exist
2. Prevent management plane changes for clients using key based authentication.
CosmosDB access keys are mainly used by applications to access data in CosmosDB containers. It is rare for organizations to have use cases where the keys are used to make management changes. To disable this capability, you can set the following account-level property - "disableKeyBasedMetadataWriteAccess": true. This can be done using an ARM template, Azure CLI or Azure PowerShell
Evaluate using RQL: config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db'AND json.rule = properties.disableKeyBasedMetadataWriteAccess is false
Azure CLI: az cosmosdb update --name <CosmosDBAccountName> --resource-group <ResourceGroupName> --disable-key-based-metadata-write-access true
Azure PowerShell: Update-AzCosmosDBAccount -ResourceGroupName <ResourceGroupName> -Name <CosmosDBAccountName> -DisableKeyBasedMetadataWriteAccess true
3. Disable local authentication for SQL API CosmosDB accounts.
The CosmosDB service currently supports five API - Core (SQL), Table, MongoDB, Cassandra, Gremlin. Of all these five APIs, only the Core (SQL) one allows identity-based access using Azure AD with RBAC. When this is implemented, a customer can disable long-lived access keys by updating the properties of the CosmosDB account using an ARM template (not yet available through the portal).
Evaluate using RQL: config from cloud.resource where cloud.type = 'azure' AND api.name = 'azure-cosmos-db' AND json.rule = properties.EnabledApiTypes equals "Sql"
Learn More with a Free Trial
Prisma Cloud helps organizations scale their cloud network security efforts. To learn more about how Prisma Cloud can help you, check out Why Prisma Cloud.
To get valuable hands-on experience with this Cloud Network Security capability, request a 30-day trial.