Forscher haben eine Methode beschrieben, mit der böswillige Akteure Schwachstellen in den Quellcode einschleusen könnten, die für menschliche Codeprüfer unsichtbar sind.
In einem Fachbeitrag, der diese Woche veröffentlicht wurde, schrieben zwei Forscher der University of Cambridge im Vereinigten Königreich, dass die Methode – die sie „Trojan Source“ nennen – im Wesentlichen gegen nahezu jede heute verwendete Programmiersprache eingesetzt werden kann und bei Lieferkettenangriffen ähnlich dem im vergangenen Jahr gegen SolarWinds gestarteten Angriff erfolgreich sein könnte.
„Da sich mit diesen Techniken problemlos wirkungsvolle Lieferkettenangriffe starten lassen, müssen Unternehmen, die an einer Softwarelieferkette beteiligt sind, unbedingt Schutzmaßnahmen ergreifen“, schrieben Nicholas Boucher und Ross Anderson in ihrem Fachbeitrag. „Wir haben Gegenmaßnahmen erörtert, die auf verschiedenen Ebenen der Softwareentwicklungs-Toolchain eingesetzt werden können: in der Sprachspezifikation, im Compiler, im Texteditor, im Code-Repository und in der Build-Pipeline.“
Auf einer Website schrieben sie: „Wenn es einem Angreifer gelingt, durch die Täuschung menschlicher Prüfer gezielte Schwachstellen in Open-Source-Code einzuschleusen, wird die nachgelagerte Software die Schwachstelle wahrscheinlich übernehmen.“
Langfristige Lösungen werden von Compilern kommen, von denen die meisten bereits Schutz gegen einen verwandten Angriff bieten, schrieben sie.
Unicode ist der Schlüssel
Der Schlüssel ist, Unicode-Steuerzeichen zu verwenden, um Tokens im Quellcode auf Kodierungsebene umzuordnen, schrieben sie. Diese visuell umgeordneten Tokens können eine logisch korrekte, semantisch aber von der durch die logische Reihenfolge der Quellcode-Tokens dargestellten Logik abweichende Logik anzeigen.
Allerdings „halten sich Compiler und Interpreter an die logische Reihenfolge des Quellcodes, nicht an die visuelle Reihenfolge“, schrieben sie.
Die Trojan-Source-Methode ermöglicht es Cyberkriminellen, Code zu erstellen, der von Compilern auf eine Weise, von menschlichen Prüfern aber auf eine andere Weise interpretiert wird. Dadurch ist sämtlicher Quellcode gefährdet, erklärten die Forscher. Sie wiesen darauf hin, dass sie funktionierende Machbarkeitsnachweise für Angriffe in einer Reihe von Programmiersprachen erstellt hatten: C, C++, C#, JavaScript, Java, Rust, Go und Python. Sie fügten hinzu, dass dieselbe Methode wahrscheinlich auch mit anderen modernen Sprachen funktionieren würde.
Lesen Sie auch: Die besten Tools für Code-Debugging und Codesicherheit
Umgang mit umgeordneten Tokens
Die Forscher beschrieben außerdem eine Reihe von Techniken, mit denen sich die visuelle Umordnung von Quellcode-Tokens ausnutzen lässt, darunter „frühe Rückgaben“, durch die „eine Funktion vorzeitig beendet wird, indem eine return-Anweisung ausgeführt wird, die visuell innerhalb eines Kommentars zu liegen scheint“, schrieben sie.
Beim „Auskommentieren“ erscheint ein Kommentar visuell als Code, wird aber nicht ausgeführt. Bei „gedehnten Zeichenketten“ erscheinen Teile von Stringliteralen visuell als Code. Das hat dieselbe Wirkung wie das Auskommentieren und führt dazu, dass Zeichenkettenvergleiche fehlschlagen.
„Der Angriff besteht darin, in Kommentaren und Zeichenketten eingebettete Steuerzeichen zu verwenden, um Quellcodezeichen so umzuordnen, dass sich seine Logik ändert“, schrieben sie.
Dies ist auf zwei Wegen möglich. Der erste besteht darin, den bidirektionalen Unicode-Algorithmus (BiDi) anzugreifen, der unter CVD-2021-42574 verfolgt wird. Der Algorithmus bestimmt die Reihenfolge, in der Text angezeigt wird. Er unterstützt Sprachen, die von links nach rechts geschrieben werden, etwa Englisch und Russisch, ebenso wie solche, die von rechts nach links geschrieben werden, darunter Arabisch und Hebräisch.
„Bidi-Überschreibungen ermöglichen es, sogar Zeichen aus nur einem Schriftsystem in einer anderen Reihenfolge anzuzeigen, als es ihrer logischen Kodierung entspricht“, schrieben Boucher und Anderson. „Diese Tatsache wurde bereits ausgenutzt, um die Dateiendungen von Schadsoftware zu verschleiern, die per E-Mail verbreitet wurde, und um gegnerische Beispiele für Pipelines des maschinellen Lernens zur Verarbeitung natürlicher Sprache (NLP) zu erstellen.“
Die Forscher hielten ihre Arbeit 99 Tage lang unter Verschluss … als Teil einer umfassenden koordinierten Offenlegungsaktion
Ein weiterer Angriff nutzt Homoglyphen, also Zeichen, die visuell nahezu identisch sind. Er wird unter CVE-2021-42694.
Die Forscher hielten ihre Arbeit 99 Tage lang unter Verschluss, damit Compiler, Interpreter, Codeeditoren und Repositories im Rahmen einer umfassenden koordinierten Offenlegungsaktion Schutzmaßnahmen implementieren konnten.
Angriffe auf die Lieferkette
Die Entdeckung der Forscher könnte zu neuartigen Lieferkettenangriffen führen, die von Cyberkriminellen zunehmend eingesetzt werden. Das zeigt der SolarWinds-Angriff, bei dem eine in Russland ansässige Gruppe Schadcode in ein Update-Paket für die von den Kunden des Unternehmens eingesetzte Orion-Software zur Fernüberwachung und -verwaltung einschleuste. Kaseya und seine Kunden waren Opfer eines ähnlichen Angriffs.
Mit Trojan Source kann ein Angreifer „durch das Einschleusen von Unicode-Bidi-Überschreibungszeichen in Kommentare und Zeichenketten in den meisten modernen Sprachen syntaktisch gültigen Quellcode erzeugen, bei dem die Anzeigereihenfolge der Zeichen eine von der tatsächlichen Logik abweichende Logik darstellt“, schrieben die Forscher. „Im Grunde wandeln wir Programm A in Programm B um. Für einen menschlichen Codeprüfer könnte ein solcher Angriff schwer zu erkennen sein, da der gerenderte Quellcode vollkommen akzeptabel aussieht. Wenn die Änderung der Logik subtil genug ist, um bei nachfolgenden Tests unentdeckt zu bleiben, könnte ein Angreifer gezielte Schwachstellen einschleusen, ohne entdeckt zu werden.“
Schritte zum Schutz des Codes
Jon Gaines, Senior Application Security Consultant bei nVisium, teilte eSecurity Planet mit, dass Trojan Source eine interessante Angriffsfläche zeige. Er fügte hinzu, dass die von den Forschern vorgestellten Machbarkeitsnachweise nicht tatsächlich bösartig seien.
„In den Händen eines versierten Angreifers oder einer Gruppe, die die Methode tatsächlich als Waffe einsetzen kann, hätten wir jedoch definitiv eine gefährliche Situation“, sagte Gaines. „Dieses Szenario zeigt die proaktive Wirkung von Quellcodeprüfungen. Es wäre derzeit eine gute Best Practice, Code nicht zu kopieren und einzufügen. Es ist immer besser, ihn selbst neu zu schreiben. Außerdem können Sie Ihre IDE oder Texteditoren so konfigurieren, dass Unicode angezeigt wird.“
Die im Fachbeitrag beschriebenen Probleme seien ernst, müssten aber im Kontext betrachtet werden, erklärte Jake Williams, Mitgründer und CTO des Unternehmens für Incident Response BreachQuest.
„Um dies auszunutzen, müsste ein Angreifer in der Lage sein, Quellcode zu verändern, der anschließend vom Opfer in Binärform kompiliert wird“, sagte Williams gegenüber eSecurity Planet mit. „Das allein ist bereits gravierend. Die Schwachstellen missbrauchen Unicode-Verarbeitungsalgorithmen, damit Hintertüren bei der Quellcodeprüfung schwerer entdeckt werden. Wenn Sie den Quellcode vor der Kompilierung nicht auf Schwachstellen und Hintertüren prüfen, ändert sich Ihre Sicherheitslage durch die Offenlegung dieser Schwachstelle praktisch nicht.“
Er wies außerdem darauf hin, dass bereits zuvor Bedenken hinsichtlich der Unicode-Verarbeitung durch Compiler bestanden hätten. Diese Untersuchung habe gezeigt, wie weit verbreitet das Problem sei, sagte er.
Boucher und Anderson empfahlen einige Maßnahmen, die Unternehmen ergreifen können. Dazu gehört, Compiler, Interpreter und Build-Pipelines so auszustatten, dass sie „bei unbestimmten bidirektionalen Steuerzeichen in Kommentaren oder Stringliteralen sowie bei Bezeichnern mit verwechslungsfähigen Zeichen aus unterschiedlichen Schriftsystemen Fehler oder Warnungen ausgeben“.
Sie erklärten außerdem, dass Sprachspezifikationen nicht abgeschlossene bidirektionale Steuerzeichen in Kommentaren und Stringliteralen verbieten sollten und dass Codeeditoren und Repository-Frontends bidirektionale Steuerzeichen sowie verwechslungsfähige Zeichen aus unterschiedlichen Schriftsystemen durch visuelle Symbole oder Warnungen sichtbar machen sollten.
Alexey Vishnyakov, Leiter der Malware-Erkennung beim Expert Security Center von Positive Technologies, erklärte, die Schwachstelle sei real – aber nicht leicht auszunutzen.
„Ein Angreifer muss zunächst aus Fragmenten des umgeordneten Codes eine funktionierende Payload zusammenstellen. Das kann je nach Länge des Programmcodes Wochen oder sogar ein Jahr dauern“, sagte Vishnyakov in einer Stellungnahme. „Anschließend muss er ein Gadget entwickeln, das die Payload sowohl funktionsfähig als auch getarnt macht – ein weiteres zeitaufwendiges Projekt.
„Dies betrifft definitiv sämtliche Software, da jede Software in einer Programmiersprache geschrieben wird. Derzeit ist der Sicherheitsgemeinschaft jedoch kein Angriff bekannt, bei dem diese Technik eingesetzt wurde.“
Weiterführende Lektüre: Die besten Tools für das Schwachstellenmanagement