Researchers from Orca Security believe that a design flaw in Microsoft Azure, where shared key authorization is set by default when creating storage accounts, might grant attackers complete access to your environment.
“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 stated.
Microsoft acknowledged that “these permissions could be abused to gain access to additional resources within a customer’s tenant.” However, Microsoft downplayed the severity of the situation later by stating that Microsoft Security Response Center “determined it was not a security issue.”
However, Microsoft admitted that this situation “warranted discussion and improvement to help customers more effectively deploy environments with least privilege and defense-in-depth to be more resilient against attackers.”
Redmond also states that shared key and shared access signature permission will be removed by default for new storage accounts later. However, it is still being determined when that will occur.
Understanding the Problem
This development occurs on April’s Patch Tuesday, and it justifies pausing the Windows update process long enough to turn off shared vital access. Microsoft and Orca both advise switching to Azure Active Directory authentication.
The problem here is that Microsoft enables entire operations on data. Storage/storageAccounts/list-Keys/action permission. Customers may offer this privilege to employees who require merely read-only access to data, but it also permits data manipulation or deletion.
Organizations face a data security risk due to this alone, but Nisimi also notes that overly lenient storage account keys may be misused to migrate laterally within a cloud environment.
There is a link between Azure Storage and Azure Functions, the cloud providers‘ serverless solution, as both Nisimi and Microsoft point out. A specialized storage space that houses the functions’ source code is created when a developer deploys a Function App.
Nisimi said, “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.”
Orchestrating an Attack
A fake employee named Chris Green is given the role of storage account contributor in Orca’s attack scenario. The data on his storage account is susceptible to manipulation if his account is compromised.
However, the attacker can filter out all function-related storage accounts (and their associated file shares containing source code) and figure out the goals of the functions from that list. In that case, compromising a Function App is also conceivable from here.
For instance, because the name of the storage account, “monitorvms98d0,” implies it has to do with monitoring virtual machines (VMs), Orca chooses it. The hacker may observe that the managed identity associated with this Function App can run a command under the Azure Resource Manager Provider after downloading the code file.
“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 getting a managed-identity access token, Orca’s hypothetical attacker performs an API request to identify all the subscription’s virtual machines. After finding one titled “CustomersDB,” the attacker uploads a reverse shell, sets write rights, and now effectively owns the VM.
“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/accesskeys are leaked,” Nisimi elaborated. “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.”
Microsoft commented, “(Orca’s report) 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 the use of role-based access.”
Microsoft plans to turn off shared access signature authorization as a default setting for new storage accounts to improve security protections. Instead, Microsoft advises IT administrators to become familiar with identity-based authorization for Azure Storage accounts.
Need a Resolution? Schedule A Call
Additional Resources: