[SANS ISC] Exposed Azure Storage Containers, (Fri, May 7th)

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

etc, you get the drift.

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

Stop any public access by making your Storage Account “private”. This should be the default, and is the only safe option. Refer to the two mentioned earlier diaries on how to do so, and how to implement prevention that works. If a Storage Account is set to “Private”, the response will always be “Resource Not Found”, irrespective of whether the attempt hits an existing container name or not.
If you “have” to keep something shared at Blob level, maybe consider increasing the obscurity and smoke screen. Don’t call your container “backup” or “data” or the like, call it “akreiqfasvkkakdff” or some such. While this doesn’t really secure your data and only kicks the can down the obscurity road, it still makes it less likely that a brute force enumeration attempt will quickly find your container.
Keep your eye on the new Azure Security Center alert titled “PREVIEW – Anonymous scan of public storage containers” (Azure Alerts Reference) that politely warns you whenever someone tries to enumerate containers in your storage account.

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”.




(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: Read More (SANS Internet Storm Center, InfoCON: green)

You might be interested in …

[ZDNet] eSafety prepares for Online Safety Act with AU$3m software pilot and 20 new staff

All posts, ZDNet

The eSafety Commissioner has only been able to action 72 of the 3,600 adult cyber abuse complaints it has received, and it’s hopeful the new Online Safety Act will allow it to do more. Source: Read More (Latest topics for ZDNet in Security)

Read More

[ThreatPost] Holy Grail of Security: Answers to ‘Did XYZ Work?’ – Podcast

All posts, ThreatPost

Verizon DBIR is already funny, useful & well-written, and it just got better with mapping to MITRE ATT&CK TTPs. The marriage could finally bring answers to “What are we doing right?” instead of the constant reminders of what’s not working in fending off threats. Source: Read More (Threatpost)

Read More

[ThreatPost] FIN7 Backdoor Masquerades as Ethical Hacking Tool

All posts, ThreatPost

The financially motivated cybercrime gang behind the Carbanak RAT is back with the Lizar malware, which can harvest all kinds of info from Windows machines. Source: Read More (Threatpost)

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.