C-Ko: September 2006

Beschreibung
SPI (Service Provider Interface) ist eine Erweiterungsschnittstelle des Winsock 2 Netzwerk-Stacks von Windows.

Was ist der Netzwerk-Stack?

TCP/IP oder einfach nur IP ist die umgangssprachliche Bezeichnung für das "Internet Protokoll". Über diese Protokollfamilie - zu der auch noch UDP, ICMP und verschiedene Hilfsprotokolle gehören - kommunizieren die Rechner im Internet.

NetBIOS oder SMB ist das "Windows Netzwerk" (Dateifreigaben).

Im Betriebssystem sind die Protokolle als "Stack" (IP-Stack, SMB-Stack) implementiert. Die Bezeichnung Stack (Stapel) kommt daher, dass in der Theorie/ Fachliteratur die Netzwerkprotokolle immer als imaginärer Stapel dargestellt werden.

Unter Windows benutzen die Programme eine Betriebssystemfunktion namens "Socket" (auch Winsock genannt) um auf den Stack zuzugreifen.

Der Netzwerk-Stack hat nichts mit dem berüchtigten "Stack Overflow" zu tun. Das ist eine andere Art von Stack.

Um den Netzwerk-Stack von Windows mit eigenen Funktionen zu erweitern - zum Beispiel durch neue Protokolle - gibt es SPI.

SPI-Service Provider können den ein- und ausgehenden Netzwerkverkehr belebig kontrollieren und verändern.

Auf was man achten sollte
Die Protokollnamen sind genauso nichtssagend wie die Namen der DLLs. Windows selbst benutzt SPI, unter anderem für QOS (Quality of Service) und diverse andere Sachen (siehe Bild).

Einige Personal Firewalls (McAfee) benutzen SPI. Schadprogramme benutzen SPI nur selten (die Programmierung ist nicht ganz einfach, und die meisten Malware-Programmierer sind Idioten).

Um Schadprogramme zu finden, muss man jede einzelne DLL überprüfen. Auch hier sind wieder die Digitalen Signaturen der Systemdateien hilfreich. Mit dem Kommandozeilenprogramm Sysinternals Sigcheck kann man den von IceSword angezeigten DLL Path aus dem Beispiel (Bild) einfach abtippen (wenn das Programm sigcheck.exe im Path ist):

C:\>sigcheck %SystemRoot%\system32\msafd.dll

Sigcheck v1.3
Copyright (C) 2004-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\winnt\system32\msafd.dll:
Verified: Signed
Signing date: 13:59 12.05.2005
Publisher: Microsoft Corporation
Description: Microsoft Windows Sockets 2.0 Service Provider
Product: Microsoft(R) Windows (R) 2000 Operating System
Version: 5.00.2195.6602
File version: 5.00.2195.6602

Wenn die DLL keine Digitale Signatur hat, kann man nur versuchen sie über den Namen, Datum oder Dateieigenschaften einem installiertem Programm zuzuordnen. Wobei Schadprogramme immer gerne gefälschte Herstellerangaben führen. Ohne Digitale Signatur kann man die Dateieigenschaften bestenfalls als "Behauptung" nehmen.

Was IceSword nicht findet
Neben der offiziellen SPI-Schnittstelle gibt es noch die Möglichkeit in guter alter Rootkit-Art mit Inline Function Hooks den Stack bzw. Netzwerktreiber zu manipulieren. So funktionieren viele Personal Firewalls. Inline Hooks werden von IceSword nicht angezeigt (außer SSDT Hooks).

Andere Werkzeuge
Sysinternals Sigcheck. Überprüft die in allen Systemdateien eingebetteten digitalen Signaturen.

Sysinternals Autoruns. SPI heißt dort "Winsock Providers". Kann im Gegensatz zu IceSword Digitale Signaturen überprüfen.

Gegen Inline Hooks gibt es diverse Mittelchen. SVV, VICE, ApiHookCheck. Sind aber alle nicht besonders zuverlässig.

Informationen
Unraveling the Mysteries of Writing a Winsock 2 Layered Service Provider. Microsoft

