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
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
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-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
