Find and list Unsecured Azure Storage Blobs

Unsecured cloud storage are often the cause of breaches. It regularly makes the headlines when an Amazon S3 bucket is found with public access and contains tens of thousands or even  millions of records including PII (Personally Identifiable Information) such as addresses, phone numbers and email addresses. The same problem can beset Azure, or I guess, any cloud platform, and while defaults have improved it is still a common misconfiguration that can lead to a breach.  Recently I found myself needing to examine some Azure storage to check for misconfigured public access on some Azure storage accounts. A colleague suggested a script he'd come across Invoke-EnumerateAzureBlobs (thanks Stephen). The PowerShell script can be used to find storage accounts and then enumerate files within that storage account if the permissions allow it. The original article can be found here and the github repo here. I would recommend reading the original post. 

On this occasion I used the this tool and then use Burp Suite Pro to take it a little further. 

I started by using Invoke-EnumerateAzureBlobs to look for the target base name. 

As can be seen from the output above the storage account is found. The -Permutations option allows you to specify a file that contains a list of prefix/suffix that can be used to try to enumerate storage accounts by adding to the Base word then using DNS brute forcing. 

If you supply an Azure Search API key it will use it to search for storage accounts and containers that have been indexed. 

The -Folders option is used to give a list of container names to try with the storage accounts that are found.  As can be seen in the listing above on lines 19-22 a storage account is found and a container called container1. There are two files within the container but for some reason the names don't appear in the output. It's easy to correct this by pasting the URL shown at line at 22 into a browser or by using curl. 

Using an xmllint and an XPath query I get the file names in the storage account. This only works because the storage account has Container public access configured.

In the next example I changed the public access level to Blob. This does not allow Listing of the resources in the container but if you can guess the names of the files inside you can still access them unrestricted.

If I try to list the container now I get an error.

If I know the name of the resource I can still access it.

Using Burp Suite Pro send a request to Intruder and use and configure the payload positions as shown.

Creating a list of both filenames and file extensions for use in the payload positions. Here the filename will be replaced by each name in the list.

Next a list of file extensions for payload position 2.

Because this is Burp Intruder in cluster bomb mode each request for a payload in position 1 is undertaken with all of the payloads in position 2 in turn. The affect is that every filename is tried with every possible file extension. If we had not known the container name from the first example we could extend this technique to try a list of containers as well. 

Each time a status code 200 shows a file was found. If you are using Blob storage on Azure always ensure that the public access permissions are set appropriately and keep monitoring your own storage accounts for changes in public access. 

$accountName = "test1012"

$rgName = "test-store"

$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName

$ctx = $storageAccount.Context

Get-AzStorageContainer -Context $ctx | Select-Object Name, PublicAccess -OutVariable strgAccResult

Name PublicAccess ------- --------------- container1 Blob PS /Users/andrewratcliffe/PowerShell Scripts>

I have heard it said recently there are few uses for the cluster bomb mode of Intruder but I have often found it be useful.