# GCP - Évasion Docker Réseau

{{#include ../../../banners/hacktricks-training.md}}

## État Initial

Dans les deux rapports où cette technique est spécifiée, les attaquants ont réussi à obtenir un accès **root** à l'intérieur d'un conteneur **Docker** géré par GCP avec accès au réseau hôte (et les capacités **`CAP_NET_ADMIN`** et **`CAP_NET_RAW`**).

## Explication de l'Attaque

Sur une instance Google Compute Engine, une inspection régulière du trafic réseau révèle de nombreuses **requêtes HTTP en clair** vers l'**instance de métadonnées** à `169.254.169.254`. Le [**Google Guest Agent**](https://github.com/GoogleCloudPlatform/guest-agent), un service open-source, effectue fréquemment de telles requêtes.

Cet agent est conçu pour **surveiller les changements dans les métadonnées**. Notamment, les métadonnées incluent un **champ pour les clés publiques SSH**. Lorsqu'une nouvelle clé publique SSH est ajoutée aux métadonnées, l'agent l'**autorise automatiquement** dans le fichier `.authorized_key`. Il peut également **créer un nouvel utilisateur** et l'ajouter aux **sudoers** si nécessaire.

L'agent surveille les changements en envoyant une requête pour **récupérer toutes les valeurs de métadonnées de manière récursive** (`GET /computeMetadata/v1/?recursive=true`). Cette requête est conçue pour inciter le serveur de métadonnées à envoyer une réponse uniquement s'il y a un changement dans les métadonnées depuis la dernière récupération, identifié par un Etag (`wait_for_change=true&last_etag=`). De plus, un paramètre de **timeout** (`timeout_sec=`) est inclus. Si aucun changement ne se produit dans le délai spécifié, le serveur répond avec les **valeurs inchangées**.

Ce processus permet au **IMDS** (Instance Metadata Service) de répondre après **60 secondes** si aucun changement de configuration n'a eu lieu, créant une **fenêtre potentielle pour injecter une réponse de configuration falsifiée** à l'agent invité.

Un attaquant pourrait exploiter cela en effectuant une **attaque Man-in-the-Middle (MitM)**, en falsifiant la réponse du serveur IMDS et en **insérant une nouvelle clé publique**. Cela pourrait permettre un accès SSH non autorisé à l'hôte.

### Technique d'Évasion

Bien que le spoofing ARP soit inefficace sur les réseaux Google Compute Engine, une [**version modifiée de rshijack**](https://github.com/ezequielpereira/rshijack) développée par [**Ezequiel**](https://www.ezequiel.tech/2020/08/dropping-shell-in.html) peut être utilisée pour l'injection de paquets dans la communication afin d'injecter l'utilisateur SSH.

Cette version de rshijack permet d'entrer les numéros ACK et SEQ en tant qu'arguments de ligne de commande, facilitant le spoofing d'une réponse avant la véritable réponse du serveur de métadonnées. De plus, un [**petit script Shell**](https://gist.github.com/ezequielpereira/914c2aae463409e785071213b059f96c#file-fakedata-sh) est utilisé pour renvoyer une **charge utile spécialement conçue**. Cette charge utile déclenche le Google Guest Agent pour **créer un utilisateur `wouter`** avec une clé publique spécifiée dans le fichier `.authorized_keys`.

Le script utilise le même ETag pour empêcher le serveur de métadonnées de notifier immédiatement le Google Guest Agent de valeurs de métadonnées différentes, retardant ainsi la réponse.

Pour exécuter le spoofing, les étapes suivantes sont nécessaires :

1. **Surveiller les requêtes au serveur de métadonnées** en utilisant **tcpdump** :
```bash
tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &
```
Cherchez une ligne similaire à :
```
<TIME> IP <LOCAL_IP>.<PORT> > 169.254.169.254.80: Flags [P.], seq <NUM>:<TARGET_ACK>, ack <TARGET_SEQ>, win <NUM>, length <NUM>: HTTP: GET /computeMetadata/v1/?timeout_sec=<SECONDS>&last_etag=<ETAG>&alt=json&recursive=True&wait_for_change=True HTTP/1.1
```
2. Envoyez les fausses métadonnées avec le bon ETAG à rshijack :
```bash
fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <LOCAL_IP>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
```
Cette étape autorise la clé publique, permettant une connexion SSH avec la clé privée correspondante.

## Références

- [https://www.ezequiel.tech/2020/08/dropping-shell-in.html](https://www.ezequiel.tech/2020/08/dropping-shell-in.html)
- [https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities](https://www.wiz.io/blog/the-cloud-has-an-isolation-problem-postgresql-vulnerabilities)

{{#include ../../../banners/hacktricks-training.md}}
