How Microsoft’s Shared Key authorization can be abused and how to fix it

When many of us moved our server and application needs to the cloud, we rejoiced that we no longer had to worry about the drudgery of patching. We didn’t have to monitor servers and their Patch Tuesday deployments; it was all in Microsoft’s hands. But as often occurs with cloud deployments, a solution that means you no longer have to worry about one area can create security issues in others.  

Time and again in the handling of any cloud deployment, how we manage identity and authentication needs to be reviewed on a scheduled basis to ensure that the security of cloud assets is being handled according to the latest recommended guidance. In the worst-case scenario, the attackers find out first and don’t inform us to take action. In the best case, researchers find a flaw and work with the vendors to help us all make better security decisions — Orca Security recently pointed out just such a flaw.

Orca, which constantly reviews for cloud misconfigurations and vulnerabilities, found that it could abuse Azure Storage account keys and use the vulnerability to gain full access to storage accounts and even move laterally within the cloud. As Orca notes in its blog, it can be all too easy to set up a storage account and business critical assets with this Shared Key authorization while inadvertently handing administrators privileges that they don’t need.

Shared Key is enabled by default

While Microsoft states in its documentation that the use of Shared Key authorization is not ideal and recommends using Azure Active Directory, which provides superior security, Shared Key authorization is still enabled by default when creating storage accounts. Administrators should have only rights over those assets to which they explicitly need access. In this case, the vulnerability can surface if DevOps have the ability to gain Azure listKeys permission.

The user who has permission to access “Microsoft.Storage/storageAccounts/listkeys/action” is not granted access to data. However, the action grants access to the keys, and one can then access the data with the keys — hence the exposure to risk when using Shared Key authorization and not authorization via OAuth/Azure AD.

Too often in cloud deployments, you get your project working and take the potentially easier way to get something set up. You don’t go back and read the guidance that states:

“Authorization with Shared Key is not recommended as it may be less secure. For optimal security, disable authorization via Shared Key for your storage account, as described in Prevent Shared Key authorization for an Azure Storage account.

Use of access keys and connection strings should be limited to initial proof of concept apps or development prototypes that don’t access production or sensitive data. Otherwise, the token-based authentication classes available in the Azure SDK should always be preferred when authenticating to Azure resources.

Microsoft recommends that clients use either Azure AD or a shared access signature (SAS) to authorize access to data in Azure Storage. For more information, see Authorize operations for data access.”

As the documentation further states:

“When you attempt to access blob data, the Azure portal first checks whether you’ve been assigned an Azure role with Microsoft.Storage/storageAccounts/listkeys/action. If you’ve been assigned a role with this action, then the Azure portal uses the account key for accessing blob data via Shared Key authorization. If you haven’t been assigned a role with this action, then the Azure portal attempts to access data using your Azure AD account.”

Attackers have already shown that they will target administrators and DevOps to gain access to key resources. Targeting a remotely working developer who is using his home computer to connect to company assets is a key means of gaining corporate secrets and credentials.

Shared Key access can leave the door open for intruders

Targeting the users who have Listkeys rights, the attacker can then identify these shared keys and move to accessing those resources. Think in terms of an attacker not having the key to the door of your house but knowing where you’ve stashed the secret key under the doormat. The end result is that the attacker can walk right in, access your data and either use it for corporate infiltration or notify you of access and demand a ransom not to destroy the data. As Orca points out, pivoting from merely reading the shared keys to performing a subscription privilege escalation can be trivial for the attacker.

If you are like many Azure customers, you may have set up your organization years ago and are not really sure what the impact will be of moving all of your authentication over to the more secure Azure Active Directory implementation. It could take time and testing that you may not have. Thus, you may have to implement a security review of your Azure assets that not only reviews for this Shared Key authorization risk but other potential configurations that may cause additional problems in the future.

Review Microsoft’s guidance 

Review the guidance for granting access to Azure storage and consider additional solutions that will monitor for misuse of access. Orca specifically has a service to monitor for unusual activity in the Microsoft.Storage/storageAccounts/listKeys/action permission so that you can be alerted should someone start abusing the rights.

Review those users/administrators that have Azure blob rights. Do they still need that right? Have they moved to other roles and duties? Should they have rights over that storage location? What is the bare minimum of rights that every DevOps needs to get their job done, but not place undue risk to the organization? Assign someone to perform regular reviews of best-practice guidance and determine whether your organization is still abiding by it.

Zero trust and least privilege are key concepts increasingly being stressed as a solution not only in traditional on-premise installations but in cloud assets as well. From users to resources, the assignment of roles should be explicitly granted and understood — attackers should not know more about your organization and how to access your data than you do.