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

Par Lucian Constantin

Rédacteur principal CSO, CSO |

Les attaquants qui ciblent les référentiels de packages open source tels que PyPI (Python Package Index) ont mis au point une nouvelle technique pour cacher leur code malveillant aux scanners de sécurité, aux révisions manuelles et à d'autres formes d'analyse de sécurité. Lors d'un incident, des chercheurs ont découvert un code malveillant caché dans un fichier de bytecode Python (PYC) qui peut être directement exécuté, contrairement aux fichiers de code source qui sont interprétés par l'environnement d'exécution Python.

"Il s'agit peut-être de la première attaque de la chaîne d'approvisionnement à tirer parti du fait que les fichiers de bytecode Python peuvent être exécutés directement, et elle survient au milieu d'un pic de soumissions malveillantes au Python Package 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 la plupart des outils de sécurité, qui n'analysent que les fichiers de code source Python (PY)."

La grande majorité des packages trouvés sur les référentiels publics tels que npm pour JavaScript, PyPI pour Python et RubyGems pour Ruby consistent en des fichiers de code open source qui sont regroupés dans des archives. Ils sont faciles à décompresser et à lire, et par conséquent, des scanners de sécurité pour ces référentiels ont été conçus pour gérer ce type d'emballage.

Les attaquants sont dans une bataille constante avec les sociétés de sécurité pour échapper à la détection, et la technique d'évasion la plus courante en matière de code en clair est l'obscurcissement. Cela consiste à utiliser des fonctionnalités du langage de programmation lui-même telles que l'encodage, le décodage ou l'évaluation pour rendre le code illisible mais fonctionnel. Par exemple, l'encodage de code malveillant en base64 est une technique couramment 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 la minification - la suppression des espaces et des commentaires du code pour le rendre plus compact mais aussi plus difficile à lire. 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 malveillant obscurci dans les fichiers a été déplacé au-delà des bords de l'écran par défaut, de sorte qu'une personne examinant manuellement le fichier de code source ne le verrait pas.

Cependant, les fichiers PYC sont différents. Ils ne sont pas lisibles par l'homme comme les scripts PY en clair. Les fichiers PYC sont générés lorsque l'interpréteur Python importe ou exécute un script Python. Puisqu'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 d'origine. Cela améliore les performances 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 la plupart des cas de logiciels malveillants PyPI, le code obscurci malveillant est destiné à atteindre 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 détecter les comportements suspects. Dans ce dernier incident, avec un package appelé fshec2 qui s'est avéré contenir un fichier PYC malveillant, 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 conçu pour le décompiler.

"Les scripts de chargement tels que ceux découverts dans le package fshec2 contiennent une quantité minimale de code Python et effectuent une action simple : le chargement d'un module Python compilé", ont déclaré les chercheurs de ReversingLabs. "Il se trouve qu'il s'agit d'un module malveillant. Inspector, l'outil par défaut fourni par l'équipe de sécurité PyPI pour analyser les packages PyPI, ne fournit, pour le moment, aucun moyen d'analyser les fichiers binaires pour détecter les comportements malveillants. Code compilé à partir du Le fichier .PYC devait être décompilé afin d'analyser son contenu."

Le package fshec2 trouvé par ReversingLabs présentait un comportement supplémentaire qui était probablement destiné à échapper à la détection. Normalement, un module est importé à partir d'un script Python à l'aide de la directive import. Cependant, le module PYC malveillant dans ce cas a été chargé à l'aide d'importlib, un package séparé qui implémente la fonctionnalité d'importation et n'est utilisé que dans des cas particuliers, comme lorsqu'une bibliothèque importée est modifiée dynamiquement lors de l'importation. Dans ce cas, le PYC malveillant n'était pas modifié, il n'y a donc aucune raison technique d'utiliser importlib autre que d'éviter d'utiliser la directive d'importation régulière, probablement pour éviter la détection.

Une fois exécutée sur une machine, la charge utile malveillante fshec2 collecte des informations sur le système telles que les noms d'utilisateur, les listes de répertoires et les noms d'hôte, puis configure une tâche cron sous Linux ou une tâche planifiée sous Windows pour exécuter des commandes extraites d'un serveur distant. Les commandes permettent au logiciel malveillant de se mettre à jour automatiquement, les attaquants pouvant fournir une nouvelle version, ainsi que des charges utiles supplémentaires sous la forme de scripts Python.

Les chercheurs de ReversingLabs ont analysé le serveur de commande et de contrôle et ont trouvé des erreurs de configuration qui leur ont permis de consulter certaines informations. Par exemple, ils ont découvert que les machines victimes recevaient un identifiant incrémentiel et ont pu confirmer que le malware avait bien été exécuté par plusieurs victimes.

"Le grand nombre de ces erreurs pourrait nous amener à la conclusion que cette attaque n'était pas l'œuvre d'un acteur parrainé par l'État et non une menace persistante avancée (APT)", ont déclaré les chercheurs. "Bien que mon équipe n'ait pas recueilli suffisamment de preuves pour prouver 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 déterminer que l'attaque a réussi dans certains cas. Nos chercheurs ne peuvent toujours pas dire qui ou quoi les cibles Cependant, nous pouvons confirmer que les développeurs ont installé le package PyPI malveillant et que leurs noms de machine, noms d'utilisateur et listes de répertoires ont été récoltés en conséquence.

Certains des noms de fichiers trouvés sur le serveur suggèrent que les attaquants ont déployé la fonctionnalité d'enregistrement de frappe sur certaines des machines.

"Historiquement, npm a été le leader malheureux 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 déclaré les chercheurs. "Au cours des six derniers mois, cependant, ReversingLabs et d'autres ont observé une augmentation marquée du volume de logiciels malveillants publiés sur PyPI. En fait, en mai, la création de nouveaux comptes d'utilisateurs et de projets sur PyPI a été temporairement suspendue pendant quelques heures en raison à un volume élevé d'activités malveillantes."

ReversingLabs a signalé le nouveau vecteur d'attaque à l'équipe de sécurité de PyPI qui a supprimé le paquet et a déclaré qu'il n'avait jamais vu cette technique d'attaque auparavant. Cela n'exclut pas la possibilité que d'autres packages similaires se retrouvent dans le référentiel.

Pour faire face à ces menaces modernes de la chaîne d'approvisionnement logicielle, les entreprises ont besoin de plus que des solutions d'analyse de code statiques. Ils ont besoin d'outils qui peuvent également surveiller les systèmes de développement sensibles pour la création de processus suspects, l'exécution de fichiers, l'accès URL non autorisé, les commandes de collecte d'informations et l'utilisation de fonctions faciles à abuser comme get_path ou importlib.

Lucian Constantin est rédacteur principal au CSO, couvrant la sécurité de l'information, la confidentialité et la protection des données.

Copyright © 2023 IDG Communications, Inc.