Was ist Trojan Source und wie schleicht er sich in Ihren Quellcode ein?
Was ist Trojan Source und wie schleicht er sich in Ihren Quellcode ein?
Anfang November veröffentlichte die Universität Cambridge ihre Forschungsarbeit namens Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren in Quellcode und Kommentaren versteckt werden können, indem gerichtete Formatierungszeichen verwendet werden. Diese können verwendet werden, um einen Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Prüfer.
Diese Schwachstelle ist neu, auch wenn Unicode in der Vergangenheit auf schändliche Art und Weise verwendet wurde, z. B. durch Verbergen der wahren Dateinamenerweiterung einer Datei durch Umkehrung der Richtung des letzten Teils eines Dateinamens. Die jüngsten Untersuchungen haben gezeigt, dass viele Compiler Unicode-Zeichen im Quellcode ohne Warnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umbrechen können. So kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie parst - und sogar Code und Kommentare vertauscht.
Lesen Sie weiter und erfahren Sie mehr. Wenn Sie selbst die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, dann nehmen Sie an unserer kostenlosen und öffentlichen Mission teil und erleben Sie es selbst.
Bidirektionaler Text
Einer dieser Trojaner-Quellen-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text mit unterschiedlicher Anzeigereihenfolge regelt, z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links). Richtungsabhängige Formatierungszeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der für den Angriff relevanten Bidi-Override-Zeichen. Nehmen Sie zum Beispiel,
RLI e d o c PDI
Die Abkürzung RLI steht für Right-to-Left Isolate. Es isoliert den Text aus 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 in der Regel keine Formatierungssteuerzeichen, einschließlich Bidi-Überschreibungen, bevor sie den Quellcode analysieren. Wenn sie die richtungsweisenden Formatierungszeichen einfach ignorieren, werden sie geparst:
e d o c
Alter Wein in neuen Schläuchen?
Das ist natürlich nichts Neues. In der Vergangenheit wurden bereits richtungsweisende Formatierungszeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als "myspecialexe.doc" angezeigt wird, könnte unschuldig genug aussehen, wäre da nicht das RLO-Zeichen(Right-to-Left-Override), das den wahren Namen als "myspecialcod.exe" offenbart.
Der Trojan Source-Angriff fügt gerichtete Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler verursachen werden. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, was dazu führt, dass der Compiler etwas völlig anderes liest als ein Mensch es tun würde.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
werden durch die richtungsweisenden Formatierungszeichen wie folgt neu geordnet
was dazu führt, dass der Code wie folgt dargestellt wird, wenn nicht ausdrücklich richtungsweisende Formatierungszeichen angegeben werden:
Die RLO verwandelt die schließende Klammer in eine öffnende Klammer und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: "Sie sind ein Administrator". Die Admin-Prüfung wurde auskommentiert, die Steuerzeichen vermitteln jedoch den Eindruck, dass sie noch vorhanden ist.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf Sie auswirken?
Viele Sprachen sind für den Angriff anfällig: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird angenommen, dass es noch mehr gibt. Der Durchschnittsentwickler mag sich darüber ärgern, richtungsweisende Formatierungszeichen im Quellcode zu sehen, aber ein Anfänger kann genauso gut mit den Schultern zucken und sich nichts dabei denken. Außerdem ist die Darstellung dieser Zeichen in hohem Maße IDE-abhängig, so dass es nie eine Garantie dafür gibt, dass sie entdeckt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies bei der Verwendung von Quellcode aus nicht vertrauenswürdigen Quellen geschehen, wo bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte dies durch einfaches Kopieren und Einfügen von im Internet gefundenem Code geschehen, etwas, das die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code voll und ganz vertrauen und uns auf ihn verlassen können. Wie können wir Quellcode, der versteckte Hintertüren enthält, aufspüren?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung nicht zulassen, es sei denn, eine Richtung ist strikt auf Strings und Kommentare beschränkt. Beachten Sie, dass ein richtungsweisendes Formatierungszeichen in einer Zeichenkette oder einem Kommentar einen Richtungswechsel bis zum Ende der Zeile verlängern kann, wenn er nicht gestoppt wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und direktionale Formatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun jeder Codezeile, die bidirektionalen Unicode-Text enthält, ein Warnzeichen und eine Meldung hinzu, obwohl nicht hervorgehoben wird, wo in der Zeile sich diese Zeichen befinden. Dies kann immer noch dazu führen, dass sich bösartige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Die Sensibilisierung von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Deshalb haben wir ein Walkthrough erstellt, das die Schwachstelle veranschaulicht. Zurzeit ist dieses Walkthrough für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr wissen wollen, probieren Sie unsere Simulation (öffentlich missions) von Trojan Source aus und lesen Sie die Trojan Source-Forschung.
Laura Verheyde
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und beschäftigt sich mit der Erforschung von Schwachstellen und der Erstellung von Inhalten für Missions und Coding Labs.
Verwandte Artikel, die wir empfehlen
Verwandte Artikel, die wir empfehlen
Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.
Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.
Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit
Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.
Was ist Trojan Source und wie schleicht er sich in Ihren Quellcode ein?
Anfang November veröffentlichte die Universität Cambridge ihre Forschungsarbeit namens Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren in Quellcode und Kommentaren versteckt werden können, indem gerichtete Formatierungszeichen verwendet werden. Diese können verwendet werden, um einen Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Prüfer.
Diese Schwachstelle ist neu, auch wenn Unicode in der Vergangenheit auf schändliche Art und Weise verwendet wurde, z. B. durch Verbergen der wahren Dateinamenerweiterung einer Datei durch Umkehrung der Richtung des letzten Teils eines Dateinamens. Die jüngsten Untersuchungen haben gezeigt, dass viele Compiler Unicode-Zeichen im Quellcode ohne Warnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umbrechen können. So kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie parst - und sogar Code und Kommentare vertauscht.
Lesen Sie weiter und erfahren Sie mehr. Wenn Sie selbst die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, dann nehmen Sie an unserer kostenlosen und öffentlichen Mission teil und erleben Sie es selbst.
Bidirektionaler Text
Einer dieser Trojaner-Quellen-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text mit unterschiedlicher Anzeigereihenfolge regelt, z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links). Richtungsabhängige Formatierungszeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der für den Angriff relevanten Bidi-Override-Zeichen. Nehmen Sie zum Beispiel,
RLI e d o c PDI
Die Abkürzung RLI steht für Right-to-Left Isolate. Es isoliert den Text aus 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 in der Regel keine Formatierungssteuerzeichen, einschließlich Bidi-Überschreibungen, bevor sie den Quellcode analysieren. Wenn sie die richtungsweisenden Formatierungszeichen einfach ignorieren, werden sie geparst:
e d o c
Alter Wein in neuen Schläuchen?
Das ist natürlich nichts Neues. In der Vergangenheit wurden bereits richtungsweisende Formatierungszeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als "myspecialexe.doc" angezeigt wird, könnte unschuldig genug aussehen, wäre da nicht das RLO-Zeichen(Right-to-Left-Override), das den wahren Namen als "myspecialcod.exe" offenbart.
Der Trojan Source-Angriff fügt gerichtete Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler verursachen werden. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, was dazu führt, dass der Compiler etwas völlig anderes liest als ein Mensch es tun würde.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
werden durch die richtungsweisenden Formatierungszeichen wie folgt neu geordnet
was dazu führt, dass der Code wie folgt dargestellt wird, wenn nicht ausdrücklich richtungsweisende Formatierungszeichen angegeben werden:
Die RLO verwandelt die schließende Klammer in eine öffnende Klammer und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: "Sie sind ein Administrator". Die Admin-Prüfung wurde auskommentiert, die Steuerzeichen vermitteln jedoch den Eindruck, dass sie noch vorhanden ist.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf Sie auswirken?
Viele Sprachen sind für den Angriff anfällig: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird angenommen, dass es noch mehr gibt. Der Durchschnittsentwickler mag sich darüber ärgern, richtungsweisende Formatierungszeichen im Quellcode zu sehen, aber ein Anfänger kann genauso gut mit den Schultern zucken und sich nichts dabei denken. Außerdem ist die Darstellung dieser Zeichen in hohem Maße IDE-abhängig, so dass es nie eine Garantie dafür gibt, dass sie entdeckt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies bei der Verwendung von Quellcode aus nicht vertrauenswürdigen Quellen geschehen, wo bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte dies durch einfaches Kopieren und Einfügen von im Internet gefundenem Code geschehen, etwas, das die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code voll und ganz vertrauen und uns auf ihn verlassen können. Wie können wir Quellcode, der versteckte Hintertüren enthält, aufspüren?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung nicht zulassen, es sei denn, eine Richtung ist strikt auf Strings und Kommentare beschränkt. Beachten Sie, dass ein richtungsweisendes Formatierungszeichen in einer Zeichenkette oder einem Kommentar einen Richtungswechsel bis zum Ende der Zeile verlängern kann, wenn er nicht gestoppt wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und direktionale Formatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun jeder Codezeile, die bidirektionalen Unicode-Text enthält, ein Warnzeichen und eine Meldung hinzu, obwohl nicht hervorgehoben wird, wo in der Zeile sich diese Zeichen befinden. Dies kann immer noch dazu führen, dass sich bösartige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Die Sensibilisierung von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Deshalb haben wir ein Walkthrough erstellt, das die Schwachstelle veranschaulicht. Zurzeit ist dieses Walkthrough für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr wissen wollen, probieren Sie unsere Simulation (öffentlich missions) von Trojan Source aus und lesen Sie die Trojan Source-Forschung.
