Les attaquants utilisent le bytecode compilé Python pour échapper à la détection

Les attaquants qui ciblent les référentiels de packages open source tels que PyPI ( Python Bundle Index) ont conçu une toute nouvelle stratégie pour dissimuler leur code nuisible aux scanners de sécurité, aux examens manuels et à d’autres types d’analyses de sécurité.

Dans un cas, des chercheurs ont en fait découvert un code malveillant dissimulé dans un Fichier de bytecode Python (PYC) qui peut être exécuté directement par opposition aux fichiers de code source qui sont interprétés par le runtime Python.

 » Il pourrait s’agir de la première attaque de la chaîne d’approvisionnement à tirer parti de la réalité que le bytecode Python les fichiers peuvent être exécutés directement, et cela survient au milieu d’un pic de soumissions nuisibles au Python Plan Index « , ont déclaré des chercheurs de la société de sécurité ReversingLabs dans un rapport.  » Si c’est le cas, cela pose encore un autre risque pour la chaîne d’approvisionnement, car ce type d’attaque est susceptible d’être manqué par de nombreux outils de sécurité, qui se contentent d’analyser les fichiers de code source Python (PY). « 

Code assemblé versus code source

La grande majorité des plans découverts sur des référentiels publics tels comme npm pour JavaScript, PyPI pour Python et RubyGems pour Ruby incluent des fichiers de code open source qui sont regroupés dans des archives. Ils sont faciles à décharger et à lire, et par conséquent, des scanners de sécurité pour ces référentiels ont été développés pour gérer ce type d’emballage.

Les opposants restent dans une lutte continue avec les entreprises de sécurité pour éviter la détection, et les plus La méthode d’évasion typique lorsqu’il s’agit de code en clair est l’obfuscation. Cela inclut l’utilisation de fonctionnalités du langage de programmation lui-même telles que l’encodage, le déchiffrement ou l’évaluation pour rendre le code illisible mais pratique. L’encodage de code destructeur en base64 est une stratégie généralement utilisée, mais les outils de sécurité peuvent gérer un tel encodage.

Dans l’écosystème PyPI, les cybercriminels à l’origine du malware W4SP Stealer sont connus pour utiliser des techniques telles que l’encodage base64, la compression LZMA , et minification– la suppression des espaces et des commentaires du code pour le rendre plus compact mais aussi plus difficile à extraire. Le groupe utilise des outils open source tiers pour y parvenir, tels que pyminifier, Kramer ou Hyperion. Dans une variante des attaques W4SP, le code destructeur masqué dans les fichiers a été déplacé au-delà des bords de l’écran par défaut, de sorte que quelqu’un examinant manuellement le fichier de code source ne le verrait pas.

Néanmoins, PYC les fichiers sont divers. Ils ne sont pas lisibles par l’homme comme les scripts PY en clair. Les fichiers PYC sont créés lorsque l’interpréteur Python importe ou exécute un script Python. Parce qu’ils sont déjà du code interprété (compilé), ils peuvent ensuite être exécutés directement par l’interpréteur Python sans réinterpréter le script initial. Cela contribue à l’efficacité car il a des temps d’exécution plus rapides, et l’utilisation la plus courante de ces fichiers est dans la distribution de modules Python.

Dans de nombreuses circonstances de logiciels malveillants PyPI, le code obscurci malveillant est indiqué pour atteindre vers une URL externe et télécharger le logiciel malveillant (généralement un voleur d’informations), ce qui est une autre opportunité pour les outils de sécurité de repérer les habitudes suspectes. Dans ce dernier événement, avec un plan appelé fshec2 qui s’est avéré inclure un fichier PYC nuisible, la charge utile malveillante complète peut être cachée dans le fichier et il est beaucoup plus difficile de la détecter si l’outil de sécurité n’est pas développé pour le décompiler.

« Les scripts de chargement tels que ceux découverts dans le package fshec2 consistent en une quantité minimale de code Python et effectuent une action simple : le chargement d’un module Python assemblé », ont déclaré les scientifiques de ReversingLabs.  » Il se trouve juste qu’il s’agit d’un module destructeur. Inspector, l’outil par défaut proposé par l’équipe de sécurité PyPI pour analyser les packages PyPI, n’offre, à l’heure actuelle, aucune méthode d’analyse des fichiers binaires pour trouver des habitudes destructrices. Code compilé à partir du. Le fichier PYC devait être décompilé afin d’évaluer son contenu. « 

