Feature Abuse: Recovering Deleted Storage Accounts to Extract Secrets
Hello everyone! Recently, I have been working on developing some interesting Azure security challenges. I came across something interesting that I wanted to share with you on how we could restore deleted storage accounts and the criteria that are required to restore the deleted storage account. Microsoft Azure documentation states the storage account might or might not be recovered.
Please note that this is just a feature abuse, We are not discussing any vulnerability here!
Now before going straight to the topic we will have a brief overview of what are storage accounts, the services provided by the storage account, and a short overview of RBAC roles, which will help us understand more clearly.
What is a Storage Account?
Azure Storage Account is a storage service provided by Microsoft Azure. It is a Microsoft-managed service that provides scalable, highly available, and secure cloud storage for data. Azure Storage Accounts provide a unique namespace for storing and accessing your data objects in the Azure cloud. The data objects can be stored in different types of storage such as Blob, File, Table, and Queue storage. You can store and retrieve large amounts of unstructured data, such as documents and media files, and easily scale your storage as your data grows. Azure storage also provides built-in data redundancy options to ensure data durability and availability, and security features to protect your data.
What is Azure RBAC (Role-Based Access Control)?
Azure Role-Based Access Control (RBAC) is a feature in Azure that allows administrators to manage access to Azure resources based on roles. Using RBAC, administrators can assign specific roles to users, groups, or services, giving them the appropriate level of access to Azure resources. This allows for more fine-grained control over access to resources, as opposed to giving all users the same level of access. Some examples of built-in roles in Azure include "Reader", "Contributor", and "Owner" each with increasing levels of permissions. Additionally, RBAC allows for the creation of custom roles with specific permissions according to the needs of the organization. With Azure RBAC, administrators can ensure that only authorized users have access to the resources they need to perform their job functions, and also by meeting compliance and security requirements.
Restoring the Storage Account
Now that we have visited some of the basics concepts let's dive straight into how we can restore deleted Storage Accounts. There are certain criteria that need to be met before going through the process of restoring the storage account.
The criteria are:
The storage account was deleted within the past 14 days. Note that there is no way to erase the deleted storage account and this is the feature that we are going to abuse.
The storage account was created with the Azure Resource Manager deployment model.
A new storage account with the same name has not yet been created since the original account was deleted.
Please note: Recovery of a deleted storage account is not guaranteed and at the time of writing this blog recovering the deleted storage account is only possible through the Azure portal.
Before we attempt to recover a deleted storage account, we need to make sure that the resource group for that account exists. If the resource group was deleted, we must recreate it. Please note recovering a resource group is not possible. If the deleted storage account used customer-managed keys with Azure Key Vault and the key vault has also been deleted, then we must restore the key vault before we restore the storage account.
The user who is attempting to restore the storage account must be assigned an Azure RBAC role that provides "Microsoft.Storage/storageAccounts/write" permission on the resource group level and "Microsoft.Storage/storageAccounts/delete" on the subscription level.
Now let's take a look at the attack scenario where an attacker could make use of storage account recovery to hopefully get access to juicy information. In this scenario, following are the pre-requisites:
- The attacker gets an initial foothold by compromising an Azure AD user account
- The compromised account must have read and write permissions on the storage account and read deleted storage accounts on the subscription level as stated in the previous section.
An attacker has compromised an Azure AD user identity. On enumerating the storage account using the user account the attacker is unable to find anything interesting. But the attacker checks if there is any storage account with commonly used names like dev or development. There is a high probability that there might be sensitive information such as API key, URLs, or user credentials in a development storage account. Since the user has permissions to recover a deleted storage account, even if such a storge account is deleted, the attacker can restore it to recover secrets.
The attacker can follow the following steps to restore a deleted storage account:
The attacker logs into the Azure portal as the compromised Azure AD user and go to Storage Accounts. Within the storage account, the attacker clicks on the restore option provided in the portal to list the deleted storage accounts.
The attacker enumerates that the resource group of the deleted storage account is available.
The attacker selects the storage account from the list and clicks on restore.
The attacker waits for the storage account to be recovered and after a few minutes, a pop-up message stating recovery successful pops up.
Aaand the recovery is successful! Now on enumerating the storage account the attacker found another user credentials within the storage account blob which could be used further to exploit as shown below.
All the contents within the storage account were recovered. The below diagram visualizes the attack scenario
Note: If the storage account resource group has been deleted:
Create a new resource group with the exact same name at the time of deletion.
Now follow the same steps from scenario 1 to restore the storage account.
If in case we are unaware of the resource group name but we know the name of the storage account we can get the name of the resource group from the drop-down list after clicking restore in the storage account from the Azure portal.
Please note the above demo is not a vulnerability found in Azure, But an abuse of the feature provided by Azure to restore the deleted storage account.
The attack scenario was possible due to the compromise of an Azure AD user identity with enough permissions on the storage account/ resource. To avoid such scenarios:
Make use of identity protection mechanisms such as MFA, Conditional Access Policy, and Azure AD Identity Protection.
It is not guaranteed that the deleted storage accounts could be recovered although there is a possibility of recovering the storage account if the above-mentioned criteria are met. To prevent accidental deletion Microsoft recommends locking resources.
Thanks for reading the post.
Nagendrra C (@nagendrra2)
Security Researcher at Altered Security