Skip to main content

In this article

Schutz vor Glassworm: Die unsichtbare Malware, die die Supply-Chain-Sicherheit neu schreibt

Artikel von
Headshot of Liran Tal

Liran Tal

0 Min. Lesezeit

Im Oktober 2025 entdeckten Sicherheitsforscher von Koi Security Glassworm, den ersten sich selbst verbreitenden Wurm, der VS-Code-Erweiterungen angreift und unsichtbare Unicode-Zeichen einsetzt, um schädlichen Code direkt vor unseren Augen zu verbergen. Mit mehr als 35.800 kompromittierten Installationen und weiterhin aktiver C2-Infrastruktur markiert Glassworm eine weitere Eskalationsstufe bei Supply-Chain-Angriffen, die unser herkömmliches Sicherheitsmodell für Code-Reviews aushebeln.

Dieser Artikel untersucht den Glassworm-Angriff, zeichnet seine Entwicklung bis zur ursprünglichen Trojan-Source-Sicherheitslücke (CVE-2021-42574) nach und zeigt, wie Entwickler und Sicherheitsteams diese Angriffe mit unsichtbaren Zeichen mithilfe von anti-trojan-source erkennen und verhindern können – einem Open-Source-Kommandozeilentool zur Erkennung, das jetzt Unicode-Analysen nach Kategorien und erweiterte Berichtsfunktionen bietet.

Die wichtigsten Erkenntnisse:

  • Unsichtbare Unicode-Zeichen können ausführbaren Schadcode verbergen, der für Code-Reviewer buchstäblich unsichtbar ist

  • Herkömmliche Code-Reviews, manche Diff-Ansichten und Syntaxhervorhebung können diese Angriffe überhaupt nicht erkennen

  • Der Angriff verbreitet sich mithilfe gestohlener Zugangsdaten selbst weiter und macht jedes Opfer zu einem neuen Infektionsvektor

  • Für die Erkennung sind spezialisierte Tools erforderlich, die Unicode-Zeichen nach Kategorie und nicht nur anhand expliziter Listen analysieren

Die Entwicklung von Angriffen mit unsichtbaren Zeichen

Den Anfang machte das treffend benannte wissenschaftliche Paper Trojan Source. Genau genommen wurden Unicode-Zeichen und Glyphen jedoch schon in früheren Jahrzehnten eingesetzt, um Systeme und Nutzer zu täuschen und zu verwirren. Die Technik ist in ihrem Kern also nicht neu.

Im November 2021 veröffentlichten die Forscher Nicholas Boucher und Ross Anderson von der University of Cambridge ihr wegweisendes Paper Trojan Source: Invisible Vulnerabilities. Darin deckten sie eine kritische Sicherheitslücke (CVE-2021-42574) auf, die praktisch alle modernen Programmiersprachen betrifft.

Das Kernproblem lag in bidirektionalen Unicode-Steuerzeichen (Bidi), die Quellcode visuell umordnen können. So täuschen sie menschliche Reviewer, während die logische Ausführungsreihenfolge erhalten bleibt, der Compiler und Interpreter folgen.

Betrachten Sie diesen C-Code:

bool isAdmin = false;
/*
 begin admins only 
*/ if (isAdmin) {
    printf("You are an admin.\n");
/*
 end admins only 
*/ }

Auf den ersten Blick sieht der obige Code so aus, als sei er durch eine Zugriffskontrolle geschützt. Verborgene Unicode-Steuerzeichen können den Kommentar jedoch so erscheinen lassen, als wäre er Code, und damit den logischen Ablauf vollständig verändern. Der Compiler sieht das eine, der menschliche Reviewer das andere.

