AZURE PENTESTING — EXPLOITING THE ANONYMOUS ACCESS TO THE BLOB STORAGE — Draft Eng — Updated :)
What is a Storage Account and how could it be vulnerable?
In simple terms, it’s a storage that allows storing Azure objects: Blobs, files, queues, and tables.
Now, due to improper practices, these objects can be accessed anonymously, but it depends on the configurations set by the cloud administrator.
Based on this, in black-box ethical hacking, it’s usual to know the name of our client’s Storage Account, whereas, in grey-box, it’s usual to have the necessary credentials to audit the Azure portal more quickly.
Based on these assumptions, we will proceed to analyze the anonymous access.
Laboratory
As a starting point, a vulnerable lab has been created. In this case, the Storage Account is “storageaccountbrp.”
Black Box
Requirement: Name of the Storage Account -> “storageaccountbrp”
Proof of concept
Since this is a black-box analysis, we’ll use Microsoft documentation to identify the Blob Storage endpoint.
According to Microsoft, the standard for identifying endpoints related to the Storage Account is as follows.
So, the endpoint that would allow access to our blob storage would be the following
Now we have the Blob Storage endpoint. Now, we wonder, is the anonymous access configuration of the Storage Account enabled?
To answer this question, we need to add the following parameters “<ContainerName>?restype=container&comp=list” to our endpoint and specify some container to analyze.
https://<StorageAccountName>.blob.core.windows.net/<ContainerName>?restype=container&comp=list
Then we need the name of some container.
Now, I will use “$logs” container because by default the Storage Account creates this container. (Updated -> There was a little updated with azure and now you can use whaterer name)
So, with the help of this name, we will find out if anonymous access is enabled WITHOUT the need to check the Azure portal, as we are currently in a black-box project.
So, the previous link would look like the following:
https://storageaccountbrp.blob.core.windows.net/$logs?restype=container&comp=list
We access to the URL and we will see the “ResourceNotFound” message. This message suggests that anonymous access is enabled
“What message would be displayed if anonymous access were disabled?”
“The following table summarizes the analysis.”
So, if it were disabled, the exploitation wouldn’t proceed. But since it is enabled, we continue.
Next, we use an enumeration tool for searching containers. For instance, we’ll use wfuzz to enumerate them.
From this point, it’s already possible to access the resource anonymously and find sensitive information.
Container: “resources”
Container: “servicios”
Container: “container”
Grey Box
Requirement: Name of the Storage Account -> “storageaccountbrp” and access to the Azure portal with the necessary read permissions on the Storage Account.
Proof of concept
In this case, we simply audit the configurations of the Storage Account in the Azure portal.
For our POC, we observe that anonymous access is enabled at the “Container” level and also in the general configuration of the Storage Account. Both of them are inappropriate configurations that allowed the exploitation of the vulnerability seen earlier as we saw in black box.
However, both configurations, at the Storage Account and Container levels, are necessary to exploit them to obtain sensitive information.
Similarly, to complement, we can use the AZ Tool to audit the current configuration. In this case, we need to analyze each container and identify the word “container” as a result.
After running the tool, we observe that the containers “servicios”, “resources”, and “container” allow anonymous access at the “container” level. Whereas for the containers ‘imagenes’, ‘secretos’, and ‘$logs’, they do not!
Cases
After analysis, three possible cases have been identified
- Case 1, for obvious reasons, wouldn’t be vulnerable since anonymous access is NOT enabled.
- Case 2 indicates that anonymous access is enabled, but no container is found during the testing period. However, a potential attacker could continue indefinitely brute-forcing or using more robust dictionary enumeration techniques. Therefore, it has been considered a “Potential” vulnerability with a “Medium” severity.
- Case 3 indicates successful access to container resources, hence its severity is higher, rated as “High” severity.
Real Case Example Found But in Google Cloud Platform
For example while auditing an application movil, we detect an API from Google Platform API
As we saw, the app movil make requests to /api/v1/upath/../../list/5658. So, we can enumerate data with a simple iteration in the ID
Then we can enter to the URL in wthaever browser without authentication because of anonymous access. Each URL from the response contains sensitive information.
The severity of the vulnerability ‘Anonymous Access to Blob Storage
Updated — This a referential score, but if you are free to disagree, it must depends on your scenary)
Mitigation
For Azure, disable anonymous access at the Storage Account level and set its container access configuration to ‘private’
For GCP, delete permissions for “allUsers” and “allAuthenticatedUsers” in the bucket configuration .
