In the past couple of weeks we heard about two interesting incidents of data leakage from Azure blobs. The Azure blob is a storage service, equivalent to AWS S3 bucket. Since the world is currently busy with much bigger events like the SolarWinds massive incident, the blob leakage didn’t get a lot of coverage. The absurd thing about leaky storage services is that they are very simple to avoid, yet they still happen:
The first event was published by The Register about a blob that contained data of a Cayman Islands-based investment fund. Data containing shareholders name, value of holdings, term sheets, passports and other documents was publicly available.
The second event was brought to us by Techradar about a Canadian app-developer that left a blob open. Not only did it contain more than half a million documents, the company did not create separation between its different clients’ data, which is a basic data management principle. The data contained things like occupational health assessments, insurance claims and other sensitive medical data (HIPAA anyone?).
We don’t hear about many publicly available Azure blob incidents, but that doesn’t mean they are uncommon, and that absolutely doesn’t mean the blob is more secure than the bucket. At the end of the day, the storage service is publicly available because someone made it so.
When initially provisioned, access is enabled from all networks and you might want to choose a specific virtual network, your office IP range or include other limitations.
One detail often missed is the access to storage accounts. You should disallow public access at the account level, and only give access to specific blobs, instead of allowing access at the account level and then disallowing it per each blob.
Another thing to remember is that the name of the blob is unique (just like the S3 bucket name), and that creates somewhat guess-able URLs. There are plenty of open-source tools out there for dictionary attacks, so think about it next time you name your blobs. In the image below you can see the blob I just created for this blog, it might still be up and running but it only contains some images of my dog. I will alert you that I activated logging for the storage account so don’t make me go all Liam Neeson on you. And this is a great opportunity to remind you to activate the monitoring options for your blob.
To sum up, misconfigurations are not a force majeure. They happen because of us, the users. Because we just wanted to provision one thing real quick, or assume someone else will update the configuration down the CI/CD process.
Overly permissive IAM policies is one of the most popular cloud-native attack vectors. From a survey we recently ran, we learned that up to 92% of the policies contain excessive permission, often allowing access to sensitive or private data, remote code execution and wallet attacks. Solvo helps to prevent all of that, simply by integrating early in your CI process, helping the developers to deliver a secured cloud infrastructure, automatically.