When you’re working with the Microsoft Azure platform, as a developer or an IT pro, you will almost certainly leverage the Microsoft Azure Storage service. The top-level object in the Azure Storage service is called a “Storage Account.” Each Storage Account can contain the following types of storage objects:
- Azure Files (SMB) shares (PaaS / Iaas)
- Blob Containers (PaaS / IaaS)
- Table Storage (PaaS)
- Queue Storage (PaaS)
Blob Containers are used to host blobs, which are arbitrary pieces of data. For example, you can upload a file from your local filesystem into a Blob, or when you provision a Microsoft Azure Virtual Machine, the VHD files supporting it are also stored as Blobs. There are two different types of storage blobs: Page Blobs, and Block Blobs. For the sake of this article, the blob types don’t really matter, we just need to understand that:
- Each Azure subscription can have multiple Storage Accounts, each with a globally unique name
- Each Storage Account can contain multiple Blob Containers
- Blob Containers can be enabled for public access
Attacks on Blob Containers
Hackers, script kiddies, and other malicious users, can perform attacks against Microsoft Azure public cloud services, including Azure Storage. Thus, it is important to understand how these services work, in order to properly secure them against such attacks, and ensure the privacy of your enterprise data.
As previously mentioned, Azure Blob containers can be configured for public access. There are three different permission levels that can be configured on each Blob Container:
- Off – Public access is completely disabled. You must have a Shared Access Signature (SAS) Token or the Primary / Secondary Storage Account keys in order to access data.
- Blob – Public access to blobs is enabled, however you must know the fully qualified URL to the blob. The attacker must know: 1) the Storage Account name, 2) the Blob Container name, and 3) the Blob name.
- Public – Public access to blobs is enabled, and Blobs can be listed anonymously. The attacker must know: 1) the Storage Account name, 2) the Blob Container name. From there, the attacker can list Blobs inside the Blob Container.
An example of an attacker’s code might look like the following, if they’re using PowerShell. While anonymous access to Blob Containers is a perfectly legitimate use case, attackers can easily build dictionaries of Storage Account names and Blob Container names, and test them for public access by using an anonymous
Storage Context from the Azure PowerShell module.
Now that we understand the attack vector on our Microsoft Azure Storage Accounts, let’s take a look at how to perform a simple audit, to make sure that our Blob Containers are secured against these types of attacks.
Blob Container Automation
Using the Microsoft Azure PowerShell module, we can perform a simple audit of our Blob Containers, to ensure that each container is configured for the appropriate level of access. In some cases, a Blob Container may intentionally be configured for public access, while other times, data will need to be kept private behind a Blob Container that has public access disabled.
To simplify the process of auditing Blob Containers, I have written a simple PowerShell script that iterates over all of the Microsoft Azure Storage Accounts in your Azure subscription, grabs a list of Blob Containers from each one, augments the Blob Container object with a
StorageAccountName property, and finally displays the results using the PowerShell
Out-GridView command. The net result of this script is a Windows Presentation Foundation (WPF) window that displays the most vital properties about the Blob Containers. This gives you a quick look at which Storage Account a container belongs to, the level of public access to the container, and the date that the container was last modified.
One of the unique attributes of this PowerShell script is that it uses PowerShell Background Jobs to spin off a thread for each Azure Storage Account in your Azure subscription. This helps speed up the auditing process, especially if you have a large number of Storage Accounts and Blob Containers inside those Storage Accounts.
Using the data from this script, you can determine if your Blob Containers are configured for the appropriate level of access. The script is uploaded onto GitHub Gist, and is embedded below.
Thanks for reading, and we’ll see you next time! Feel free to follow me on Twitter to keep track of the latest data center, cloud, and automation news!