Une mauvaise configuration dans Google Cloud Platform pourrait permettre aux attaquants d’obtenir un contrôle complet sur une machine virtuelle en tirant parti des fonctionnalités légitimes du système, selon une nouvelle étude publiée jeudi.

Le fournisseur de réponse aux incidents dans le cloud Mitiga a découvert la mauvaise configuration il y a quelques mois lors de recherches sur le moteur de calcul de Google Cloud Platform (GCP), en particulier son machine virtuelle (VM) service. La société a découvert une mauvaise configuration qui pourrait permettre aux acteurs de la menace de transmettre et de recevoir des données de machines virtuelles et éventuellement d’obtenir un contrôle complet du système.

Le vecteur d’attaque est un vecteur exposé métadonnées API appelée « getSerialPortOutput », qui est utilisée à des fins de suivi et de lecture des verrous de port série. Mitiga a découvert que l’API pouvait être utilisée de manière abusive pour accéder aux machines virtuelles dans GCP, même avec des pare-feu et d’autres contrôles d’accès en place.

Andrew Johnston, consultant principal chez Mitiga, a décrit une mauvaise configuration comme une « fonctionnalité dangereuse » dans un article de blog Jeudi.

« Chez Mitiga, nous pensons que cette mauvaise configuration est probablement assez courante pour justifier des préoccupations ; cependant, avec un contrôle d’accès approprié à l’environnement GCP, il n’y a pas de faille exploitable », a-t-il écrit.

Publicité

Johnston a déclaré à SearchSecurity que les organisations disposant d’environnements de production sur GCP peuvent être exposées au risque d’exfiltration de données ou d’avoir une machine virtuelle complètement compromise et utilisée comme infrastructure de commande et de contrôle pour les acteurs de la menace. Cependant, il a souligné que le problème n’était techniquement pas une vulnérabilité dans le cloud de Google.

« C’est plutôt un vecteur d’attaque qui abuse des fonctionnalités légitimes du système », a déclaré Johnston.

Comment cela fonctionne-t-il ?

À première vue, le problème avec l’API getSerialPortOutput semblait se limiter à des fuites de données potentielles.

« En soi, cette API ne représente pas beaucoup plus qu’une méthode furtive d’exfiltration », a écrit Johnston dans le rapport. « Bien qu’intéressant, il serait beaucoup plus puissant si nous pouvions identifier une méthode API compagnon qui permettrait à un adversaire d’envoyer des données à la machine. Combinées, les méthodes permettraient une commande et un contrôle complets (C2) sur une machine avec uniquement des informations d’identification cloud.

Mitiga, Google Cloud Platform, Mauvaise Configuration
Mitiga a constaté que les acteurs de la menace pouvaient abuser des API de métadonnées de Google Cloud Platform et transmettre des données à des machines virtuelles, en contournant les pare-feu et autres contrôles d’accès.

Mitiga a découvert et testé deux vecteurs d’attaque possibles qui impliquent l’abus d’une autre API, SetMetadata. Les deux cas ont commencé avec un attaquant accédant aux informations d’identification cloud d’une victime, ce qui a activé les autorisations d’API pour SetMetadata. Un cas impliquait des méthodes traditionnelles de mouvement latéral basées sur le réseau avant l’infection par le logiciel malveillant, tandis que l’autre exploitait les logiciels malveillants abusant des API.

Avec les API, un acteur de la menace pourrait envoyer des commandes malveillantes à l’intérieur de métadonnées personnalisées aux machines virtuelles dans le cloud Google. Sans contrôles d’accès supplémentaires, les acteurs de la menace pourraient prendre le contrôle de la machine virtuelle.

Bien que l’application de ces techniques nécessite des autorisations pertinentes telles que les informations d’identification GCP, le partage et la réutilisation des mots de passe administratifs et des noms d’utilisateur sont courants dans les entreprises et peuvent entraîner une probabilité plus élevée de fuite.

Comparées aux réseaux sur site, les informations d’identification cloud sont incroyablement puissantes, a déclaré Johnston. Souvent, avoir ces informations d’identification est la seule exigence pour accéder au système.

Les risques sont en outre mis en évidence par une autre étape de la séquence d’attaque alternative qui implique l’obtention d’autorisations d’API pour getSerialPortOutput. L’instance cloud est disponible même pour les rôles de visionneuse à faible autorisation, selon le rapport.

« Un adversaire pourrait potentiellement utiliser cette méthode pour exfiltrer furtivement d’un système auquel l’adversaire a eu accès via une méthode traditionnelle », a écrit Johnston dans le rapport.

