Des chercheurs de la société de sécurité cloud Snyk ont ​​récemment découvert une vulnérabilité qui aurait permis aux attaquants d'effectuer une prise de contrôle complète du compte et une exécution de code à distance (RCE) dans Gitpod, un environnement de développement cloud (CDE) populaire. Ces derniers sont recherchés, car ils sont plus faciles à déployer et à entretenir que les environnements locaux et promettent une meilleure sécurité. Cependant, les entreprises doivent évaluer correctement les risques de sécurité propres aux architectures CDE peuvent amener, d'autant plus qu'ils n'ont pas fait l'objet d'un examen minutieux de la part de la communauté de la sécurité. « De nombreuses questions restent sans réponse avec l'adoption d'environnements de développement basés sur le cloud : que se passe-t-il si un espace de travail IDE cloud est infecté par des logiciels malveillants ? Que se passe-t-il lorsque les contrôles d'accès sont insuffisants et permettent un accès entre utilisateurs ou même entre entreprises aux espaces de travail ? Que se passe-t-il lorsqu'un développeur malhonnête exfiltre la propriété intellectuelle de l'entreprise à partir d'une machine hébergée dans le cloud hors de la visibilité du logiciel de prévention des pertes de données ou de sécurité des points finaux de l'organisation ? », ont expliqué les chercheurs de Snyk dans leur rapport, qui fait partie d'un projet plus vaste visant à enquêter sur la sécurité de CDE.

Les environnements de développement intégrés (IDE) traditionnels qui sont déployés localement sur des postes de travail de développeur individuels peuvent également présenter pléthore de problèmes de sécurité et de vulnérabilités. En fait, les CDE constituent à bien des égards une grande amélioration par rapport aux IDE traditionnels : ils peuvent éliminer la dérive de configuration qui se produit au fil du temps avec les postes de travail/ordinateurs portables des développeurs et éviter les collisions de dépendance qui se produisent lorsque les développeurs travaillent sur différents projets. Mais aussi réduire la fenêtre des attaques car ces environnements de travail sous forme de container peuvent être à durée limitée. Lorsque des failles sont détectées, le fournisseur CDE peut probablement déployer un correctif plus rapidement qu'une entreprise pourrait le faire sur tous ses postes de travail et ordinateurs portables de développeur exécutant un IDE traditionnel. Bien sûr, les temps de réponse de sécurité peuvent varier d'un fournisseur de CDE à l'autre. Les sociétés doivent donc choisir leur fournisseur avec soin si elles lui confient leur infrastructure de développement, y compris le code, les jetons d'accès, les secrets de production et d'autres propriétés intellectuelles.

Le piratage WebSocket intersite souvent mal compris

La vulnérabilité découverte par Snyk, que l'équipe Gitpod a résolue en une journée, est identifiée comme CVE-2023-0957 et entre dans une catégorie de problèmes connus sous le nom de cross-site WebSocket hijacking. Un mécanisme de sécurité de base intégré aux navigateurs connu sous le nom de Same Origin Policy (SOP), empêche le code exécuté sur un site de lire les informations d'un autre site auquel un visiteur est connecté. Étant donné que les requêtes du navigateur vers un site - par exemple, le site A - incluent généralement les cookies de session d'un utilisateur, sans SOP, un site malveillant B visité par l'utilisateur pourrait charger une ressource du site A et être en mesure de voler le cookie de session d'un utilisateur avec emplacement A. Le problème est que ce mécanisme de défense n'existe que pour HTTP mais pas WebSocket, une technologie de communication bidirectionnelle pour qu'un navigateur échange des données avec un serveur en utilisant une connexion persistante. « Lorsqu'une poignée de main WebSocket repose uniquement sur des cookies HTTP pour l'authentification, un site Web malveillant est capable d'instancier une nouvelle connexion WebSocket à l'application vulnérable, permettant à un attaquant d'envoyer et de recevoir des données via la connexion », ont expliqué les chercheurs de Snyk. En d'autres termes, si un utilisateur visite un site web malveillant et que ce site ouvre une connexion WebSocket en son nom à un autre serveur auprès duquel il est authentifié, le site malveillant peut envoyer des commandes malveillantes via la connexion et recevoir des réponses en se superposant au cookie de l'utilisateur. C'est pourquoi les connexions WebSocket doivent être implémentées avec une authentification supplémentaire.

