Protecting against #ChaosDB

Cloud security researchers @sagitz and @nirohfeld who both work at Wiz recently discovered what I think is a major vulnerability that exploits the recent CosmosDB Jupyter notebook feature to escalate access into other customer notebooks, harvest the CosmosDB keys and access their data!! This vulnerability has been tagged “#ChaosDB”. Microsoft has since disabled this feature and notified customers— https://www.theregister.com/2021/08/27/chaos_db_azure_cosmos_flaw/.

So what else can you do if you’ve had the feature enabled in the past apart from urgently regenerating your CosmosDB account keys and investigating suspicious events in your Azure Logs? Below are a set of recommendations to protect Azure environments not only against this particular vulnerability but others that might happen in the future. This is by no means an exhaustive list.

Improve your CosmosDB 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 would still need to compromise a trusted network to use the key for access.

CosmosDB network-level access protection

• Evaluate using Azure Policy. Here are three built-in policies that we can use: CosmosDB accounts should use private link; Azure Cosmos DB should disable public network access; Azure Cosmos DB accounts should have firewall rules.
• If you’re using a cloud native security tool like Prisma Cloud, you could use RQL to add accessment policies at scale using the Resource Query Language (RQL).
• Evaluate using Prisma Cloud 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
• Reference: https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-firewall
• Reference: https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-private-endpoints

2. Prevent control 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 control plane changes like modifications of account, database or container properties. 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
• You can evaluate using this built-in Azure Policy — Azure Cosmos DB key based metadata write access should be disabled.
• Evaluate using the built-in Azure Policy: Azure Cosmos DB key based metadata write access should be disabled.
• Evaluate using RQL: config from cloud.resource where cloud.type = ‘azure’ AND api.name = ‘azure-cosmos-db’AND json.rule = properties.disableKeyBasedMetadataWriteAccess is false
• Remediate using Azure CLI — az cosmosdb update — name <CosmosDBAccountName> — resource-group <ResourceGroupName> — disable-key-based-metadata-write-access true
• Remediate using Azure PowerShell — Update-AzCosmosDBAccount -ResourceGroupName <ResourceGroupName> -Name <CosmosDBAccountName> -DisableKeyBasedMetadataWriteAccess true
• Reference — https://docs.microsoft.com/en-us/azure/cosmos-db/role-based-access-control#prevent-sdk-changes

3. Disable local (key-based) 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 setting the following account-level property — “disableLocalAuth”: true. This can be done using an ARM template (not yet available through the portal).

Disable Key-Based authentication for SQL API Cosmos Accounts

• Evaluate using the built-in Azure Policy: Cosmos DB database accounts should have local authentication methods disabled
• Evaluate using Prisma Cloud RQL: config from cloud.resource where cloud.type = ‘azure’ AND api.name = ‘azure-cosmos-db’ AND json.rule = properties.EnabledApiTypes equals “Sql”
• Reference — https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#disable-local-auth

4. Implement an automated key rotation

• CosmosDB does not currently have a built-in key rotation capabilities that is integrated with Azure Key Vault (similar to the capabilities currently available for Storage Accounts)
• The approach highlighted here fro Azure SQL can be adapted for Cosmos DB — https://docs.microsoft.com/en-us/azure/key-vault/secrets/tutorial-rotation#create-and-deploy-sql-server-password-rotation-function

For information on Pentesting Azure, I highly recommend a book that @kfosaeen and myself authored — Penetration Testing Azure for Ethical Hackers