isc.sans.eduSANS Internet Storm Center

Threat Level: green Handler on Duty: Guy Bruneau SANS ISC: SANS Site Network Current Site Other SANS Sites Help Graduate Degree Programs Security Training Security Certification Security Awareness Training Penetration Testing Industrial Control Systems Cyber Defense Foundations DFIR Software Security Government OnSite Training Sign Up for Free! Forgot Password? Log In or Sign Up for Free ! Last Daily Podcast (Fri, May 7th): Azure Blob Scans; Qualcomm MSM Vuln.; Google 2SF Default; Celebrite UFED Patch 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 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". Keywords: Azure brute force brute forcing cloud Storage 1 comment(s) Join us at SANS! Attend with Daniel Wesemann in starting If you have more information or corrections regarding our diary, please share . Top of page Recent Diaries Alternative Ways To Perform Basic Tasks May 6th 2021 3 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 → Top of page Latest Discussions API port data created Apr 25th 2021 2 weeks 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 → Top of page 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) Contact Us Contact Us About Us Handlers Diary Podcasts Jobs Tools DShield Sensor DNS Looking Glass Honeypot (RPi/AWS) InfoSec Glossary Fightback Data HTTP Header Activity TCP/UDP Port Activity Port Trends Presentations & Papers SSH Scanning Activity SSL CRL Activity Suspicious Domains Threat Feeds Activity Threat Feeds Map Useful InfoSec Links Weblogs Research Papers Forums Auditing Diary Discussions Forensics General Discussions Industry News Network Security Penetration Testing Software Security Questions? Feedback? Use our contact form or report bugs here For interactive help and to chat with other users, try our Slack group. The Internet Storm Center is a community for everyone, so join the conversation YouTube Twitter LinkedIn ISC Feed Shop Link To Us About Us Handlers Privacy Policy Back To Top Developers: We have an API for you!...