L'architecture Gitpod se compose de plusieurs microservices déployés dans un environnement Kubernetes, avec des espaces de travail utilisateur déployés sous forme de pods éphémères. Les espaces de travail Gitpod se composent d'un composant serveur écrit en TypeScript et d'une application web pour le tableau de bord construite avec React qui communique via WebSocket avec une API JSONRPC exposée par le serveur. Le tableau de bord est l'interface avec laquelle le développeur interagit et où il peut importer un référentiel à partir d'un fournisseur de gestion de code source comme GitHub. Une fois configuré, l'espace de travail est également rendu accessible via SSH et HTTP à l'aide de sous-domaines dédiés sous le domaine gitpod.io.

Comment les chercheurs ont exploité la faille Gitpod désormais corrigée

Les chercheurs de Snyk ont ​​vérifié que l'implémentation de Gitpod WebSocket n'utilisait pas d'authentification supplémentaire et qu'un attaquant pouvait ouvrir une connexion WebSocket à l'espace de travail à partir d'une origine différente. Cependant, un mécanisme différent récemment mis en œuvre dans les navigateurs, appelé cookies SameSite, est entré en jeu, rendant leur attaque inefficace. Les cookies SameSite sont conçus comme une défense contre les attaques de falsification de requêtes intersites (CSRF), où un site peut forcer le navigateur d'un utilisateur à émettre une requête vers un autre site au nom de l'utilisateur. Cependant, contrairement au SOP, qui vérifie le schéma d'origine + hôte (y compris les sous-domaines) + port, la politique SameSite vérifie uniquement que le domaine est le même. SameSite s'applique à tous les cookies, y compris ceux envoyés via WebSocket, ce qui signifie que pour lancer une attaque cross-site WebSocket hijacking contre Gitpod, un attaquant devrait utiliser une page web malveillante également hébergée sur gitpod.io. Étant donné que chaque espace de travail se voit attribuer son propre sous-domaine, les chercheurs de Snyk ont ​​dû trouver un moyen de diffuser une page web malveillante à partir d'un espace de travail Gitpod qu'ils ont configuré. L'éditeur de code par défaut dans les espaces de travail Gitpod est VS Code (Visual Studio Code) et il est exposé via une interface web. Ainsi, les chercheurs de Snyk ont ​​tenté de tuer le processus VS Code dans l'espace de travail à l'aide de l'interface de ligne de commande et de lier un serveur web basé sur Python au port précédemment utilisé par VS Code pour servir leur fichier HTML malveillant. Cela n'a pas fonctionné, car un processus « superviseur » qui surveille l'espace de travail a redémarré l'espace de travail.

Finalement, les chercheurs ont observé que s'ils ne tuaient que le processus VS Code, mais ne liaient pas le port à un autre, le superviseur tenterait uniquement de redémarrer VS Code et non l'ensemble de l'espace de travail. Cela leur a donné l'idée d'arrêter VS Code et de le remplacer rapidement par une version corrigée qu'ils ont créée et qui a servi leur exploit via le point de terminaison de l'API /version, qui ne renvoie normalement que le numéro de version de VS Code. « Nous l'avons modifié pour que le bon Content-Type de text/html et le contenu d'un fichier HTML soient renvoyés », ont déclaré les chercheurs. « Maintenant, nous avons mis fin au processus vscode, permettant à nos modifications nouvellement introduites de se charger dans une instance de processus VS Code nouvellement générée ».

Possédant un lien avec leur page web malveillante s'exécutant sur un espace de travail à l'intérieur de Gitpod et sur un sous-domaine Gitpod, les chercheurs n'ont donc plus eu qu'à l'envoyer à un utilisateur Gitpod visé connecté à son propre espace de travail pour activer l'exploit en ouvrant une connexion WebSockets à l'espace de travail de la victime et émettre des méthodes JSONRPC telles que getLoggedInUser, getGitpodTokens, getOwnerToken et addSSHPublicKey. La dernière méthode permet à un attaquant d'ajouter sa propre clé SSH dans l'espace de travail de la victime, d'assurer un accès distant persistant via SSH dans l'espace de travail. Les chercheurs de Snyk ont ​​félicité Gitpod pour son temps de réponse rapide et son correctif, mais ont ajouté que « les espaces de travail des développeurs cloud devenant de plus en plus populaires, il est important de prendre en compte les risques supplémentaires qui sont introduits ».