GCP - Network Docker Escape

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

État initial

Dans les deux rapports où cette technique est décrite, 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 de l’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 metadata à 169.254.169.254. Le Google Guest Agent, un service open-source, effectue fréquemment ce type de requêtes.

Cet agent est conçu pour surveiller les changements dans la metadata. Notamment, la metadata inclut un champ pour les clés publiques SSH. Lorsqu’une nouvelle clé publique SSH est ajoutée à la metadata, l’agent l’autorise automatiquement dans le fichier .authorized_key. Il peut aussi 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 metadata de façon récursive (GET /computeMetadata/v1/?recursive=true). Cette requête est conçue pour inciter le serveur de metadata à renvoyer une réponse uniquement s’il y a eu un changement dans la metadata 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 survient pendant le délai spécifié, le serveur répond avec les valeurs inchangées.

Ce processus permet à l’IMDS (Instance Metadata Service) de répondre après 60 secondes si aucune modification de configuration n’a eu lieu, créant une fenêtre potentielle pour injecter une fausse réponse de configuration vers le guest agent.

Un attaquant pourrait exploiter cela en réalisant une attaque Man-in-the-Middle (MitM), en spoofant 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

Alors que l’ARP spoofing est 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 de fournir les numéros ACK et SEQ en tant qu’arguments en ligne de commande, facilitant le spoofing d’une réponse avant la réponse réelle du serveur Metadata. De plus, un petit Shell script est utilisé pour renvoyer une charge utile spécialement conçue. Cette charge 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 Metadata d’avertir immédiatement le Google Guest Agent de valeurs de metadata différentes, retardant ainsi la notification.

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

1. Surveiller les requêtes vers le serveur de metadata en utilisant tcpdump :

Recherchez une ligne similaire à :