Was ist Trojaner-Software und wie gelangt sie in den Quellcode?
Anfang November veröffentlichte die Universität Cambridge folgende Forschungsergebnisse: Trojanisches Pferd – Quelle. Diese Studie konzentrierte sich auf die Möglichkeit, mithilfe von gerichteten Formatierungszeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Dies kann dazu genutzt werden, Code zu erstellen, den Compiler anders interpretieren als menschliche Code-Prüfer.
Zwar wurde Unicode in der Vergangenheit schon einmal böswillig eingesetzt, beispielsweise um die tatsächliche Dateinamenerweiterung einer Datei zu verbergen, doch diese Schwachstelle ist neu. Umkehrung der letzten Zeichen des Dateinamens. Jüngsten Untersuchungen zufolge ignorieren viele Compiler Unicode-Zeichen im Quellcode ohne Warnung, während Texteditoren, darunter auch Code-Editoren, Zeilen mit Kommentaren und Code auf dieser Grundlage neu formatieren können. Daher können Editoren Code und Kommentare in einer anderen Reihenfolge anzeigen als Compiler sie parsen. Dies gilt sogar dann, wenn Code und Kommentare vertauscht werden.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Hacking-Simulation von Trojan Source ausprobieren möchten, können Sie sich direkt über den kostenlosen Service anmelden. Erleben Sie selbst, wie es ist, eine öffentliche Aufgabe zu erfüllen.
bidirektionaler Text
Eine dieser Trojaner-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional). Dieser Algorithmus behandelt die Ausrichtung von Texten mit unterschiedlicher Anzeigereihenfolge, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Mit Hilfe von Richtungsformatierungszeichen können Gruppen neu angeordnet und die Zeichenreihenfolge angezeigt werden.
Die obige Tabelle enthält einige Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Beispielsweise:
RLI e d o c PD
Die Abkürzung RLI steht für „Right-to-Left Isolation“. Der Text wird vom Kontext (durch PDI getrennt) isoliert. Klicken Sie auf „Pop Directional Isolate“ und lesen Sie von rechts nach links. Das Ergebnis sieht wie folgt aus:
c o d e
Compiler und Interpreter verarbeiten jedoch in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode parsen. Wenn die Richtungsformatierungszeichen einfach ignoriert werden, wird der Code wie folgt geparst.
e d o c
Ein alter Wein in einer neuen Flasche?
Natürlich ist dies nichts Neues unter der Sonne. In der Vergangenheit wurden Richtungszeichen verwendet. Sie wurden in Dateinamen eingefügt, um ihre bösartige Natur zu verbergen. Eine E-Mail-Anhang mit dem Namen „myspecialexe.doc“ könnte völlig harmlos erscheinen, wenn es sich nicht um RLO (Right-to-Left Override) handeln würde, das darauf hinweist, dass der tatsächliche Name „myspecialcod.exe“ lautet.
Trojanische Code-Angriffe fügen Steuerzeichen in Kommentare und Zeichenfolgen im Quellcode ein. In solchen Fällen treten keine Syntax- oder Kompilierungsfehler auf. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas völlig anderes liest als das, was für Menschen lesbar ist.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
Die Ausrichtung wird für jedes Zeichen wie folgt neu angeordnet.
Wenn das Richtungsformatzeichen nicht explizit aufgerufen wird, wird der Code wie folgt gerendert.
RLO kehrt die schließende Klammer in der letzten Zeile in eine öffnende Klammer um und umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das folgende Ergebnis: „Sie sind Administrator.“ Die Administratorprüfung wurde auskommentiert, aber wenn man sich die Steuerzeichen ansieht, hat man den Eindruck, dass diese Prüfung immer 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?
C, C++, C#, JavaScript, Java, Rust, Go, Python und viele andere Sprachen sind anfällig für Angriffe, und es wird vermutet, dass noch mehr Sprachen anfällig für Angriffe sind. Nun mögen erfahrene Entwickler beim Anblick von Richtungszeichen im Quellcode die Stirn runzeln, aber Anfänger sollten vielleicht besser mit den Schultern zucken und sich keine Gedanken darüber machen. Außerdem hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nicht garantiert ist, dass sie entdeckt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Vor allem kann dies passieren, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, in der bösartige Code-Beiträge nicht auffallen. Zweitens kann dies auch passieren, wenn man einfach Code aus dem Internet kopiert und einfügt. Das haben die meisten unserer Entwickler schon einmal gemacht. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit dieser Code vertrauenswürdig und zuverlässig ist. Wie kann man Quellcode mit versteckten Hintertüren herausfiltern?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, sofern diese nicht streng auf Zeichenfolgen und Kommentare beschränkt sind.Beachten Sie, dass Zeichen zur Formatierung der Richtung von Zeichenfolgen oder Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, wenn sie nicht gepoppt werden. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur Formatierung der Richtung explizit rendern und hervorheben. Seit November fügt GitHub nun allen Codezeilen, die bidirektionalen Unicode-Text enthalten, ein Warnsymbol und eine Meldung hinzu. Die Zeilenposition dieser Zeichen wird jedoch nicht hervorgehoben. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit böswilligen Richtungsänderungen heimlich eingeschleust werden.
Da die Kommunikation zwischen Entwicklern und Code-Reviewern unerlässlich ist, haben wir einen Leitfaden zur Erläuterung von Schwachstellen erstellt. Derzeit ist diese Übung in Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unser Produkt aus: Trojan Source Simulation (öffentliche Mission) und lesen Sie Trojan Source Research.
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Demo-Termin vereinbaren
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 folgende Forschungsergebnisse: Trojanisches Pferd – Quelle. Diese Studie konzentrierte sich auf die Möglichkeit, mithilfe von gerichteten Formatierungszeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Dies kann dazu genutzt werden, Code zu erstellen, den Compiler anders interpretieren als menschliche Code-Prüfer.
Zwar wurde Unicode in der Vergangenheit schon einmal böswillig eingesetzt, beispielsweise um die tatsächliche Dateinamenerweiterung einer Datei zu verbergen, doch diese Schwachstelle ist neu. Umkehrung der letzten Zeichen des Dateinamens. Jüngsten Untersuchungen zufolge ignorieren viele Compiler Unicode-Zeichen im Quellcode ohne Warnung, während Texteditoren, darunter auch Code-Editoren, Zeilen mit Kommentaren und Code auf dieser Grundlage neu formatieren können. Daher können Editoren Code und Kommentare in einer anderen Reihenfolge anzeigen als Compiler sie parsen. Dies gilt sogar dann, wenn Code und Kommentare vertauscht werden.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Hacking-Simulation von Trojan Source ausprobieren möchten, können Sie sich direkt über den kostenlosen Service anmelden. Erleben Sie selbst, wie es ist, eine öffentliche Aufgabe zu erfüllen.
bidirektionaler Text
Eine dieser Trojaner-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional). Dieser Algorithmus behandelt die Ausrichtung von Texten mit unterschiedlicher Anzeigereihenfolge, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Mit Hilfe von Richtungsformatierungszeichen können Gruppen neu angeordnet und die Zeichenreihenfolge angezeigt werden.
Die obige Tabelle enthält einige Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Beispielsweise:
RLI e d o c PD
Die Abkürzung RLI steht für „Right-to-Left Isolation“. Der Text wird vom Kontext (durch PDI getrennt) isoliert. Klicken Sie auf „Pop Directional Isolate“ und lesen Sie von rechts nach links. Das Ergebnis sieht wie folgt aus:
c o d e
Compiler und Interpreter verarbeiten jedoch in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode parsen. Wenn die Richtungsformatierungszeichen einfach ignoriert werden, wird der Code wie folgt geparst.
e d o c
Ein alter Wein in einer neuen Flasche?
Natürlich ist dies nichts Neues unter der Sonne. In der Vergangenheit wurden Richtungszeichen verwendet. Sie wurden in Dateinamen eingefügt, um ihre bösartige Natur zu verbergen. Eine E-Mail-Anhang mit dem Namen „myspecialexe.doc“ könnte völlig harmlos erscheinen, wenn es sich nicht um RLO (Right-to-Left Override) handeln würde, das darauf hinweist, dass der tatsächliche Name „myspecialcod.exe“ lautet.
Trojanische Code-Angriffe fügen Steuerzeichen in Kommentare und Zeichenfolgen im Quellcode ein. In solchen Fällen treten keine Syntax- oder Kompilierungsfehler auf. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas völlig anderes liest als das, was für Menschen lesbar ist.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
Die Ausrichtung wird für jedes Zeichen wie folgt neu angeordnet.
Wenn das Richtungsformatzeichen nicht explizit aufgerufen wird, wird der Code wie folgt gerendert.
RLO kehrt die schließende Klammer in der letzten Zeile in eine öffnende Klammer um und umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das folgende Ergebnis: „Sie sind Administrator.“ Die Administratorprüfung wurde auskommentiert, aber wenn man sich die Steuerzeichen ansieht, hat man den Eindruck, dass diese Prüfung immer 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?
C, C++, C#, JavaScript, Java, Rust, Go, Python und viele andere Sprachen sind anfällig für Angriffe, und es wird vermutet, dass noch mehr Sprachen anfällig für Angriffe sind. Nun mögen erfahrene Entwickler beim Anblick von Richtungszeichen im Quellcode die Stirn runzeln, aber Anfänger sollten vielleicht besser mit den Schultern zucken und sich keine Gedanken darüber machen. Außerdem hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nicht garantiert ist, dass sie entdeckt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Vor allem kann dies passieren, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, in der bösartige Code-Beiträge nicht auffallen. Zweitens kann dies auch passieren, wenn man einfach Code aus dem Internet kopiert und einfügt. Das haben die meisten unserer Entwickler schon einmal gemacht. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit dieser Code vertrauenswürdig und zuverlässig ist. Wie kann man Quellcode mit versteckten Hintertüren herausfiltern?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, sofern diese nicht streng auf Zeichenfolgen und Kommentare beschränkt sind.Beachten Sie, dass Zeichen zur Formatierung der Richtung von Zeichenfolgen oder Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, wenn sie nicht gepoppt werden. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur Formatierung der Richtung explizit rendern und hervorheben. Seit November fügt GitHub nun allen Codezeilen, die bidirektionalen Unicode-Text enthalten, ein Warnsymbol und eine Meldung hinzu. Die Zeilenposition dieser Zeichen wird jedoch nicht hervorgehoben. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit böswilligen Richtungsänderungen heimlich eingeschleust werden.
Da die Kommunikation zwischen Entwicklern und Code-Reviewern unerlässlich ist, haben wir einen Leitfaden zur Erläuterung von Schwachstellen erstellt. Derzeit ist diese Übung in Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unser Produkt aus: Trojan Source Simulation (öffentliche Mission) und lesen Sie Trojan Source Research.
Anfang November veröffentlichte die Universität Cambridge folgende Forschungsergebnisse: Trojanisches Pferd – Quelle. Diese Studie konzentrierte sich auf die Möglichkeit, mithilfe von gerichteten Formatierungszeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Dies kann dazu genutzt werden, Code zu erstellen, den Compiler anders interpretieren als menschliche Code-Prüfer.
Zwar wurde Unicode in der Vergangenheit schon einmal böswillig eingesetzt, beispielsweise um die tatsächliche Dateinamenerweiterung einer Datei zu verbergen, doch diese Schwachstelle ist neu. Umkehrung der letzten Zeichen des Dateinamens. Jüngsten Untersuchungen zufolge ignorieren viele Compiler Unicode-Zeichen im Quellcode ohne Warnung, während Texteditoren, darunter auch Code-Editoren, Zeilen mit Kommentaren und Code auf dieser Grundlage neu formatieren können. Daher können Editoren Code und Kommentare in einer anderen Reihenfolge anzeigen als Compiler sie parsen. Dies gilt sogar dann, wenn Code und Kommentare vertauscht werden.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Hacking-Simulation von Trojan Source ausprobieren möchten, können Sie sich direkt über den kostenlosen Service anmelden. Erleben Sie selbst, wie es ist, eine öffentliche Aufgabe zu erfüllen.
bidirektionaler Text
Eine dieser Trojaner-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional). Dieser Algorithmus behandelt die Ausrichtung von Texten mit unterschiedlicher Anzeigereihenfolge, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Mit Hilfe von Richtungsformatierungszeichen können Gruppen neu angeordnet und die Zeichenreihenfolge angezeigt werden.
Die obige Tabelle enthält einige Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Beispielsweise:
RLI e d o c PD
Die Abkürzung RLI steht für „Right-to-Left Isolation“. Der Text wird vom Kontext (durch PDI getrennt) isoliert. Klicken Sie auf „Pop Directional Isolate“ und lesen Sie von rechts nach links. Das Ergebnis sieht wie folgt aus:
c o d e
Compiler und Interpreter verarbeiten jedoch in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode parsen. Wenn die Richtungsformatierungszeichen einfach ignoriert werden, wird der Code wie folgt geparst.
e d o c
Ein alter Wein in einer neuen Flasche?
Natürlich ist dies nichts Neues unter der Sonne. In der Vergangenheit wurden Richtungszeichen verwendet. Sie wurden in Dateinamen eingefügt, um ihre bösartige Natur zu verbergen. Eine E-Mail-Anhang mit dem Namen „myspecialexe.doc“ könnte völlig harmlos erscheinen, wenn es sich nicht um RLO (Right-to-Left Override) handeln würde, das darauf hinweist, dass der tatsächliche Name „myspecialcod.exe“ lautet.
Trojanische Code-Angriffe fügen Steuerzeichen in Kommentare und Zeichenfolgen im Quellcode ein. In solchen Fällen treten keine Syntax- oder Kompilierungsfehler auf. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas völlig anderes liest als das, was für Menschen lesbar ist.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
Die Ausrichtung wird für jedes Zeichen wie folgt neu angeordnet.
Wenn das Richtungsformatzeichen nicht explizit aufgerufen wird, wird der Code wie folgt gerendert.
RLO kehrt die schließende Klammer in der letzten Zeile in eine öffnende Klammer um und umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das folgende Ergebnis: „Sie sind Administrator.“ Die Administratorprüfung wurde auskommentiert, aber wenn man sich die Steuerzeichen ansieht, hat man den Eindruck, dass diese Prüfung immer 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?
C, C++, C#, JavaScript, Java, Rust, Go, Python und viele andere Sprachen sind anfällig für Angriffe, und es wird vermutet, dass noch mehr Sprachen anfällig für Angriffe sind. Nun mögen erfahrene Entwickler beim Anblick von Richtungszeichen im Quellcode die Stirn runzeln, aber Anfänger sollten vielleicht besser mit den Schultern zucken und sich keine Gedanken darüber machen. Außerdem hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nicht garantiert ist, dass sie entdeckt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Vor allem kann dies passieren, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, in der bösartige Code-Beiträge nicht auffallen. Zweitens kann dies auch passieren, wenn man einfach Code aus dem Internet kopiert und einfügt. Das haben die meisten unserer Entwickler schon einmal gemacht. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit dieser Code vertrauenswürdig und zuverlässig ist. Wie kann man Quellcode mit versteckten Hintertüren herausfiltern?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, sofern diese nicht streng auf Zeichenfolgen und Kommentare beschränkt sind.Beachten Sie, dass Zeichen zur Formatierung der Richtung von Zeichenfolgen oder Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, wenn sie nicht gepoppt werden. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur Formatierung der Richtung explizit rendern und hervorheben. Seit November fügt GitHub nun allen Codezeilen, die bidirektionalen Unicode-Text enthalten, ein Warnsymbol und eine Meldung hinzu. Die Zeilenposition dieser Zeichen wird jedoch nicht hervorgehoben. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit böswilligen Richtungsänderungen heimlich eingeschleust werden.
Da die Kommunikation zwischen Entwicklern und Code-Reviewern unerlässlich ist, haben wir einen Leitfaden zur Erläuterung von Schwachstellen erstellt. Derzeit ist diese Übung in Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unser Produkt aus: Trojan Source Simulation (öffentliche Mission) und lesen Sie Trojan Source Research.
Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Bericht anzeigenDemo-Termin vereinbaren
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 folgende Forschungsergebnisse: Trojanisches Pferd – Quelle. Diese Studie konzentrierte sich auf die Möglichkeit, mithilfe von gerichteten Formatierungszeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Dies kann dazu genutzt werden, Code zu erstellen, den Compiler anders interpretieren als menschliche Code-Prüfer.
Zwar wurde Unicode in der Vergangenheit schon einmal böswillig eingesetzt, beispielsweise um die tatsächliche Dateinamenerweiterung einer Datei zu verbergen, doch diese Schwachstelle ist neu. Umkehrung der letzten Zeichen des Dateinamens. Jüngsten Untersuchungen zufolge ignorieren viele Compiler Unicode-Zeichen im Quellcode ohne Warnung, während Texteditoren, darunter auch Code-Editoren, Zeilen mit Kommentaren und Code auf dieser Grundlage neu formatieren können. Daher können Editoren Code und Kommentare in einer anderen Reihenfolge anzeigen als Compiler sie parsen. Dies gilt sogar dann, wenn Code und Kommentare vertauscht werden.
Lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Hacking-Simulation von Trojan Source ausprobieren möchten, können Sie sich direkt über den kostenlosen Service anmelden. Erleben Sie selbst, wie es ist, eine öffentliche Aufgabe zu erfüllen.
bidirektionaler Text
Eine dieser Trojaner-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional). Dieser Algorithmus behandelt die Ausrichtung von Texten mit unterschiedlicher Anzeigereihenfolge, wie beispielsweise Englisch (von links nach rechts) und Arabisch (von rechts nach links). Mit Hilfe von Richtungsformatierungszeichen können Gruppen neu angeordnet und die Zeichenreihenfolge angezeigt werden.
Die obige Tabelle enthält einige Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Beispielsweise:
RLI e d o c PD
Die Abkürzung RLI steht für „Right-to-Left Isolation“. Der Text wird vom Kontext (durch PDI getrennt) isoliert. Klicken Sie auf „Pop Directional Isolate“ und lesen Sie von rechts nach links. Das Ergebnis sieht wie folgt aus:
c o d e
Compiler und Interpreter verarbeiten jedoch in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode parsen. Wenn die Richtungsformatierungszeichen einfach ignoriert werden, wird der Code wie folgt geparst.
e d o c
Ein alter Wein in einer neuen Flasche?
Natürlich ist dies nichts Neues unter der Sonne. In der Vergangenheit wurden Richtungszeichen verwendet. Sie wurden in Dateinamen eingefügt, um ihre bösartige Natur zu verbergen. Eine E-Mail-Anhang mit dem Namen „myspecialexe.doc“ könnte völlig harmlos erscheinen, wenn es sich nicht um RLO (Right-to-Left Override) handeln würde, das darauf hinweist, dass der tatsächliche Name „myspecialcod.exe“ lautet.
Trojanische Code-Angriffe fügen Steuerzeichen in Kommentare und Zeichenfolgen im Quellcode ein. In solchen Fällen treten keine Syntax- oder Kompilierungsfehler auf. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas völlig anderes liest als das, was für Menschen lesbar ist.
Beispielsweise eine Datei, die die folgenden Bytes in dieser Reihenfolge enthält:
Die Ausrichtung wird für jedes Zeichen wie folgt neu angeordnet.
Wenn das Richtungsformatzeichen nicht explizit aufgerufen wird, wird der Code wie folgt gerendert.
RLO kehrt die schließende Klammer in der letzten Zeile in eine öffnende Klammer um und umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das folgende Ergebnis: „Sie sind Administrator.“ Die Administratorprüfung wurde auskommentiert, aber wenn man sich die Steuerzeichen ansieht, hat man den Eindruck, dass diese Prüfung immer 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?
C, C++, C#, JavaScript, Java, Rust, Go, Python und viele andere Sprachen sind anfällig für Angriffe, und es wird vermutet, dass noch mehr Sprachen anfällig für Angriffe sind. Nun mögen erfahrene Entwickler beim Anblick von Richtungszeichen im Quellcode die Stirn runzeln, aber Anfänger sollten vielleicht besser mit den Schultern zucken und sich keine Gedanken darüber machen. Außerdem hängt die Visualisierung dieser Zeichen stark von der IDE ab, sodass nicht garantiert ist, dass sie entdeckt werden.
Aber wie konnte diese Schwachstelle überhaupt in den Quellcode gelangen? Vor allem kann dies passieren, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, in der bösartige Code-Beiträge nicht auffallen. Zweitens kann dies auch passieren, wenn man einfach Code aus dem Internet kopiert und einfügt. Das haben die meisten unserer Entwickler schon einmal gemacht. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Dies wirft die Frage auf, inwieweit dieser Code vertrauenswürdig und zuverlässig ist. Wie kann man Quellcode mit versteckten Hintertüren herausfiltern?
Wessen Problem ist das?
Einerseits sollten Compiler und Build-Pipelines keine Quellcodezeilen mit mehr als einer Richtung zulassen, sofern diese nicht streng auf Zeichenfolgen und Kommentare beschränkt sind.Beachten Sie, dass Zeichen zur Formatierung der Richtung von Zeichenfolgen oder Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, wenn sie nicht gepoppt werden. Im Allgemeinen sollten Code-Editoren verdächtige Unicode-Zeichen wie Homoglyphen und Zeichen zur Formatierung der Richtung explizit rendern und hervorheben. Seit November fügt GitHub nun allen Codezeilen, die bidirektionalen Unicode-Text enthalten, ein Warnsymbol und eine Meldung hinzu. Die Zeilenposition dieser Zeichen wird jedoch nicht hervorgehoben. Dadurch können weiterhin böswillige Richtungsänderungen zusammen mit böswilligen Richtungsänderungen heimlich eingeschleust werden.
Da die Kommunikation zwischen Entwicklern und Code-Reviewern unerlässlich ist, haben wir einen Leitfaden zur Erläuterung von Schwachstellen erstellt. Derzeit ist diese Übung in Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unser Produkt aus: Trojan Source Simulation (öffentliche Mission) und lesen Sie Trojan Source Research.
Inhaltsverzeichnis
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Demo-Termin vereinbarenDownloadHilfreiche Ressourcen für den Einstieg
Themen und Inhalte der Sicherheitsschulung
Die branchenweit besten Inhalte werden unter Berücksichtigung der Kundenrollen ständig weiterentwickelt und an die sich ständig verändernde Softwareentwicklungsumgebung angepasst. Es werden Themen angeboten, die alle Bereiche von KI bis hin zu XQuery-Injection abdecken und für verschiedene Rollen geeignet sind, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA-Mitarbeitern. Sehen Sie sich vorab an, was der Inhaltskatalog nach Themen und Rollen zu bieten hat.
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.
Hilfreiche Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
Cybermon 2025 Bit The Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Stärken Sie die Entwicklung von Sicherheits-KI in großem Maßstab durch den Einsatz fortschrittlicher KI/LLM-Sicherheitslösungen.
Erläuterung des Gesetzes zur Cyber-Resilienz: Bedeutung der Entwicklung von Sicherheitsdesign-Software
Erfahren Sie mehr über die Anforderungen und Anwendungsbereiche des EU-Cyberresilienzgesetzes (CRA) und darüber, wie sich Ingenieurteams durch Design, Praktiken, Schwachstellenvermeidung und die Einrichtung einer Entwicklerumgebung sicher vorbereiten können.
Erfolgsfaktor 1: Definierte und messbare Erfolgskriterien
Enabler 1 bietet eine zehnteilige Reihe von Erfolgsfaktoren, die zeigen, wie sichere Codierung zu Geschäftsergebnissen wie einer schnelleren Risikominderung und Kostensenkung für die Reifung langfristiger Programme beitragen kann.
