Eine Analyse der xz-Hintertür, Teil 3
Diesmal geht es um das zentrale Shellskript des Angreifers: Wie es beim Paketbau Schadcode in die xz-Bibliothek liblzma einfügt und woher der Schadcode kommt.
Nun geht es endlich ans Eingemachte, der Schadcode im Build-Prozess baut Malware in das xz-Paket ein. Kleine Rekapitulation: Im ersten Teil dieser Serie haben wir nachvollzogen, wie der Angreifer das Build-System der "xz Utils" (im Folgenden nur "xz" genannt) unterwandert hat und warum er überhaupt xz aufs Korn genommen hat, obwohl er es letztlich auf OpenSSH abgesehen hatte. Teil zwei hat dann nachgezeichnet, wie das erste Shellskript des Angreifers in der Testdatei bad-3-corrupt_lzma2.xz versteckt war, wie es von dort extrahiert wurde und was es tut: Im Wesentlichen extrahiert es ein weiteres Shellskript aus einer weiteren angeblichen Testdatei (good-large_compressed.lzma) und führt es aus.
In diesem Teil der Serie geht es nun um dieses zweite Shellskript. Es fällt mit knapp 250 Zeilen zu umfangreich aus, um es im Artikel vollständig wiederzugeben. Wir haben für Sie aber sowohl die originale Variante als auch eine, die wir zur besseren Lesbarkeit formatiert und kommentiert haben verlinkt.
Der Angreifer hingegen hat versucht, die Lesbarkeit des Skripts so gering wie möglich zu halten. Das sieht man schon an den ersten Zeilen, die eine Reihe von Variablen definieren. Eigentlich ist das gute Praxis, aber die hier definierten Variablen tragen nichtssagende einzelne Buchstaben als Namen. Die ihnen zugewiesenen Werte sind ein Sammelsurium, das unter anderem aus Compiler-Flags (-fPIC -DPIC -fno-lto -ffunction-sections -fdata-sections
), regulären Ausdrücken (^pic_flag=\" -fPIC -DPIC\"$
) und Code-Fragmenten (__get_cpuid(
) besteht. Zwei Variablen verweisen auf die manipulierten Testdateien (p="good-large_compressed.lzma"
und U="bad-3-corrupt_lzma2.xz"
). Der Code wurde aus diesen Dateien extrahiert, aber offenbar wird er auch mit diesen Dateien arbeiten.