GCP - AppEngine Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aby uzyskać więcej informacji o App Engine, sprawdź:
appengine.applications.get
, appengine.instances.get
, appengine.instances.list
, appengine.operations.get
, appengine.operations.list
, appengine.services.get
, appengine.services.list
, appengine.versions.create
, appengine.versions.get
, appengine.versions.list
, cloudbuild.builds.get
,iam.serviceAccounts.actAs
, resourcemanager.projects.get
, storage.objects.create
, storage.objects.list
To są potrzebne uprawnienia do wdrożenia aplikacji za pomocą gcloud
cli. Może get
i list
można by uniknąć.
Możesz znaleźć przykłady kodu w Pythonie na https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine
Domyślnie nazwa usługi aplikacji będzie default
, a tylko jedna instancja może mieć tę samą nazwę.
Aby to zmienić i utworzyć drugą aplikację, w app.yaml
zmień wartość klucza głównego na coś takiego jak service: my-second-app
Daj temu co najmniej 10-15 minut, jeśli to nie zadziała, zadzwoń deploy another of times i poczekaj kilka minut.
Można wskazać konto usługi do użycia, ale domyślnie używane jest domyślne SA App Engine.
URL aplikacji wygląda mniej więcej tak https://<proj-name>.oa.r.appspot.com/
lub https://<service_name>-dot-<proj-name>.oa.r.appspot.com
Możesz mieć wystarczające uprawnienia, aby zaktualizować AppEngine, ale nie aby utworzyć nowy. W takim przypadku oto jak możesz zaktualizować bieżący App Engine:
Jeśli już skompromitowałeś AppEngine i masz uprawnienia appengine.applications.update
oraz actAs nad kontem usługi, możesz zmodyfikować konto usługi używane przez AppEngine za pomocą:
appengine.instances.enableDebug
, appengine.instances.get
, appengine.instances.list
, appengine.operations.get
, appengine.services.get
, appengine.services.list
, appengine.versions.get
, appengine.versions.list
, compute.projects.get
Dzięki tym uprawnieniom możliwe jest logowanie się przez ssh w instancjach App Engine typu flexible (nie standardowym). Niektóre z uprawnień list
i get
mogą nie być naprawdę potrzebne.
appengine.applications.update
, appengine.operations.get
Myślę, że to tylko zmienia tło SA, które Google będzie używać do konfigurowania aplikacji, więc nie sądzę, że można to wykorzystać do kradzieży konta usługi.
appengine.versions.getFileContents
, appengine.versions.update
Nie jestem pewien, jak używać tych uprawnień ani czy są one przydatne (zauważ, że gdy zmieniasz kod, tworzona jest nowa wersja, więc nie wiem, czy możesz po prostu zaktualizować kod lub rolę IAM jednej z nich, ale przypuszczam, że powinieneś być w stanie to zrobić, może zmieniając kod wewnątrz bucketu??).
Jak wspomniano, wersje appengine generują pewne dane wewnątrz bucketu w formacie nazwy: staging.<project-id>.appspot.com
. Zauważ, że nie jest możliwe wcześniejsze przejęcie tego bucketu, ponieważ użytkownicy GCP nie są uprawnieni do generowania bucketów przy użyciu nazwy domeny appspot.com
.
Jednakże, mając dostęp do odczytu i zapisu w tym bucketie, możliwe jest eskalowanie uprawnień do SA przypisanego do wersji AppEngine poprzez monitorowanie bucketu i w każdej chwili, gdy dokonana zostanie zmiana, jak najszybciej modyfikowanie kodu. W ten sposób kontener, który zostanie utworzony z tego kodu, wykona zainfekowany kod.
Aby uzyskać więcej informacji i PoC, sprawdź odpowiednie informacje z tej strony:
Chociaż App Engine tworzy obrazy dockerowe wewnątrz Artifact Registry. Przetestowano, że nawet jeśli zmodyfikujesz obraz wewnątrz tej usługi i usuniesz instancję App Engine (tak aby wdrożona została nowa), wykonywany kod się nie zmienia. Może być możliwe, że przeprowadzając atak Race Condition, podobnie jak w przypadku bucketów, może być możliwe nadpisanie wykonywanego kodu, ale to nie zostało przetestowane.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)