Experten der University of Cambridge erläutern eine Schwachstelle, von der laut den Forschern quasi alle modernen Compiler betroffen sind. Bei dieser neuen Angriffsmethode wird eine legitime Funktion eines Entwicklungstools verwendet, bei der der Quellcode etwas anzeigt, aber etwas ganz anderes kompiliert (die Programmiersprache in die Programmiersprache eines bestimmten Computers übersetzt) wird. Das ist durch Steuerzeichen im Unicode machbar.
Meistens werden Steuerzeichen nicht mit dem restlichen Code auf dem Bildschirm angezeigt (es gibt allerdings Editors, die es tun), aber diese Zeichen verändern den Text auf eine bestimmte Weise. Diese Tabelle enthält beispielsweise die Codes des Unicode-Bidi-Algorithmus.
Wie Sie wahrscheinlich wissen, werden manche menschlichen Sprachen von links nach rechts geschrieben (z. B. Deutsch) und andere von rechts nach links (z. B. Arabisch). Wenn der Code nur eine Sprache enthält, ist das kein Problem. Aber wenn in einer Codezeile sowohl deutsche als auch arabische Wörter enthalten sind, stellt die Funktion Bidi override sicher, dass die Sprachen korrekt dargestellt werden.
In der Studie wurde diese Art von Code auch angewendet. Zum Beispiel, um in der Programmiersprache Python den Comment Terminator von der Mitte der Linie ans Ende zu verschieben. Mithilfe von RLI-Code versetzen die Forscher nur wenige Zeichen und ließen alles andere unberührt.
Auf der rechten Seite wird die Version angezeigt, die die Programmierer sehen, wenn sie den Quellcode überprüfen und auf der linken Seite wird angezeigt, wie der Code ausgeführt wird. Die meisten Compiler ignorieren Steuerzeichen. Jeder, der den Code überprüft, wird denken, dass die fünfte Linie nur ein harmloser Kommentar ist. Aber die versteckte Early-Return-Anweisung befielt dem Programm die Schritte auszulassen, die für die Abbuchung des Betrags erforderlich sind. In diesem Beispiel wird das Banking-Programm das Geld auszahlen, aber den Betrag nicht vom Konto abbuchen.
Warum ist das gefährlich?
Auf den ersten Blick erscheint die Schwachstelle zu simpel, um gefährlich zu sein. Wer wird unsichtbare Zeichen in einen Code einfügen, in der Hoffnung, dass die Quellcodeprüfer es nicht merken? Trotzdem ist das Problem ernst genug, um eine ID zu erhalten (CVE-2021-42574). Vor der Veröffentlichung des Berichts haben die Autoren die Entwickler der gängigsten Compiler benachrichtigt, damit sie ausreichend Zeit haben, um die Patches für die Sicherheitslücke bereitzustellen.
Im Bericht werden die grundlegenden Angriffsmöglichkeiten erklärt. Die zwei Ausführungsstrategien bestehen darin, einen Befehl in einem Kommentar zu verstecken und etwas in einer Linie zu verstecken, die auf dem Bildschirm angezeigt wird. Rein theoretisch ist es möglich genau die gegenteilige Wirkung zu erzielen: Einen Code erstellen, der wie ein Befehl aussieht, aber tatsächlich Teil eines Kommentars ist und deshalb nicht ausgeführt werden kann. Es ist davon auszugehen, dass es auch noch kreativere Methoden für den Exploit dieser Schwachstelle gibt.
Sie könnte z. B. für ausgefeilte Lieferkettenangriffe verwendet werden, indem ein Anbieter einem Unternehmen Code liefert, der korrekt aussieht, aber nicht so funktioniert, wie er sollte. Sobald das Produkt mit diesem Code auf den Markt kommt, kann die „alternative Funktion“ von Dritten ausgenutzt werden, um die Kunden anzugreifen.
Wie gefährlich ist die Schwachstelle wirklich?
Kurz nachdem der Bericht „Trojan Source: Invisible Vulnerabilities“ (Trojan Source: Unsichtbare Schwachstellen) veröffentlicht wurde, kritisierte der Programmierer Russ Cox den Inhalt. Er war, um es milde auszudrücken, vollkommen unbeeindruckt. Das begründete er folgendermaßen:
- Die Angriffsmethode ist nicht neu.
- Viele Code-Editors verwenden Syntax Highlighting, bzw. Code Coloring, um „unsichtbaren“ Code anzuzeigen.
- Patches für die Compiler seien nicht erforderlich – es reiche aus, den Code sorgfältig auf zufällige oder absichtliche Fehler zu überprüfen.
Tatsächlich gab es bereits 2017 Probleme mit den Steuerzeichen im Unicode. Auch die Probleme mit den Homoglyphen – Zeichen, die ähnlich aussehen, aber verschiedenen Code haben – sind nichts Neues und können ebenso dafür verwendet werden, veränderten Code zu verschleiern, damit er die manuelle Prüfung übersteht.
Allerdings leugnet Cox mit seiner kritischen Analyse das Problem nicht – er findet die Beschreibung einfach nur zu dramatisch. Ähnlich wie der apokalyptische Artikel von Brian Krebs „Trojan Source‘ Bug Threatens the Security of All Code“ (Trojan-Source-Schwachstelle bedroht die Sicherheit von allem Code).
Das Problem besteht tatsächlich, aber glücklicherweise ist die Lösung einfach. Alle bereits oder bald verfügbaren Patches werden die Kompilierung von Code mit solchen Zeichen blockieren. (Ein Beispiel ist die Sicherheitsbenachrichtigung der Entwickler von Rust-Compiler.) Wenn Sie eigene Buildtools für Softwareentwicklung verwenden, empfehlen wir Ihnen ähnliche Prüfungen durchzuführen, um sich zu vergewissern, dass sich im Quellcode keine Zeichen verstecken, die sich normalerweise nicht dort befinden sollten.
Die Gefahr von Lieferkettenangriffen
Viele Unternehmen beauftragen externe Dienstleister mit den Entwicklungsaufgaben oder verwenden vorgefertigte Open-Source-Module für ihre Projekte. Das ermöglicht Lieferkettenangriffe. Cyberkriminelle können Auftragnehmer kompromittieren oder Code in ein Open-Source-Projekt einbetten, der als Hintertür dient, um in der letzten Version der Software schädlichen Code einzuschleusen. Bei den Code-Audits werden solche Hintertüren in der Regel gefunden. Ist das nicht der Fall, dann erhalten die Kunden zwar Software von einer vertrauenswürdigen Quelle, können aber ihre Daten trotzdem verlieren.
Trojan Source ist ein Beispiel für einen weit ausgeklügelteren Angriff. Anstatt zu versuchen Megabytes an schädlichen Code in das Endprodukt zu schmuggeln, können die Angreifer diesen Ansatz verwenden, um Schadcode in wichtige Elemente der Software einzuschleusen, der sehr schwer zu entdecken ist und viele Jahre darauf ausgenutzt werden kann.
So können Sie sich schützen
Wir empfehlen Folgendes, um sich vor Angriffen nach der Trojan-Source-Methode zu schützen:
- Aktualisieren Sie alle Compiler, die Sie verwenden (wenn ein Patch dafür bereitgestellt wurde).
- Schreiben Sie außerdem Ihre eigenen Skripts, die eine gewisse Anzahl an Steuerzeichen im Quellcode entdecken können.
Zur Verhinderung von Lieferkettenangriffen ist es erforderlich sowohl manuelle Code-Audits als auch einige automatisierte Tests durchzuführen. Grundsätzlich ist es sinnvoll den eigenen Code aus der Perspektive eines Cyberverbrechers zu analysieren und Schwachstellen zu suchen, die den ganzen Sicherheitsmechanismus außer Gefecht setzen könnten. Wenn Ihnen unternehmenseigene Ressourcen für diese Art von Analysen fehlen, ziehen Sie in Betracht externe Experten damit zu beauftragen.