Azure Storage Account Key Vulnerability
Researchers from Orca found that Azure Storage shared key authorization is enabled by default, and “an attacker can not only gain full access to storage accounts and potentially critical business assets, but also move laterally in the environment and even execute remote code.” Organizations are urged to disable Azure Shared Key authorization and use Azure Active Directory authentication instead.
This is one of those “ease of startup trumped security” design choices that were made in many products (think hard-coded passwords) and delighted bad guys. Good to see that Microsoft intends to “…move away from shared key authorization” even if it does sound odd to see it called “…part of ongoing experience improvements” Yes, in general it is an “improved experience” over when bad actors can take over storage accounts…
So much for that easy button. If you're using it, turn off Azure Shared Key authorization, use AAD authentication. While it looked like you were just enabling read-only access, you were actually enabling modification/deletion capabilities as well. Expect Microsoft to publish updated guidance on using Azure Shared Storage shared key authorization, as well as configuration changes to make it disabled out-of-the-box.
While I’m glad that this is being highlighted, let’s be clear on this one. It is standard stock behavior from Azure Storage. Yes, it’s a vector in very specific situations but this isn’t unauthenticated RCE. Much like the Omigod issue a few years ago, it’s awareness but not mass scale issues. The bigger issue with this service is we still find open Azure buckets in the wild with sensitive data.
Here’s an example of the tug between enabling functions by default and secure configuration. Vendors typically provide products fully enabled; adversaries take advantage of the default configuration. The CIS Community Defense Model demonstrates that establishing and maintaining a secure configuration (Control 4) protects against the five major attack types, which reinforces the importance of secure configuration. See the CIS Azure Foundations Benchmark for secure configuration recommendations to protect the customer tenant.
The resistance of developers to safe defaults, particularly to "safe out of the box," remains high. While safe defaults may make setup marginally more difficult, changing defaults late breaks things.
William Hugh Murray
Read more in
Orca: From listKeys to Glory: How We Achieved a Subscription Privilege Escalation and RCE by Abusing Azure Storage Account Keys
CSO Online: How Microsoft’s Shared Key authorization can be abused and how to fix it
The Register: Azure admins warned to disable shared key access as backdoor attack detailed
MSRC: Best practices regarding Azure Storage Keys, Azure Functions, and Azure Role Based Access