Selon le chercheur en sécurité Imre Rad, les machines virtuelles de Google Compute Engine peuvent être piratées et forcées à céder l’accès au shell racine via une attaque DHCP astucieuse.

Bien que la faiblesse reste non corrigée, certains facteurs atténuants diminuent le risque potentiel. Dans l’ensemble, c’est un hack assez soigné si peu pratique : c’est un Ocean’s Eleven d’exploitation que vous pourriez trouver intéressant du point de vue de la sécurité du réseau.

Dans une écriture sur GitHub, Rad explique que les attaquants peuvent s’emparer des machines virtuelles GCE car ils s’appuient sur ISC DHCP logiciel qui utilise un générateur de nombres aléatoires faible.

Une attaque réussie implique de surcharger la machine virtuelle d’une victime avec du trafic DHCP afin qu’elle finisse par utiliser un serveur de métadonnées contrôlé par un attaquant malveillant, qui peut se trouver sur le même réseau ou de l’autre côté d’Internet. Le flot DHCP proviendrait généralement d’un système voisin contrôlé par un attaquant hébergé dans Google Cloud.

Lorsque la technique est parfaitement réussie, la VM utilise le serveur de métadonnées non autorisé pour sa configuration au lieu d’un serveur officiel de Google, et finalement le mécréant peut se connecter à la VM via SSH en tant qu’utilisateur root.

L’implémentation du client DHCP par ISC, selon Rad, repose sur trois éléments pour générer un identifiant aléatoire : l’heure Unix lorsque le processus est démarré ; le PID du processus dhclient ; et la somme des quatre derniers octets des adresses Ethernet (MAC) des cartes d’interface réseau de la machine. Ce nombre aléatoire, XID, est utilisé par le client pour suivre ses communications avec les serveurs DHCP de Google.

L’idée est donc de frapper la machine virtuelle victime avec un flux de paquets DHCP, avec une meilleure estimation du XID, jusqu’à ce que le client dh les accepte sur les paquets légitimes du serveur DHCP de Google, auquel cas vous pouvez configurer la pile réseau sur la machine virtuelle victime pour utilisez le serveur de métadonnées non autorisé en créant un alias des noms d’hôte du serveur Google.

Deux de ces ingrédients XID, dit Rad, sont prévisibles. Les quatre derniers octets de l’adresse MAC sont les mêmes que l’adresse IP interne de la box. Et le PID est attribué par le noyau Linux de manière linéaire.

« Pour monter cette attaque, l’attaquant doit créer plusieurs paquets DHCP à l’aide d’un ensemble de XID précalculés/suspects et inonder directement le dhclient de la victime », explique Rad.

« Si le XID est correct, la machine victime applique la configuration réseau. Il s’agit d’une condition de concurrence, mais comme le flot est rapide et exhaustif, le serveur de métadonnées n’a aucune chance réelle de gagner.

La création du XID correct dans un flot de paquets DHCP est facilitée par le schéma de randomisation insuffisant. Cela permet à l’attaquant de reconfigurer la pile réseau de la cible à volonté.

Ne devrait pas être une nouveauté pour Google

Selon Rad, Google s’appuie sur ses serveurs de métadonnées pour gérer la distribution des clés SSH. En usurpant l’identité d’un serveur de métadonnées, l’accès SSH peut être accordé à l’attaquant.

La technique de Rad est basée sur une attaque divulgué l’année dernière par le chercheur en sécurité Chris Moberly, mais diffère en ce que l’inondation DHCP est effectuée à distance et que les XID sont devinés.

Dans les trois scénarios d’attaque conçus par Rad, deux nécessitent que l’attaquant se trouve sur le même sous-réseau que la machine virtuelle cible pour envoyer le flot de trafic DHCP. Dans un scénario, la machine virtuelle victime doit redémarrer et dans l’autre, elle actualise son bail DHCP. Le troisième permet une attaque à distance sur Internet mais nécessite que le pare-feu devant la VM cible soit complètement ouvert.

Rad admet que ce troisième cas n’est « probablement pas un scénario courant », mais note que la console GCP Cloud fournit cette option et suppose qu’il y aura probablement des VM avec cette configuration.

Les techniques de défense suggérées consistent à ne pas faire référence au serveur de métadonnées à l’aide de son nom d’hôte virtuel (metadata.google.internal), à ne pas gérer le nom d’hôte virtuel via DHCP, à sécuriser la communication du serveur de métadonnées à l’aide de TLS et à bloquer UDP sur les ports 67/68 entre les machines virtuelles.

Google aurait été informé de ce problème en septembre 2020. Après neuf mois d’inaction, Rad a publié son avis. La Chocolaterie n’a pas immédiatement répondu à une demande de commentaire. Nous imaginons que Google Cloud peut avoir des défenses en place, telles que la détection d’un trafic DHCP étrange, par exemple. ®