GCP - Network Docker Escape
É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. L' Agent invité Google, 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é SSH publique 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 des 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 eu 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 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 s'il n'y a eu aucun changement de configuration, créant une fenêtre potentielle pour injecter une fausse réponse de configuration à l'agent invité.
Un attaquant pourrait exploiter cela en effectuant une attaque de type Man-in-the-Middle (MitM), en usurpant la réponse du serveur IMDS et insérant une nouvelle clé publique. Cela pourrait permettre un accès SSH non autorisé à l'hôte.
Technique d'évasion
Bien que le détournement 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 l'Agent invité Google 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 l'Agent invité Google de différentes valeurs de métadonnées, retardant ainsi la réponse.
Pour exécuter l'usurpation, les étapes suivantes sont nécessaires :
Surveiller les requêtes vers le serveur de métadonnées en utilisant tcpdump :
Cherchez une ligne similaire à :
Envoyez les fausses données de métadonnées avec le bon ETAG à rshijack :
Cette étape autorise la clé publique, permettant la connexion SSH avec la clé privée correspondante.
Références
Last updated
