Attackers have made it known that Microsoft is clearly in their cross hairs when it comes to potential targets. Just last month the US Justice Department disclosed that Solorigate continues to comprise security when they confirmed over 80% of Microsoft email accounts were breached across four different federal prosecutors offices. In August Microsoft released another security patch (the second of two) for PrintNightmare, which allows remote attackers system level escalation of all Windows clients and servers. Since Microsoft still has the dominate market share for desktop OS, email/office services, along with the second largest market share in cloud computing, any security vulnerability found within the Microsoft ecosystem has cascading effects across the board.
Based on this, we wanted to let our customers know our response to the latest Microsoft security vulnerability. On August 12, Microsoft confirmed a security vulnerability dubbed ChaosDB whereby attackers can download, delete, or modify all data stored within the Azure Cosmos DB service. In response to the vulnerability Microsoft has since disabled the feature that can be exploited and notified potentially affected customers. However, according to the research team that identified the vulnerability they believe the actual number of customers affected is much higher and has the potential to expose thousands of companies dating back to 2019.
Cosmos DB is Microsoft’s fully managed NoSQL database service hosted on Azure which boasts customers such as Mars, Mercedes Benz, and Chipotle. The ChaosDB vulnerability affects customers that use the Jupyter Notebook feature. This built-in feature allows customers to share data visualizations and narrative text based on the data stored in Cosmos DB. Unfortunately, the Jupyter Notebook feature has been enabled by default for customers since February 2021, and fixing the vulnerability is no easy task. Because the vulnerability exposes public keys that can be used to access other Cosmos databases, the resolution requires that customers manually rotate their Cosmos DB primary keys – which are typically long-lived keys and used across multiple services or applications.
For customers using Cosmos DB, we highly recommend following Microsoft’s guidance and rotate their keys, but we also recognize that business can’t stop and unless you’ve automated key rotation, that task may take time and coordination across multiple teams. This blog will help provide some assistance on how one of our newest services can help identify and mitigate ChaosDB.
MVISION Cloud Native Application Protection Platform (CNAPP) is a new service we launched this year that provides complete visibility and security into services and applications built on top of cloud native solutions. MVISION CNAPP helps customers secure the underlying platform like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud used to build applications but also provides complete build and runtime protection for applications using virtual machines, Docker, and Kubernetes.
As part of this service, MVISION CNAPP has a feature called the custom policy builder. The custom policy builder is a great way for customers to audit services across their entire cloud environment in real time to identify risky configurations but can also be used to curate a specific policy to the customer’s unique environment based on several API properties.
How does the custom policy builder work? Once MVISION CNAPP is connected to a customer’s AWS, Azure, or GCP account, the custom policy builder will list all the supported services within each cloud platform. Along with all the supported services, the custom policy builder will also list all the available API attributes for each of those services – attributes that customers can use as triggers for creating security incidents and automatic responses. A good example of the capability would be “if MVISION CNAPP identifies a public Amazon S3 bucket, performs a scan to on the bucket objects to identify any sensitive data and alerts teams via a SNS notification.” When new vulnerabilities like ChaosDB hit the wire, the custom policy builder is purpose built to help customers identify and understand their risk to anything new.
So how can CNAPP help identify if you’re at risk for ChaosDB? Essentially, you’ll want to answer three questions to understand your risk:
- Are we using Cosmos DB?
- If so, do our Cosmos databases have unrestricted access?
- If an attacker did have access to our Cosmos DB keys, what level of access would they have with those keys?
To find answers to these questions, I’ll show how you can create several custom policies using the MVISION CNAPP custom policy builder, but you can combine and mix these rules based on your needs.
In the first example, I’m going to answer the first two questions to see if we’re running Cosmos DB and if the service has unrestricted network access. Under the MVISION CNAPP menu I’ll click on Policy | Configuration Audit | Actions | Create Policy. From there I’ll give my policy a name and select Microsoft Azure | Next. The custom policy builder will automatically prepopulate all the available services in Azure when I click on Select Resource Type. Select Azure Cosmos DB and the custom policy builder will now show me all the available API attributes for that service. Start typing for the string of properties.publicNetworkAccess with a statement of equals to Enabled with a severity level you assign. Click Test Rule and the custom policy builder will check if you’re running any Cosmos DBs that allow access from any source.
Figure 1: Custom Policy Builder Screenshot
If the results of the custom policy show any incidents where Cosmos DB has unrestricted access, you’ll want to immediately change that setting by Configuring an IP firewall in Azure Cosmos DB.
Now let’s see if we have any Cosmos databases where we haven’t set firewall rules. These rules can be based on a set of IP addresses or private end points and should have been set when you created the DBs, but let’s confirm. You’ll follow the same steps as before but select the following criteria for the policy using AND statements:
- ipRangeFilter equals to not set
- virtualNetworksRules is not set
- privateEndpointConnections is not set
Figure 2: Custom Policy Builder Screenshot 2
If you see any results from the custom policy, you’ll want to review the IP address and endpoints to make sure you’re familiar with access from those sources. If you’re not familiar with those sources or the sources are too broad, follow Configuring an IP firewall in Azure Cosmos DB to make the necessary changes.
Finally, let’s show how MVISION CNAPP can audit to see what is possible if your keys were exposed. In general, database keys are issued out to applications so they can access data. Rarely would you issue keys to make configuration changes or write changes to your database services. If you granted keys that can make changes, you may have issued an overly permissive key. Eventually you’ll want to regenerate those keys, but in the meantime let’s identify if the keys can make write changes.
We’ll follow the same procedure as before but use the properties.disableKeyBasedMetadataWriteAccess equals to false
Figure 3: Custom Policy Builder Screenshot 3
Like in the previous examples, if you find any results here that show you’ve issued keys that can make write changes, you’ll want to disable the feature by following Disable key based metadata write access.
Our custom policy builder is just one of the many features we’ve introduced with MVISION CNAPP. I invite you to check out the solution by visiting http://mcafee.com/CNAPP for more information or request a demo at https://mcafee.com/demo.