Erklärung der Verschleierung in der Bash-Phase
- In xz/liblzma wurde eine Backdoor entdeckt. Sie betrifft OpenSSH-Server.
- Der Fokus liegt weniger auf der eingebetteten Binärdatei der Backdoor als auf dem anfänglichen Bash-Teil und der dabei verwendeten einfachen, aber cleveren Verschleierungsmethode.
- Dieser Artikel erklärt, wie die Bash-Phase verschleiert wird und wie sie extrahiert wird.
Bevor es losgeht
- Zwei Versionen von xz/liblzma (5.6.0 und 5.6.1) sind betroffen. Es gibt feine Unterschiede.
- Der Bash-Teil ist in drei Stufen (oder vier Stufen?) aufgeteilt, die von Stage 0 bis Stage 2 benannt werden.
- Auch „Stage 3“ wird erwähnt, ist aber möglicherweise noch nicht vollständig implementiert.
- Die verschleierten/verschlüsselten Stufen und die anschließende binäre Backdoor sind in zwei Testdateien versteckt.
Stage 0
- Der Startpunkt ist die Datei
m4/build-to-host.m4. Dieser Code wird irgendwo im Build-Prozess ausgeführt und extrahiert das Skript für Stage 1.
- Er liest Bytes aus der Testdatei, leitet sie an die Standardausgabe weiter und verwendet den Befehl
tr, um Zeichen auf andere Zeichen abzubilden.
Stage 1
- Eine Bash-Datei, die mit „####Hello####“ beginnt. Sie sorgt dafür, dass sie nur unter Linux ausgeführt wird.
- Sie verwendet
eval, um srcdir aus config.status zu extrahieren, und enthält eine komplexe Kette von head-Befehlen, die bestimmte Bytes überspringt und ausgibt.
- Mit dem Befehl
tr wird eine einfache Substitutionschiffre angewendet, danach wird mit xz entpackt und ausgeführt.
Stage 2
- Stage 2 ist ein Bash-Skript, das den eigentlichen Kompilierungsprozess verändert.
- Es scheint eine Art „Erweiterungs-/Patch“-System zu geben, mit dem neue Skripte ausgeführt werden können, ohne die Testdatei ständig weiter zu verändern.
- Es enthält Code, der
.o-Dateien extrahiert und in den Kompilierungs-/Linking-Prozess integriert.
Zusammenfassung
- Dieser Prozess ist stark verborgen und mit komplexen Mitteln ausschließlich aus Standard-Kommandozeilenwerkzeugen aufgebaut.
- Die dreistufige Ausführung und das „Erweiterungs“-System sind zukunftssicher angelegt, sodass die binären Testdateien später nicht erneut geändert werden müssen.
- Dass ein solcher Angriff eher zufällig entdeckt wurde, wirft in der Security-Community viele Fragen auf.
Meinung von GN⁺
- Dieser Artikel unterstreicht die Bedeutung von Software-Sicherheit und Supply-Chain-Angriffen. Er macht auf Schwachstellen aufmerksam, die im Software-Build-Prozess entstehen können, und erinnert an die Wichtigkeit von Code-Reviews und Security-Audits.
- Die Verschleierungstechniken und die mehrstufige Angriffsmethode zeigen, wie ausgefeilt Angreifer in Systeme eindringen können. Diese Techniken haben auch einen pädagogischen Wert für Security-Experten.
- Ähnliche Security-Tools oder Projekte mit vergleichbaren Funktionen sind etwa OWASP Dependency-Check oder Sonatypes Nexus Platform. Sie helfen dabei, Sicherheitslücken in Software-Abhängigkeiten zu identifizieren.
- Bei der Einführung solcher Techniken muss die Sicherheit in allen Phasen der Software-Supply-Chain gestärkt werden. Der Vorteil ist eine höhere Systemsicherheit, der Nachteil ist, dass Angriffe mit solchen Methoden schwer zu erkennen sein können.
- Dieser Vorfall zeigt zugleich die Stärken und Schwächen der Open-Source-Community. Community-basierte Reviews und Beiträge sind wichtig für Wachstum und Sicherheit von Projekten, zugleich besteht aber auch das Risiko böswilliger Mitwirkender.
Noch keine Kommentare.