Was ist Trojan Source und wie gelangt es in Ihren Quellcode?
Anfang November veröffentlichte die Universität Cambridge ihre Forschungsarbeit mit dem Titel „Trojan-Source“. Diese Forschungsarbeit befasste sich damit, wie Backdoors mithilfe von 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-Prüfer.
Diese Schwachstelle ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke genutzt wurde, beispielsweise um die tatsächliche Dateiendung einer Datei zu verbergen, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Jüngste Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen, die Kommentare und darauf basierenden Code enthalten, neu anordnen können. Daher ist es möglich, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als sie vom Compiler analysiert werden, wobei sogar Code und Kommentare vertauscht werden können.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie gleich loslegen und den simulierten Hack von Trojan Source ausprobieren möchten, besuchen Sie unsere kostenlose Seite und öffentliche Mission, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Angriffe von Trojan-Source nutzt den Unicode-Bidi-Algorithmus (bidirektional), der dafür zuständig ist, wie Text mit unterschiedlicher Anzeigereihenfolge zusammengefügt wird, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Die Zeichen der Richtungsformatierung können verwendet werden, um die Gruppierung neu zu ordnen und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der mit dem Angriff in Verbindung stehenden, annullierten Charaktere aus Bidi. Nehmen wir zum Beispiel
RLI e d a c PDI
Die Abkürzung RLI steht für „Von rechts nach links isolieren”. Der Text wird aus seinem Kontext isoliert (begrenzt durch PDI, Pop-Richtungsisolierung) und von rechts nach links gelesen. Das Ergebnis lautet:
c a d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Aufhebungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatzeichen einfach ignorieren, analysieren sie:
e d a c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden Richtungsformatzeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang mit dem Namen „myspecialexe.doc” könnte recht harmlos erscheinen, wäre da nicht das Zeichen RLO (Right-to-Left Override), das verrät, dass der eigentliche Name „myspecialcod.exe” lautet.
Der Trojaner-Angriff fügt Formatierungszeichen in die Kommentare und Zeichenfolgen des Quellcodes ein, da diese keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen ändern die Reihenfolge, in der die Logik des Codes angezeigt wird, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird entsprechend den Richtungsformatzeichen wie folgt neu angeordnet
sodass der Code wie folgt dargestellt wird, wenn die Richtungsformatzeichen nicht explizit aufgerufen werden:
Der RLO wandelt das geschlossene Korsett in ein offenes Korsett um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Du bist ein Administrator“. Die Administratorprüfung war kommentiert, aber die Steuerzeichen vermitteln den Eindruck, dass sie noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie kann sich das auf Sie auswirken?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es gibt vermutlich noch weitere. Nun könnte der durchschnittliche Entwickler die Anzeige von Richtungszeichen im Quellcode missbilligen, aber ein Neuling würde vielleicht nur mit den Schultern zucken und sich keine weiteren Gedanken darüber machen. Außerdem hängt die Anzeige dieser Zeichen stark von der IDE ab, sodass es keine Garantie dafür gibt, dass sie erkannt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Erstens kann dies passieren, wenn Quellcode aus unzuverlässigen Quellen verwendet wird, in denen böswillige Code-Beiträge unbemerkt geblieben sind. Zweitens könnte dies einfach durch Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten verschiedener Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen können. Wie können wir Quellcode erkennen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Compiler-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass ein Richtungsformatierungszeichen in einer Zeichenfolge oder einem Kommentar, wenn es nicht erscheint, eine Richtungsänderung bis zum Ende der Zeile verlängern kann. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und Richtungsformatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun ein Signal und eine Warnmeldung zu jeder Codezeile hinzu, die bidirektionalen Unicode-Text enthält, hebt jedoch nicht hervor, an welcher Stelle der Zeile sich diese Zeichen befinden. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen eingefügt werden.
Es ist unerlässlich, dass Entwickler und Code-Prüfer sensibilisiert sind. Aus diesem Grund haben wir ein Tutorial erstellt, das die Schwachstelle veranschaulicht. Derzeit ist dieses Tutorial für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr erfahren möchten, probieren Sie unsere Simulation (öffentliche Missionen) von Trojan Source aus und lesen Sie die Untersuchung zu Trojanischen Quellen.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung 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 Universität Cambridge ihre Forschungsarbeit mit dem Titel „Trojan-Source“. Diese Forschungsarbeit befasste sich damit, wie Backdoors mithilfe von 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-Prüfer.
Diese Schwachstelle ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke genutzt wurde, beispielsweise um die tatsächliche Dateiendung einer Datei zu verbergen, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Jüngste Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen, die Kommentare und darauf basierenden Code enthalten, neu anordnen können. Daher ist es möglich, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als sie vom Compiler analysiert werden, wobei sogar Code und Kommentare vertauscht werden können.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie gleich loslegen und den simulierten Hack von Trojan Source ausprobieren möchten, besuchen Sie unsere kostenlose Seite und öffentliche Mission, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Angriffe von Trojan-Source nutzt den Unicode-Bidi-Algorithmus (bidirektional), der dafür zuständig ist, wie Text mit unterschiedlicher Anzeigereihenfolge zusammengefügt wird, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Die Zeichen der Richtungsformatierung können verwendet werden, um die Gruppierung neu zu ordnen und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der mit dem Angriff in Verbindung stehenden, annullierten Charaktere aus Bidi. Nehmen wir zum Beispiel
RLI e d a c PDI
Die Abkürzung RLI steht für „Von rechts nach links isolieren”. Der Text wird aus seinem Kontext isoliert (begrenzt durch PDI, Pop-Richtungsisolierung) und von rechts nach links gelesen. Das Ergebnis lautet:
c a d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Aufhebungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatzeichen einfach ignorieren, analysieren sie:
e d a c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden Richtungsformatzeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang mit dem Namen „myspecialexe.doc” könnte recht harmlos erscheinen, wäre da nicht das Zeichen RLO (Right-to-Left Override), das verrät, dass der eigentliche Name „myspecialcod.exe” lautet.
Der Trojaner-Angriff fügt Formatierungszeichen in die Kommentare und Zeichenfolgen des Quellcodes ein, da diese keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen ändern die Reihenfolge, in der die Logik des Codes angezeigt wird, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird entsprechend den Richtungsformatzeichen wie folgt neu angeordnet
sodass der Code wie folgt dargestellt wird, wenn die Richtungsformatzeichen nicht explizit aufgerufen werden:
Der RLO wandelt das geschlossene Korsett in ein offenes Korsett um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Du bist ein Administrator“. Die Administratorprüfung war kommentiert, aber die Steuerzeichen vermitteln den Eindruck, dass sie noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie kann sich das auf Sie auswirken?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es gibt vermutlich noch weitere. Nun könnte der durchschnittliche Entwickler die Anzeige von Richtungszeichen im Quellcode missbilligen, aber ein Neuling würde vielleicht nur mit den Schultern zucken und sich keine weiteren Gedanken darüber machen. Außerdem hängt die Anzeige dieser Zeichen stark von der IDE ab, sodass es keine Garantie dafür gibt, dass sie erkannt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Erstens kann dies passieren, wenn Quellcode aus unzuverlässigen Quellen verwendet wird, in denen böswillige Code-Beiträge unbemerkt geblieben sind. Zweitens könnte dies einfach durch Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten verschiedener Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen können. Wie können wir Quellcode erkennen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Compiler-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass ein Richtungsformatierungszeichen in einer Zeichenfolge oder einem Kommentar, wenn es nicht erscheint, eine Richtungsänderung bis zum Ende der Zeile verlängern kann. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und Richtungsformatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun ein Signal und eine Warnmeldung zu jeder Codezeile hinzu, die bidirektionalen Unicode-Text enthält, hebt jedoch nicht hervor, an welcher Stelle der Zeile sich diese Zeichen befinden. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen eingefügt werden.
Es ist unerlässlich, dass Entwickler und Code-Prüfer sensibilisiert sind. Aus diesem Grund haben wir ein Tutorial erstellt, das die Schwachstelle veranschaulicht. Derzeit ist dieses Tutorial für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr erfahren möchten, probieren Sie unsere Simulation (öffentliche Missionen) von Trojan Source aus und lesen Sie die Untersuchung zu Trojanischen Quellen.
Anfang November veröffentlichte die Universität Cambridge ihre Forschungsarbeit mit dem Titel „Trojan-Source“. Diese Forschungsarbeit befasste sich damit, wie Backdoors mithilfe von 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-Prüfer.
Diese Schwachstelle ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke genutzt wurde, beispielsweise um die tatsächliche Dateiendung einer Datei zu verbergen, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Jüngste Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen, die Kommentare und darauf basierenden Code enthalten, neu anordnen können. Daher ist es möglich, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als sie vom Compiler analysiert werden, wobei sogar Code und Kommentare vertauscht werden können.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie gleich loslegen und den simulierten Hack von Trojan Source ausprobieren möchten, besuchen Sie unsere kostenlose Seite und öffentliche Mission, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Angriffe von Trojan-Source nutzt den Unicode-Bidi-Algorithmus (bidirektional), der dafür zuständig ist, wie Text mit unterschiedlicher Anzeigereihenfolge zusammengefügt wird, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Die Zeichen der Richtungsformatierung können verwendet werden, um die Gruppierung neu zu ordnen und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der mit dem Angriff in Verbindung stehenden, annullierten Charaktere aus Bidi. Nehmen wir zum Beispiel
RLI e d a c PDI
Die Abkürzung RLI steht für „Von rechts nach links isolieren”. Der Text wird aus seinem Kontext isoliert (begrenzt durch PDI, Pop-Richtungsisolierung) und von rechts nach links gelesen. Das Ergebnis lautet:
c a d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Aufhebungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatzeichen einfach ignorieren, analysieren sie:
e d a c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden Richtungsformatzeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang mit dem Namen „myspecialexe.doc” könnte recht harmlos erscheinen, wäre da nicht das Zeichen RLO (Right-to-Left Override), das verrät, dass der eigentliche Name „myspecialcod.exe” lautet.
Der Trojaner-Angriff fügt Formatierungszeichen in die Kommentare und Zeichenfolgen des Quellcodes ein, da diese keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen ändern die Reihenfolge, in der die Logik des Codes angezeigt wird, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird entsprechend den Richtungsformatzeichen wie folgt neu angeordnet
sodass der Code wie folgt dargestellt wird, wenn die Richtungsformatzeichen nicht explizit aufgerufen werden:
Der RLO wandelt das geschlossene Korsett in ein offenes Korsett um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Du bist ein Administrator“. Die Administratorprüfung war kommentiert, aber die Steuerzeichen vermitteln den Eindruck, dass sie noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie kann sich das auf Sie auswirken?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es gibt vermutlich noch weitere. Nun könnte der durchschnittliche Entwickler die Anzeige von Richtungszeichen im Quellcode missbilligen, aber ein Neuling würde vielleicht nur mit den Schultern zucken und sich keine weiteren Gedanken darüber machen. Außerdem hängt die Anzeige dieser Zeichen stark von der IDE ab, sodass es keine Garantie dafür gibt, dass sie erkannt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Erstens kann dies passieren, wenn Quellcode aus unzuverlässigen Quellen verwendet wird, in denen böswillige Code-Beiträge unbemerkt geblieben sind. Zweitens könnte dies einfach durch Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten verschiedener Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen können. Wie können wir Quellcode erkennen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Compiler-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass ein Richtungsformatierungszeichen in einer Zeichenfolge oder einem Kommentar, wenn es nicht erscheint, eine Richtungsänderung bis zum Ende der Zeile verlängern kann. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und Richtungsformatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun ein Signal und eine Warnmeldung zu jeder Codezeile hinzu, die bidirektionalen Unicode-Text enthält, hebt jedoch nicht hervor, an welcher Stelle der Zeile sich diese Zeichen befinden. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen eingefügt werden.
Es ist unerlässlich, dass Entwickler und Code-Prüfer sensibilisiert sind. Aus diesem Grund haben wir ein Tutorial erstellt, das die Schwachstelle veranschaulicht. Derzeit ist dieses Tutorial für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr erfahren möchten, probieren Sie unsere Simulation (öffentliche Missionen) von Trojan Source aus und lesen Sie die Untersuchung zu Trojanischen Quellen.
Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung 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 Universität Cambridge ihre Forschungsarbeit mit dem Titel „Trojan-Source“. Diese Forschungsarbeit befasste sich damit, wie Backdoors mithilfe von 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-Prüfer.
Diese Schwachstelle ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke genutzt wurde, beispielsweise um die tatsächliche Dateiendung einer Datei zu verbergen, indem die Richtung des letzten Teils eines Dateinamens umgekehrt wurde. Jüngste Untersuchungen haben ergeben, dass viele Compiler Unicode-Zeichen im Quellcode ohne Vorwarnung ignorieren, während Texteditoren, einschließlich Code-Editoren, Zeilen, die Kommentare und darauf basierenden Code enthalten, neu anordnen können. Daher ist es möglich, dass der Editor den Code und die Kommentare anders und in einer anderen Reihenfolge anzeigt, als sie vom Compiler analysiert werden, wobei sogar Code und Kommentare vertauscht werden können.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie gleich loslegen und den simulierten Hack von Trojan Source ausprobieren möchten, besuchen Sie unsere kostenlose Seite und öffentliche Mission, um es selbst zu erleben.
Bidirektionaler Text
Einer dieser Angriffe von Trojan-Source nutzt den Unicode-Bidi-Algorithmus (bidirektional), der dafür zuständig ist, wie Text mit unterschiedlicher Anzeigereihenfolge zusammengefügt wird, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Die Zeichen der Richtungsformatierung können verwendet werden, um die Gruppierung neu zu ordnen und die Reihenfolge der Zeichen anzuzeigen.
Die obige Tabelle enthält einige der mit dem Angriff in Verbindung stehenden, annullierten Charaktere aus Bidi. Nehmen wir zum Beispiel
RLI e d a c PDI
Die Abkürzung RLI steht für „Von rechts nach links isolieren”. Der Text wird aus seinem Kontext isoliert (begrenzt durch PDI, Pop-Richtungsisolierung) und von rechts nach links gelesen. Das Ergebnis lautet:
c a d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Aufhebungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatzeichen einfach ignorieren, analysieren sie:
e d a c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden Richtungsformatzeichen in Dateinamen eingefügt, um deren bösartige Natur zu verschleiern. Ein E-Mail-Anhang mit dem Namen „myspecialexe.doc” könnte recht harmlos erscheinen, wäre da nicht das Zeichen RLO (Right-to-Left Override), das verrät, dass der eigentliche Name „myspecialcod.exe” lautet.
Der Trojaner-Angriff fügt Formatierungszeichen in die Kommentare und Zeichenfolgen des Quellcodes ein, da diese keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen ändern die Reihenfolge, in der die Logik des Codes angezeigt wird, sodass der Compiler etwas völlig anderes liest als ein Mensch.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
wird entsprechend den Richtungsformatzeichen wie folgt neu angeordnet
sodass der Code wie folgt dargestellt wird, wenn die Richtungsformatzeichen nicht explizit aufgerufen werden:
Der RLO wandelt das geschlossene Korsett in ein offenes Korsett um und umgekehrt in der letzten Zeile. Das Ergebnis der Ausführung dieses Codes wäre: „Du bist ein Administrator“. Die Administratorprüfung war kommentiert, aber die Steuerzeichen vermitteln den Eindruck, dass sie noch vorhanden war.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie kann sich das auf Sie auswirken?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, und es gibt vermutlich noch weitere. Nun könnte der durchschnittliche Entwickler die Anzeige von Richtungszeichen im Quellcode missbilligen, aber ein Neuling würde vielleicht nur mit den Schultern zucken und sich keine weiteren Gedanken darüber machen. Außerdem hängt die Anzeige dieser Zeichen stark von der IDE ab, sodass es keine Garantie dafür gibt, dass sie erkannt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Erstens kann dies passieren, wenn Quellcode aus unzuverlässigen Quellen verwendet wird, in denen böswillige Code-Beiträge unbemerkt geblieben sind. Zweitens könnte dies einfach durch Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen verlassen sich auf Softwarekomponenten verschiedener Anbieter. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen können. Wie können wir Quellcode erkennen, der versteckte Hintertüren enthält?
Wessen Problem ist das?
Einerseits sollten Compiler und Compiler-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass ein Richtungsformatierungszeichen in einer Zeichenfolge oder einem Kommentar, wenn es nicht erscheint, eine Richtungsänderung bis zum Ende der Zeile verlängern kann. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen, wie Homoglyphen und Richtungsformatierungszeichen, explizit darstellen und hervorheben. Seit November fügt GitHub nun ein Signal und eine Warnmeldung zu jeder Codezeile hinzu, die bidirektionalen Unicode-Text enthält, hebt jedoch nicht hervor, an welcher Stelle der Zeile sich diese Zeichen befinden. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit harmlosen Richtungsänderungen eingefügt werden.
Es ist unerlässlich, dass Entwickler und Code-Prüfer sensibilisiert sind. Aus diesem Grund haben wir ein Tutorial erstellt, das die Schwachstelle veranschaulicht. Derzeit ist dieses Tutorial für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie also mehr erfahren möchten, probieren Sie unsere Simulation (öffentliche Missionen) von Trojan Source aus und lesen Sie die Untersuchung zu Trojanischen Quellen.
Inhaltsverzeichnis
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
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: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.