Was ist eine Trojaner-Quelle und wie gelangt sie in Ihren Quellcode?
Anfang November veröffentlichte die Universität Cambridge ihre Studie mit dem Titel „Trojan-Source“. Der Schwerpunkt dieser Studie liegt darauf, wie Backdoors mithilfe von gezielten Formatierungszeichen in Quellcode und Kommentaren versteckt werden können. Diese können zum Schreiben von Code verwendet werden, wobei der Compiler die Logik anders interpretiert als ein menschlicher Code-Prüfer.
Diese Sicherheitslücke ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke missbraucht wurde, beispielsweise um die tatsächliche Dateierweiterung einer Datei zu verbergen, indem der letzte Teil des Dateinamens umgekehrt wurde. 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 Code, der auf diesen Zeichen basiert, möglicherweise neu anordnen.Daher kann die Art und Weise, wie Editoren Code und Kommentare anzeigen, sich von der Art und Weise unterscheiden, wie Compiler Code und Kommentare analysieren, und sogar zu einer Vertauschung von Code und Kommentaren führen.
Bitte lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und die Hacker-Simulation von Trojan Source ausprobieren möchten, können Sie unsere kostenlose Version Public Mission testen und selbst erleben.
bidirektionaler Text
Eine der Trojaner-Quellangriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenführung von Texten mit unterschiedlicher Anzeigereihenfolge (z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links)) verarbeitet. Ausrichtung formatierte Zeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Zeichenreihenfolge anzuzeigen.
Die obige Tabelle enthält einige Bidi-Ersatzzeichen, die mit Angriffen in Verbindung stehen. Ein Beispiel:
RLI e d o c PDI
Die Abkürzung RLI steht für „Right-to-Left Isolation” (Isolierung von rechts nach links). Dabei wird der Text von seinem Kontext isoliert (durch PDI, Popular Direction Isolation) und von rechts nach links gelesen. Dies führt zu:
c o d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Überschreibungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden gezielte Formatierungszeichen in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Wäre da nicht RLO, würde ein E-Mail-Anhang mit dem Namen „myspecialexe.doc“ völlig harmlos aussehen (von rechts nach links gesteuert), doch die angezeigten Zeichen zeigen, dass der eigentliche Name „myspecialcod.exe“ lautet.
Der Trojan Source-Angriff fügt gezielte Formatierungszeichen in Kommentare und Zeichenfolgen im Quellcode ein, da diese Zeichen keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen verändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas ganz anderes liest als der Mensch.
Beispielsweise eine Datei, die in dieser Reihenfolge die folgenden Bytes enthält:
Die Zeichen werden entsprechend der Richtung neu sortiert, wie unten gezeigt.
Wenn kein Formatierungszeichen für die Ausrichtung angegeben wird, wird der Code wie folgt dargestellt:
RLO 反转最后一行中的右大括号为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, vermutlich noch weitere. Derzeit ignorieren normale Entwickler möglicherweise gezielte Formatierungszeichen im Quellcode, aber Neulinge zucken vielleicht nur mit den Schultern und denken sich nichts dabei. Darüber hinaus hängt die Sichtbarkeit dieser Zeichen stark von der IDE ab, sodass nicht garantiert werden kann, dass sie entdeckt werden.
Aber wie gelangt diese Schwachstelle überhaupt in den Quellcode? Erstens kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird und bösartige Code-Beiträge unbemerkt bleiben.Zweitens kann dies durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten von mehreren Anbietern angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen und uns darauf verlassen können. Wie können wir Quellcode filtern, der versteckte Hintertüren enthält?
Wer ist dafür verantwortlich?
Einerseits sollten Compiler und Compiler-Pipelines die Verwendung von Quellcodezeilen mit mehreren Richtungen verbieten, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatierungszeichen in Zeichenfolgen oder Kommentaren, die nicht hervorgehoben werden, die Richtungsänderung bis zum Zeilenende verlängern können.Im Allgemeinen sollte der Code-Editor verdächtige Unicode-Zeichen, wie z. B. Isomorphen und richtungsgebundene Formatierungszeichen, deutlich darstellen und hervorheben. Seit November fügt GitHub nun Warnmarkierungen und Meldungen in Codezeilen ein, die bidirektionalen Unicode-Text enthalten, obwohl es die Position dieser Zeichen in der Zeile nicht hervorhebt. Dies kann dennoch böswillige Richtungsänderungen sowie harmlose Richtungsänderungen ermöglichen.
Das Bewusstsein von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Aus diesem Grund haben wir eine Übung erstellt, um Schwachstellen zu veranschaulichen. Derzeit ist diese Übung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unsere Trojan Source-Simulation (öffentliche Aufgabe)aus und lesen Sie anschließend die Trojan Source-Studie.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
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 Studie mit dem Titel „Trojan-Source“. Der Schwerpunkt dieser Studie liegt darauf, wie Backdoors mithilfe von gezielten Formatierungszeichen in Quellcode und Kommentaren versteckt werden können. Diese können zum Schreiben von Code verwendet werden, wobei der Compiler die Logik anders interpretiert als ein menschlicher Code-Prüfer.
Diese Sicherheitslücke ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke missbraucht wurde, beispielsweise um die tatsächliche Dateierweiterung einer Datei zu verbergen, indem der letzte Teil des Dateinamens umgekehrt wurde. 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 Code, der auf diesen Zeichen basiert, möglicherweise neu anordnen.Daher kann die Art und Weise, wie Editoren Code und Kommentare anzeigen, sich von der Art und Weise unterscheiden, wie Compiler Code und Kommentare analysieren, und sogar zu einer Vertauschung von Code und Kommentaren führen.
Bitte lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und die Hacker-Simulation von Trojan Source ausprobieren möchten, können Sie unsere kostenlose Version Public Mission testen und selbst erleben.
bidirektionaler Text
Eine der Trojaner-Quellangriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenführung von Texten mit unterschiedlicher Anzeigereihenfolge (z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links)) verarbeitet. Ausrichtung formatierte Zeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Zeichenreihenfolge anzuzeigen.
Die obige Tabelle enthält einige Bidi-Ersatzzeichen, die mit Angriffen in Verbindung stehen. Ein Beispiel:
RLI e d o c PDI
Die Abkürzung RLI steht für „Right-to-Left Isolation” (Isolierung von rechts nach links). Dabei wird der Text von seinem Kontext isoliert (durch PDI, Popular Direction Isolation) und von rechts nach links gelesen. Dies führt zu:
c o d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Überschreibungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden gezielte Formatierungszeichen in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Wäre da nicht RLO, würde ein E-Mail-Anhang mit dem Namen „myspecialexe.doc“ völlig harmlos aussehen (von rechts nach links gesteuert), doch die angezeigten Zeichen zeigen, dass der eigentliche Name „myspecialcod.exe“ lautet.
Der Trojan Source-Angriff fügt gezielte Formatierungszeichen in Kommentare und Zeichenfolgen im Quellcode ein, da diese Zeichen keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen verändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas ganz anderes liest als der Mensch.
Beispielsweise eine Datei, die in dieser Reihenfolge die folgenden Bytes enthält:
Die Zeichen werden entsprechend der Richtung neu sortiert, wie unten gezeigt.
Wenn kein Formatierungszeichen für die Ausrichtung angegeben wird, wird der Code wie folgt dargestellt:
RLO 反转最后一行中的右大括号为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, vermutlich noch weitere. Derzeit ignorieren normale Entwickler möglicherweise gezielte Formatierungszeichen im Quellcode, aber Neulinge zucken vielleicht nur mit den Schultern und denken sich nichts dabei. Darüber hinaus hängt die Sichtbarkeit dieser Zeichen stark von der IDE ab, sodass nicht garantiert werden kann, dass sie entdeckt werden.
Aber wie gelangt diese Schwachstelle überhaupt in den Quellcode? Erstens kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird und bösartige Code-Beiträge unbemerkt bleiben.Zweitens kann dies durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten von mehreren Anbietern angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen und uns darauf verlassen können. Wie können wir Quellcode filtern, der versteckte Hintertüren enthält?
Wer ist dafür verantwortlich?
Einerseits sollten Compiler und Compiler-Pipelines die Verwendung von Quellcodezeilen mit mehreren Richtungen verbieten, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatierungszeichen in Zeichenfolgen oder Kommentaren, die nicht hervorgehoben werden, die Richtungsänderung bis zum Zeilenende verlängern können.Im Allgemeinen sollte der Code-Editor verdächtige Unicode-Zeichen, wie z. B. Isomorphen und richtungsgebundene Formatierungszeichen, deutlich darstellen und hervorheben. Seit November fügt GitHub nun Warnmarkierungen und Meldungen in Codezeilen ein, die bidirektionalen Unicode-Text enthalten, obwohl es die Position dieser Zeichen in der Zeile nicht hervorhebt. Dies kann dennoch böswillige Richtungsänderungen sowie harmlose Richtungsänderungen ermöglichen.
Das Bewusstsein von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Aus diesem Grund haben wir eine Übung erstellt, um Schwachstellen zu veranschaulichen. Derzeit ist diese Übung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unsere Trojan Source-Simulation (öffentliche Aufgabe)aus und lesen Sie anschließend die Trojan Source-Studie.
Anfang November veröffentlichte die Universität Cambridge ihre Studie mit dem Titel „Trojan-Source“. Der Schwerpunkt dieser Studie liegt darauf, wie Backdoors mithilfe von gezielten Formatierungszeichen in Quellcode und Kommentaren versteckt werden können. Diese können zum Schreiben von Code verwendet werden, wobei der Compiler die Logik anders interpretiert als ein menschlicher Code-Prüfer.
Diese Sicherheitslücke ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke missbraucht wurde, beispielsweise um die tatsächliche Dateierweiterung einer Datei zu verbergen, indem der letzte Teil des Dateinamens umgekehrt wurde. 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 Code, der auf diesen Zeichen basiert, möglicherweise neu anordnen.Daher kann die Art und Weise, wie Editoren Code und Kommentare anzeigen, sich von der Art und Weise unterscheiden, wie Compiler Code und Kommentare analysieren, und sogar zu einer Vertauschung von Code und Kommentaren führen.
Bitte lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und die Hacker-Simulation von Trojan Source ausprobieren möchten, können Sie unsere kostenlose Version Public Mission testen und selbst erleben.
bidirektionaler Text
Eine der Trojaner-Quellangriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenführung von Texten mit unterschiedlicher Anzeigereihenfolge (z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links)) verarbeitet. Ausrichtung formatierte Zeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Zeichenreihenfolge anzuzeigen.
Die obige Tabelle enthält einige Bidi-Ersatzzeichen, die mit Angriffen in Verbindung stehen. Ein Beispiel:
RLI e d o c PDI
Die Abkürzung RLI steht für „Right-to-Left Isolation” (Isolierung von rechts nach links). Dabei wird der Text von seinem Kontext isoliert (durch PDI, Popular Direction Isolation) und von rechts nach links gelesen. Dies führt zu:
c o d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Überschreibungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden gezielte Formatierungszeichen in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Wäre da nicht RLO, würde ein E-Mail-Anhang mit dem Namen „myspecialexe.doc“ völlig harmlos aussehen (von rechts nach links gesteuert), doch die angezeigten Zeichen zeigen, dass der eigentliche Name „myspecialcod.exe“ lautet.
Der Trojan Source-Angriff fügt gezielte Formatierungszeichen in Kommentare und Zeichenfolgen im Quellcode ein, da diese Zeichen keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen verändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas ganz anderes liest als der Mensch.
Beispielsweise eine Datei, die in dieser Reihenfolge die folgenden Bytes enthält:
Die Zeichen werden entsprechend der Richtung neu sortiert, wie unten gezeigt.
Wenn kein Formatierungszeichen für die Ausrichtung angegeben wird, wird der Code wie folgt dargestellt:
RLO 反转最后一行中的右大括号为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, vermutlich noch weitere. Derzeit ignorieren normale Entwickler möglicherweise gezielte Formatierungszeichen im Quellcode, aber Neulinge zucken vielleicht nur mit den Schultern und denken sich nichts dabei. Darüber hinaus hängt die Sichtbarkeit dieser Zeichen stark von der IDE ab, sodass nicht garantiert werden kann, dass sie entdeckt werden.
Aber wie gelangt diese Schwachstelle überhaupt in den Quellcode? Erstens kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird und bösartige Code-Beiträge unbemerkt bleiben.Zweitens kann dies durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten von mehreren Anbietern angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen und uns darauf verlassen können. Wie können wir Quellcode filtern, der versteckte Hintertüren enthält?
Wer ist dafür verantwortlich?
Einerseits sollten Compiler und Compiler-Pipelines die Verwendung von Quellcodezeilen mit mehreren Richtungen verbieten, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatierungszeichen in Zeichenfolgen oder Kommentaren, die nicht hervorgehoben werden, die Richtungsänderung bis zum Zeilenende verlängern können.Im Allgemeinen sollte der Code-Editor verdächtige Unicode-Zeichen, wie z. B. Isomorphen und richtungsgebundene Formatierungszeichen, deutlich darstellen und hervorheben. Seit November fügt GitHub nun Warnmarkierungen und Meldungen in Codezeilen ein, die bidirektionalen Unicode-Text enthalten, obwohl es die Position dieser Zeichen in der Zeile nicht hervorhebt. Dies kann dennoch böswillige Richtungsänderungen sowie harmlose Richtungsänderungen ermöglichen.
Das Bewusstsein von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Aus diesem Grund haben wir eine Übung erstellt, um Schwachstellen zu veranschaulichen. Derzeit ist diese Übung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unsere Trojan Source-Simulation (öffentliche Aufgabe)aus und lesen Sie anschließend die Trojan Source-Studie.
Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenDemo 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 Studie mit dem Titel „Trojan-Source“. Der Schwerpunkt dieser Studie liegt darauf, wie Backdoors mithilfe von gezielten Formatierungszeichen in Quellcode und Kommentaren versteckt werden können. Diese können zum Schreiben von Code verwendet werden, wobei der Compiler die Logik anders interpretiert als ein menschlicher Code-Prüfer.
Diese Sicherheitslücke ist neu, obwohl Unicode in der Vergangenheit bereits für böswillige Zwecke missbraucht wurde, beispielsweise um die tatsächliche Dateierweiterung einer Datei zu verbergen, indem der letzte Teil des Dateinamens umgekehrt wurde. 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 Code, der auf diesen Zeichen basiert, möglicherweise neu anordnen.Daher kann die Art und Weise, wie Editoren Code und Kommentare anzeigen, sich von der Art und Weise unterscheiden, wie Compiler Code und Kommentare analysieren, und sogar zu einer Vertauschung von Code und Kommentaren führen.
Bitte lesen Sie weiter, um mehr zu erfahren. Oder wenn Sie die Ärmel hochkrempeln und die Hacker-Simulation von Trojan Source ausprobieren möchten, können Sie unsere kostenlose Version Public Mission testen und selbst erleben.
bidirektionaler Text
Eine der Trojaner-Quellangriffe nutzt den Unicode-Bidi-Algorithmus (bidirektional), der die Zusammenführung von Texten mit unterschiedlicher Anzeigereihenfolge (z. B. Englisch (von links nach rechts) und Arabisch (von rechts nach links)) verarbeitet. Ausrichtung formatierte Zeichen können verwendet werden, um die Gruppierung neu zu organisieren und die Zeichenreihenfolge anzuzeigen.
Die obige Tabelle enthält einige Bidi-Ersatzzeichen, die mit Angriffen in Verbindung stehen. Ein Beispiel:
RLI e d o c PDI
Die Abkürzung RLI steht für „Right-to-Left Isolation” (Isolierung von rechts nach links). Dabei wird der Text von seinem Kontext isoliert (durch PDI, Popular Direction Isolation) und von rechts nach links gelesen. Dies führt zu:
c o d e
Allerdings verarbeiten Compiler und Interpreter Formatsteuerzeichen, einschließlich Bidi-Überschreibungen, in der Regel nicht, bevor sie den Quellcode analysieren. Wenn sie die Richtungsformatierungszeichen einfach ignorieren, analysieren sie:
e d o c
Alter Wein in neuen Schläuchen?
Natürlich ist das nichts Neues. In der Vergangenheit wurden gezielte Formatierungszeichen in Dateinamen eingefügt, um ihre bösartige Natur zu verschleiern. Wäre da nicht RLO, würde ein E-Mail-Anhang mit dem Namen „myspecialexe.doc“ völlig harmlos aussehen (von rechts nach links gesteuert), doch die angezeigten Zeichen zeigen, dass der eigentliche Name „myspecialcod.exe“ lautet.
Der Trojan Source-Angriff fügt gezielte Formatierungszeichen in Kommentare und Zeichenfolgen im Quellcode ein, da diese Zeichen keine Syntax- oder Kompilierungsfehler verursachen. Diese Steuerzeichen verändern die Anzeigereihenfolge der Codelogik, sodass der Compiler etwas ganz anderes liest als der Mensch.
Beispielsweise eine Datei, die in dieser Reihenfolge die folgenden Bytes enthält:
Die Zeichen werden entsprechend der Richtung neu sortiert, wie unten gezeigt.
Wenn kein Formatierungszeichen für die Ausrichtung angegeben wird, wird der Code wie folgt dargestellt:
RLO 反转最后一行中的右大括号为左大括号，反之亦然。执行此代码的结果将是：“你是管理员”。管理员支票被注释掉了，但是控制角色给人的印象是它仍然存在。
(Quelle: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
Wie wirkt sich das auf Sie aus?
Viele Sprachen sind anfällig für Angriffe: C, C++, C#, JavaScript, Java, Rust, Go und Python, vermutlich noch weitere. Derzeit ignorieren normale Entwickler möglicherweise gezielte Formatierungszeichen im Quellcode, aber Neulinge zucken vielleicht nur mit den Schultern und denken sich nichts dabei. Darüber hinaus hängt die Sichtbarkeit dieser Zeichen stark von der IDE ab, sodass nicht garantiert werden kann, dass sie entdeckt werden.
Aber wie gelangt diese Schwachstelle überhaupt in den Quellcode? Erstens kann dies passieren, wenn Quellcode aus nicht vertrauenswürdigen Quellen verwendet wird und bösartige Code-Beiträge unbemerkt bleiben.Zweitens kann dies durch einfaches Kopieren und Einfügen von Code aus dem Internet geschehen, was die meisten Entwickler schon einmal getan haben. Die meisten Unternehmen sind auf Softwarekomponenten von mehreren Anbietern angewiesen. Dies wirft die Frage auf, inwieweit wir diesem Code vollständig vertrauen und uns darauf verlassen können. Wie können wir Quellcode filtern, der versteckte Hintertüren enthält?
Wer ist dafür verantwortlich?
Einerseits sollten Compiler und Compiler-Pipelines die Verwendung von Quellcodezeilen mit mehreren Richtungen verbieten, es sei denn, eine Richtung ist streng auf Zeichenfolgen und Kommentare beschränkt. Beachten Sie, dass Richtungsformatierungszeichen in Zeichenfolgen oder Kommentaren, die nicht hervorgehoben werden, die Richtungsänderung bis zum Zeilenende verlängern können.Im Allgemeinen sollte der Code-Editor verdächtige Unicode-Zeichen, wie z. B. Isomorphen und richtungsgebundene Formatierungszeichen, deutlich darstellen und hervorheben. Seit November fügt GitHub nun Warnmarkierungen und Meldungen in Codezeilen ein, die bidirektionalen Unicode-Text enthalten, obwohl es die Position dieser Zeichen in der Zeile nicht hervorhebt. Dies kann dennoch böswillige Richtungsänderungen sowie harmlose Richtungsänderungen ermöglichen.
Das Bewusstsein von Entwicklern und Code-Reviewern ist von entscheidender Bedeutung. Aus diesem Grund haben wir eine Übung erstellt, um Schwachstellen zu veranschaulichen. Derzeit ist diese Übung für Java, C#, Python, GO und PHP verfügbar.
Wenn Sie mehr erfahren möchten, probieren Sie unsere Trojan Source-Simulation (öffentliche Aufgabe)aus und lesen Sie anschließend die Trojan Source-Studie.
Verzeichnis
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Demo buchen下载Ressourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Sicherheitsschulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Softwareentwicklungslandschaft anzupassen und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für verschiedene Positionen geeignet, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA-Mitarbeitern. Verschaffen Sie sich einen ersten Überblick nach Themen und Rollen und erfahren Sie, was unser Inhaltsverzeichnis 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.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
Cybermon 2025: Der Kampf gegen den Boss hat nun in SCW ganzjährig begonnen. Der Kampf um die Sicherheit von KI/LLM auf Stammesebene, die Entwicklung von Sicherheits-KI wird durch groß angelegte Modelle verstärkt.
Auslegung des Gesetzes zur Netzresilienz: Was bedeutet es, durch die Entwicklung von Design-Software Sicherheit zu erreichen?
Verstehen Sie die Anforderungen des EU-Gesetzes zur Netzresilienz (CRA), für wen es gilt und wie sich Ingenieurteams durch Designpraktiken, Schwachstellenprävention und Kompetenzaufbau für Entwickler darauf vorbereiten können.
Treibende Faktoren 1: Klare und messbare Erfolgskriterien
Enabler 1 ist der Auftakt zu unserer 10-teiligen Reihe über Erfolgsfaktoren. Er zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und schnellerer Reifung langfristiger Pläne in Verbindung gebracht werden kann.
