Darstellung der Autostart-Technik von TDSS

Originalartikel von Ding Plazo (Threats Analyst bei Trend Micro)

Die TDSS-Schädlingsfamilie bleibt eine ernste Gefahr für die Nutzer, vor allem wegen ihrer mächtigen Möglichkeiten der Verschleierung, dank derer die Malware ihre Hauptkomponenten vor den Sicherheitsanwendungen verstecken kann:


Es gibt TDSS-Varianten, die sehr “ertragsreiche” Sicherheitslücken für ihre Verbreitung nutzen. Exemplare einer neuen Variante WORM_TDSS.TX nutzt die berüchtigte LNK-Sicherheitslücke (durch Stuxnet zu zweifelhaftem Ruhm gelangt) für die Verbreitung.

Die Malware nutzt zwei Techniken für ihre Autostart-Routinen:

  • Zufällig gewählte Systemtreiber-Dateien (normalerweise in %Windows%\System32\Drivers) ändern ihren Ressourcen-Abschnitt und nutzen diese Tatsache, um direkt Festplatten-Sektoren zu lesen sowie um die DLL-Dateien für das eigene böswillige Verhalten zusammenzustellen.
  • Ändern des Master Boot Records (MBR) und somit Lesen von Festplatten-Sektoren und Zusammenstellen von DLL-Dateien für das eigene böswillige Verhalten.

Die zweite Technik wurde bereits im Blogeintrag „Mebroot-Variante agiert wie TDSS“ beschrieben. Deshalb konzentriert sich dieser Eintrag auf die erste Technik.

