Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC: SANS Internet Storm Center SANS Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Exposed Azure Storage Containers

Published: 2021-05-07
Last Updated: 2021-05-07 00:02:16 UTC
by Daniel Wesemann (Version: 1)
1 comment(s)

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
storageaccount.blob.core.windows.net/backups
storageaccount.blob.core.windows.net/test
storageaccount.blob.core.windows.net/data
[...]
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

  1. 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.
  2. 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.
  3. 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".

 

 

 

1 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Alternative Ways To Perform Basic Tasks
May 6th 2021
2 days ago by Xme (0 comments)

May 2021 Forensic Contest
May 5th 2021
4 days ago by Brad (0 comments)

Quick and dirty Python: masscan
May 4th 2021
4 days ago by Rick (0 comments)

Important Apple Updates
May 4th 2021
4 days ago by Rick (0 comments)

PuTTY And FileZilla Use The Same Fingerprint Registry Keys
May 2nd 2021
6 days ago by DidierStevens (0 comments)

View All Diaries →

Latest Discussions

API port data
created Apr 25th 2021
1 week ago by JJ (1 reply)

RSS feed containing non-XML compatible characters
created Apr 14th 2021
3 weeks ago by Anonymous (1 reply)

Handler's Diary (Full text) RSS Feeds stopt working due to a typo
created Mar 5th 2021
2 months ago by bas.auer@auerplace.nl (0 replies)

port_scan issue in Snort3
created Feb 23rd 2021
2 months ago by astraea (0 replies)

PFSense
created Dec 23rd 2020
4 months ago by bas.auer@auerplace.nl (6 replies)

View All Forums →

Latest News

Top Diaries

Maldocs: Protection Passwords
Feb 28th 2021
2 months ago by DidierStevens (0 comments)

An infection from Rig exploit kit
Jun 17th 2019
1 year ago by Brad (0 comments)

Qakbot infection with Cobalt Strike
Mar 3rd 2021
2 months ago by Brad (0 comments)

Fun with DNS over TLS (DoT)
Mar 1st 2021
2 months ago by Rob VandenBrink (0 comments)

Adversary Simulation with Sim
Mar 2nd 2021
2 months ago by Russ McRee (0 comments)