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.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
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 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.
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.
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo 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 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.
Inhaltsübersicht
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Die Leistungsfähigkeit von OpenText Fortify + Secure Code Warrior
OpenText Fortify und Secure Code Warrior bündeln ihre Kräfte, um Unternehmen dabei zu helfen, Risiken zu reduzieren, Entwickler zu Sicherheits-Champions zu machen und Kundenvertrauen aufzubauen. Lesen Sie hier mehr darüber.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
Ressourcen für den Einstieg
OWASP Top 10 für LLM-Bewerbungen: Was ist neu, was hat sich geändert, und wie bleibt man sicher?
Bleiben Sie bei der Absicherung von LLM-Anwendungen mit den neuesten OWASP Top 10 Updates immer einen Schritt voraus. Entdecken Sie, was neu ist, was sich geändert hat und wie Secure Code Warrior Sie mit aktuellen Lernressourcen ausstattet, um Risiken in der generativen KI zu minimieren.
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
.png)
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
Die Vorteile eines Benchmarking der Sicherheitskompetenzen von Entwicklern
Der zunehmende Fokus auf sicheren Code und Secure-by-Design-Prinzipien erfordert, dass Entwickler von Beginn des SDLC an in Cybersicherheit geschult werden, wobei Tools wie Secure Code Warrior's Trust Score dabei helfen, ihre Fortschritte zu messen und zu verbessern.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
