GCP - Évasion Docker Réseau

Reading time: 5 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

É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, 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 développée par Ezequiel 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 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 :

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

Envoyez les fausses métadonnées avec le bon ETAG à rshijack :