Auf der Website zcodec.com wird ein angeblicher "multimedia compressor/decompressor" (Codec) angeboten.

zCodec is a multimedia compressor/decompressor which registers into the Windows collection of multimedia drivers and integrates with any application using DirectShow and Microsoft Video for Windows. zCodec will highly increase quality of video files you play.

zCodec enhances your music listening experience by improving the sound quality of video files sound, MP3, internet radio, Windows Media and other music files. Renew stereo depth, add 3D surround sound, restore sound clarity, boost your audio levels, and produce deep, rich bass sounds.

Dateiname ist ZCodec1000.exe. Dieser "Codec" ist ein klassisches trojanisches Pferd.

Der Zcodec Installer installierte bei mehreren Tests unter anderem zwei verwandte Rootkits (im folgenden TEIL1 und TEIL2 genannt, offenbar Varianten von "Ruins", dieser Name taucht teilweise auch als Registry-Schlüssel auf). Außerdem weitere Malware-Komponenten die nicht näher untersucht wurden. Bei einem Versuch wurde zusätzlich zum Ruins Rootkit von einem per DLL-Injection ferngesteuerten IE-Prozess die Software "Monaco Gold Casino" geladen. Die Casino-Software wurde nicht näher untersucht.

Die Rootkits und das Casino sind nicht im Installer enthalten. Sie werden von Websites in der Ukraine und in Canada nachgeladen. Die IPs sind 85.255.117.107 und 69.50.190.131. Bei jedem Aufruf werden leicht unterschiedliche EXEs geladen.

TEIL1 wird von McAfee Version 4847 als "Spy-Agent.bc" erkannt, von BitDefender Version 7.2 als "MemScan:Trojan.Agent.QB", von NOD32v2 Version 1.1744 als "a variant of Win32/Small.FB". Stand aller aller Scanner ist der 7.9.2006 oder der 8.9.2006. Alle anderen Scanner, die von Virustotal angeboten werden, haben die EXE nicht erkannt. Erkennung von TEIL2 wurde nicht getestet.

Laut einer Analyse von Panda Software überwacht die Software Zugriffe auf bestimmte Porno-Websites. Das genaue Verhalten ist nicht bekannt.

Der Zcodec-Installer verbiegt die DNS Einträge von Windows auf die IP-Adressen 85.255.115.3 (Primär) und 85.255.112.10.

Die manipulierten DNS Einträge dienen vermutlich dazu den Aufruf von Suchergebnissen zu kontrollieren. Bei einem Test mit Google wurde beim Klick auf die Suchergebnisse eine Porno-Site und eBay geladen.

Analyse TEIL2 (vermutlich "Ruins" Rootkit)
Genau wie die anderen erkannten Varianten legt TEIL2 einen versteckten Autostart unter HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\System an. Typ ist REG_SZ, enthält Dateiname der EXE (ohne Pfad).

Beim Booten wird offenbar von der EXE Code in CSRSS.EXE injiziert. Danach gibt sich die EXE selbst einen neuen Dateinamen und beendet sich.

TEIL2 ist ein User-Mode Hooker, der in allen Benutzerprozessen Funktionen der Systembibliothek ntdll.dll mit Inline Function Hooks manipuliert. Es hat keinen erkennbaren Kernel-Mode Teil. Es gibt keinen Prozess und kein Treiber.

TEIL2 versteckt seine EXE-Datei und Registry Einträge. ~~Die Class-ID ist offenbar immer gleich: a199f5d8-9680-4463-ava4-5e10e008792f (siehe Bild).~~ Update: Das stimmt nicht. Die Class-ID ist offenbar ein Zufallswert.

TEIL2 wurde extrahiert und einzeln auf einem Testsystem gestartet.

Schnelltest TEIL2 vs Anti-Rootkit

System: Windows 2000 Pro SP4

