GCP - Network Docker Escape
État initial
Dans les deux articles 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).
Attaque
Lorsque vous inspectez le trafic réseau sur une instance Google Compute Engine régulière, vous verrez beaucoup de requêtes HTTP en clair dirigées vers l'instance de métadonnées sur 169.254.169.254. Un service qui effectue de telles requêtes est l'agent open-source Google Guest Agent. Exemple de requête :
Cet agent surveille les métadonnées pour détecter des changements. À l'intérieur des métadonnées, il y a un champ avec des clés publiques SSH autorisées.
Ainsi, lorsqu'une nouvelle clé publique SSH apparaît dans les métadonnées, l'agent va autoriser cette clé dans le fichier .authorized_key de l'utilisateur et il va créer un nouvel utilisateur si nécessaire en l'ajoutant aux sudoers.
La manière dont l'agent Google Guest surveille les changements est par un appel pour récupérer toutes les valeurs des métadonnées de manière récursive (GET /computeMetadata/v1/?recursive=true), indiquant au serveur de métadonnées de ne répondre que lorsqu'il y a un changement par rapport aux dernières valeurs de métadonnées récupérées, identifiées par son Etag (wait_for_change=true&last_etag=).
Cette requête inclut également un délai d'attente (timeout_sec=), donc si un changement ne se produit pas dans le temps spécifié, le serveur de métadonnées répond avec les valeurs inchangées.
Cela fait que l'IMDS réponde après 60 secondes s'il n'y a pas eu de changement de configuration dans cet intervalle, permettant une fenêtre pour injecter une fausse réponse de configuration à l'agent invité de l'IMDS.
Par conséquent, si un attaquant réussit à réaliser une attaque MitM, il pourrait usurper la réponse du serveur IMDS en insérant une nouvelle clé publique pour permettre à un nouvel utilisateur d'accéder via SSH à l'hôte.
Évasion
Le spoofing ARP ne fonctionne pas sur les réseaux Google Compute Engine, cependant, Ezequiel a généré cette version modifiée de rshijack **** qui peut être utilisée pour injecter un paquet dans la communication afin d'injecter l'utilisateur SSH.
Cette version modifiée de rshijack permet de passer les numéros ACK et SEQ en arguments de ligne de commande, économisant du temps et nous permettant d'usurper une réponse avant que la vraie réponse des métadonnées n'arrive.
De plus, ce petit script Shell **** qui retournerait un payload spécialement conçu qui déclencherait l'agent Google Guest à créer l'utilisateur wouter, avec notre propre clé publique dans son fichier .authorized_keys.
Ce script reçoit l'ETag en paramètre, car en gardant le même ETag, le serveur de métadonnées ne dirait pas immédiatement à l'agent Google Guest que les valeurs des métadonnées étaient différentes lors de la prochaine réponse, attendant plutôt le nombre de secondes spécifié dans timeout_sec.
Pour réaliser l'usurpation, vous devriez surveiller les requêtes vers le serveur de métadonnées avec tcpdump : tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & en attendant une ligne qui ressemblerait à ceci :
Lorsque vous voyez cette valeur, envoyez les fausses métadonnées avec le bon ETAG à rshijack :
fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <IP_LOCALE>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost
Et cela devrait faire en sorte que l'agent autorise cette clé publique qui vous permettra de vous connecter via SSH avec la clé privée.
Références
Dernière mise à jour
