Backdoor dans le module python ssh-decorator

La question revient très régulièrement : peut-on faire confiance aux outils ou librairies open-source du marché ?

En tant que pentester, on a constamment à développer des plus ou moins gros outils, et le choix des librairies que l'on utilise dans ces outils peut vite devenir un véritable casse-tête.

On peut penser - et très souvent à tort - que lorsqu’un outil est open-source et largement utilisé, que quelqu’un « a bien dû jeter un œil un moment ou un autre ». Et bien, oui, dans certaines situations des personnes (qui ont du temps) jettent un œil et ça fait très peur.

C’est le cas par exemple du package ssh-decorator de Python, une jolie backdoor qui envoie tout simplement les identifiants (avec clé privée et mot de passe le cas échéant) en requête POST et en clair (en http) à un site tiers a été découverte. La fonction « log » a pour objectif de faire fuiter ces informations critiques vers le site ssh-decorate :

ssh-decorate

Le thread Reddit : https://www.reddit.com/r/Python/comments/8hvzja/backdoor_in_sshdecorator_package/?st=jgynd5qc&sh=81855e72

Le package n’est dorénavant plus accessible, mais la première release date de Septembre 2017 (https://libraries.io/pypi/ssh-decorate/0.1) cela veut potentiellement dire que ça fait plus de 9 mois que des identifiants sont récupérés…

Je n’ose même pas imaginer le nombre de librairies dont le code source n’a pas été audité, ou même où personne n’a jeté un petit coup d’œil rapide, car quand on voit à quel point la backdoor de ssh-decorator est béante, on se demande comment elle a pu rester aussi longtemps disponible et exploitée.

Bien sûr, il est très compliqué d’avoir un contrôle total sur les librairies utilisées dans un script (surtout que dans certaines situations, les librairies peuvent elles-mêmes utiliser des librairies vulnérables). L’objectif est dans un premier temps de bien évaluer la criticité des données traitées par le script, l’environnement dans lequel il sera exécuté (serveur de production ? de test ? VM ?) et d’adapter en fonction le choix de ses librairies en priorisant bien sûr, des modules largement utilisés et maitrisés.

Si ce n’est pas possible, il est recommandé de tester le script dans des environnements cloisonnés et prendre le temps de véritablement comprendre comment vos données critiques sont utilisées (un WireShark ne suffit pas 😊, une backdoor fourbe enverra par exemple vos données une fois tous les 10 du mois).

En attendant, si vous utilisiez ce module, désinstallez-le vite et changez tous vos mots de passe/clés privées SSH.