An exploitation path involving Azure shared key authorization could allow full access to accounts and business data and ultimately lead to remote code execution (RCE), cloud security company Orca warns.
Along with Azure Active Directory (Azure AD) credentials, shared keys represent one of the authorization methods that Microsoft Azure Storage accounts can take advantage of, and is part of Azure infrastructure by default.
Compared to Azure AD, shared keys provide inferior security, and Microsoft recommends not using storage authorization via access keys when granular access is required, as that would expose organizations to risks.
The attack scenario that Orca has discovered represents further proof of these risks and underlines the need for organizations to disable shared key authorization as a security best practice.
By default, Azure generates two 512-bit storage account access keys for any newly created account. Because these keys are like root passwords for that account, anyone in the possession of these keys can abuse shared key authorization to obtain access to a storage account.
“With this key, obtained either through a leakage or appropriate AD role, 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,” Orca notes.
The company’s investigation revealed that access key authentication can be used to perform more actions than defined by the permissions Azure accounts are given to ensure their access to the data they require.
Specifically, an Azure Storage account with permissions to read data objects may also be able to modify and delete data, Orca says.
Furthermore, the company discovered that a compromised Storage account can be abused to exfiltrate a higher-privileged identity and then abuse it to move laterally and to deploy and execute a reverse shell in virtual machines, using specific API calls.
The main issue here, Orca notes, is the level of access that an attacker could gain by compromising an Azure Storage account or by obtaining their access keys, combined with the fact that, once inside the environment, the attacker can access data and perform malicious actions without being detected.
Despite the potential risks associated with shared keys, however, the feature cannot be removed from Azure “without making significant changes to the system’s design,” Orca was told.
Applying the principle of least-privilege mitigates the risks associated with this exploitation scenario, as does completely disabling shared key authorization in Azure.
Microsoft has published a blog post detailing best practices, as well as the steps that the company is taking to move away from shared key authorization.
Related: Severe Azure Vulnerability Led to Unauthenticated Remote Code Execution
Related: CSRF Vulnerability in Kudu SCM Allowed Code Execution in Azure Services
Related: Azure Services SSRF Vulnerabilities Exposed Internal Endpoints, Sensitive Data
