Des attaquants ont exploité une vulnérabilité d’injection de script via GitHub Actions et poussé du code malveillant dans la bibliothèque Ultralytics AI dans Python servant à concevoir des modèles de vision par ordinateur.
Les utilisateurs d’Ultralytics doivent redoubler de vigilance. Des attaquants ont réussi à compromettre avec du code malveillant des paquets YOLO publiés sur PyPI, l’index officiel des paquets Python. Ce n’est pas un petit projet : YOLO (algorithme de détection d’objet) compte plus de 30 000 étoiles et plus de 6 000 forks sur GitHub et les paquets PyPI concernés ont cumulé près de 60 millions de téléchargements. Le code a servi a déployé un malware de minage de crypto-monnaie sur les systèmes ayant installé le paquet, mais les attaquants auraient pu diffuser n’importe quel type de logiciel malveillant. Selon les chercheurs de ReversingLabs, les pirates ont tiré parti d’un exploit connu via GitHub Actions pour introduire leur code au cours du processus de construction automatisé, contournant ainsi le processus habituel d’examen de revue. En conséquence, le code n’était présent que dans le paquetage poussé vers PyPI et non dans le dépôt sur GitHub.
La version trojanisée d’Ultralytics sur PyPI (8.3.41) a été publiée le 4 décembre. Les développeurs d’Ultralytics ont été alertés le 5 décembre et ont tenté de publier une nouvelle version (8.3.42) pour résoudre le problème, mais comme ils n’avaient pas compris la source de la compromission, cette version a fini par inclure également le code vérolé. Une version propre et sûre (8.3.43) a finalement été publiée le même jour. « Contrairement à la récente compromission d’un paquet npm de confiance @solana/web3.js, qui a également eu un rayon d’impact similaire, mais qui a été causée par la compromission de l’un des comptes du mainteneur, dans ce cas, l’intrusion dans l’environnement de construction a été réalisée par un vecteur plus sophistiqué, en exploitant une GitHub Actions Script Injection connue qui a été précédemment signalée par le chercheur en sécurité Adnan Khan », ont écrit les experts de ReversingLab dans leur rapport.
Régression d’une vulnérabilité précédemment corrigée
GitHub Actions est un service CI/CD servant aux utilisateurs de GitHub à automatiser la construction et le test du code logiciel en définissant des flux de travail qui s’exécutent automatiquement à l’intérieur de conteneurs sur l’infrastructure de GitHub ou de l’utilisateur. Les flux d’actions GitHub sont une série de processus ou d’« actions » définis dans des fichiers .yml à l’intérieur des dépôts qui sont exécutés lorsque certains événements déclencheurs se produisent, par exemple lorsqu’un nouveau code est livré dans le dépôt. Il est courant que les développeurs travaillent sur leurs propres forks (versions) et soumettent ensuite les correctifs au projet principal par le biais de pull requests. Par défaut, tout le monde peut forker un projet et soumettre des demandes d’extraction, ce qui signifie que les propriétaires de projets doivent être très prudents quant à la manière dont ils utilisent GitHub Actions, notamment en ce qui concerne les actions et les déclencheurs qu’ils autorisent. Le chercheur en sécurité Adnan Khan a l’habitude d’enquêter et de trouver des problèmes de sécurité liés à ces environnements. En août, il a signalé à Ultralytics une vulnérabilité d’injection de script qui pouvait déjà entraîner l’exécution d’un code arbitraire dans le contexte du flux de travail, ce qui a été corrigé par la suite. Cependant, une régression a été introduite par la suite. « Il semble que le point d’injection exploité par l’acteur de la menace ait été introduit dans ultralytics/actions@c1365ce. 10 jours après la publication par Ultralytics de l’avis relatif à la première vulnérabilité », a écrit M. Khan dans le fil de commentaires relatif à cette dernière compromission.
Les attaquants semblent également avoir utilisé une technique d’empoisonnement de cache pour persister dans leurs modifications via GitHub Actions que M. Khan avait documenté en mai dernier sur son blog personnel. Selon l’analyse du code malveillant par ReversingLabs, l’attaquant a modifié deux fichiers : downloads.py et model.py. Le code injecté dans model.py vérifie le type de système sur lequel le paquet est déployé afin de télécharger une charge utile destinée à cette plateforme et à son architecture processeur. Le code malveillant effectuant le téléchargement de la charge utile est stocké dans downloads.py. « Bien que dans ce cas, sur la base des informations actuelles dont dispose l’équipe de recherche de RL, il semble que cette charge malveillante servie était simplement un mineur XMRig, et que la fonctionnalité de hack était destinée au minage de crypto-monnaie », écrivent les chercheurs de ReversingLabs. « Mais il n’est pas difficile d’imaginer l’impact potentiel et les dommages si les acteurs de la menace décidaient d’implanter des logiciels malveillants plus agressifs comme des portes dérobées ou des trojans d’accès à distance (RAT). » Le rapport de ReversingLabs inclut des indicateurs de compromission et des hachages de fichiers pour détecter l’infection. Les systèmes qui ont déployé Ultralytics 8.3.41 et 8.3.42 devraient faire l’objet d’un audit de sécurité.
Un rapport de Netscout révèle qu’un regain d’activité des hacktivistes est à l’origine de la forte augmentation des attaques par déni de service distribué visant à saturer et à submerger les ressources des gouvernements, des services publics et des services financiers.
Selon une dernière enquête de Netscout, les secteurs des infrastructures critiques, notamment les banques, les services financiers, les administrations et les services publics tels que les fournisseurs d’énergie, ont connu une augmentation de 55 % des attaques par déni de service distribué (DDoS) au cours des quatre dernières années. Publié quelques jours seulement après la révélation par Cloudflare de l’attaque DDoS la plus importante de l’histoire à 3,8 Tb/s, le rapport de Netscout révèle que…
Il vous reste 95% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Des chercheurs en sécurité de watchTowr ont récemment démontré comment des pirates pouvaient abuser de Whois pour obtenir des certificats délivrés frauduleusement pour des domaines dont ils ne sont pas propriétaires. Une situation qui a fait réagir Google qui veut interdire ce répertoire pour identifier les contacts de domaine à partir du 1er novembre 2024.
Le célèbre annuaire de noms de domaine Whois de l’Icann pour retrouver l’identité et les coordonnées de ceux qui détiennent ces noms de domaine (nom et prénom, adresse postale, téléphone et email) est bien malgré lui sous le feu des projecteurs. Des chercheurs en sécurité de de watchTowr ont découvert récemment que certains serveurs de courrier électronique et autorités de certification (AC) s’appuient sur des enregistrements périmés pour les…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Des chercheurs ont trouvé un moyen, via des clés de test, de rendre inutile la fonction Secure Boot lors du démarrage des systèmes d’exploitation. Plusieurs modèles de PC et de serveurs sont concernés par la faille baptisée PKfail.
Des chercheurs en sécurité avertissent que certains fabricants de PC et de serveurs utilisent des clés cryptographiques non sécurisées comme base de confiance pour Secure Boot, une fonction de sécurité importante dans les ordinateurs modernes qui empêche les malwares de s’activer au début du processus de démarrage. L’une de ces clés a fait l’objet d’une fuite accidentelle, ce qui risque de rompre les garanties de démarrage sécurisé pour des centaines de modèles d’ordinateurs provenant de sept fabricants. Cependant, près de 900 modèles au cours des 12 dernières années utilisent des clés qui ont probablement été générées à des fins de test et qui n’auraient jamais dû être utilisées en production, selon un rapport de la société de sécurité Binarly, qui a baptisé ce problème PKfail. Au début de l’année, nous avons remarqué que la clé privée d’American Megatrends International (AMI) liée à la « clé principale » de Secure Boot, appelée Platform Key (PK), avait été exposée publiquement dans une fuite de données », écrivent les chercheurs. « L’incident s’est produit chez un ODM [original design manufacturer] responsable du développement de microprogrammes pour de nombreux fournisseurs de terminaux, y compris un basé aux États-Unis. Ces équipements correspondant à cette clé sont toujours déployés sur le terrain, et la clé est également utilisée dans des terminaux d’entreprise récemment mis sur le marché. »
Secure Boot est une fonctionnalité de l’UEFI (Unified Extensible Firmware Interface), qui a succédé au BIOS (Basic Input/Output System) traditionnel présent sur les anciens ordinateurs. En principe, le Secure Boot garantit que le système ne démarre qu’avec des logiciels et des firmwares fiables. Il est essentiel de garantir l’intégrité du processus de démarrage, car les codes malveillants qui s’exécutent à ce stade précoce prennent le contrôle total du système d’exploitation, en désactivant ou en contournant ses fonctions de sécurité. Avant que le système Secure Boot ne soit largement adopté, de nombreux malwares injectaient du code dans le chargeur de démarrage des ordinateurs compromis ou dans le BIOS/UEFI lui-même. Ces bootkits – rootkits au niveau du démarrage – donnent aux attaquants une persistance de haut niveau sur les systèmes compromis et la possibilité de cacher des fichiers et des processus à tous les produits de sécurité des points finaux fonctionnant sur ces systèmes. Secure Boot utilise le chiffrement à clé publique, celles-ci sont stockées dans l’UEFI étant utilisées pour valider les composants signés avec les clés privées correspondantes. Au cœur du système se trouve une clé publique appelée « Platform Key » : cette dernière est censée être générée par le fabricant de l’ordinateur et, selon les chercheurs de Binarly, devrait être renouvelée périodiquement et, idéalement, ne pas être réutilisée d’une ligne de produits à l’autre afin de limiter l’impact d’une compromission. En outre, la clé privée doit être stockée en toute sécurité dans des modules de sécurité matériels (HSM), d’où elle ne peut pas être facilement volée ou divulguée.
Une clé privée racine qui n’a rien à faire dans un dépôt public GitHub
En aucun cas la clé privée racine d’un dispositif de sécurité aussi important ne devrait se retrouver dans un dépôt public sur GitHub, comme l’a fait la clé de la plateforme AMI trouvée par Binarly. Ce n’est pas le seul problème. AMI est l’un des trois fournisseurs de BIOS indépendants (IBV) qui produisent des implémentations UEFI de référence pour les fabricants de PC et les OEM, qui personnalisent ensuite ces implémentations pour leurs produits. Binarly estime que la génération de nouvelles clés de plateforme devrait faire partie de ce processus de personnalisation, car ce sont les fabricants de PC qui devraient être responsables de leurs « plateformes », et non une tierce partie. Le certificat de clé publique de la clé privée qui a fait l’objet d’une fuite comporte un champ Common Name qui indique « DO NOT TRUST – AMI Test PK » (ne pas faire confiance – AMI Test PK). Pourtant, il a été utilisé dans des centaines de modèles de sept fournisseurs différents.
« Cette clé a probablement été incluse dans leur implémentation de référence en espérant qu’elle serait remplacée par une autre clé générée en toute sécurité par les entités en aval de la chaîne d’approvisionnement », écrivent les chercheurs. « Les clés de test sont partagées avec des partenaires commerciaux et des fournisseurs en espérant qu’elles soient traitées comme des clés non fiables. En outre, la clé AMI qui a fait l’objet d’une fuite a été utilisée dans de nombreuses gammes de produits, des ordinateurs portables de jeu aux cartes mères de serveurs, ce qui accroît considérablement l’impact de la fuite dans tous les secteurs et pour tous les types d’utilisateurs.
Comment les attaquants peuvent-ils abuser de la clé divulguée ?
Secure Boot dispose de quatre emplacements de clés et de bases de données dans l’UEFI. La clé de plateforme, utilisée pour valider tous les composants du microprogramme, et une autre clé, appelée clé d’échange de clés (KEK), sont au cœur de ce système. La KEK peut servir pour mettre à jour une base de données appelée db, qui contient les signatures des chargeurs d’amorçage et d’autres composants EFI tiers autorisés à être exécutés, par exemple le chargeur d’amorçage Windows ou celui de Linux. Il peut également actualiser dbx, une base de données qui contient une liste noire de signatures, par exemple pour les bootloader vulnérables. Un attaquant disposant d’un accès privilégié au système d’exploitation d’un ordinateur qui exploite la fuite de PK peut générer une autre KEK, puis la signer et l’insérer dans l’emplacement KEK à l’aide d’outils tels que efi-updatevar. Il peut ensuite se servir de sa nouvelle clé pour modifier la base de données de signatures db afin d’y ajouter la signature d’un module .efi malveillant qu’il a créé et placé dans la partition EFI sur le disque. Ce module sera alors exécuté à l’amorçage, ce qui lui permettra de contrôler le démarrage et le noyau de Windows.
Les attaquants exploitent déjà les vulnérabilités connues de Secure Boot pour déployer des bootkits. L’année dernière, des chercheurs d’ESET ont mis en garde contre un nouveau bootkit UEFI appelé BlackLotus qui exploite une vulnérabilité de Windows connue sous le nom de Baton Drop (CVE-2022-21894) pour contourner la fonction via des composants de chargeur d’amorçage vulnérables. Il ne serait donc pas surprenant que des attaquants commencent à exploiter une fuite de la clé de plateforme. Il y a deux ans, des chercheurs d’Eclypsium ont découvert des vulnérabilités qui pouvaient être utilisées pour contourner Secure Boot, tandis que Binarly a présenté 12 autres failles qui pouvaient conduire à l’exécution de code à distance avant le démarrage dans les implémentations UEFI. La possibilité que le PK de test AMI soit tombé entre de mauvaises mains n’est pas à exclure. Selon les chercheurs de Binarly, le dépôt contenant la clé a été supprimé au bout de quatre mois, mais il a fallu cinq mois pour supprimer tous les forks. La clé privée n’était pas stockée en clair et était chiffrée, mais protégée uniquement par un mot de passe de quatre caractères qui pouvait être déchiffré en quelques secondes à l’aide d’outils de reconnaissance de mot de passe basique.
L’utilisation de clés de plateforme AMI de test dans les binaires des microprogrammes est courante.
Après avoir trouvé la clé divulguée, les experts ont découvert des rapports datant de 2016 selon lesquels certaines clés de plateforme contiennent des mots tels que « NE PAS FAIRE CONFIANCE » et « clé de test. » Il y avait même un identifiant de vulnérabilité (CVE-2016-5247) généré à l’époque pour plusieurs modèles Lenovo utilisant des clés de test AMI. Mais la clé qui a fait l’objet d’une fuite a été trouvée dans des micrologiciels publiés dès 2018 et plus récemment cette année. Pour savoir si la pratique est encore courante, les spécialistes de Binarly ont analysé leur base de données de dizaines de milliers de binaires de micrologiciels collectés au fil des ans et ont identifié 22 PK de test AMI différentes avec des avertissements « DO NOT TRUST » ou « DO NOT SHIP ». Ces clés ont été trouvées dans des binaires de microprogrammes UEFI pour près de 900 cartes mères d’ordinateurs et de serveurs différents provenant de plus de 10 fournisseurs, dont Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo et Supermicro. Ensemble, ils représentaient plus de 10 % des images de microprogrammes de l’ensemble de la base.
Ces clés ne sont pas fiables, car elles ont probablement été partagées avec de nombreux fournisseurs, OEM, ODM et développeurs – et ont probablement été stockées de manière non sécurisée. Il est possible que certaines d’entre elles aient déjà fait l’objet d’une fuite ou d’un vol dans le cadre d’incidents non découverts. L’année dernière, un dump de données publié par un cybergang relatif au fabricant de cartes mères et d’ordinateurs Micro-Star International (MSI) comprenait une clé privée OEM d’Intel et, un an plus tôt, une fuite de données de Lenovo comprenait le code source d’un micrologiciel et les clés de signature Intel Boot Guard.
Binarly a mis en place un scanner en ligne permettant aux utilisateurs de soumettre des copies du micrologiciel de leur carte mère afin de vérifier s’il utilise une clé de test, et une liste des modèles de cartes mères concernés est incluse dans le bulletin de l’entreprise. Malheureusement, les utilisateurs ne peuvent pas faire grand-chose tant que les vendeurs n’ont pas fourni de mises à jour du micrologiciel avec de nouvelles clés de test générées de manière sécurisée, en supposant que les modèles de leurs cartes mères soient encore pris en charge. La première utilisation de ces clés de test trouvée par Binarly remonte à 2012.
- 1
- 2