Az - Storage Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Storage Privesc

Aby uzyskać więcej informacji na temat przechowywania, sprawdź:

Az - Storage Accounts & Blobs

Microsoft.Storage/storageAccounts/listkeys/action

Podmiot z tym uprawnieniem będzie mógł wylistować (i wartości sekretne) klucze dostępu kont przechowywania. Pozwoli to podmiotowi na eskalację jego uprawnień w odniesieniu do kont przechowywania.

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

Microsoft.Storage/storageAccounts/regenerateKey/action

Principal z tym uprawnieniem będzie mógł odnowić i uzyskać nową wartość sekretu kluczy dostępu konta magazynowego. Pozwoli to principalowi na eskalację jego uprawnień w odniesieniu do kont magazynowych.

Ponadto w odpowiedzi użytkownik otrzyma wartość odnowionego klucza oraz wartość klucza, który nie został odnowiony:

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

Microsoft.Storage/storageAccounts/write

Osoba z tym uprawnieniem będzie mogła tworzyć lub aktualizować istniejące konto magazynu, zmieniając dowolne ustawienie, takie jak zasady sieciowe lub polityki.

# 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

Pierwsze uprawnienie pozwala na modyfikację polityk niezmienności w kontenerach, a drugie na ich usunięcie.

Note

Zauważ, że jeśli polityka niezmienności jest w stanie blokady, nie możesz wykonać żadnej z tych operacji.

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

To powinno umożliwić użytkownikowi posiadającemu tę uprawnienie przejęcie własności plików w udostępnionym systemie plików.

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

To powinno umożliwić użytkownikowi posiadającemu tę uprawnienie modyfikację uprawnień plików w udostępnionym systemie plików.

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

To powinno umożliwić użytkownikowi posiadającemu tę uprawnienie wykonywanie działań w systemie plików jako superużytkownik.

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

Dzięki temu uprawnieniu, atakujący może utworzyć i zaktualizować (jeśli ma uprawnienie Microsoft.Storage/storageAccounts/localusers/read) nowego lokalnego użytkownika dla konta Azure Storage (skonfigurowanego z hierarchiczną przestrzenią nazw), w tym określenie uprawnień użytkownika i katalogu domowego. To uprawnienie jest istotne, ponieważ pozwala atakującemu przyznać sobie dostęp do konta magazynu z określonymi uprawnieniami, takimi jak odczyt (r), zapis (w), usunięcie (d) i lista (l) oraz inne. Dodatkowo metody uwierzytelniania, które to wykorzystuje, mogą obejmować hasła generowane przez Azure oraz pary kluczy SSH. Nie ma sprawdzenia, czy użytkownik już istnieje, więc można nadpisać innych użytkowników, którzy już tam są. Atakujący mógłby podnieść swoje uprawnienia i uzyskać dostęp SSH do konta magazynu, potencjalnie ujawniając lub kompromitując wrażliwe dane.

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

Dzięki temu uprawnieniu, atakujący może zregenerować hasło dla lokalnego użytkownika w koncie Azure Storage. Daje to atakującemu możliwość uzyskania nowych poświadczeń uwierzytelniających (takich jak hasło SSH lub SFTP) dla użytkownika. Wykorzystując te poświadczenia, atakujący mógłby uzyskać nieautoryzowany dostęp do konta storage, przeprowadzać transfery plików lub manipulować danymi w kontenerach storage. Może to prowadzić do wycieku danych, uszkodzenia lub złośliwej modyfikacji zawartości konta storage.

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

Aby uzyskać dostęp do Azure Blob Storage za pomocą SFTP (is_hns_enabled powinno być ustawione na true) przy użyciu lokalnego użytkownika przez SFTP, możesz (możesz również użyć klucza ssh do połączenia):

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

Dzięki tym uprawnieniom atakujący może przywrócić usunięty kontener, podając jego ID usuniętej wersji lub przywrócić konkretne bloby w kontenerze, jeśli były wcześniej usunięte w sposób miękki. Ta eskalacja uprawnień może pozwolić atakującemu na odzyskanie wrażliwych danych, które miały być trwale usunięte, co potencjalnie prowadzi do nieautoryzowanego dostępu.

#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

Dzięki tym uprawnieniom, atakujący może przywrócić usuniętą usługę plików Azure, podając jej ID usuniętej wersji. Ta eskalacja uprawnień może pozwolić atakującemu na odzyskanie wrażliwych danych, które miały być trwale usunięte, co potencjalnie prowadzi do nieautoryzowanego dostępu.

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

Inne interesujące uprawnienia (TODO)

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action: Zmienia właściciela bloba
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action: Modyfikuje uprawnienia bloba
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action: Zwraca wynik polecenia bloba
  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/immutableStorage/runAsSuperUser/action

Odniesienia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks