Skip to content

Latest commit

 

History

History
192 lines (135 loc) · 10 KB

az-storage-privesc.md

File metadata and controls

192 lines (135 loc) · 10 KB
Raw

Az - Storage Privesc

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Storage Privesc

For more information about storage check:

{% content-ref url="../az-services/az-storage.md" %} az-storage.md {% endcontent-ref %}

Microsoft.Storage/storageAccounts/listkeys/action

A principal with this permission will be able to list (and the secret values) of the access keys of the storage accounts. Allowing the principal to escalate its privileges over the storage accounts.

az storage account keys list --account-name <acc-name>

Microsoft.Storage/storageAccounts/regenerateKey/action

A principal with this permission will be able to renew and get the new secret value of the access keys of the storage accounts. Allowing the principal to escalate its privileges over the storage accounts.

Moreover, in the response, the user will get the value of the renewed key and also of the not renewed one:

az storage account keys renew --account-name <acc-name> --key key2

Microsoft.Storage/storageAccounts/write

A principal with this permission will be able to create or update an existing storage account updating any setting like network rules or policies.

{% code overflow="wrap" %}

# e.g. set default action to allow so network restrictions are avoided
az storage account update --name <acc-name> --default-action Allow

# e.g. allow an IP address
az storage account update --name <acc-name> --add networkRuleSet.ipRules value=<ip-address>

{% endcode %}

Blobs Specific privesc

Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/write | Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies/delete

The first permission allows to modify immutability policies in containers and the second to delete them.

{% hint style="info" %} Note that if an immutability policy is in lock state, you cannot do neither of both {% endhint %}

az storage container immutability-policy delete \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --resource-group <RESOURCE_GROUP>

az storage container immutability-policy update \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --period <NEW_RETENTION_PERIOD_IN_DAYS>

File shares specific privesc

Microsoft.Storage/storageAccounts/fileServices/takeOwnership/action

This should allow a user having this permission to be able to take the ownership of files inside the shared filesystem.

Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action

This should allow a user having this permission to be able to modify the permissions files inside the shared filesystem.

Microsoft.Storage/storageAccounts/fileServices/fileshares/files/actassuperuser/action

This should allow a user having this permission to be able to perform actions inside a file system as a superuser.

Microsoft.Storage/storageAccounts/localusers/write (Microsoft.Storage/storageAccounts/localusers/read)

With this permission, an attacker can create and update (if has Microsoft.Storage/storageAccounts/localusers/read permission) a new local user for an Azure Storage account (configured with hierarchical namespace), including specifying the user’s permissions and home directory. This permission is significant because it allows the attacker to grant themselves to a storage account with specific permissions such as read (r), write (w), delete (d), and list (l) and more. Additionaly the authentication methods that this uses can be Azure-generated passwords and SSH key pairs. There is no check if a user already exists, so you can overwrite other users that are already there. The attacker could escalate their privileges and gain SSH access to the storage account, potentially exposing or compromising sensitive data.

{% code overflow="wrap" %}

az storage account local-user create \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <LOCAL_USER_NAME> \
  --permission-scope permissions=rwdl service=blob resource-name=<CONTAINER_NAME> \
  --home-directory <HOME_DIRECTORY> \
  --has-ssh-key false/true # Depends on the auth method to use

{% endcode %}

Microsoft.Storage/storageAccounts/localusers/regeneratePassword/action

With this permission, an attacker can regenerate the password for a local user in an Azure Storage account. This grants the attacker the ability to obtain new authentication credentials (such as an SSH or SFTP password) for the user. By leveraging these credentials, the attacker could gain unauthorized access to the storage account, perform file transfers, or manipulate data within the storage containers. This could result in data leakage, corruption, or malicious modification of the storage account content.

{% code overflow="wrap" %}

az storage account local-user regenerate-password \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <LOCAL_USER_NAME>

{% endcode %}

To access Azure Blob Storage via SFTP using a local user via SFTP you can (you can also use ssh key to connect):

{% code overflow="wrap" %}

sftp <local-user-name>@<storage-account-name>.blob.core.windows.net
#regenerated-password

{% endcode %}

Microsoft.Storage/storageAccounts/restoreBlobRanges/action, Microsoft.Storage/storageAccounts/blobServices/containers/read, Microsoft.Storage/storageAccounts/read && Microsoft.Storage/storageAccounts/listKeys/action

With this permissions an attacker can restore a deleted container by specifying its deleted version ID or undelete specific blobs within a container, if they were previously soft-deleted. This privilege escalation could allow an attacker to recover sensitive data that was meant to be permanently deleted, potentially leading to unauthorized access.

{% code overflow="wrap" %}

#Restore the soft deleted container
az storage container restore \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --name <CONTAINER_NAME> \
  --deleted-version <VERSION>

#Restore the soft deleted blob
az storage blob undelete \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --name "fileName.txt"

{% endcode %}

Microsoft.Storage/storageAccounts/fileServices/shares/restore/action && Microsoft.Storage/storageAccounts/read

With these permissions, an attacker can restore a deleted Azure file share by specifying its deleted version ID. This privilege escalation could allow an attacker to recover sensitive data that was meant to be permanently deleted, potentially leading to unauthorized access.

{% code overflow="wrap" %}

az storage share-rm restore \
  --storage-account <STORAGE_ACCOUNT_NAME> \
  --name <FILE_SHARE_NAME> \
  --deleted-version <VERSION>

{% endcode %}

Other interesting looking permissions (TODO)

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action: Changes ownership of the blob
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action: Modifies permissions of the blob
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action: Returns the result of the blob command
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/immutableStorage/runAsSuperUser/action

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}