Une faille de sécurité non corrigée affectant la plate-forme Compute Engine de Google pourrait être exploitée par un attaquant pour prendre le contrôle de machines virtuelles sur le réseau.
« Cela se fait en usurpant l’identité du serveur de métadonnées du point de vue de la machine virtuelle ciblée », a déclaré le chercheur en sécurité Imre Rad dans un Analyse publié vendredi. « En montant cet exploit, l’attaquant peut s’accorder l’accès via SSH (authentification par clé publique) afin qu’il puisse ensuite se connecter en tant qu’utilisateur root. »
Moteur de calcul Google (GCE) est un composant d’infrastructure en tant que service (IaaS) de Google Cloud Platform qui permet aux utilisateurs de créer et de lancer des machines virtuelles (VM) à la demande. GCE fournit une méthode de stockage et de récupération des métadonnées sous la forme du serveur de métadonnées, qui offre un point central pour définir les métadonnées sous la forme de paires clé-valeur qui sont ensuite fournies aux machines virtuelles lors de l’exécution.
Selon le chercheur, le problème est une conséquence de la faiblesse des nombres pseudo-aléatoires utilisés par le client DHCP ISC, ce qui entraîne un scénario dans lequel un adversaire crée plusieurs paquets DHCP en utilisant un ensemble d’identifiants de transaction précalculés (aka XID) et inonde le client DHCP de la victime, conduisant finalement à l’usurpation d’identité du serveur de métadonnées.
Protocole de configuration d’hôte dynamique (DHCP) est un protocole de gestion de réseau utilisé pour automatiser le processus de configuration des appareils sur les réseaux IP. Un serveur DHCP attribue dynamiquement une adresse IP et d’autres paramètres de configuration réseau à chaque périphérique client sur un réseau afin qu’ils puissent communiquer avec d’autres réseaux.
« Si le XID est correct, la machine victime applique la configuration réseau », a expliqué Rad dans la rédaction technique. « Il s’agit d’une situation de concurrence critique, mais comme le flot est rapide et exhaustif, le serveur de métadonnées n’a aucune chance réelle de gagner. À ce stade, l’attaquant est en mesure de reconfigurer la pile réseau de la victime. »
Étant donné qu’un serveur de métadonnées peut être utilisé pour distribuer et gérer les clés SSH, un client — ayant maintenant établi une connexion TCP avec le serveur malveillant — peut récupérer la clé publique SSH de l’attaquant, qui peut ensuite être utilisée par l’attaquant pour ouvrir un shell distant en tant qu’utilisateur root.
Dans un scénario réel potentiel, la chaîne d’attaque susmentionnée peut être exploitée par un adversaire pour obtenir un accès complet à une machine virtuelle ciblée lors de son redémarrage ou via Internet dans les cas où le pare-feu de la plate-forme cloud est désactivé.
Google a été informé du problème le 27 septembre 2020, qui a depuis reconnu le rapport, le décrivant comme une « belle prise », mais n’a pas encore déployé de correctif ni fourni de calendrier pour la mise à disposition de la correction. .
« Jusqu’à ce que le correctif arrive, n’utilisez pas DHCP ou ne configurez pas de règle de pare-feu au niveau de l’hôte pour vous assurer que la communication DHCP provient du serveur de métadonnées (169.254.169.254) », a noté Rad. « Bloquez UDP/68 entre les machines virtuelles, afin que seul le serveur de métadonnées puisse exécuter DHCP. »
C’est loin d’être la première fois que Rad identifie des problèmes dans Google Cloud Platform.
En septembre 2020, Google a rectifié un élévation des privilèges locaux vulnérabilité dans le Outil de configuration du système d’exploitation qui pourraient être exploités par un acteur disposant des droits d’exécution de code sur les VM GCE affectées pour effectuer des opérations non autorisées.
Plus tôt en janvier, Rad a également découvert qu’il était possible de réaliser l’exécution de code arbitraire dans une machine virtuelle en obtenant un shell sur le service de base de données Cloud SQL. Le problème a été résolu par Google le 16 février 2021.
