Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

This commit is contained in:
Translator
2025-02-08 13:48:14 +00:00
parent 8437acc8c1
commit 2bc6eb347a

View File

@@ -38,7 +38,7 @@ az storage account update --name <acc-name> --add networkRuleSet.ipRules value=<
### 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 excluí-las.
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.
@@ -70,7 +70,7 @@ Isso deve permitir que um usuário com essa permissão possa realizar ações de
### 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 seus privilégios e obter acesso SSH à conta de armazenamento, potencialmente expondo ou comprometendo dados sensíveis.
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> \
@@ -89,14 +89,14 @@ az storage account local-user regenerate-password \
--resource-group <RESOURCE_GROUP_NAME> \
--name <LOCAL_USER_NAME>
```
Para acessar o Azure Blob Storage via SFTP usando um usuário local via SFTP, você pode (você também pode usar uma chave ssh para se conectar):
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 <local-user-name>@<storage-account-name>.blob.core.windows.net
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 restaurar blobs específicos dentro de um contêiner, se eles foram previamente excluídos de forma suave. Essa escalada de privilégio pode permitir que um atacante recupere dados sensíveis que deveriam ter sido excluídos permanentemente, potencialmente levando a acesso não autorizado.
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 pode permitir que um atacante recupere dados sensíveis que deveriam ter sido excluídos permanentemente, potencialmente levando a acesso não autorizado.
```bash
#Restore the soft deleted container
az storage container restore \
@@ -112,7 +112,7 @@ az storage blob undelete \
```
### 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 escalada 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.
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> \