If you are working with Azure, you probably heard about recent “security breach” happened with Microsoft. And Microsoft even responded:
In a nutshell, SOCRadar discovered misconfigured Azure Blob Storage which was publicly exposed. Unfortunately, it had A LOT of sensitive data inside.
Right now this situation is going into discussions around impact and if SOCRadar actions were ethical, however, that is not a first time someone highlighted this issue.
A bit of history.
In the beginning of 2021 security researcher from CyberARK released an article about hunting publicly exposed blob storage in Azure environment (sounds familiar, isn’t it?).
Tool to find publicly exposed blobs even was published on GitHub:
Let me use a quote from this article:
Spoiler alert: we found millions of files – many containing sensitive information including individuals’ medical records and personal data, companies’ contracts, signatures, invoices, and much more. In one case, we contacted an American electronics repairing company that had invoices and pictures of their customers’ products including personal details and UID’s publicly opened and helped them change the access level of those files to private.
So, we can see that security researches was mentioning this situation for quite a some time. But it just didn’t catch attention in the past, because it was not a Microsoft, who “leaked”.
What is actually happening?
Basically, situation is that any content of Azure Storage Account can be publicly exposed and allow anonymous access to content in it. That is happening because if you make your Storage Account publicly available, you have following options:
- No public read access: The container and its blobs can be accessed only with an authorized request. This option is the default for all new containers.
- Public read access for blobs only: Blobs within the container can be read by anonymous request, but container data is not available anonymously. Anonymous clients cannot enumerate the blobs within the container.
- Public read access for container and its blobs: Container and blob data can be read by anonymous request, except for container permission settings and container metadata. Clients can enumerate blobs within the container by anonymous request, but cannot enumerate containers within the storage account.
Just in case, here is a picture with difference between Storage Account, Container and Blob:
So, with several clicks you can make data in Storage Account publicly available.
At this moment it is important to remind Shared Responsibility Matrix.
And as you can see, it is “Customer” responsibility to configure PaaS services (like Storage account) in a proper way to protect data.
How we can prevent issue from happening?
Easiest answer is to go and manually disable public access in Azure Portal, but there is a problem with this approach scalability.
We can talk about writing a script to do that, but in Azure there a better way to do that, especially for large scale environments.
This solutions is Azure Policy.
Using following policy in Audit mode, you can find all Storage Accounts with Public Access Allowed:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "audit"
}
}After, if you more decisive, you can change mode to “Deny” and that will prevent creation of Storage Accounts with allowed public access (NOTE: It also might affect existing resources modification if they have public access allowed).
In more details, you can read official docs from Microsoft
Also, you could (and probably should) use some Cloud Security Posture Management system to track and manage misconfigurations and vulnerabilities in your cloud. Defender for Cloud with built-in recommendations should be more than enough as a start.
What you should do?
First of all, review if you have any Storage Accounts with public access allowed, then depending on your situation plan remediation activities. You can use Azure Policies for that, or Defender for Cloud, or even 3rd party CSPM tools like Wiz.IO.
Any cloud provider has security recommendations, which you should follow. In this case Microsoft has recommendations you can find here
Also, if you have Storage Accounts with public access allowed, you can check if anonymous access was used in the past using storage account metrics
More details can be found here.
Summary and personal opinion
In current situation we are seeing typical situation of customer misconfiguring something in Azure. Let us be honest, we all saw that happening in different companies. In this case it is Microsoft. People are working everywhere and people are making mistakes.
For me more important is that someone highlighted this situation before, we still have it, and we are going have it in the future, because it is a nature of any technology. It can be misconfigured.
Alex Vanyurikhin 