GCP - Network Docker Escape
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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).
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 usurpant 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.
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 l'usurpation 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 l'usurpation, les étapes suivantes sont nécessaires :
Surveiller les requêtes au serveur de métadonnées en utilisant tcpdump:
Recherchez une ligne similaire à :
Envoyez les fausses données de métadonnées avec le bon ETAG à rshijack :
Cette étape autorise la clé publique, permettant une connexion SSH avec la clé privée correspondante.
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)
