Trojan-Source-Angriffe in JavaScript-Codebasen mit ESLint effektiv erkennen und entschärfen

Am 1. November 2021 beschrieb die öffentliche Veröffentlichung einer Arbeit mit dem Titel Trojan Source: Unsichtbare Schwachstellen, wie Angreifer Unicode-Steuerzeichen für bidirektionalen Text einsetzen können, um schädlichen Quellcode in eine ansonsten unbedenkliche Codebasis einzuschleusen. Bei diesem Angriff werden Reviewer dazu gebracht, den verschleierten schädlichen Quellcode mit Kommentaren zu verwechseln.

Das folgende Snippet aus VS Code zeigt einen Trojan-Source-Angriff in JavaScript-Quellcode:

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

Und wie sieht es jetzt mit diesem Screenshot aus:

Haben Sie das Problem im obigen Quellcode entdeckt? Falls nicht, sehen Sie sich das Code-Snippet noch einmal genauer an.

Was hier passiert: Es handelt sich um einen Angriff vom Typ Stretched String. Der Code in Zeile 3 erweckt den Eindruck, als prüfe der bedingte Ausdruck, ob die Variable accessLevel dem Wert user entspricht. Am Ende der Zeile steht ein Kommentar zu Logikprüfungen, der harmlos wirken mag. Tatsächlich sieht es jedoch ganz anders aus.

Tatsächlich wird der echte Zeichenfolgenwert der Prüfung der Variable accessLevel durch bidirektionale Unicode-Zeichen in Zeile 3 verschleiert. So sieht die tatsächliche Zeile 3 aus, die der Compiler ausführt:

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

Die Arbeit beschreibt verschiedene Arten, bidirektionale Steuerzeichen zu missbrauchen, um schädlichen Code in Quellcode einzuschleusen: Commenting-Out, Stretched String, Invisible Functions und Homoglyph Function. Die Forschenden haben JavaScript-Beispiele für alle diese Angriffe bereitgestellt, die über dieses trojan-source-Repository auf GitHub ausgeführt werden.

Der Einsatz bidirektionaler Steuerzeichen ist zwar neu, aber diese Art von Angriff ist nicht wirklich neu und wurde bereits in früheren Mailinglisten und Diskussionsforen erwähnt. Beispiele dafür sind dieser Golang-Issue aus dem Jahr 2017 zum Verbot von RTL-/LTR-Zeichen oder dieser Bugzilla-Eintrag aus dem Jahr 2011 mit dem Titel [BiDi] Irreführende Darstellung bidirektionaler Zeichenfolgen bei Verwendung von RLO, LRO oder PDF (Hinweis: Der Eintrag ist über Google Cache zugänglich).

Trojan-Source-Angriffe im Quellcode erkennen

Ihre Codebearbeitungs- und Code-Review-Prozesse finden möglicherweise auf Plattformen oder mit Tools statt, die diese gefährlichen bidirektionalen Unicode-Zeichen nicht hervorheben können. Das bedeutet, dass sich solche bidirektionalen Zeichen möglicherweise bereits in Ihrer Codebasis befinden.

Wie finden Sie also heraus, ob Ihr Quellcode bidirektionale Unicode-Zeichen enthält? Dafür habe ich ein npm-Paket namens anti-trojan-source entwickelt. Es scannt ein Verzeichnis oder liest Eingaben über die Standardeingabe (STDIN) ein und sucht im Text nach solchen Unicode-Zeichen.

Mit npx können Sie Dateien wie folgt scannen:

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

Oder Sie verwenden das Paket als Bibliothek in einem JavaScript-Projekt:

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

Trojan-Source-Angriffe in JavaScript mit ESLint verhindern

Hinweis der Redaktion: Seit der Erstveröffentlichung dieses Beitrags wurden Trojan-Source-Regeln zu Snyk Code hinzugefügt. Erfahren Sie mehr in unserem Blogbeitrag So verhindern Sie Trojan-Source-Angriffe mit Snyk Code.

Noch besser, als vorhandene Probleme nur aufzuspüren, ist es, Ihre Codebasis proaktiv abzusichern und so zu verhindern, dass Trojan-Source-Angriffe überhaupt in Ihren Quellcode gelangen. In der JavaScript-Community verlassen wir uns häufig auf ESLint und seine verschiedenen Plugins, um Standards für Codequalität und Codestil durchzusetzen.

Mit eslint-plugin-anti-trojan-source können Sie jetzt auch ein ESLint-Plugin einbinden, das sicherstellt, dass weder Ihre Entwickler noch Ihre CI- und Build-Systeme versehentlich Code zusammenführen, der durch bidirektionale Unicode-Zeichen potenziell schädlich ist.

Hier sehen Sie eine Beispielkonfiguration für ESLint in einem JavaScript-Projekt:

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

Und hier eine Beispielausgabe für ein anfälliges Code-Snippet, das in die Codebasis gelangt ist:

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

Wie geht das Ökosystem gegen Trojan-Source-Angriffe vor?

IDEs wie VS Code haben Versionen veröffentlicht, die diese Unicode-Zeichen hervorheben, damit Programmierer darauf aufmerksam werden und beim Prüfen und Bearbeiten von Code den richtigen Kontext berücksichtigen. Ebenso hat GitHub Warnungen veröffentlicht, sodass visuell dargestellte Codebasen nun die Verwendung dieser potenziell gefährlichen Trojaner auf GitHub hervorheben, wenn bidirektionale Zeichen darin vorkommen:

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

Beachten Sie jedoch, dass GitHub nicht alle Arten von Trojaner-Malware-Angriffen hervorhebt. Betrachten Sie beispielsweise den folgenden Fall, den die Arbeit beschreibt und als Invisible Functions bezeichnet:

Wie Sie im obigen JavaScript-Code-Snippet sehen, zeigt GitHub beim Prüfen dieses Codes keine Warnungen an. Was passiert hier tatsächlich?

Die Funktionsdeklaration in Zeile 7 enthält tatsächlich ein Unicode-Steuerzeichen für ein Leerzeichen der Breite null, gekennzeichnet als U200B. Dadurch sieht sie optisch wie eine legitime Funktion function isAdmin() aus.

Wir können das überprüfen, indem wir den Code mit einem Tool wie bat ausgeben. Dabei handelt es sich um einen Klon des UNIX-cat-Tools mit besserer Syntaxhervorhebung und Git-Integration:

Einige Sprachlaufzeiten wie Zig haben dagegen in Erwägung gezogen, bei der Erkennung bidirektionaler Unicode-Zeichen im Quellcode einen Compilerfehler auszugeben und das Umgehen dieser Fehler durch einen expliziten Kommentar zu ermöglichen.

Ressourcen zu Trojan-Source-Angriffen

Ich hoffe, dieser Beitrag hat Ihnen geholfen, Trojan-Source-Angriffe und ihre möglichen Auswirkungen auf das JavaScript-Ökosystem zu verstehen. Wenn Sie mehr über diese Angriffe erfahren möchten, empfehle ich Ihnen die folgenden Ressourcen:

1. Blogbeitrag: So verhindern Sie Trojan-Source-Angriffe mit Snyk Code

2. Die offizielle Website zu Trojan Source: https://www.trojansource.codes

3. Das offizielle Trojan-Source-Repository mit Codebeispielen und Proofs of Concept: https://github.com/nickboucher/trojan-source

4. Der offizielle Ankündigungs-Blogbeitrag zu Trojan Source:  https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities