Azure admins warned to disable shared key access as backdoor attack detailed
The default is that sharing is caring as Redmond admits: 'These permissions could be abused'
A design flaw in Microsoft Azure – that shared key authorization is enabled by default when creating storage accounts – could give attackers full access to your environment, according to Orca Security researchers.
"Similar to the abuse of public AWS S3 buckets seen in recent years, attackers can also look for and utilize Azure access keys as a backdoor into an organization," Orca's Roi Nisimi warned today.
In response, Redmond admitted "these permissions could be abused to gain access to additional resources within a customer's tenant."
However, after further investigation, the Microsoft Security Response Center "determined it was not a security issue." That said, the Windows giant acknowledged the issue "warranted discussion and improvement to help customers more effectively deploy environments with least privilege and defense-in-depth to be more resilient against attackers."
Additionally, at some later date, Redmond says new storage accounts will have shared key and shared access signature authorization disabled by default, but there's no word on when that will happen.
This development coincides with April's Patch Tuesday, and it definitely merits taking a quick break from updating Windows to disable shared key access. Both Orca and Microsoft suggest using Azure Active Directory authentication instead.
The issue here is that the Microsoft.Storage/storageAccounts/listKeys/action permission enables full operations on data. While customers may grant this permission to users within their organization who need read-only access to data, it also allows the data to be manipulated or even deleted.
This, on its own, presents a data security risk to organizations, but Nisimi explains that overly permissive storage account keys can also be abused to move laterally inside the cloud environment.
As both Nisimi and Microsoft note, there's a connection between Azure Storage and Azure Functions, which is the cloud provider's serverless service. When a developer deploys a Function App, this action creates a dedicated storage account that hosts all functions' source code. As Nisimi explains:
The storage account of a Function App can be found inside the AzureWebJobStorage environment variable under Application Settings, which includes a connection string to the storage account, together with one of the storage account keys.
In Orca's attack scenario, a fictional employee, Chris Green, is assigned a storage account contributor role. If his account is compromised, attackers can manipulate storage account data.
From here, however, it's also possible to compromise a Function App provided the attacker can filter out all function-related storage accounts (and their related file shares with source code) and from that list determine the functions' objectives.
For this example, Orca selects a storage account named "monitorvms98d0," because the name suggests it has to do with monitoring virtual machines (VMs). After downloading the code file, the attacker can see that the managed identity assigned to this Function App can execute a command under the Azure Resource Manager Provider.
- Apple squashes iOS, macOS zero-day bugs already exploited by snoops
- Microsoft, Fortra are this fed up with cyber-gangs abusing Cobalt Strike
- Tear in Microsoft Azure Service Fabric can give attackers full admin privileges
- Azure issues not adequately fixed for months, complain bug hunters
"At this point stealing credentials and Escalating Privileges, as scary as it may sound, is fairly easy," Nisimi said. "Once an attacker locates the Storage Account of a Function App that is assigned with a strong managed identity, it can run code on its behalf and as a result acquire a subscription privilege escalation (PE)."
After obtaining a managed-identity access token, Orca's fictional attacker uses an API call to list all the VMs in the subscription, finds a promising VM labeled "CustomersDB," uploads a reverse shell to the VM and then sets write permissions to the VM, which the attacker now effectively owns.
"This attack-flow scenario is possible if an AD User with listKeys permissions is being compromised (as in our example), but also if storage accounts' connection-strings/access-keys are leaked," Nisimi wrote. "By overriding function files in storage accounts, an attacker can steal and exfiltrate a higher-privileged identity and use it to move laterally, exploit and compromise victims' most valuable crown jewels."
For its part, Microsoft says Orca's research "highlighted opportunities for us to continue to improve to help customers correctly configure their environments with least privilege."
"We're also planning for guidance and support so that new storage accounts can have shared key and shared access signature (SAS) authorization disabled by default to encourage use of role-based access," Redmond wrote. But in the meantime, it suggests customers check out its update on how to enforce the use of identity-based authorization for Storage using Azure Policy. ®