A couple months ago, we already covered the topic of exposed Azure Blob Storage in two separate ISC diaries, "Exposed Blob Storage in Azure" and "Preventing Exposed Blob Storage in Azure". The information therein is still relevant and valid, so if you are using Azure Storage, and haven't read these two diaries yet, please do. There is no doubt that having an Azure Storage Container that is shared publicly at level "Container" is usually a bad idea, because everyone who knows the Container name can then trivially enumerate the contents, by simply tucking a /?comp=list&restype=container onto the URL. But the container names themselves cannot be enumerated quite as easily, so some users of Azure Storage seem to feel safe-ish behind this layer of obscurity. But recently, we noticed a significant uptick in attempts to blindly enumerate existing storage containers. You can think of it as a dictionary attack of sorts, because the log files show the bad guys sequentially probing storageaccount.blob.core.windows.net/backup The question is, how does this work? How do the attackers even distinguish between a Container that doesn't exist at all, and one that does exist, but has access restrictions set to "Blob"? Well, here is how: See it? "Blob not found" versus "Resource not found". This tells us that the container "/files/" exists, whereas "/othercontainer/" doesn't. We could call this an example of CWE-209 https://cwe.mitre.org/data/definitions/209.html aka "Error Message Containing Sensitive Information". It is similar to a lesson learned two decades ago when error messages were distinguishing between "login incorrect" and "password incorrect" and indirectly facilitated brute-force breakin attempts by allowing an attacker to more readily identify valid accounts. As a "countermeasure", you can
Here's an example of how this new "PREVIEW" alert looks like. Note the terms that were included in this particular enumeration attempt. If your Container shared at level "Blob" happens to be called one of these names, assume that it already has been "found".
|
Daniel 385 Posts ISC Handler May 7th 2021 |
Thread locked Subscribe |
May 7th 2021 1 year ago |
Great article. I wrote a little about this myself hxxp://blog.infosecmatters.net/2020/08/find-and-list-unsecured-azure-storage.html
|
Anonymous |
Quote |
May 8th 2021 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!