Comment détecter et atténuer efficacement les attaques Trojan Source dans les bases de code JavaScript avec ESLint

Le 1er novembre 2021, la publication d’un article intitulé Trojan Source: Invisible Vulnerabilities a décrit comment des acteurs malveillants pouvaient utiliser des caractères de contrôle bidirectionnels Unicode pour insérer du code source malveillant dans une base de code apparemment inoffensive. Cette attaque repose sur la confusion des personnes chargées de la revue, qui prennent le code source malveillant obfusqué pour des commentaires.

Voici un extrait affiché dans VS Code illustrant une attaque Trojan Source dans du code source JavaScript :

1// running internal logic for privileged users:
2var accessLevel = "user";
3if (accessLevel != "user‮ ⁦// Check if admin⁩ ⁦") {
4    console.log("You are an admin.");
5}

Et avec cette capture d’écran ?

Avez-vous repéré le problème dans le code source ci-dessus ? Si ce n’est pas le cas, examinez l’extrait de code d’un peu plus près.

Voici ce qui se passe : il s’agit d’une attaque de type Stretched String. Le code de la ligne 3 donne l’impression que l’expression conditionnelle vérifie si la variable accessLevel est égale à la valeur user. Un commentaire en fin de ligne semble évoquer des vérifications logiques et paraît inoffensif, mais la réalité est tout autre.

En réalité, l’utilisation de caractères bidirectionnels Unicode à la ligne 3 dissimule la véritable valeur de chaîne utilisée lors de la vérification de la variable accessLevel. Voici la véritable ligne 3, telle qu’elle est interprétée par le compilateur :

1If (accessLevel != "user // Check if admin") {

L’article décrit plusieurs façons d’exploiter les caractères de contrôle bidirectionnels pour injecter du code malveillant dans une source : Commenting-Out, Stretched String, Invisible Functions et Homoglyph Function. Les chercheurs ont fourni des exemples JavaScript de toutes ces attaques dans le dépôt trojan-source sur GitHub.

Bien que l’utilisation de caractères de contrôle bidirectionnels soit une approche novatrice, ce type d’attaque n’est pas nouveau : il a déjà été évoqué dans des listes de diffusion et des forums de discussion. On peut notamment citer cette discussion Golang de 2017 sur l’interdiction des caractères RTL/LTR, ou encore cette entrée Bugzilla de 2011 intitulée [BiDi] Misleading display of bidirectional strings when RLO, LRO or PDF is used (à consulter via Google Cache).

Détecter les attaques Trojan Source dans le code source

Vos outils et processus de modification et de revue de code utilisent peut-être des plateformes qui ne mettent pas en évidence ces caractères bidirectionnels Unicode dangereux. Il se peut donc que votre base de code en contienne déjà.

Comment savoir si votre code source contient des caractères bidirectionnels Unicode ? Pour vous aider, j’ai créé un package npm appelé anti-trojan-source qui analyse un répertoire ou lit les données depuis l’entrée standard (STDIN) afin d’y repérer ces caractères Unicode éventuellement présents dans le texte.

Vous pouvez utiliser npx pour analyser des fichiers comme suit :

1npx anti-trojan-source --files='src/**/*.js'

Ou, si vous souhaitez l’utiliser comme bibliothèque dans un projet JavaScript :

1import { hasTrojanSource } from 'anti-trojan-source'
2const isDangerous = hasTrojanSource({
3  sourceText: 'if (accessLevel != "user) {' // Check if admin
4})

Prévenir les attaques Trojan Source en JavaScript avec ESLint

Note de la rédaction : Depuis la publication initiale de cet article, des règles contre Trojan Source ont été ajoutées à Snyk Code. Pour en savoir plus, consultez notre article How to prevent Trojan Source attacks with Snyk Code.

Mais mieux encore que de repérer les problèmes existants, c’est de protéger proactivement votre base de code pour empêcher toute attaque Trojan Source d’y être introduite. Dans la communauté JavaScript, nous nous appuyons souvent sur ESLint et ses différents plugins pour faire respecter les normes de qualité et de style du code.

Avec eslint-plugin-anti-trojan-source, vous pouvez désormais ajouter un plugin ESLint pour éviter que vos développeurs, vos systèmes d’intégration continue ou vos processus de build ne fusionnent par erreur du code potentiellement malveillant en raison de caractères bidirectionnels Unicode.

Voici un exemple de configuration ESLint pour un projet JavaScript :

1"eslintConfig": {
2    "plugins": [
3        "anti-trojan-source"
4    ],
5    "rules": {
6        "anti-trojan-source/no-bidi": "error"
7    }
8}

Et voici un exemple de résultat pour un extrait de code vulnérable qui s’est retrouvé dans la base de code :

1$ npm run lint
2
3/Users/lirantal/projects/repos/@gigsboat/cli/index.js
4  1:1  error  Detected potential trojan source attack with unicode bidi introduced in this comment: ' begin admins only '  anti-trojan-source/no-bidi if (isAdmin) {
5  1:1  error  Detected potential trojan source attack with unicode bidi introduced in this comment: ' end admin only    anti-trojan-source/no-bidi }
6
7/Users/lirantal/projects/repos/@gigsboat/cli/lib/helper.js
8  2:1  error  Detected potential trojan source attack with unicode bidi introduced in this code: '"user" // Check if admin

Comment l’écosystème lutte-t-il contre les attaques Trojan Source ?

Des IDE comme VS Code ont publié des versions qui mettent en évidence ces caractères Unicode, afin que les développeurs les remarquent et puissent les interpréter correctement lors de la revue et de la modification du code. De même, GitHub a publié des avertissements : les bases de code affichées sur GitHub mettent désormais en évidence l’utilisation de ces caractères Trojan potentiellement dangereux lorsqu’elles contiennent des caractères bidirectionnels :

Source : https://github.com/nickboucher/trojan-source/blob/main/JavaScript/stretched-string.js

Cependant, sachez que GitHub ne met pas en évidence tous les types d’attaques par logiciel malveillant Trojan. Prenons par exemple le cas présenté dans l’article et baptisé Invisible Functions :

Comme vous pouvez le voir dans l’extrait de code JavaScript ci-dessus, GitHub n’affiche aucun avertissement lors de la revue de ce code. Que se passe-t-il réellement ?

La déclaration de fonction à la ligne 7 contient en réalité un caractère de contrôle Unicode d’espace sans chasse, identifié par U200B, qui donne visuellement l’impression qu’il s’agit d’une fonction légitime function isAdmin().

Nous pouvons le vérifier en affichant le code avec un outil comme bat, un clone de l’outil UNIX cat offrant une meilleure coloration syntaxique et une intégration Git :

Cela dit, certains environnements d’exécution, comme Zig, envisagent favorablement de déclencher une erreur de compilation en cas de détection de caractères bidirectionnels Unicode dans le code source, tout en permettant de contourner ces erreurs au moyen d’un commentaire explicite.

Ressources sur les attaques Trojan Source

J’espère que cet article vous a aidé à comprendre les attaques Trojan Source et la manière dont elles peuvent se manifester dans l’écosystème JavaScript. Pour en savoir plus sur ces attaques, je vous recommande les ressources suivantes :

1. Article de blog : comment prévenir les attaques Trojan Source avec Snyk Code

2. Site officiel de Trojan Source : https://www.trojansource.codes

3. Dépôt officiel de Trojan Source avec des exemples de code et des preuves de concept : https://github.com/nickboucher/trojan-source

4. Article officiel annonçant Trojan Source :  https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities