What’s going on hacker folks, this is shellbreak back again with another blog post, but this time, it will be about how I found my first bug in an azure cloud storage service.
The vulnerability was a Massive Information Disclosure due to a publicly accessible container hosted on an azure storage blob.
I found this bug in one of my engagements, and when I was pentesting the client’s applications, I had no idea about Azure (my only cloud related background is some AWS knowledge gained from solving “Bucket” machine from HackTheBox). However, with real dedication, there’s nothing we can’t learn
Enough talking and let’s get into the fun stuff.
Since I have found this vulnerability in a real prod environment , I will be obfuscating some output in the screenshots.
When I was viewing the source of the main page, I found a URL like:
I knew it was an Azure blob, but I didn’t have any idea how to enumerate it to see if I can find any sensitive data.
I spent sometime googling and eventually I found this blog post:
The blog mentions a tool that can be used to automate the process of enumertating the blobs to find accessible containers.
So, let’s get started.
The tool takes a username as an argument and looks for containers by brute forcing using a given wordlist.
As I was only interested in Azure at this moment, I used the
--disable-gcp arguments to ignore fuzzing for storage services related to AWS and Google.
python3 cloud_enum.py -k USERNAME --disable-aws --disable-gcp
And I found that there’s a container called
test , and the URL to access its content is
But the tool already does that for us, and you can see that we have 2 juicy files, one of them is the
zip and the other is
These files can be downloaded just by visiting their URLs.
However, I wanted to enumerate even more, so I tried the following:
Not what I expected
But then I remembered that in order to see a container’s content, some parameters need to be provided
?restype=container&comp=list , so using the almighty
ffuf to do so,
ffuf -u https://REDACTED.blob.core.windows.net/FUZZ?restype=container&comp=list -w /path/to/wordlist
I have found another container, but I wasn’t lucky enough to find any sensitive files in it
The blog I linked above has mentioned another powershell-based tool.
The tool uses a built-in wordlist, that’s why it managed to find only one container, while using the
ffuf method described above we have found 2 containers.
Fun thing about this engagement. I spent 2 weeks trying to find critical vulns like RCE and SQLi, but didn’t find any. Eventually instead of finding a SQLi that probably would take a lot of time to exploit (especially if it’s time-based), a single misconfiguration gave me the ability to download the entire database of the client. remember the
A BACPAC file is a ZIP file with an extension of BACPAC containing the metadata and data from the database. A BACPAC file can be stored in Azure Blob storage or in local storage in an on-premises location and later imported back into Azure SQL Database, Azure SQL Managed Instance, or a SQL Server instance
Besides, the logs I’ve found in the
zip file saved me a lot of time, as it contained a ton of logs related to the back-end service in use
So, that was it for now, I hope you guys enjoyed reading it, and I’ll see you all in the next write up.