Was ist Trojan Source und wie schleicht es sich in Ihren Quellcode ein?
Anfang November veröffentlichte die University of Cambridge ihre Forschungsergebnisse unter dem Namen Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren mithilfe von direktionalen Formatierungszeichen im Quellcode und in Kommentaren versteckt werden können. Diese können verwendet werden, um Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Reviewer.
Diese Sicherheitslücke ist neu – obwohl Unicode in der Vergangenheit auf schändliche Weise verwendet wurde, beispielsweise indem die wahre Dateinamenerweiterung einer Datei versteckt wurde, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Die jüngsten Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, wohingegen Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umfließen lassen können. Daher kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie analysiert – sogar Code und Kommentare werden ausgetauscht.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, besuchen Sie unseren kostenlosen und öffentlichen Auftrag, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Trojan-Source-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der das Zusammenstellen von Text mit einer anderen Anzeigereihenfolge, wie Englisch (von links nach rechts) und Arabisch (von rechts nach links), verarbeitet. Zeichen der direktionalen Formatierung können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der Bidi-Override-Zeichen, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLI e d o c PDI
Die Abkürzung RLI steht für Von rechts nach links isolieren. Es wird den Text aus seinem Kontext isolieren (durch PDI abgegrenzt), Pop-Directional-Isolieren) und liest es 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, vor dem Analysieren des Quellcodes. Wenn sie die direktionalen Formatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Flaschen?
Natürlich ist das nichts Neues unter der Sonne. In der Vergangenheit wurden Zeichen zur direktionalen Formatierung verwendet und in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als „myspecialexe.doc” angezeigt wird, könnte harmlos genug aussehen, wäre da nicht das vorhandene RLO-Zeichen (Überschreibung von rechts nach links), das den tatsächlichen Namen „myspecialcod.exe” angibt.
Der Trojan Source-Angriff fügt direktionale Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler erzeugen. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird wie folgt nach den direktionalen Formatierungszeichen neu angeordnet
Dadurch wird der Code wie folgt gerendert, wenn Zeichen für die direktionale Formatierung nicht explizit aufgerufen werden:
Das RLO dreht die schließende Klammer in eine öffnende Klammer um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Sie sind ein Administrator“. Der Admin-Check wurde auskommentiert, aber die Steuerzeichen erwecken den Eindruck, dass er noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf dich auswirken?
Viele Sprachen sind anfällig für den Angriff: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird davon ausgegangen, dass es noch mehr gibt. Nun, der durchschnittliche Entwickler mag es missbilligen, wenn er Zeichen für direktionale Formatierung im Quellcode sieht, aber ein Anfänger könnte genauso gut mit den Schultern zucken und sich keine Gedanken darüber machen. Darüber hinaus hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nie garantiert werden kann, dass sie erkannt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird, bei denen bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte es durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten mehrerer Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code voll vertrauen und uns darauf verlassen können? Wie können wir nach Quellcode suchen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung verbieten, es sei denn, eine Richtung ist strikt auf Zeichenketten und Kommentare beschränkt. Beachten Sie, dass ein direktionales Formatierungszeichen in einer Zeichenfolge oder einem Kommentar eine Richtungsänderung bis zum Ende der Zeile verlängern kann, wenn es nicht eingeblendet wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur direktionalen Formatierung explizit rendern 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 sich diese Zeichen in der Zeile befinden. Dies kann immer noch dazu führen, dass sich böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Entwickler und Code-Reviewer müssen unbedingt dafür sensibilisiert werden. Aus diesem Grund haben wir eine Komplettlösung erstellt, die die Sicherheitsanfälligkeit veranschaulicht. Derzeit ist diese Komplettlösung für Java, C#, Python, GO und PHP verfügbar.
Wenn du also mehr wissen willst, probiere unsere Simulation (öffentliche Missionen) von Trojan Source aus und lies die Trojanische Quellenforschung.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
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.
Anfang November veröffentlichte die University of Cambridge ihre Forschungsergebnisse unter dem Namen Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren mithilfe von direktionalen Formatierungszeichen im Quellcode und in Kommentaren versteckt werden können. Diese können verwendet werden, um Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Reviewer.
Diese Sicherheitslücke ist neu – obwohl Unicode in der Vergangenheit auf schändliche Weise verwendet wurde, beispielsweise indem die wahre Dateinamenerweiterung einer Datei versteckt wurde, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Die jüngsten Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, wohingegen Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umfließen lassen können. Daher kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie analysiert – sogar Code und Kommentare werden ausgetauscht.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, besuchen Sie unseren kostenlosen und öffentlichen Auftrag, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Trojan-Source-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der das Zusammenstellen von Text mit einer anderen Anzeigereihenfolge, wie Englisch (von links nach rechts) und Arabisch (von rechts nach links), verarbeitet. Zeichen der direktionalen Formatierung können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der Bidi-Override-Zeichen, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLI e d o c PDI
Die Abkürzung RLI steht für Von rechts nach links isolieren. Es wird den Text aus seinem Kontext isolieren (durch PDI abgegrenzt), Pop-Directional-Isolieren) und liest es 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, vor dem Analysieren des Quellcodes. Wenn sie die direktionalen Formatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Flaschen?
Natürlich ist das nichts Neues unter der Sonne. In der Vergangenheit wurden Zeichen zur direktionalen Formatierung verwendet und in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als „myspecialexe.doc” angezeigt wird, könnte harmlos genug aussehen, wäre da nicht das vorhandene RLO-Zeichen (Überschreibung von rechts nach links), das den tatsächlichen Namen „myspecialcod.exe” angibt.
Der Trojan Source-Angriff fügt direktionale Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler erzeugen. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird wie folgt nach den direktionalen Formatierungszeichen neu angeordnet
Dadurch wird der Code wie folgt gerendert, wenn Zeichen für die direktionale Formatierung nicht explizit aufgerufen werden:
Das RLO dreht die schließende Klammer in eine öffnende Klammer um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Sie sind ein Administrator“. Der Admin-Check wurde auskommentiert, aber die Steuerzeichen erwecken den Eindruck, dass er noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf dich auswirken?
Viele Sprachen sind anfällig für den Angriff: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird davon ausgegangen, dass es noch mehr gibt. Nun, der durchschnittliche Entwickler mag es missbilligen, wenn er Zeichen für direktionale Formatierung im Quellcode sieht, aber ein Anfänger könnte genauso gut mit den Schultern zucken und sich keine Gedanken darüber machen. Darüber hinaus hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nie garantiert werden kann, dass sie erkannt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird, bei denen bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte es durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten mehrerer Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code voll vertrauen und uns darauf verlassen können? Wie können wir nach Quellcode suchen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung verbieten, es sei denn, eine Richtung ist strikt auf Zeichenketten und Kommentare beschränkt. Beachten Sie, dass ein direktionales Formatierungszeichen in einer Zeichenfolge oder einem Kommentar eine Richtungsänderung bis zum Ende der Zeile verlängern kann, wenn es nicht eingeblendet wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur direktionalen Formatierung explizit rendern 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 sich diese Zeichen in der Zeile befinden. Dies kann immer noch dazu führen, dass sich böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Entwickler und Code-Reviewer müssen unbedingt dafür sensibilisiert werden. Aus diesem Grund haben wir eine Komplettlösung erstellt, die die Sicherheitsanfälligkeit veranschaulicht. Derzeit ist diese Komplettlösung für Java, C#, Python, GO und PHP verfügbar.
Wenn du also mehr wissen willst, probiere unsere Simulation (öffentliche Missionen) von Trojan Source aus und lies die Trojanische Quellenforschung.
Anfang November veröffentlichte die University of Cambridge ihre Forschungsergebnisse unter dem Namen Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren mithilfe von direktionalen Formatierungszeichen im Quellcode und in Kommentaren versteckt werden können. Diese können verwendet werden, um Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Reviewer.
Diese Sicherheitslücke ist neu – obwohl Unicode in der Vergangenheit auf schändliche Weise verwendet wurde, beispielsweise indem die wahre Dateinamenerweiterung einer Datei versteckt wurde, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Die jüngsten Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, wohingegen Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umfließen lassen können. Daher kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie analysiert – sogar Code und Kommentare werden ausgetauscht.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, besuchen Sie unseren kostenlosen und öffentlichen Auftrag, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Trojan-Source-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der das Zusammenstellen von Text mit einer anderen Anzeigereihenfolge, wie Englisch (von links nach rechts) und Arabisch (von rechts nach links), verarbeitet. Zeichen der direktionalen Formatierung können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der Bidi-Override-Zeichen, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLI e d o c PDI
Die Abkürzung RLI steht für Von rechts nach links isolieren. Es wird den Text aus seinem Kontext isolieren (durch PDI abgegrenzt), Pop-Directional-Isolieren) und liest es 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, vor dem Analysieren des Quellcodes. Wenn sie die direktionalen Formatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Flaschen?
Natürlich ist das nichts Neues unter der Sonne. In der Vergangenheit wurden Zeichen zur direktionalen Formatierung verwendet und in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als „myspecialexe.doc” angezeigt wird, könnte harmlos genug aussehen, wäre da nicht das vorhandene RLO-Zeichen (Überschreibung von rechts nach links), das den tatsächlichen Namen „myspecialcod.exe” angibt.
Der Trojan Source-Angriff fügt direktionale Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler erzeugen. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird wie folgt nach den direktionalen Formatierungszeichen neu angeordnet
Dadurch wird der Code wie folgt gerendert, wenn Zeichen für die direktionale Formatierung nicht explizit aufgerufen werden:
Das RLO dreht die schließende Klammer in eine öffnende Klammer um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Sie sind ein Administrator“. Der Admin-Check wurde auskommentiert, aber die Steuerzeichen erwecken den Eindruck, dass er noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf dich auswirken?
Viele Sprachen sind anfällig für den Angriff: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird davon ausgegangen, dass es noch mehr gibt. Nun, der durchschnittliche Entwickler mag es missbilligen, wenn er Zeichen für direktionale Formatierung im Quellcode sieht, aber ein Anfänger könnte genauso gut mit den Schultern zucken und sich keine Gedanken darüber machen. Darüber hinaus hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nie garantiert werden kann, dass sie erkannt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird, bei denen bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte es durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten mehrerer Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code voll vertrauen und uns darauf verlassen können? Wie können wir nach Quellcode suchen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung verbieten, es sei denn, eine Richtung ist strikt auf Zeichenketten und Kommentare beschränkt. Beachten Sie, dass ein direktionales Formatierungszeichen in einer Zeichenfolge oder einem Kommentar eine Richtungsänderung bis zum Ende der Zeile verlängern kann, wenn es nicht eingeblendet wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur direktionalen Formatierung explizit rendern 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 sich diese Zeichen in der Zeile befinden. Dies kann immer noch dazu führen, dass sich böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Entwickler und Code-Reviewer müssen unbedingt dafür sensibilisiert werden. Aus diesem Grund haben wir eine Komplettlösung erstellt, die die Sicherheitsanfälligkeit veranschaulicht. Derzeit ist diese Komplettlösung für Java, C#, Python, GO und PHP verfügbar.
Wenn du also mehr wissen willst, probiere unsere Simulation (öffentliche Missionen) von Trojan Source aus und lies die Trojanische Quellenforschung.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
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.
Anfang November veröffentlichte die University of Cambridge ihre Forschungsergebnisse unter dem Namen Trojan-Source. Diese Forschung konzentrierte sich darauf, wie Hintertüren mithilfe von direktionalen Formatierungszeichen im Quellcode und in Kommentaren versteckt werden können. Diese können verwendet werden, um Code zu erstellen, dessen Logik vom Compiler anders interpretiert wird als von einem menschlichen Code-Reviewer.
Diese Sicherheitslücke ist neu – obwohl Unicode in der Vergangenheit auf schändliche Weise verwendet wurde, beispielsweise indem die wahre Dateinamenerweiterung einer Datei versteckt wurde, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Die jüngsten Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, wohingegen Texteditoren, einschließlich Code-Editoren, Zeilen mit Kommentaren und darauf basierendem Code umfließen lassen können. Daher kann es vorkommen, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als der Compiler sie analysiert – sogar Code und Kommentare werden ausgetauscht.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und das simulierte Hacken von Trojan Source ausprobieren möchten, besuchen Sie unseren kostenlosen und öffentlichen Auftrag, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Trojan-Source-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der das Zusammenstellen von Text mit einer anderen Anzeigereihenfolge, wie Englisch (von links nach rechts) und Arabisch (von rechts nach links), verarbeitet. Zeichen der direktionalen Formatierung können verwendet werden, um die Gruppierung neu zu organisieren und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der Bidi-Override-Zeichen, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLI e d o c PDI
Die Abkürzung RLI steht für Von rechts nach links isolieren. Es wird den Text aus seinem Kontext isolieren (durch PDI abgegrenzt), Pop-Directional-Isolieren) und liest es 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, vor dem Analysieren des Quellcodes. Wenn sie die direktionalen Formatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Flaschen?
Natürlich ist das nichts Neues unter der Sonne. In der Vergangenheit wurden Zeichen zur direktionalen Formatierung verwendet und in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Ein E-Mail-Anhang, der als „myspecialexe.doc” angezeigt wird, könnte harmlos genug aussehen, wäre da nicht das vorhandene RLO-Zeichen (Überschreibung von rechts nach links), das den tatsächlichen Namen „myspecialcod.exe” angibt.
Der Trojan Source-Angriff fügt direktionale Formatierungszeichen in Kommentare und Zeichenketten im Quellcode ein, da diese keine Syntax- oder Kompilierungsfehler erzeugen. Diese Steuerzeichen ändern die Anzeigereihenfolge der Logik des Codes, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Zum Beispiel eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird wie folgt nach den direktionalen Formatierungszeichen neu angeordnet
Dadurch wird der Code wie folgt gerendert, wenn Zeichen für die direktionale Formatierung nicht explizit aufgerufen werden:
Das RLO dreht die schließende Klammer in eine öffnende Klammer um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Sie sind ein Administrator“. Der Admin-Check wurde auskommentiert, aber die Steuerzeichen erwecken den Eindruck, dass er noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie könnte sich das auf dich auswirken?
Viele Sprachen sind anfällig für den Angriff: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es wird davon ausgegangen, dass es noch mehr gibt. Nun, der durchschnittliche Entwickler mag es missbilligen, wenn er Zeichen für direktionale Formatierung im Quellcode sieht, aber ein Anfänger könnte genauso gut mit den Schultern zucken und sich keine Gedanken darüber machen. Darüber hinaus hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nie garantiert werden kann, dass sie erkannt werden.
Aber wie konnte sich diese Sicherheitslücke überhaupt in den Quellcode einschleichen? In erster Linie kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird, bei denen bösartige Codebeiträge unbemerkt geblieben sind. Zweitens könnte es durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten von uns Entwicklern schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten mehrerer Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code voll vertrauen und uns darauf verlassen können? Wie können wir nach Quellcode suchen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines Quellcodezeilen mit mehr als einer Richtung verbieten, es sei denn, eine Richtung ist strikt auf Zeichenketten und Kommentare beschränkt. Beachten Sie, dass ein direktionales Formatierungszeichen in einer Zeichenfolge oder einem Kommentar eine Richtungsänderung bis zum Ende der Zeile verlängern kann, wenn es nicht eingeblendet wird. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur direktionalen Formatierung explizit rendern 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 sich diese Zeichen in der Zeile befinden. Dies kann immer noch dazu führen, dass sich böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen einschleichen.
Entwickler und Code-Reviewer müssen unbedingt dafür sensibilisiert werden. Aus diesem Grund haben wir eine Komplettlösung erstellt, die die Sicherheitsanfälligkeit veranschaulicht. Derzeit ist diese Komplettlösung für Java, C#, Python, GO und PHP verfügbar.
Wenn du also mehr wissen willst, probiere unsere Simulation (öffentliche Missionen) von Trojan Source aus und lies die Trojanische Quellenforschung.
Inhaltsverzeichnis
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
