With the headline “Improperly Configured AWS S3 Bucket Exposes 10 Million Hotel Guest Records” in this week’s SANS NewsBites, I wanted to shed a little light on the same problem, but in Azure.
Microsoft Azure Blob Storage is very similar to AWS S3, and comes in three access control flavors:
- “Private” is thankfully the default. and turns off anonymous public access
- “Blob” allows unauthenticated public access to a file, as long as you know its name
- “Container” is the same as blob, but also allows to list the folder contents
You can check the configured access level by looking at your Azure resources, clicking on the storage accounts, and then drilling down into the storage containers present:
An access level of “Blob” can be sufficient for something like a public website. It behaves very similar to a web server – if someone knows or can guess the file name, they can access the file, no questions asked. For business data, this level of access is dangerous though, because its “security” basically just relies on your assumption that nobody else knows or can guess the file name. More often than not, this assumption turns out to be ill-advised. Other files that you intentionally share publicly might have a similar naming structure, or you maybe are using easily guessable names to begin with. In a nutshell: If you would consider a file too sensitive to store on your public web server, don’t store it in a Azure container with “Blob” access, either.
An access level of “Container” is the same as “Blob”, but worse. An attacker just needs to know the name of the Storage Account itself. That’s the part of the name in front of the *.blob.core.windows.net URLs that you certainly have encountered before. That name space is pretty small, because the Storage Account Name has to be unique across all Azure tenants (Microsoft Azure Customers). While creating a new storage account, “name collisions” are therefore quite frequent:
The container name itself (one level below the storage account) only needs to be unique per storage account though, and cannot be directly enumerated. Therefore, even accounts that are exposed at access level “Container” retain a tiny modicum of security-by-obscurity, presumed that your container is indeed named obscurely. In my example shown, the container is named “logs”, and would likely be discovered real quick once someone develops any interest in my “temporaryexampleonly” container. Enumerating the contents is then only one API call away, and the resulting XML/JSON is readily machine parseable to extract the URLs of all the files in the container. Once the file and path names are known, the files can be obtained even if the access level is later changed back to “Blob”.
One way to quickly find out if you have exposed Containers in your Azure Storage setup is to use Azure Security Center (ASC). Even at the “Free” tier, you will see recommendations like these:
If your ASC displays this recommendation for any of your storage accounts, take it seriously, and investigate if the flagged resource is public-by-design, or public-by-mistake.
In the next diary, I’m going to show how you can reliably prevent the problem from occurring in the first place.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License. Read More
The post Exposed Blob Storage in Azure, (Thu, Nov 12th) appeared first on Malware Devil.
https://malwaredevil.com/2020/11/12/exposed-blob-storage-in-azure-thu-nov-12th/?utm_source=rss&utm_medium=rss&utm_campaign=exposed-blob-storage-in-azure-thu-nov-12th
