Critical flaw in Azure Storage Account Keys design could allow easy hack

A “design issue” that was discovered in Microsoft Azure might be used by attackers to get access to storage accounts, move laterally inside the system, and even execute remote code. These goals could be accomplished by exploiting the bug.

“It is feasible to abuse and utilize Microsoft Storage Accounts by manipulating Azure Functions to steal access-tokens of higher privilege identities, move laterally, possibly access important company assets, and execute remote code (RCE),” Orca stated in a recent study that was shared . “This can be accomplished by abusing and using Azure Functions.”

The exploitation route that forms the basis of this attack is a system known as Shared Key authorization. Storage accounts have this mechanism activated by default, so it can be exploited easily.

Microsoft claims that when a storage account is created in Azure, two access keys with a total length of 512 bits are generated automatically. These keys may be put to use to authorize access to data either via the Shared Key authorization protocol or through the use of SAS tokens that have been signed with the shared key.

According to the cloud security company, it is possible to steal these access tokens by manipulating Azure Functions. This might make it possible for a threat actor who has access to an account with the Storage Account Contributor role to escalate privileges and take control of systems.

If a managed identity were to be used to activate the Function app, for example, it might be misused to carry out any command. When you deploy an Azure Function app, a dedicated storage account is automatically generated for the app. This, in turn, makes it feasible to do what we just discussed.

After an adversary has discovered the storage account of a Function app that has been provided with a robust managed identity, they are able to execute code on the app’s behalf and, as a consequence, get an increase in their subscription privileges (PE).

In other words, a threat actor is able to raise their privileges, move laterally, access additional resources, and even run a reverse shell on virtual machines if they exfiltrate the access-token of the managed identity that is allocated to the Azure Function app and send it to a remote server.

To travel laterally, exploit, and compromise the most priceless crown jewels of victims, an attacker may steal and exfiltrate a higher-privileged identity by altering function files in storage accounts, according to Nisimi.

It is advised that companies think about removing Azure Shared Key authorization and instead adopting Azure Active Directory authentication as a mitigating strategy. Microsoft said in a coordinated disclosure that it “plans to enhance how Functions client tools function with storage accounts.” This statement was made in reference to the company’s upcoming changes.

“Among them are modifications to provide improved support for use cases using identities. After the new experiences have been validated and identity-based connections for AzureWebJobsStorage have become generally available, identity will become the default mode for AzureWebJobsStorage. This is intended to move away from shared key authorization, which has been the current mode “the technology behemoth elaborated further.