Was ist ein Trojaner-Quellcode und wie dringt er in den Quellcode ein?
Anfang November veröffentlichte die Universität Cambridge eine Studie mit dem Titel „Trojan Horse Source“. Diese Studie konzentrierte sich auf Methoden, um mithilfe von gerichteten Formatzeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Mit diesen Zeichen kann Code erstellt werden, dessen Logik vom Compiler anders interpretiert wird als von menschlichen Code-Reviewern.
Diese Schwachstelle ist neu. Allerdings wurde Unicode in der Vergangenheit missbräuchlich verwendet. Beispielsweise wurde Unicode verwendet, um die tatsächliche Dateiendung einer Datei wie folgt zu verbergen. Die Richtung des letzten Teils des Dateinamens umkehren. Jüngste 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 möglicherweise neu formatieren. Daher kann es vorkommen, dass Editoren Code und Kommentare anders oder in einer anderen Reihenfolge anzeigen als Compiler. Das Gleiche gilt für den Austausch von Code und Kommentaren.
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
Interaktiver Text
Eine dieser Trojaner-Quellcode-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text in unterschiedlichen Anzeigereihenfolgen wie Englisch (von links nach rechts) oder Arabisch (von rechts nach links) verarbeitet. Mit Hilfe von richtungsgebundenen Zeichen können Gruppen neu angeordnet und die Reihenfolge der Zeichen angezeigt werden.
Die obige Tabelle enthält einige der Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Zum Beispiel:
RLI Wir gehen zu c. PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
Allerdings verarbeiten Compiler und Interpreter in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode analysieren. Wenn die Formatzeichen für die Richtungsangabe einfach ignoriert werden, wird der folgende Inhalt analysiert.
私たちはcに行きます
Alten Wein in neue Flaschen füllen?
Natürlich ist dies nichts Neues. Bislang wurden Zeichen im Format für die Richtungsangabe in Dateinamen eingefügt, um ihre Schädlichkeit zu verbergen. Selbst wenn ein E-Mail-Anhang als „myspecialexe.doc” angezeigt wird, kann er völlig harmlos erscheinen, wenn er nicht für RLO (Right-to-Left Override) bestimmt ist. Die Zeichen präsentieren sich so, dass ihr eigentlicher Name „myspecialcod.exe” erkennbar wird.
Trojanische Pferde-Quellcode-Angriffe erzeugen keine Syntax- oder Kompilierungsfehler, sondern fügen Kommentare und Zeichenfolgen mit Steuerzeichen in den Quellcode ein. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik und veranlassen den Compiler, etwas völlig anderes als Menschen zu lesen.
Beispielsweise eine Datei, die die folgenden Bytes in der folgenden Reihenfolge enthält.
Die Reihenfolge wird anhand des Formatzeichens wie folgt sortiert:
Wenn die Richtungsspezifikationszeichen nicht explizit aufgerufen werden, wird der Code wie folgt gerendert.
RLO ersetzt in der letzten Zeile geschlossene Klammern durch öffnende Klammern. Das Gleiche gilt auch umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das Ergebnis „Sie sind Administrator“. Die Administratorprüfung ist zwar auskommentiert, aber die Steuerzeichen vermitteln den Eindruck, als wäre sie noch vorhanden.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つけられる保証はありません。
Wie gelangt diese Schwachstelle überhaupt in den Quellcode? Zunächst einmal kann dieses Problem auftreten, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, deren Beitrag durch bösartigen Code übersehen wurde. Zweitenskann es vorkommen, dass Entwickler, wie es früher häufig der Fall war, Code aus dem Internet kopieren und einfügen. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Daher stellt sich die Frage, inwieweit man diesem Code vertrauen kann und sollte. Wie kann man Quellcode auf versteckte Hintertüren überprüfen?
Wessen Problem ist das?
Auf der einen Seite sollten Compiler und Build-Pipelines keine mehrdimensionalen Quellcodezeilen zulassen, es sei denn, eine Dimension ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatzeichen in Zeichenfolgen und Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, sofern sie nicht entfernt werden.Im Allgemeinen sollten Code-Editoren fragwürdige Unicode-Zeichen wie Homoglyphen und Richtungsformatzeichen explizit rendern und hervorheben. Seit November fügt GitHub allen Zeilen mit bidirektionalem Unicode-Text ein Warnsymbol und eine Meldung hinzu. Es wird jedoch nicht hervorgehoben, wo sich diese Zeichen in der Zeile befinden.Trotzdem können neben harmlosen Richtungsänderungen auch böswillige Richtungsänderungen auftreten.
Es ist unerlässlich, dass Entwickler und Code-Reviewer sich dessen bewusst sind. Aus diesem Grund haben wir eine Schritt-für-Schritt-Anleitung erstellt, in der die Schwachstelle erläutert wird. Derzeit ist diese Anleitung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie uns aus: Trojaner-Quellcode-Simulation (öffentliche Mission)und lesen Sie die Trojaner-Quellcode-Untersuchung.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und konzentriert sich auf die Untersuchung von Schwachstellen und die Erstellung von Inhalten für Mission Labs und Coding Labs.
Anfang November veröffentlichte die Universität Cambridge eine Studie mit dem Titel „Trojan Horse Source“. Diese Studie konzentrierte sich auf Methoden, um mithilfe von gerichteten Formatzeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Mit diesen Zeichen kann Code erstellt werden, dessen Logik vom Compiler anders interpretiert wird als von menschlichen Code-Reviewern.
Diese Schwachstelle ist neu. Allerdings wurde Unicode in der Vergangenheit missbräuchlich verwendet. Beispielsweise wurde Unicode verwendet, um die tatsächliche Dateiendung einer Datei wie folgt zu verbergen. Die Richtung des letzten Teils des Dateinamens umkehren. Jüngste 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 möglicherweise neu formatieren. Daher kann es vorkommen, dass Editoren Code und Kommentare anders oder in einer anderen Reihenfolge anzeigen als Compiler. Das Gleiche gilt für den Austausch von Code und Kommentaren.
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
Interaktiver Text
Eine dieser Trojaner-Quellcode-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text in unterschiedlichen Anzeigereihenfolgen wie Englisch (von links nach rechts) oder Arabisch (von rechts nach links) verarbeitet. Mit Hilfe von richtungsgebundenen Zeichen können Gruppen neu angeordnet und die Reihenfolge der Zeichen angezeigt werden.
Die obige Tabelle enthält einige der Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Zum Beispiel:
RLI Wir gehen zu c. PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
Allerdings verarbeiten Compiler und Interpreter in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode analysieren. Wenn die Formatzeichen für die Richtungsangabe einfach ignoriert werden, wird der folgende Inhalt analysiert.
私たちはcに行きます
Alten Wein in neue Flaschen füllen?
Natürlich ist dies nichts Neues. Bislang wurden Zeichen im Format für die Richtungsangabe in Dateinamen eingefügt, um ihre Schädlichkeit zu verbergen. Selbst wenn ein E-Mail-Anhang als „myspecialexe.doc” angezeigt wird, kann er völlig harmlos erscheinen, wenn er nicht für RLO (Right-to-Left Override) bestimmt ist. Die Zeichen präsentieren sich so, dass ihr eigentlicher Name „myspecialcod.exe” erkennbar wird.
Trojanische Pferde-Quellcode-Angriffe erzeugen keine Syntax- oder Kompilierungsfehler, sondern fügen Kommentare und Zeichenfolgen mit Steuerzeichen in den Quellcode ein. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik und veranlassen den Compiler, etwas völlig anderes als Menschen zu lesen.
Beispielsweise eine Datei, die die folgenden Bytes in der folgenden Reihenfolge enthält.
Die Reihenfolge wird anhand des Formatzeichens wie folgt sortiert:
Wenn die Richtungsspezifikationszeichen nicht explizit aufgerufen werden, wird der Code wie folgt gerendert.
RLO ersetzt in der letzten Zeile geschlossene Klammern durch öffnende Klammern. Das Gleiche gilt auch umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das Ergebnis „Sie sind Administrator“. Die Administratorprüfung ist zwar auskommentiert, aber die Steuerzeichen vermitteln den Eindruck, als wäre sie noch vorhanden.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つけられる保証はありません。
Wie gelangt diese Schwachstelle überhaupt in den Quellcode? Zunächst einmal kann dieses Problem auftreten, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, deren Beitrag durch bösartigen Code übersehen wurde. Zweitenskann es vorkommen, dass Entwickler, wie es früher häufig der Fall war, Code aus dem Internet kopieren und einfügen. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Daher stellt sich die Frage, inwieweit man diesem Code vertrauen kann und sollte. Wie kann man Quellcode auf versteckte Hintertüren überprüfen?
Wessen Problem ist das?
Auf der einen Seite sollten Compiler und Build-Pipelines keine mehrdimensionalen Quellcodezeilen zulassen, es sei denn, eine Dimension ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatzeichen in Zeichenfolgen und Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, sofern sie nicht entfernt werden.Im Allgemeinen sollten Code-Editoren fragwürdige Unicode-Zeichen wie Homoglyphen und Richtungsformatzeichen explizit rendern und hervorheben. Seit November fügt GitHub allen Zeilen mit bidirektionalem Unicode-Text ein Warnsymbol und eine Meldung hinzu. Es wird jedoch nicht hervorgehoben, wo sich diese Zeichen in der Zeile befinden.Trotzdem können neben harmlosen Richtungsänderungen auch böswillige Richtungsänderungen auftreten.
Es ist unerlässlich, dass Entwickler und Code-Reviewer sich dessen bewusst sind. Aus diesem Grund haben wir eine Schritt-für-Schritt-Anleitung erstellt, in der die Schwachstelle erläutert wird. Derzeit ist diese Anleitung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie uns aus: Trojaner-Quellcode-Simulation (öffentliche Mission)und lesen Sie die Trojaner-Quellcode-Untersuchung.
Anfang November veröffentlichte die Universität Cambridge eine Studie mit dem Titel „Trojan Horse Source“. Diese Studie konzentrierte sich auf Methoden, um mithilfe von gerichteten Formatzeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Mit diesen Zeichen kann Code erstellt werden, dessen Logik vom Compiler anders interpretiert wird als von menschlichen Code-Reviewern.
Diese Schwachstelle ist neu. Allerdings wurde Unicode in der Vergangenheit missbräuchlich verwendet. Beispielsweise wurde Unicode verwendet, um die tatsächliche Dateiendung einer Datei wie folgt zu verbergen. Die Richtung des letzten Teils des Dateinamens umkehren. Jüngste 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 möglicherweise neu formatieren. Daher kann es vorkommen, dass Editoren Code und Kommentare anders oder in einer anderen Reihenfolge anzeigen als Compiler. Das Gleiche gilt für den Austausch von Code und Kommentaren.
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
Interaktiver Text
Eine dieser Trojaner-Quellcode-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text in unterschiedlichen Anzeigereihenfolgen wie Englisch (von links nach rechts) oder Arabisch (von rechts nach links) verarbeitet. Mit Hilfe von richtungsgebundenen Zeichen können Gruppen neu angeordnet und die Reihenfolge der Zeichen angezeigt werden.
Die obige Tabelle enthält einige der Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Zum Beispiel:
RLI Wir gehen zu c. PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
Allerdings verarbeiten Compiler und Interpreter in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode analysieren. Wenn die Formatzeichen für die Richtungsangabe einfach ignoriert werden, wird der folgende Inhalt analysiert.
私たちはcに行きます
Alten Wein in neue Flaschen füllen?
Natürlich ist dies nichts Neues. Bislang wurden Zeichen im Format für die Richtungsangabe in Dateinamen eingefügt, um ihre Schädlichkeit zu verbergen. Selbst wenn ein E-Mail-Anhang als „myspecialexe.doc” angezeigt wird, kann er völlig harmlos erscheinen, wenn er nicht für RLO (Right-to-Left Override) bestimmt ist. Die Zeichen präsentieren sich so, dass ihr eigentlicher Name „myspecialcod.exe” erkennbar wird.
Trojanische Pferde-Quellcode-Angriffe erzeugen keine Syntax- oder Kompilierungsfehler, sondern fügen Kommentare und Zeichenfolgen mit Steuerzeichen in den Quellcode ein. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik und veranlassen den Compiler, etwas völlig anderes als Menschen zu lesen.
Beispielsweise eine Datei, die die folgenden Bytes in der folgenden Reihenfolge enthält.
Die Reihenfolge wird anhand des Formatzeichens wie folgt sortiert:
Wenn die Richtungsspezifikationszeichen nicht explizit aufgerufen werden, wird der Code wie folgt gerendert.
RLO ersetzt in der letzten Zeile geschlossene Klammern durch öffnende Klammern. Das Gleiche gilt auch umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das Ergebnis „Sie sind Administrator“. Die Administratorprüfung ist zwar auskommentiert, aber die Steuerzeichen vermitteln den Eindruck, als wäre sie noch vorhanden.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つけられる保証はありません。
Wie gelangt diese Schwachstelle überhaupt in den Quellcode? Zunächst einmal kann dieses Problem auftreten, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, deren Beitrag durch bösartigen Code übersehen wurde. Zweitenskann es vorkommen, dass Entwickler, wie es früher häufig der Fall war, Code aus dem Internet kopieren und einfügen. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Daher stellt sich die Frage, inwieweit man diesem Code vertrauen kann und sollte. Wie kann man Quellcode auf versteckte Hintertüren überprüfen?
Wessen Problem ist das?
Auf der einen Seite sollten Compiler und Build-Pipelines keine mehrdimensionalen Quellcodezeilen zulassen, es sei denn, eine Dimension ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatzeichen in Zeichenfolgen und Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, sofern sie nicht entfernt werden.Im Allgemeinen sollten Code-Editoren fragwürdige Unicode-Zeichen wie Homoglyphen und Richtungsformatzeichen explizit rendern und hervorheben. Seit November fügt GitHub allen Zeilen mit bidirektionalem Unicode-Text ein Warnsymbol und eine Meldung hinzu. Es wird jedoch nicht hervorgehoben, wo sich diese Zeichen in der Zeile befinden.Trotzdem können neben harmlosen Richtungsänderungen auch böswillige Richtungsänderungen auftreten.
Es ist unerlässlich, dass Entwickler und Code-Reviewer sich dessen bewusst sind. Aus diesem Grund haben wir eine Schritt-für-Schritt-Anleitung erstellt, in der die Schwachstelle erläutert wird. Derzeit ist diese Anleitung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie uns aus: Trojaner-Quellcode-Simulation (öffentliche Mission)und lesen Sie die Trojaner-Quellcode-Untersuchung.
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und konzentriert sich auf die Untersuchung von Schwachstellen und die Erstellung von Inhalten für Mission Labs und Coding Labs.
Anfang November veröffentlichte die Universität Cambridge eine Studie mit dem Titel „Trojan Horse Source“. Diese Studie konzentrierte sich auf Methoden, um mithilfe von gerichteten Formatzeichen Hintertüren in Quellcode und Kommentaren zu verstecken. Mit diesen Zeichen kann Code erstellt werden, dessen Logik vom Compiler anders interpretiert wird als von menschlichen Code-Reviewern.
Diese Schwachstelle ist neu. Allerdings wurde Unicode in der Vergangenheit missbräuchlich verwendet. Beispielsweise wurde Unicode verwendet, um die tatsächliche Dateiendung einer Datei wie folgt zu verbergen. Die Richtung des letzten Teils des Dateinamens umkehren. Jüngste 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 möglicherweise neu formatieren. Daher kann es vorkommen, dass Editoren Code und Kommentare anders oder in einer anderen Reihenfolge anzeigen als Compiler. Das Gleiche gilt für den Austausch von Code und Kommentaren.
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
Interaktiver Text
Eine dieser Trojaner-Quellcode-Angriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenstellung von Text in unterschiedlichen Anzeigereihenfolgen wie Englisch (von links nach rechts) oder Arabisch (von rechts nach links) verarbeitet. Mit Hilfe von richtungsgebundenen Zeichen können Gruppen neu angeordnet und die Reihenfolge der Zeichen angezeigt werden.
Die obige Tabelle enthält einige der Bidi-Überschreibungszeichen, die mit Angriffen in Verbindung stehen. Zum Beispiel:
RLI Wir gehen zu c. PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
Allerdings verarbeiten Compiler und Interpreter in der Regel keine Formatsteuerzeichen, einschließlich Bidi-Overrides, bevor sie den Quellcode analysieren. Wenn die Formatzeichen für die Richtungsangabe einfach ignoriert werden, wird der folgende Inhalt analysiert.
私たちはcに行きます
Alten Wein in neue Flaschen füllen?
Natürlich ist dies nichts Neues. Bislang wurden Zeichen im Format für die Richtungsangabe in Dateinamen eingefügt, um ihre Schädlichkeit zu verbergen. Selbst wenn ein E-Mail-Anhang als „myspecialexe.doc” angezeigt wird, kann er völlig harmlos erscheinen, wenn er nicht für RLO (Right-to-Left Override) bestimmt ist. Die Zeichen präsentieren sich so, dass ihr eigentlicher Name „myspecialcod.exe” erkennbar wird.
Trojanische Pferde-Quellcode-Angriffe erzeugen keine Syntax- oder Kompilierungsfehler, sondern fügen Kommentare und Zeichenfolgen mit Steuerzeichen in den Quellcode ein. Diese Steuerzeichen ändern die Anzeigereihenfolge der Codelogik und veranlassen den Compiler, etwas völlig anderes als Menschen zu lesen.
Beispielsweise eine Datei, die die folgenden Bytes in der folgenden Reihenfolge enthält.
Die Reihenfolge wird anhand des Formatzeichens wie folgt sortiert:
Wenn die Richtungsspezifikationszeichen nicht explizit aufgerufen werden, wird der Code wie folgt gerendert.
RLO ersetzt in der letzten Zeile geschlossene Klammern durch öffnende Klammern. Das Gleiche gilt auch umgekehrt. Wenn Sie diesen Code ausführen, erhalten Sie das Ergebnis „Sie sind Administrator“. Die Administratorprüfung ist zwar auskommentiert, aber die Steuerzeichen vermitteln den Eindruck, als wäre sie noch vorhanden.
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つけられる保証はありません。
Wie gelangt diese Schwachstelle überhaupt in den Quellcode? Zunächst einmal kann dieses Problem auftreten, wenn Quellcode aus einer nicht vertrauenswürdigen Quelle verwendet wird, deren Beitrag durch bösartigen Code übersehen wurde. Zweitenskann es vorkommen, dass Entwickler, wie es früher häufig der Fall war, Code aus dem Internet kopieren und einfügen. Die meisten Unternehmen sind auf Softwarekomponenten verschiedener Anbieter angewiesen. Daher stellt sich die Frage, inwieweit man diesem Code vertrauen kann und sollte. Wie kann man Quellcode auf versteckte Hintertüren überprüfen?
Wessen Problem ist das?
Auf der einen Seite sollten Compiler und Build-Pipelines keine mehrdimensionalen Quellcodezeilen zulassen, es sei denn, eine Dimension ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatzeichen in Zeichenfolgen und Kommentaren die Richtungsänderung bis zum Zeilenende verlängern können, sofern sie nicht entfernt werden.Im Allgemeinen sollten Code-Editoren fragwürdige Unicode-Zeichen wie Homoglyphen und Richtungsformatzeichen explizit rendern und hervorheben. Seit November fügt GitHub allen Zeilen mit bidirektionalem Unicode-Text ein Warnsymbol und eine Meldung hinzu. Es wird jedoch nicht hervorgehoben, wo sich diese Zeichen in der Zeile befinden.Trotzdem können neben harmlosen Richtungsänderungen auch böswillige Richtungsänderungen auftreten.
Es ist unerlässlich, dass Entwickler und Code-Reviewer sich dessen bewusst sind. Aus diesem Grund haben wir eine Schritt-für-Schritt-Anleitung erstellt, in der die Schwachstelle erläutert wird. Derzeit ist diese Anleitung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie uns aus: Trojaner-Quellcode-Simulation (öffentliche Mission)und lesen Sie die Trojaner-Quellcode-Untersuchung.
目次
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
Die Leistungsfähigkeit von OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Ressourcen für den Einstieg
Securing the Future of Software: Why Secure Code Warrior and KnowBe4 Are Joining Forces
I am thrilled to announce today an upcoming strategic partnership between Secure Code Warrior and KnowBe4. KnowBe4 is a world-renowned leader in comprehensively managing human and agentic AI risk, making them the perfect partner to help us distribute foundational security awareness to organizations across the globe.
Post-Quantum Cryptography: Quantum Computers Will Break Today’s Encryption – Are You Ready?
Post-quantum cryptography (PQC) is critical for protecting data from quantum computing threats. Learn how “harvest now, decrypt later” exposes risk and how developers can prepare for quantum-safe security.
.png)