ApiHookCheck 1.01, VICE 2.0 finden Hooks (VICE-Ausgabe so undurchschaubar wie immer)
SVV 2.3 zeigt "deep red" an, was auch immer das bedeutet
IceSword 1.18 findet Datei, Registry-Schlüssel, "Reboot and Monitor" erwischt den Injektor (EXE-Datei)
DarkSpy 1.0.5 findet Datei, Registry-Schlüssel
Sophos Anti-Rootkit 1.0 findet Datei und Registry Einträge (siehe Bild)
BlackLight Beta 2.2.1046 findet versteckte Datei
Bitdefender Rootkit Uncover v1.0 Beta 2 findet versteckte Datei
GMER 1.0.10.10122 findet einen Registry-Schlüssel (Test abgebrochen da extrem langsam)
AVG Anti-Rootkit Beta 1.0.0.13 findet versteckte Datei
Rootkit Unhoker 2.022 Intergrity Check meldet "Parasit" (obwohl die Software offiziell gar keine User-Mode Hooker erkennt)
Rootkit Revealer 1.7 findet nichts

Warum findet Rootkit Revealer nichts?
Vermutlich liegt das an der Architektur des Programms. ~~Rootkit Revealer startet einen Dienst als SYSTEM um den eigentlichen Scan durchzuführen. TEIL2 injiziert sich offenbar nicht in SYSTEM-Prozesse und bleibt daher unsichtbar.~~ Update: Diese Analyse ist vermutlich falsch. Update 2: Dieses Problem betrifft scheinbar nur Windows 2000. Unter Windows XP Pro SP2 wird das Rootkit erkannt. Update 3: War doch richtig. Rootkit Revealer findet TEIL2 nur wenn zwischen der Installation und dem Scan kein Reboot liegt. Rootkit installieren -> Reboot -> Scan: Rootkit Revealer findet nichts, getestet mit Windows 2000 und XP. Nur wenn man den Reboot wegläßt, wird es gefunden.

Entfernen
Die Entfernung mit Sophos Anti-Rootkit 1.0 funktionierte bei allen Varianten Problemlos. Andere Anti-Rootkits wurden nicht getestet.

Nach einer Infektion mit einem Malware-Rootkit wird empfohlen die Festplatte komplett zu löschen und das letzte Backup wiederherzustellen (vorher Image machen zur Beweissicherung). Wenn man mehrere Partitionen hat, sollte es ausreichen die mit dem Betriebssystem zu löschen. Ohne ihre Autostarts ist eventuell vorhandene Malware auf anderen Partitionen nur eine nutzlose Datei.

Fazit
User-Mode Hooker sind relativ schwierig zu finden. Am einfachsten ist noch die Suche nach den versteckten Objekten oder die Suche nach dem Injektor (mit IceSwords "Reboot and Monitor"). Da IceSword im Ring 0 (Kernel) arbeitet, können sich Prozesse von User-Mode Rootkits nicht verstecken.

Das simple Open Source Programm ApiHookCheck aus dem Jahr 2004 überraschte durch die beste Erkennungsleistung gegen Inline Function Hooks (neben SVV).

SVV (inzwischen auch Open Source) liefert wie üblich nur eine diffuse "Farbe" als Ergebniss. Mit der Option "/m" werden (fast) die selben Informationen wie bei ApiHookCheck angezeigt. Die Anzeige entspricht dann in etwa VICE ohne die ganzen Fehlalarme.

VICE hat die genauesten Erkennungsroutinen, erzeugt aber sehr viele Fehlalarme. Man muss die bösen Hooks unter hunderten von Schrottanzeigen herauslesen.

IceSword konnte mit seiner "Reboot and Monitor" Funktion als einziges Programm den Injektor bei seiner Arbeit erwischen.

Rootkit Unhooker hat offenbar eine Anti-Hook Routine zum Selbstschutz implementiert. Beim Start wird davor gewarnt, das eigentliche Programm erkennt aber keine User-Mode Hooks.

Das Versagen der meisten kommerziellen Scanner bei der Suche nach den versteckten Registry-Schlüsseln ist äußerst peinlich.

Rootkit Revealer versagte ~~total~~ fast total (siehe Text).

Ausgewählte Links