Die gepatchte und kompromittierte Datei hat Trend Micro als BKDR_TIDSERV.DZ identifiziert. TDSS zielt auf BootExecute-Anwendungen ab, die vom Session Manager (smss.exe) gestartet werden, bevor der initiale Befehl ((Winlogon in Windows XP) und verschiedene Subsysteme gestartet werden. Die User-Modus-Anwendungen laufen zu diesem Zeitpunkt noch nicht. BootExecute-Anwendungen müssen nativ sein, weil sie so früh laufen. Nativ heißt in diesem Zusammenhang, dass lediglich das Windows NT Native API verfügbar ist. Das Win32-Subsystem, bestehend aus Kernle-Modus win32k.sys Komponenten und User-Mode Client/Server Runtime CSRSS wurden zu diesem Zeitpunkt von SMSS noch nicht gestartet. Auch die Kernel32-Bibliothek steht BootExecute-Anwendungen noch nicht zur Verfügung:


Diese Anwendungen werden für spezielle Aufgaben genutzt, die auszuführen sind, bevor alles andere auf dem System startet. Nachdem der Session Manager diesen infizierten Treiber geladen hat, führt er den Entry Point des Treibers aus, der von der Malware so gesetzt ist, dass er auf den überschriebenen Code der Ressource-Sektion zeigt. Währenddessen bootet das System noch. Die Abbildung zeigt, wo TDSS in die Startup-Prozedur des Systems eingreift:

Der Malware-Code setzt seinen Buffer, indem er nt!ExAllocatePool aufruft und dann den Code in den allozierten Buffer schreibt. Danach führt er den ursprünglichen Entry Point des Treibers aus, bevor er API nt!IoRegisterPlugPlayNotification aufruft, die eine Callback-Routine ausführt, die auf den allozierten Buffer zeigt. Dies ist ein Teil des Codes, den TDSS nutzt,um obige Routine auszuführen:

.rsrc:FC5470B0 lea ecx, [ebx+364h]
.rsrc:FC5470B6 push ecx
.rsrc:FC5470B7 push ebx
.rsrc:FC5470B8 sub ebx, 8122F44Bh
.rsrc:FC5470BE add ebx, eax
.rsrc:FC5470C0 add ebx, edi
.rsrc:FC5470C2 push ebx
.rsrc:FC5470C3 push [ebp+arg_0]
.rsrc:FC5470C6 lea eax, [ebp+var_20]
.rsrc:FC5470C9 push eax
.rsrc:FC5470CA push 1
.rsrc:FC5470CC push 2
.rsrc:FC5470CE push 48399F96h
.rsrc:FC5470D3 push [ebp+var_4]
.rsrc:FC5470D6 call get_api
.rsrc:FC5470DB call eax ; {nt!IoRegisterPlugPlayNotification (8057f628)}
.rsrc:FC5470DB ; this will execute the callback routine, which is the
.rsrc:FC5470DB ; malware codes copied on allocated memory.
.rsrc:FC5470DB ;
.rsrc:FC5470DB ; this malware’s callback routine was computed in ebx.

Die Callback-Routine liest mehr Malware-Code direkt von der Festplatte, entschlüsselt ihn und führt die gelesenen Daten aus. TDSS stellt sicher, dass die korrekten Daten gelesen werden. Dann bereitet die Malware einige Zeichenketten vor, die sie mithilfe des DBGPrint API darstellen kann. Sie werden nur im Debug-Modus angezeigt. Dazu gehören:

  • “Everybody’s a jerk. You, me, this jerk. That’s just my philosophy“
  • “Dude, meet me in Montana XX00, Jesus (H. Christ)” oder auch
  • “I felt like putting a bullet between the eyes of every panda that wouldn’t screw to save it’s species.”

Dann erzeugt der Schädling zwei zufällige 8 Zeichen wie etwa \pccjapft\eyrkiuhi und stellt die folgenden Dateien in den Ordner:

  • Config.ini – Hauptkonfigurationsdatei der Malware,
  • Tdlcmd.dll – DLL Hauptdatei, die as Verhalten des Schädlings einschließlich der API-Hooks enthält,
  • Rsrc.dat – Originalressource der gepatchten SYS-Datei sowie
  • TMP file – Kopie von tdlcmd.dll

Dies ist ein Beispiel des Inhalts von Config.ini:

[main]
version=3.273
quote=Tempers are wearing thin. Let’s hope some robot doesn’t kill everybody
botid=72607dae-9d01-4c33-9a85-bc9ed0c92cf6
affid=20409
subid=0
installdate=3.9.2010 7:20:44
builddate=2.7.2010 5:13:9
rnd=73586283
[injector]
*=tdlcmd.dll
[tdlcmd]
version=3.82

Der Inhalt dieser Malware-Dateien wurde direkt von der Festplatte gelesen. Zuerst wird der gemeinsame Buffer alloziert mithilfe von “nt!IoAllocateMdl”, dann wird “atapi!IdePortDispatch” verwendet, um direkt von der Festplatte zu lesen und das Ergebnis in den Buffer zu stellen. Hier ein Beispiel:

seg000:810EF079 lea ecx, [ebp+var_6C]
seg000:810EF07C mov [eax+4], ecx
seg000:810EF07F mov eax, [esi+60h]
seg000:810EF082 dec byte ptr [esi+23h]
seg000:810EF085 sub eax, 24h ; ‚$‘
seg000:810EF088 push esi
seg000:810EF089 mov [esi+60h], eax
seg000:810EF08C push edi
seg000:810EF08D mov [eax+14h], edi
seg000:810EF090 call [ebp+arg_4] ; ss:0010:fc942814={atapi!IdePortDispatch (fc304852)}

Danach werden diese Daten entschlüsselt und nach der Zeichenkette TDLD gesucht – TDLF für Dateien oder TDLN für freie Blöcke.

Eine sorgfältige Analyse erlaubt es, die DLL-Hauptdatei zusammenzustellen, indem die Nutzung des APIs atapi!IdePortDispatch überwacht wird. Auf diese Weise erhält man ein perfektes Abbild der DLL-Datei. Diese kann mithilfe üblicher UPX—Software entpackt werden und in Debugger wie Ollydbg und IDAPro geladen werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*