Romain Leclaire

Tech et Culture Numérique

Des packages invisibles - La nouvelle arme des hackers pour contaminer vos projets open source

Des packages invisibles - La nouvelle arme des hackers pour contaminer vos projets open source

La cybersécurité vit une période troublante. Des chercheurs de la firme Aikido Security ont révélé hier une campagne d'attaque particulièrement sophistiquée visant les dépôts de code open source, avec une technique jusqu'ici rarement vue à cette échelle, l'utilisation de caractères Unicode totalement invisibles pour dissimuler du code malveillant.

Entre les 3 et le 9 mars derniers, pas moins de 151 packages malveillants ont été uploadés sur GitHub, NPM et le marketplace VS Code. En apparence, rien d'anormal. En réalité, une menace redoutable se cachait dans ces lignes de code. Les attaques par supply chain, ou attaques de la chaîne d'approvisionnement, ne sont pas nouvelles. Depuis une dizaine d'années, des groupes malveillants publient régulièrement des packages qui imitent des bibliothèques populaires, dans l'espoir que des développeurs les intègrent par erreur dans leurs projets. Certains de ces packages frauduleux ont été téléchargés des milliers de fois avant d'être détectés.

Ce qui change cette fois, c'est la méthode. Le groupe à l'origine de cette campagne (baptisé Glassworm par les chercheurs d'Aikido) a recours à des caractères Unicode issus des zones dites "Public Use Areas". Ces plages de caractères, réservées au départ à la définition d'emojis, de drapeaux et d'autres symboles, représentent chaque lettre de l'alphabet latin lorsqu'elles sont interprétées par un ordinateur. Mais pour l'œil humain ? Elles sont absolument invisibles.

Ce que vous voyez n'est pas ce que la machine exécute

Concrètement, un développeur qui inspecte l'un de ces packages ne verra rien de suspect. Les éditeurs de code, les terminaux, les interfaces de revue de code, tous affichent ces caractères comme de simples espaces ou des lignes vides. Aucune alerte, aucun signal d'alarme. Pourtant, lors de l'exécution du code JavaScript, un petit décodeur intégré dans le package extrait les vrais octets cachés derrière ces caractères fantômes, puis les transmet à la fonction eval(), l'équivalent d'un interrupteur qui déclenche le code malveillant. Dans des incidents antérieurs, ce payload décodé allait chercher un script de second niveau, capable de voler des tokens, des identifiants et des secrets stockés sur la machine. La qualité des parties visibles du code rend la menace encore plus difficile à détecter. Les commits accompagnant ces packages ressemblent à des contributions tout à fait légitimes: corrections de bugs, ajustements de documentation, légères refactorisations. Rien ne trahit une intention malveillante à première lecture.

L'IA au service des attaquants

Les chercheurs soupçonnent fortement que Glassworm utilise des modèles de langage pour générer ces packages à grande échelle. La logique est implacable: concevoir manuellement 151 contributions crédibles, adaptées à des codebases différentes, est humainement impossible dans un délai aussi court. L'intelligence artificielle, en revanche, excelle à produire du code cohérent et convaincant.

Cette technique des caractères Unicode invisibles avait déjà été observée en 2024, d'abord utilisée pour injecter des instructions cachées dans des prompts destinés aux moteurs d'IA. Les LLMs lisaient sans peine ces caractères invisibles et suivaient les instructions qu'ils contenaient. Depuis, le procédé a migré vers les attaques de logiciels traditionnels, avec les effets que l'on constate aujourd'hui.

Comment se protéger ?

La vigilance reste la meilleure arme. Avant d'intégrer un package dans un projet, il est essentiel de vérifier son origine, d'inspecter soigneusement son nom pour détecter d'éventuelles fautes de frappe, et d'auditer ses dépendances. Les outils d'analyse statique classiques ne suffiront plus face à du code rendu volontairement invisible. À mesure que les attaquants s'appuient davantage sur l'IA pour produire des packages d'apparence irréprochable, la prudence des développeurs devient plus que jamais un rempart indispensable.

Commentaires