Was ist Trojan Source und wie gelangt es in Ihren Quellcode?

Anfang November veröffentlichte die University of Cambridge ihre Forschungsarbeit mit dem Titel Trojan-Source. Diese Untersuchung konzentriert sich darauf, wie Backdoors mithilfe von Richtungsformatierungszeichen in Quellcode und Kommentaren versteckt werden können. Auf diese Weise lässt sich Code erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Reviewer.

Diese Schwachstelle ist neu – obwohl Unicode in der Vergangenheit bereits für bösartige Zwecke missbraucht wurde, etwa um die wahre Dateiendung durch Umkehrung der Reihenfolge des letzten Dateinamen-Teils zu verschleiern. Die aktuelle Forschung zeigt, dass viele Compiler Unicode-Zeichen im Quellcode warnungslos ignorieren, während Texteditoren (einschließlich Code-Editoren) Zeilen mit Kommentaren und Code basierend auf diesen Zeichen umbrechen können. Dadurch kann der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigen, als der Compiler sie verarbeitet – bis hin zum Vertauschen von Code und Kommentaren.

Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie selbst aktiv werden und einen simulierten Trojan-Source-Angriff ausprobieren möchten, nehmen Sie an unserer kostenlosen und öffentlichen Mission teil, um es selbst zu erleben.

Bidirektionaler Text

Einer dieser Trojan-Source-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der steuert, wie Text mit unterschiedlicher Leserichtung, wie etwa Englisch (von links nach rechts) und Arabisch (von rechts nach links), zusammengesetzt wird. Richtungsformatierungszeichen können verwendet werden, um die Gruppierung und Anzeigereihenfolge von Zeichen neu zu ordnen.

Die obige Tabelle enthält einige der für den Angriff relevanten Bidi-Override-Zeichen. Nehmen wir zum Beispiel:

RLI e d o c PDI

Die Abkürzung RLI steht für Right-to-Left Isolate. Sie isoliert den Text von seinem Kontext (begrenzt durch PDI, Pop-Directional-Isolate) und liest ihn von rechts nach links. Das Ergebnis ist:

c o d e

Compiler und Interpreter verarbeiten jedoch normalerweise keine Formatierungssteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode parsen. Wenn sie die Richtungsformatierungszeichen einfach ignorieren, parsen sie:

e d o c

Alter Wein in neuen Schläuchen?

Natürlich ist das nichts Neues unter der Sonne. In der Vergangenheit wurden Richtungsformatierungszeichen bereits in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als 'myspecialexe.doc' angezeigt wird, könnte harmlos wirken, wäre da nicht das RLO-Zeichen (Right-to-Left override), das den wahren Namen als 'myspecialcod.exe' entlarvt.

Der Trojan-Source-Angriff fügt Richtungsformatierungszeichen in Kommentare und Strings innerhalb des Quellcodes ein, da diese keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen verändern die Anzeigereihenfolge der Codelogik, wodurch der Compiler etwas völlig anderes liest, als ein Mensch sehen würde.

Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:

wird durch die Richtungsformatierungszeichen wie folgt neu angeordnet

was dazu führt, dass der Code wie folgt dargestellt wird, wenn Richtungsformatierungszeichen nicht explizit hervorgehoben werden:

Das RLO-Zeichen kehrt in der letzten Zeile die schließende Klammer in eine öffnende um und umgekehrt. Die Ausführung dieses Codes würde „You are an admin“ ergeben. Die Admin-Prüfung wurde zwar auskommentiert, doch die Steuerzeichen erwecken den Anschein, sie sei noch vorhanden.

(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)

Wie könnte Sie das betreffen?

Viele Sprachen sind anfällig für diesen Angriff: C, C++, C#, JavaScript, Java, Rust, Go und Python – und es ist davon auszugehen, dass es noch mehr sind. Ein erfahrener Entwickler mag bei Richtungsformatierungszeichen im Quellcode stutzen, doch ein Anfänger zuckt vielleicht nur mit den Schultern und denkt sich nichts dabei. Zudem hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass man sich nie darauf verlassen kann, dass sie erkannt werden.

Doch wie kann diese Schwachstelle überhaupt in den Quellcode gelangen? Erstens durch die Verwendung von Quellcode aus nicht vertrauenswürdigen Quellen, bei denen bösartige Beiträge unbemerkt geblieben sind. Zweitens durch einfaches Kopieren und Einfügen von Code aus dem Internet – etwas, das die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten verschiedener Anbieter. Das wirft die Frage auf: Inwieweit können wir diesem Code voll und ganz vertrauen? Wie können wir Quellcode auf versteckte Hintertüren prüfen?

Wessen Problem ist das?

Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Schreibrichtung ablehnen, es sei denn, eine Richtung ist strikt auf Strings und Kommentare beschränkt. Beachten Sie, dass ein Richtungsformatierungszeichen in einem String oder Kommentar, wenn es nicht beendet wird, einen Richtungswechsel bis zum Zeilenende erzwingen kann. Generell sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Richtungsformatierungszeichen explizit darstellen und hervorheben. Seit November zeigt GitHub bei jeder Codezeile mit bidirektionalem Unicode-Text ein Warnsymbol und eine Meldung an, auch wenn nicht hervorgehoben wird, an welcher Stelle sich diese Zeichen befinden. Dies kann dazu führen, dass sich bösartige Richtungsänderungen zusammen mit harmlosen einschleichen.

Das Bewusstsein bei Entwicklern und Code-Reviewern ist entscheidend. Deshalb haben wir eine Anleitung erstellt, die diese Schwachstelle veranschaulicht. Diese Anleitung ist derzeit für Java, C#, Python, Go und PHP verfügbar.

Wenn Sie mehr erfahren möchten, probieren Sie unsere Simulation (öffentliche Missionen) zu Trojan Source aus und lesen Sie die Trojan Source-Forschung.

Simulation in Java

Simulation in C#

Simulation in PHP

Simulation in GO

Simulation in Python