Bien qu’il n’ait pas observé d’activité de menace autour de la mauvaise configuration, Johnston a déclaré qu’il était difficile de le confirmer pour tous les clients, ce qui est l’une des raisons pour lesquelles Mitiga a voulu faire connaître ses conclusions. Si le vecteur d’attaque était exploité, ce serait relativement évident, selon Johnston. Cependant, les risques n’ont pas été clairement documentés par Google, a-t-il déclaré.

« Cela implique des appels répétés à l’AP Google, ce qui nous préoccupait et pourquoi nous voulions faire avancer cette recherche et pourquoi nous voulions nous engager avec Google en premier lieu », a déclaré Johnston à SearchSecurity. « Je n’ai trouvé aucune recherche indiquant que ces API étaient dangereuses – ou du moins ce n’était pas très clair – et c’était notre principale préoccupation. »

Divulgation et mesures correctives

Mitiga a rapporté les résultats à Google programme de signalement des vulnérabilités (VRP); les deux fournisseurs ont convenu que le problème n’est pas une vulnérabilité, « mais plutôt simplement dangereuse sur le plan fonctionnel » qui pourrait être utilisée pour contourner les paramètres du pare-feu.

Mitiga a recommandé à Google d’apporter deux modifications à la fonction getSerialPortOutput, notamment en limitant son utilisation aux seuls rôles d’autorisation de niveau supérieur et en permettant aux organisations de désactiver tout ajout ou modification des métadonnées de machine virtuelle au moment de l’exécution. Mitiga a également recommandé une révision de la documentation GCP pour indiquer clairement que l’accès aux machines virtuelles n’est pas entièrement limité par des pare-feu et d’autres contrôles d’accès au réseau.

Cependant, Google n’était pas d’accord avec la majorité des recommandations.

Après un long échange, Google a finalement convenu que certaines parties de sa documentation pourraient être clarifiées et a accepté d’apporter des modifications à la documentation indiquant que le plan de contrôle peut accéder aux machines virtuelles, quels que soient les paramètres du pare-feu. Google n’a pas reconnu les autres recommandations ni parlé de détails quant à savoir si un utilisateur de GCP pouvait échapper aux accusations en utilisant la méthode getSerialPortOutput », a écrit Johnston dans le rapport.

Google a accordé à Johnston 100 $ via son VRP pour le rapport de mauvaise configuration.

Google a refusé de commenter le dossier.

Afin de renforcer les systèmes contre la mauvaise configuration GCP, Mitiga a recommandé d’attribuer des autorisations spécifiques si nécessaire aux utilisateurs conformément à la principe du moindre privilège, par opposition aux rôles intégrés.

Cependant, la sécurité du cloud est un domaine en évolution qui nécessite un niveau d’attention différent de celui des réseaux sur site, a déclaré Johnston. La plus grande leçon que Mitiga a tirée de cette découverte a été les nombreux effets secondaires involontaires de la transition vers le cloud.

Alors que Johnston a déclaré que le cloud a été incroyable pour les développeurs et le rythme de développement en termes de création d’applications de niveau entreprise, il existe des défis supplémentaires en matière de sécurité du cloud. Une partie de cette confusion provient des termes et des idées qui ont été tirés des réseaux locaux traditionnels qui ne s’appliquent pas toujours au cloud de la même manière. Un exemple est le programme commun de vulnérabilité et de divulgation.

Un autre exemple est centré sur le principe de responsabilité partagée sur lequel le cloud fonctionne. Johnston a déclaré que cela peut causer de la confusion quant à la façon exacte dont il est partagé, mais comprendre la différence dans la façon dont le cloud modifie ces termes ainsi que la technologie sous-jacente est important pour la sécurité du cloud.

« Alors que les entreprises poursuivent leur transition vers le cloud, il est vraiment important de comprendre à quoi ressemble la surface d’attaque de votre cloud et de vous assurer que vous avez la bonne journalisation et les alertes en place », a-t-il déclaré.

Rate this post
Publicité
Article précédentFMET est une nouvelle et merveilleuse idée de métaverse
Article suivantComment connecter et synchroniser Trello avec Google Calendar
Avatar
Violette Laurent est une blogueuse tech nantaise diplômée en communication de masse et douée pour l'écriture. Elle est la rédactrice en chef de fr.techtribune.net. Les sujets de prédilection de Violette sont la technologie et la cryptographie. Elle est également une grande fan d'Anime et de Manga.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici