Les acteurs de la menace utilisent une attaque appelée « Revival Hijack », où ils enregistrent de nouveaux projets PyPI en utilisant les noms de packages précédemment supprimés pour mener des attaques sur la chaîne d’approvisionnement.
La technique « pourrait être utilisée pour détourner 22K packages PyPI existants et conduire par la suite à des centaines de milliers de téléchargements de packages malveillants », affirment les chercheurs.
Détournement de projets populaires
« Revival Hijack » est un vecteur d’attaque qui consiste à enregistrer un nouveau projet avec le nom d’un package qui a été supprimé de la plateforme PyPI. Ce faisant, un auteur de menace pourrait envoyer du code malveillant aux développeurs qui extraient des mises à jour.
L’attaque est possible car PyPI met immédiatement à disposition pour enregistrement les noms des projets Python supprimés.
Les développeurs qui décident de supprimer un projet de PyPI ne reçoivent qu’un avertissement sur les conséquences potentielles, y compris le scénario d’attaque Revival Hijack.
« La suppression de ce projet rendra le nom du projet accessible à tout autre utilisateur de PyPI”, prévient la boîte de dialogue.
« Cet utilisateur pourra faire de nouvelles versions sous ce nom de projet, tant que les noms de fichiers de distribution ne correspondent pas aux noms de fichiers d’une distribution précédemment publiée.”
Selon des chercheurs de JFrog, une plate-forme de chaîne d’approvisionnement logicielle, il y a plus de 22 000 paquets supprimés sur PyPI qui sont vulnérables à l’attaque Revival Hijack, et certains d’entre eux sont très populaires.
Les chercheurs disent que la moyenne mensuelle des paquets supprimés sur PyPI est de 309, indiquant un flux constant de nouvelles opportunités pour les attaquants.
JFrog indique qu’un développeur peut décider de supprimer son package pour diverses raisons, allant du script qui n’est plus nécessaire à la réécriture d’un outil et à sa publication sous un nouveau nom.
Dans certains cas, le package devient redondant car ses fonctionnalités sont introduites dans des bibliothèques officielles ou des API intégrées.
Le cas de » pingdomv3”
À la mi-avril, JFrog a observé un détournement de relance exploité dans la nature, lorsqu’un acteur menaçant a ciblé le « pingdomv3 » – une implémentation du service de surveillance de site Web de l’API Pingdom.
Le package a été supprimé le 30 mars, mais un nouveau développeur a détourné le nom et publié une mise à jour le même jour, indiquant que les attaquants étaient au courant du problème.
Dans une mise à jour ultérieure, le package incluait un cheval de Troie Python masqué à l’aide de Base64 et ciblant les environnements Jenkins CI/CD.
JFrog saute à la rescousse
Les chercheurs de JFrog ont pris des mesures pour atténuer le risque d’attaques de détournement de relance en créant de nouveaux projets Python avec les noms des packages les plus populaires déjà supprimés.
JFrog explique que PyPI maintient une liste de blocage non publique qui empêche certains noms d’être enregistrés sur de nouveaux projets, mais la plupart des packages supprimés ne figurent pas sur cette liste.
Cela a conduit l’entreprise de sécurité à prendre des mesures indirectes pour atténuer la menace de « détournement de relance » et a enregistré le plus populaire des packages supprimés/vulnérables sous un compte nommé security_holding.
Les packages abandonnés sont vides et les chercheurs ont changé les numéros de version en 0.0.0.1, pour s’assurer que les utilisateurs actifs ne tirent pas de mise à jour.
Cette action réserve essentiellement les noms des paquets et empêche les acteurs malveillants de les détourner à des fins néfastes.
Trois mois plus tard, JFrog a remarqué que les packages de son référentiel comptaient près de 200 000 téléchargements à partir de scripts automatisés et d’erreurs de saisie utilisateur.
Le cas du “détournement de relance » est beaucoup plus dangereux que les attaques standard de typosquattage sur PyPI, car les utilisateurs qui tirent une mise à jour pour leurs projets sélectionnés ne font pas d’erreur.
Pour atténuer la menace, les utilisateurs et les organisations peuvent utiliser l’épinglage de packages pour rester sur des versions spécifiées, connues pour être dignes de confiance, vérifier l’intégrité du package, auditer son contenu et rechercher des changements dans la propriété du package ou une activité de mise à jour atypique.