GCP - 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
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
Storage
Podstawowe informacje:
storage.objects.get
To uprawnienie pozwala na pobieranie plików przechowywanych w Cloud Storage. Może to potencjalnie umożliwić eskalację uprawnień, ponieważ w niektórych przypadkach przechowywane są tam informacje wrażliwe. Co więcej, niektóre usługi GCP przechowują swoje dane w bucketach:
- GCP Composer: Kiedy tworzysz Composer Environment, kod wszystkich DAGów zostanie zapisany w buckecie. Te zadania mogą zawierać interesujące informacje w swoim kodzie.
- GCR (Container Registry): Obrazy kontenerów są przechowywane w bucketach, co oznacza, że jeśli potrafisz odczytać buckety, będziesz w stanie pobrać obrazy i wyszukać leaks i/lub kod źródłowy.
storage.objects.setIamPolicy
Może to dać ci uprawnienie do wykorzystania dowolnego z powyższych scenariuszy opisanych w tej sekcji.
# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>
# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>
# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY
storage.buckets.setIamPolicy
Przykład, jak zmodyfikować uprawnienia przy użyciu tego uprawnienia, znajdziesz na tej stronie:
# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>
# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>
# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY
GCP - Public Buckets Privilege Escalation
storage.hmacKeys.create
Funkcja “interoperability” Cloud Storage, zaprojektowana dla cross-cloud interactions (np. z AWS S3), obejmuje creation of HMAC keys for Service Accounts and users. Atakujący może to wykorzystać, generating an HMAC key for a Service Account with elevated privileges, co pozwala na escalating privileges within Cloud Storage. Podczas gdy HMAC keys powiązane z użytkownikami są możliwe do pobrania tylko przez web console, zarówno access and secret keys pozostają perpetually accessible, co umożliwia ich przechowywanie jako kopii zapasowej dostępu. Natomiast HMAC keys powiązane z Service Account są dostępne przez API, ale ich access and secret keys nie są możliwe do odzyskania po utworzeniu, co utrudnia utrzymanie ciągłego dostępu.
# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance
## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"storage-sa@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')
# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a
# Use it
gsutil ls gs://[BUCKET_NAME]
# Restore
gcloud config set pass_credentials_to_gsutil true
Inny exploit script dla tej metody można znaleźć tutaj.
storage.objects.create, storage.objects.delete = Uprawnienia zapisu w Storage
Aby utworzyć nowy obiekt w bucketcie potrzebujesz storage.objects.create, a według dokumentacji potrzebujesz także storage.objects.delete, aby modyfikować istniejący obiekt.
Bardzo częstym wektorem eksploatacji bucketów, do których masz zapis, jest sytuacja gdy bucket przechowuje pliki serwera WWW — możesz wtedy być w stanie umieścić nowy kod, który zostanie użyty przez aplikację webową.
Composer
Composer to zarządzany w GCP Apache Airflow. Ma kilka istotnych cech:
- Uruchamia się w klastrze GKE, więc SA używane przez klaster jest dostępne dla kodu uruchamianego wewnątrz Composer.
- Wszystkie komponenty środowiska Composer (kod DAGów, pluginy i dane) są przechowywane w bucketcie GCP. Jeśli atakujący ma uprawnienia do odczytu i zapisu, może monitorować bucket i za każdym razem, gdy DAG zostanie utworzony lub zaktualizowany, przesłać jego backdoorowaną wersję, aby środowisko Composer pobrało wersję z backdoorem.
PoC tego ataku znajduje się w repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Cloud Functions
- Kod Cloud Functions jest przechowywany w Storage i za każdym razem, gdy tworzona jest nowa wersja, kod jest wypychany do bucketa, a następnie na jego podstawie budowany jest nowy kontener. W związku z tym nadpisanie kodu zanim nowa wersja zostanie zbudowana pozwala na wykonanie dowolnego kodu w Cloud Function.
PoC tego ataku znajduje się w repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
App Engine
Wersje AppEngine generują dane w buckecie o nazwie w formacie: staging.<project-id>.appspot.com. W tym buckecie można znaleźć folder o nazwie ae, który zawiera podfolder dla każdej wersji aplikacji AppEngine, a wewnątrz tych folderów znajduje się plik manifest.json. Ten plik zawiera JSON z listą wszystkich plików, które mają być użyte do utworzenia danej wersji. Ponadto można znaleźć rzeczywiste nazwy plików, URL do nich w bucketcie GCP (pliki w buckecie mają nazwy będące ich sha1) oraz sha1 każdego pliku.
Uwaga: nie jest możliwe wstępne przejęcie tego bucketa, ponieważ użytkownicy GCP nie mają uprawnień do tworzenia bucketów używających domeny appspot.com.
Jednak przy dostępie do odczytu i zapisu w tym buckecie możliwe jest eskalowanie uprawnień do SA przypisanego do wersji App Engine poprzez monitorowanie bucketa i każdorazowe, jak najszybsze zmodyfikowanie nowej wersji (gdy zostanie opublikowana). W ten sposób kontener tworzony z tego kodu wykona zainstalowany backdoor.
Wspomniany atak można przeprowadzić na wiele sposobów — wszystkie zaczynają się od monitorowania bucketa staging.<project-id>.appspot.com:
- Prześlij kompletny nowy kod wersji AppEngine do innego, dostępnego bucketa i przygotuj plik
manifest.jsonz nazwą nowego bucketa i sha1 plików. Gdy nowa wersja pojawi się w oryginalnym buckecie, wystarczy zmodyfikowaćmanifest.jsoni przesłać złośliwą wersję. - Prześlij zmodyfikowany plik
requirements.txt, który będzie używał złośliwych zależności, i zaktualizujmanifest.jsono nową nazwę pliku, URL i jego hash. - Prześlij zmodyfikowany
main.pylubapp.yaml, który wykona złośliwy kod, i zaktualizujmanifest.jsono nową nazwę pliku, URL i jego hash.
PoC tego ataku znajduje się w repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine
GCR
- Google Container Registry przechowuje obrazy w bucketach; jeśli możesz zapisywać w tych bucketach, możesz potencjalnie przemieszczać się lateralnie do środowisk, w których te buckety są uruchamiane.
- Bucket używany przez GCR będzie miał URL podobny do
gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com(górne subdomeny są wyspecyfikowane tutaj).
Tip
Ta usługa jest przestarzała, więc ten atak jest już niewiele wart. Ponadto Artifact Registry, usługa ją zastępująca, nie przechowuje obrazów w bucketach.
Referencje
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
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
HackTricks Cloud

