Shared Key authorisation is enabled by default for organisations using Azure but this poses a serious security risk, warns Orca. The security company found that it could give attackers full access including allowing them to steal access tokens, move laterally within a network and access business assets.
Researchers say organisations should disable Azure Shared Key authorisation, which is on by default, and instead use the Azure Active Directory authentication which is more secure. “Implementing the principle of least-privilege, this risk can be greatly reduced,” they explained.
Microsoft describes the issue as a “by-design flaw” that it will address in future updates to “provide improved safeguards for customers”. This will include changes to storage account defaults. “Orca’s report has highlighted opportunities for us to continue to improve to help customers correctly configure their environments with least-privilege. The risk of these scenarios can be minimised by applying proper administration and ensuring that users are delegated the lowest level of permissions necessary.”
By-design flaws are technically not a vulnerability as an attacker can abuse the account “in the way Microsoft designed them” rather than through a security weakness in the product. “However, this does not mean that it is less dangerous,” Orca Researchers warned. The big difference is that a by-design flaw may not be possible or practical to fix, particularly if a lot of systems already use it, which then in turn increases the risk if a vulnerability path is discovered that uses this flaw.
“Unfortunately this is an attacker’s bread-and-butter and can be abused repeatedly, exposing organisations with weak security postures to an infinite threat. Similar to the abuse of public AWS S3 buckets seen in recent years, attackers can also look for and utilise Azure access keys as a backdoor into an organisation,” Orca researchers warned.
A surprising discovery
Orca Security describes the “critical exploitation path” as surprising, explaining that once the key in the Azure Shared Key authorisation method, which is on by default, is obtained by an attacker, they then gain full access to storage accounts. The bigger risk though, is that it could also allow them to run remote code against the storage account files.
Gaining the “key” effectively gives the attacker “full-access permission to storage accounts”. They can then manipulate the code to steal an access token of the Azure Function App’s assigned managed-identity and then further escalate their privileges, allowing them to move laterally within the system and access new resources such as code execution.
Orca gave the example of a user account having the “Storage Account Contributor” role. If that account is compromised the attacker would have access to the entire storage account data. They’d also be able to list all storage account names in a subscription and read and write all data objects in one of them.
Fuction Apps host source code inside dedicated storage accounts. Creating a function inside a Function app creates a host.json config file, a “unique and recurring signature” which can be used to filter out function-related storage accounts and give the attacker access to run remote code.
Active Directory authentication
Of the two forms of security for Azure storage accounts, Orca recommends switching to Azure Active Directory as it “provides superior security and ease of use”. Microsoft also recommends this approach as “when you create a storage account, Azure generates two 512-bit storage account access keys for that account”, similar to a root password and so disallowing Shared Key access is a “security best practice”.
The reason for disabling access to those keys is that anyone able to access them can gain full access to the entire storage account. But enough systems already utilise the keys that disabling access by default could break too many implementations.
The problem, according to Orca, comes down to how permissions are handled under the Shared Key Authorisation system. “Microsoft.Storage/storageAccounts/listKeys/action is a required permission for an entity seeking to read data objects. As the name suggests, listKeys allows listing access keys of storage accounts. So if a storage account is configured by default with Shared Key authorisation, and we can’t list its access keys, it’s impossible to access data.”
“To address this issue, we suggest starting with identifying all entities with top-level (subscription/resource-group) assigned roles which contain the listKeys permission, and alter them according to the principle of least-privilege. listKeys can be included in an assigned role, through a specific Resource IAM panel, and as a result allow full access only to this particular resource,” Orca wrote.
It comes down to a lack of granular permissions, something set to be addressed in the April public preview update that will introduce support for Oauth over REST, updating the portal to provide more specific rights as required for any use case.
Read more: UK cloud market competition probe could target AWS and Azure
..