Le plan fshec2 découvert par ReversingLabs affichait un comportement supplémentaire qui était probablement destiné à échapper à la détection. En règle générale, un module est importé à partir d’un script Python à l’aide de l’instruction d’importation. Néanmoins, le module PYC malveillant dans ce cas a été rempli à l’aide d’importlib, un plan différent qui implémente la fonctionnalité d’importation et est utilisé uniquement pour des cas spécifiques, comme lorsqu’une bibliothèque importée est personnalisée dynamiquement lors de l’importation. Dans ce cas, le PYC destructeur n’a pas été modifié, il n’y a donc aucun facteur technique à utiliser importlib en plus d’éviter d’utiliser la réglementation d’importation de routine, très probablement pour l’évasion de la détection.

La prise d’identifiants semble être le objectif principal

Lorsqu’elle est exécutée sur un appareil, la charge utile destructrice fshec2 rassemble des informations sur le système telles que les noms d’utilisateur, les listes de sites d’annuaire et les noms d’hôte, puis configure une tâche cron sur Linux ou un ensemble up job sous Windows pour exécuter des commandes provenant d’un serveur distant. Les commandes permettent au logiciel malveillant de se mettre à jour automatiquement, les agresseurs ayant la possibilité de fournir une nouvelle version, ainsi que des charges utiles supplémentaires sous la forme de scripts Python.

Les chercheurs de ReversingLabs ont analysé la commande et le contrôle serveur et ont trouvé des erreurs de configuration qui leur ont permis d’entrevoir certains détails. Par exemple, ils ont découvert que les créateurs de victimes se voyaient offrir un identifiant supplémentaire et avaient la possibilité de confirmer que le logiciel malveillant avait certainement été exécuté par un certain nombre de victimes.

 » La grande variété de ces erreurs peut nous conduire à la conclusion que cette attaque n’était pas l’œuvre d’un acteur parrainé par l’État et non un risque persistant sophistiqué (APT) », ont déclaré les chercheurs.  » Bien que mon équipe n’ait pas rassemblé de preuves adéquates pour montrer cette hypothèse d’une manière ou d’une autre, la récolte des noms de fichiers en incrémentant l’ID de fichier nous a permis de comprendre que l’attaque a parfois réussi. Nos scientifiques ne peuvent toujours pas dire qui ou quelles étaient les cibles. . Cependant, nous pouvons valider que les développeurs ont installé le bundle PyPI nuisible et que leurs noms d’appareils, noms d’utilisateur et listes de répertoires ont été collectés en conséquence. « 

Certains des noms de fichiers trouvés sur le serveur recommandent que le les agresseurs ont déployé des performances d’enregistrement de frappe sur certaines des machines.

« Historiquement, npm a été le leader regrettable et PyPI a également couru dans la course pour voir quelle plate-forme open source attirait le plus l’attention des auteurs de logiciels malveillants », ont dit les scientifiques.  » Au cours des 6 derniers mois, néanmoins, ReversingLabs et d’autres ont observé une augmentation significative du volume de logiciels malveillants publiés sur PyPI. En réalité, en mai, la création de tout nouveaux comptes d’utilisateurs et de tâches sur PyPI a été temporairement suspendue pendant quelques d’heures en raison d’un volume élevé d’activités nuisibles. « 

ReversingLabs a signalé le nouveau vecteur d’attaque à l’équipe de sécurité PyPI qui a éliminé le paquet et a déclaré qu’il n’avait jamais vu cette méthode d’attaque auparavant. Cela n’exclut pas la possibilité que d’autres offres groupées comparables fassent leur chemin dans le référentiel.

Pour gérer ces aléas de la chaîne d’approvisionnement logicielle moderne, les organisations ont besoin de plus que des options d’analyse de code statique. Ils ont besoin d’outils qui peuvent également suivre les systèmes d’avancement délicats pour la création de procédures suspectes, l’exécution de fichiers, l’accès non autorisé aux URL, les commandes d’événements d’information et l’utilisation de fonctions faciles à abuser comme get_path ou importlib.