Was ist Trojan Source und wie schleicht es sich in Ihren Quellcode ein?
Anfang November veröffentlichte die University of Cambridge ihre Forschung namens 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 Umkehren der Richtung des letzten Teils eines Dateinamens. 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 basierender 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 öffentlicher 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-Charaktere, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLIe d o cPDI
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:
ǞǞǞ
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 in Dateinamen eingefügt um ihre 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 (Überschreibung von rechts nach links) vorhandenes Zeichen, 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 ist die Visualisierung dieser Zeichen stark von der IDE abhängig, 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, und lies die Trojanische Quellenforschung.
Anfang November veröffentlichte die University of Cambridge ihre Forschung namens 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 Umkehren der Richtung des letzten Teils eines Dateinamens. 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 basierender 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 öffentlicher 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-Charaktere, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLIe d o cPDI
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:
ǞǞǞ
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 in Dateinamen eingefügt um ihre 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 (Überschreibung von rechts nach links) vorhandenes Zeichen, 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 ist die Visualisierung dieser Zeichen stark von der IDE abhängig, 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, und lies die Trojanische Quellenforschung.
Anfang November veröffentlichte die University of Cambridge ihre Forschung namens 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 Umkehren der Richtung des letzten Teils eines Dateinamens. 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 basierender 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 öffentlicher 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-Charaktere, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLIe d o cPDI
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:
ǞǞǞ
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 in Dateinamen eingefügt um ihre 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 (Überschreibung von rechts nach links) vorhandenes Zeichen, 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 ist die Visualisierung dieser Zeichen stark von der IDE abhängig, 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, und lies die Trojanische Quellenforschung.
Anfang November veröffentlichte die University of Cambridge ihre Forschung namens 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 Umkehren der Richtung des letzten Teils eines Dateinamens. 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 basierender 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 öffentlicher 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-Charaktere, die für den Angriff relevant sind. Nehmen wir zum Beispiel
RLIe d o cPDI
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:
ǞǞǞ
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 in Dateinamen eingefügt um ihre 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 (Überschreibung von rechts nach links) vorhandenes Zeichen, 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 ist die Visualisierung dieser Zeichen stark von der IDE abhängig, 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, und lies die Trojanische Quellenforschung.
%20(1).avif)
.avif)
