IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Une porte dérobée découverte dans la bibliothèque Ruby strong_password
Utilisée par les applications web RoR pour tester la force des mots de passe

Le , par Christian Olivier

161PARTAGES

3  0 
Tute Costa, développeur chez Epion Health, a récemment découvert une porte dérobée dissimulée dans une bibliothèque utilisée par les applications web Ruby on Rails (RoR) pour vérifier la force des mots de passe. Bien que le langage de script Ruby et RoR ne soient plus aussi populaires qu’avant, ils sont toujours intégrés dans de nombreux environnements de développement d’entreprise, dont un nombre inconnu pourrait avoir utilisé la bibliothèque strong_password dans sa version infectée 0.0.7.


La découverte a eu lieu après que le développeur ait remarqué quelque chose d’inhabituel lors de la mise à jour d’une famille de bibliothèques utilisées par son entreprise pour corriger des bogues et des vulnérabilités de sécurité. En s’intéressant à la bibliothèque strong_password sur RubyGems.org, il n’a pas réussi à trouver un journal récapitulant les modifications qui lui permettrait de comprendre comment il est passé de la version 0.0.6 à la version 0.0.7 compromise.

En comparant les deux versions, il a remarqué que la mystérieuse version 0.0.7 intégrait un lien de téléchargement qui « ;récupère et exécute le code stocké dans pastebin.com, uniquement en mode production, avec une gestion des exceptions vides qui ignore toute erreur qu’elle peut générer.

La porte dérobée téléchargerait le code à partir de l’adresse de Pastebin pour les sites de production et donnait aux attaquants le pouvoir d’exécuter en toute discrétion du code distant en production à volonté. Cette vulnérabilité a été identifiée par le nom de code « CVE-2019-13354 ». La bibliothèque infectée a, par la suite, été extraite et remplacée dans la version 0.0.8.


Il ne s’agissait pas d’une attaque spéculative - quelqu’un a réfléchi à ce qu’il faisait et a installé cette porte dérobée de façon à ce qu’elle soit difficile à détecter. La mise à jour malveillante a été publiée par un compte vide sous un nom différent de celui du responsable officiel (probablement victime du piratage de son compte Pastebin mal sécurisé), Brian McManus. Ce dernier a confié à Costa dans un courriel : « La bibliothèque semble m’avoir été retirée… Lorsque je me connecte à rubygems.org, je ne semble plus avoir la propriété ».

Cet évènement survient dans un contexte inquiétant de ciblage des bibliothèques Ruby par des individus malveillants. En mars dernier déjà, une porte dérobée a été trouvée dans la bibliothèque Bootstrap-Sass Ruby, le hacker ayant semble-t-il piraté le compte de l’un des développeurs du projet. La version malveillante du package bootstrap-sass (version 3.2.0.3) a été publiée dans le référentiel officiel de RubyGems. Elle incluait une porte dérobée furtive permettant aux attaquants d’exécuter des commandes à distance dans les applications Rails côté serveur. Le code malveillant a été supprimé via une mise à jour de la bibliothèque.

Le grand nombre de bibliothèques utilisées par RoR (et d’autres frameworks de développement dans la ligne de mire) amène à se demander quel pourrait être le degré de surveillance approprié lorsque de nouvelles versions apparaissent. Heureusement que cette fois-ci un développeur faisait attention.

Source : With a Twist

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Ruby 2.6 est disponible en version stable avec un nouveau compilateur JIT en mode expérimental et un nouveau module pour analyser du code Ruby

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 02/08/2019 à 0:01
24.9. Sécurité
Général

L'installation d'une gemme permet à son code de s'exécuter dans le contexte de votre application. Clairement, cela a des implications en termes de sécurité: installer une gemme malveillante sur un serveur peut permettre à son serveur de pénétrer complètement dans son serveur. Pour cette raison, la sécurité du code des pierres précieuses est un sujet de discussion active au sein de la communauté Ruby.

RubyGems est capable de signer de manière cryptographiqueles les depuis la version 0.8.11. Cette signature fonctionne en utilisant la commande gem cert pour créer une paire de clés, puis en empaquetant les données de signature dans la gem elle-même. La commande gem install vous permet éventuellement de définir une politique de sécurité et de vérifier la clé de signature d'un gem avant de l'installer.

Cependant, cette méthode de sécurisation des pierres précieuses n'est pas largement utilisée. Il nécessite un certain nombre d’ étapes manuelles de la part du développeur et il n’existe pas de chaîne de confiance bien établie pour les clés de signature de gemmes. Des discussions sur de nouveaux modèles de signature tels que X509 et OpenPGP se poursuivent dans le wiki rubygems-trust , la liste RubyGems-Developers et dans IRC . L'objectif est d'améliorer (ou de remplacer) le système de signature afin qu'il soit facile pour les auteurs et transparent pour les utilisateurs.
Utilisation des gems

Installer avec une politique de confiance.

gem install gemname -P HighSecurity : Tous les gems dépendants doivent être signés et vérifiés.

gem install gemname -P MediumSecurity : tous les gems dépendants signés doivent être vérifiés.

bundle --trust-policy MediumSecurity : comme ci-dessus, sauf que Bundler ne reconnaît que l' --trust-policy long --trust-policy , pas le short -P .

Mise en garde : les certificats de gemmes sont approuvés globalement, de sorte que l'ajout d'un cert.pem pour un gem approuve automatiquement toutes les gemmes signées par ce cert.

Vérifier la somme de contrôle, si disponible

gem fetch gemname -v version ruby -rdigest/sha2 -e "puts Digest::SHA512.new.hexdigest(File.read('gemname-version.gem'))
0  0 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 09/05/2020 à 0:51
Erreur de traduction sur ce paragraphe.
Citation Envoyé par Madmac Voir le message

Cependant, cette méthode de sécurisation des gemmes n'est pas largement utilisée. Il nécessite un certain nombre d’ étapes manuelles de la part du développeur et il n’existe pas de chaîne de confiance bien établie pour les clés de signature de gemmes. Des discussions sur de nouveaux modèles de signature tels que X509 et OpenPGP se poursuivent dans le wiki rubygems-trust , la liste RubyGems-Developers et dans IRC . L'objectif est d'améliorer (ou de remplacer) le système de signature afin qu'il soit facile pour les auteurs et transparent pour les utilisateurs.
0  0