Angriffstechniken:

  • Vorzeitige Rückgaben: Eine `return`-Anweisung so aussehen lassen, als befände sie sich innerhalb eines Kommentars

  • Auskommentieren: Kommentare visuell wie ausführbaren Code erscheinen lassen

  • Gestreckte Zeichenfolgen: Zeichenfolgenliterale visuell wie Code erscheinen lassen

  • Homoglyphen: Visuell identische Zeichen aus unterschiedlichen Schriftsystemen verwenden (CVE-2021-42694)

Der Verstärkungseffekt in der Supply Chain

Die Forscher hinter Trojan Source identifizierten den entscheidenden Multiplikatoreffekt in der modernen Softwareentwicklung:

„Wenn es einem Angreifer gelingt, gezielte Sicherheitslücken in Open-Source-Code einzuschleusen, indem er menschliche Reviewer täuscht, übernehmen nachgelagerte Softwareprodukte die Sicherheitslücke wahrscheinlich ebenfalls.“

Genau das beobachten wir heute bei realen Angriffen.

Glassworm: Die nächste Entwicklungsstufe (2025)

Vier Jahre nach der Offenlegung von Trojan Source setzen Angreifer diese Techniken nun in freier Wildbahn ein. Im Oktober 2025 trat Glassworm auf – der erste sich selbst verbreitende Wurm, der unsichtbare Unicode-Zeichen nutzt, um VS-Code-Erweiterungen auf dem OpenVSX-Marktplatz zu kompromittieren.

Was Glassworm besonders macht:

  1. Unsichtbare Code-Injektion: Nutzt Unicode-Variationsselektoren, die keine sichtbare Ausgabe erzeugen. Der Code ist weder verschleiert noch minimiert, sondern für das menschliche Auge buchstäblich unsichtbar

  2. Selbstverbreitung: Stiehlt NPM-, GitHub- und OpenVSX-Zugangsdaten, um automatisch weitere Pakete und Erweiterungen zu kompromittieren und so exponentielles Wachstum zu erzeugen

  3. Unzerstörbare Infrastruktur:

    1. Solana-Blockchain als primärer C2-Kanal (unveränderlich und nicht abschaltbar)

    2. Google Kalender als Backup-C2-Kanal (legitimer Dienst, der Sicherheitskontrollen umgeht)

    3. Direkte IP-Verbindungen mit dynamischer Verschlüsselung

  4. Umfassende RAT-Funktionen: Macht infizierte Entwickler-Workstations mit SOCKS-Proxys, verborgenen VNC-Servern und P2P-Befehlskanälen zu krimineller Infrastruktur

So funktioniert der Glassworm-Angriff

Phase 1: Die unsichtbare Payload

Als Sicherheitsforscher die kompromittierte VS-Code-Erweiterung CodeJoy (Version 1.8.3) untersuchten, fanden sie zwischen Zeile 2 und Zeile 7 scheinbar leere Zeilen:

import * as vscode from 'vscode';

// [MASSIVE GAP HERE - APPEARS EMPTY]

export function activate(context: vscode.ExtensionContext) {

Doch diese Lücke war nicht leer. Sie enthielt ausführbaren JavaScript-Code, der in nicht druckbaren Unicode-Zeichen codiert war – genauer gesagt in Unicode-Variationsselektoren, die keinerlei sichtbare Darstellung erzeugen.

Für Entwickler beim Code-Review: Leerzeilen oder Leerraum.

Für statische Analysetools: nichts zu analysieren.

Für den JavaScript-Interpreter: ausführbarer Schadcode.

Phase 2: Blockchain-basierter C2-Kanal

Der unsichtbare Code stellt eine Verbindung zur Solana-Blockchain her und liest Transaktionsmemos von einer fest codierten Wallet-Adresse aus. Im Memo befindet sich ein JSON-Objekt mit einem Base64-codierten Link zum Herunterladen der nächsten Phase:

{"link":"aHR0cDovLzIxNy42OS4zLjIxOC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlTdg=="}

Dekodiert: http://217.69.3.218/qQD%2FJoi3WCWSk8ggGHiSv%3D%3D

Beachten Sie: Blockchain-Transaktionen sind unveränderlich und können weder gelöscht noch modifiziert werden. Krypto-Wallets sind pseudonym; es sind weder Hosting-Anbieter noch Registrare beteiligt. Angreifer können für minimale Kosten neue Transaktionen mit URLs zu neuen Payloads veröffentlichen.

Phase 3: Zugangsdaten abgreifen

Die heruntergeladene Payload (mit AES-256-CBC verschlüsselt; die Schlüssel werden in HTTP-Antwort-Headern übermittelt) zielt auf die folgenden vertraulichen Zugangsdaten ab:

  • NPM-Authentifizierungstoken – zum Veröffentlichen schädlicher Pakete

  • GitHub-Token – zum Kompromittieren von Repositorys

  • OpenVSX-Zugangsdaten – zum Einschleusen weiterer Erweiterungen

  • Git-Zugangsdaten – zum Einspielen schädlichen Codes

  • 49 verschiedene Kryptowährungs-Wallet-Erweiterungen – MetaMask, Phantom, Coinbase usw.

Doch das ist noch nicht alles: Als Backup-C2-Kanal dient Google Kalender. Die Malware ruft einen Kalendereintrag ab, dessen Titel eine Base64-codierte URL enthält:

aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==

Achten Sie auf den Pfad: /get_zombi_payload/ – ja, „zombi“ wie in Zombie-Botnetz.

Die nächste und letzte Phase heißt ZOMBI – The Full RAT (Remote Access Trojan). Die finale Payload verwandelt infizierte Entwickler-Workstations in Knoten eines kriminellen Infrastrukturnetzwerks. Dazu nutzt sie SOCKS-Proxys, um Datenverkehr innerhalb von Unternehmensnetzwerken weiterzuleiten, sowie weitere Netzwerkmechanismen wie WebRTC, BitTorrent und verborgene VNC-Verbindungen.

Der Angreifer kann Ihren Browser mit Ihren angemeldeten Sitzungen verwenden, auf Ihre E-Mails und Slack zugreifen, Ihren Quellcode lesen, weitere Zugangsdaten stehlen und sich in andere Systeme Ihres Netzwerks vorarbeiten – während auf Ihrem Bildschirm nichts Verdächtiges zu sehen ist.

Unsichtbare Zeichen mit anti-trojan-source erkennen

Das Projekt anti-trojan-source ist ein Open-Source-Sicherheitstool, das speziell zur Erkennung Unicode-basierter Angriffe entwickelt wurde, einschließlich der Injektion unsichtbarer Zeichen wie bei Glassworm. Ursprünglich wurde es zur Erkennung von Trojan-Source-Angriffen entwickelt. Inzwischen bietet es umfassenden Schutz durch die Erkennung expliziter Zeichen und die Unicode-Analyse nach Kategorien.

Was anti-trojan-source erkennt

277 explizit festgelegte verwechselbare Zeichen:

  • Bidirektionale Unicode-Steuerzeichen (U+202A–U+202E, U+2066–U+2069)

  • Zeichen mit Breite null (U+200B, U+200C, U+200D)

  • Variationsselektoren (U+FE00–U+FE0F) – die 16 grundlegenden Selektoren

  • Erweiterte Variationsselektoren (U+E0100–U+E01EF) – 240 zusätzliche Zeichen, die Glassworm verwendet

  • Geschütztes Leerzeichen (U+00A0)

  • Wortverbinder, bedingter Trennstrich und weitere unsichtbare Zeichen

Kategoriebasierte Erkennung (zukunftssicher):

  • Alle Unicode-Formatierungszeichen (Kategorie Cf) – erkennt unsichtbare Formatierungszeichen anhand ihrer Kategorie

  • Alle Unicode-Steuerzeichen (Kategorie Cc) – mit Ausnahme gängiger Leerraumzeichen (TAB, LF, CR)

Dank dieses kategoriebasierten Ansatzes kann anti-trojan-source auch künftig neu zu Unicode hinzugefügte unsichtbare Zeichen erkennen, ohne dass die Zeichenliste explizit aktualisiert werden muss.

Erkennungsfunktionen

1. Einfache boolesche Erkennung

import { hasConfusables } from 'anti-trojan-source'

const code = readFileSync('suspicious-file.js', 'utf-8')
const isDangerous = hasConfusables({ sourceText: code })

if (isDangerous) {
  console.error('⚠️ Invisible characters detected!')
}

2. Detaillierte Ergebnisse

import { hasConfusables } from 'anti-trojan-source'

const findings = hasConfusables({
  sourceText: code,
  detailed: true
})

findings.forEach(finding => {
  console.log(`Line ${finding.line}:${finding.column}`)
  console.log(`  Character: ${finding.codePoint} ${finding.name}`)
  console.log(`  Category: ${finding.category}`)
  console.log(`  Context: ${finding.snippet}`)
})

Beispielausgabe:

Line 3:45
  Character: U+E0100 VARIATION SELECTOR-17
  Category: Variation Selector
  Context: const value = getUserInput()

Line 12:8
  Character: U+200B ZERO WIDTH SPACE  
  Category: Cf (Format)
  Context: if (isAdmin) {

3. CLI-Anwendungsbeispiel mit mehreren Ausgabemodi

# Simple mode (exit code 1 if found)
npx anti-trojan-source --files='src/**/*.js'

# Verbose mode with detailed information
npx anti-trojan-source --files='src/**/*.js' --verbose

# JSON mode for programmatic processing
npx anti-trojan-source --files='src/**/*.js' --json

Implementierungsleitfaden für anti-trojan-source

Installieren Sie das Kommandozeilentool in Ihrem Projekt:

npm install -D anti-trojan-source

Oder führen Sie es direkt mit npx aus (keine Installation erforderlich):

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

Scannen Sie anschließend eine einzelne Datei:

npx anti-trojan-source src/index.js

Oder scannen Sie mehrere Dateien mit Shell-Globbing:

npx anti-trojan-source --files='src/**/*.{js,ts,jsx,tsx}'

Die anti-trojan-source-CLI unterstützt den Ausführlichkeitsmodus für detaillierte Ausgaben. Er ist hilfreich, wenn Sie genau wissen müssen, was wo erkannt wurde: 

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

Beispielausgabe:

[x] Detected cases of trojan source in the following files:
| 
 - src/utils.js
   Line 12:34 - U+200B ZERO WIDTH SPACE [Cf (Format)]
   Snippet: const value = getUserInput()
   Line 45:10 - U+202E RIGHT-TO-LEFT OVERRIDE [Cf (Format)]
   Snippet: if (isAdmin) { // Check permissions
   Line 78:22 - U+E0100 VARIATION SELECTOR-17 [Variation Selector]
   Snippet: const token = process.env.API_KEY

Ein JSON-Ausgabemodus wird ebenfalls unterstützt und ermöglicht die programmgesteuerte Analyse. Er eignet sich für Automatisierung, CI/CD-Integration und benutzerdefinierte Berichte:

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

Beispielausgabe: 

[
  {
    "file": "src/utils.js",
    "findings": [
      {
        "line": 12,
        "column": 34,
        "codePoint": "U+200B",
        "name": "ZERO WIDTH SPACE",
        "category": "Cf (Format)",
        "snippet": "const value = getUserInput()"
      },
      {
        "line": 45,
        "column": 10,
        "codePoint": "U+202E",
        "name": "RIGHT-TO-LEFT OVERRIDE",
        "category": "Cf (Format)",
        "snippet": "if (isAdmin) { // Check permissions"
      }
    ]
  }
]

CI/CD-Integration

Im Folgenden sehen Sie ein Beispiel dafür, wie Sie eine GitHub Action erstellen, die Sie in Ihren CI-Prozess integrieren können:

Erstellen Sie die Datei .github/workflows/security-scan.yml:

name: Unicode Security Scan

on:
  pull_request:
  push:
    branches: [main, master, develop]

jobs:
  scan-invisible-chars:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Scan for invisible Unicode attacks
        run: npx anti-trojan-source --files='**/*.{js,ts,jsx,tsx,py,java,go,rs}' --json

      - name: Fail on detection
        if: failure()
        run: |
          echo "::error::Invisible Unicode characters detected in source code"
          echo "::error::This could indicate a Trojan Source or Glassworm-style attack"
          exit 1

Erweiterte kategoriebasierte Erkennung

Unicode-Kategorien verstehen

anti-trojan-source sucht nicht nur nach bestimmten Zeichen, sondern analysiert Zeichen auch anhand ihrer Unicode-Kategorie. So ist das Tool gegen neue Angriffe gewappnet.

Formatkategorie (Cf):

  • Zeichen, die die Formatierung beeinflussen, aber keine sichtbare Ausgabe erzeugen

  • Umfasst bidirektionale Steuerzeichen, unsichtbare Trennzeichen und Zeichen mit Breite null

  • Beispiele: U+200B (ZERO WIDTH SPACE), U+202E (RIGHT-TO-LEFT OVERRIDE)

Steuerzeichenkategorie (Cc):

  • Nicht druckbare Steuerzeichen

  • Bereiche: U+0000–U+001F und U+007F–U+009F

  • Ausnahme: TAB (U+0009), LF (U+000A) und CR (U+000D) stehen als legitime Zeichen auf einer Zulassungsliste

Warum ist die kategoriebasierte Erkennung wichtig?

Ein herkömmlicher Ansatz würde dem folgenden JavaScript-Code ähneln:

const dangerousChars = ['\u200B', '\u200C', '\u200D', /* ... explicit list */];
// Problem: New Unicode versions add new characters
// Problem: Attackers can use unlisted characters

Ein kategoriebasierter Ansatz bietet dagegen folgende Vorteile:

  • Erkennt ALLE Zeichen der Formatkategorie (Cf), auch wenn sie nicht explizit aufgeführt sind

  • Erkennt ALLE Steuerzeichen (Cc) mit Ausnahme zugelassener Leerraumzeichen

So geht es weiter

Verlassen Sie sich nicht ausschließlich auf visuelle Code-Reviews. Einige IDEs wie VS Code und die Online-Diff-Ansicht von GitHub zeigen Unicode-Zeichen zwar inzwischen teilweise an. Vertrauen Sie jedoch nicht darauf, dass „alles in Ordnung aussieht“, und nehmen Sie nicht an, dass Ihre Tools unsichtbare Zeichen automatisch anzeigen. Scannen Sie gezielt danach.

Wir empfehlen, den gesamten Code vor dem Zusammenführen von Pull Requests zu scannen. Integrieren Sie Snyk (kostenlos): Snyk führt automatisch statische Codeanalysen aus und überwacht Ihr Projekt kontinuierlich – für GitHub-Quellcode-Repositorys und über weitere Integrationen.

Nutzen Sie das Kommandozeilentool anti-trojan-source, um potenziell gefährliche Zeichen gezielt in Ihrem Quellcode zu erkennen.

Möchten Sie Ihre Entwicklungspipeline gegen die nächste Generation von Supply-Chain-Bedrohungen wappnen? Laden Sie das Whitepaper herunter: Navigating the modern software supply chain: Securing open source, AI-generated code, & SBOM compliance.

Ressourcen

Tools:

Forschung:

Standards:

Sichern Sie Ihre Supply Chain mit Snyk

87 % der Befragten waren von Problemen mit der Supply-Chain-Sicherheit betroffen. Schützen Sie Ihre Supply Chain mit Snyk.

Live-Demo buchen