Zunächst möchten wir herzlich denjenigen Personen danken, die im Forum kernelmode.info aktiv sind, insbesondere R136a1 und EP_X0FF. Sie haben eine fundierte Analyse der Umgehung des Treibersignierungszwangs geliefert, die das Gesamtverständnis der Sache ungemein fördert.

Die folgende Analyse steht in engem Zusammenhang mit dem Red Paper von G Data über Uroburos, das am 28. Februar veröffentlicht wurde. Das Paper kann unter der folgenden Adresse heruntergeladen werden: https://secure.gd/dl-en-rp-Uroburos 
Für interessierte Forscherkollegen stellen wir die Hashsumme des Samples bereit, das für den vorliegenden Artikel verwendet wurde:
SHA256: 33460a8f849550267910b7893f0867afe55a5a24452d538f796d9674e629acc4
Bei der Datei handelt es sich um einen 64-Bit-Treiber, der 2011 kompiliert wurde.

Die meisten Rootkits nutzen die Modifizierung des Kernels bzw. das Kernel-Patching, um ihre Aktivitäten zu verschleiern und das Verhalten des infizierten Systems zu modifizieren. Zum Schutz des Betriebssystems Windows führte Microsoft bei den 64-Bit-Versionen eine neue Technologie ein. Die Kernel-Patch-Schutztechnologie (auch als „PatchGuard“ bezeichnet) prüft die Integrität des Windows Kernels, damit sichergestellt ist, dass keine entscheidenden Teile modifiziert werden. Wenn eine bösartige Modifizierung des Kernels erkannt wird, wird die Funktion KeBugCheckEx() ausgeführt, die mit einem Argument des Werts 0x109 (CRITICAL_STRUCTURE_CORRUPTION) als Fehlercode aufgerufen wird. Daraufhin wird das System abgeschaltet und ein „Bluescreen“ angezeigt.
Microsoft beschreibt, dass die Kernel-Patch-Schutztechnologie die folgenden Modifizierungen verhindert:

• Modifizierung der System Services Tables, z. B. durch Hooken der Tabelle KeServiceDescriptor
• Modifizierung der Interrupt Descriptor Table (IDT)
• Modifizierung der Global Descriptor Table (GDT)
• Nutzung von Kernel-Stacks, die vom Kernel nicht zugewiesen wurden
• Patching von Teilen des Kernels

Die Entwickler von Uroburos haben sich zur Umgehung des Kernel-Patch-Schutzes dieselben Inline-Hooks zunutze gemacht, die in unserem letzten Red Paper erläutert wurden. Ziel des Angreifers ist es, die Funktion KeBugCheckEx() zu hooken, um eine Verarbeitung des Fehlercodes 0x109 zu vermeiden.
Der folgende Screenshot zeigt das Codefragment, mit dem die Adresse von KeBugCheckEx() in qword_787D8 gespeichert wird:

Nachfolgender Screenshot zeigt, dass Uroburos prüft, ob der Fehlercode 0x109 ist:

Wenn Sie weitere Informationen über die von den Entwicklern genutzte Technik wünschen, empfehlen wir folgenden Link: http://www.codeproject.com/Articles/28318/Bypassing-PatchGuard

Rootkits sind meist Treiber, die im Kernelraum operieren. Um diese Art der Malware zu bekämpfen, hat Microsoft für die 64-Bit-Versionen von Windows Vista und für neuere Betriebssysteme eine Treibersignierungsrichtlinie entwickelt.  Zum Laden eines Treibers muss die .sys-Datei von einem authentifizierten Herausgeber signiert sein.
Entwickler können den Prozess des Treibersignierungszwangs in der Entwicklungsphase eines Treibers deaktivieren. Das heißt, Entwickler müssen in der Entwicklungsphase nicht jede kompilierte Treiberversion signieren. In diesem Fall wird der Desktop des betreffenden Computers geändert. Unten rechts auf dem Desktop wird die Meldung „Testmodus“ angezeigt. Der Name des Flags, mit dem der aktuelle Status der Richtlinie gespeichert wird, lautet g_CiEnabled. Der Wert von g_CiEnabled wird beim Startvorgang von Windows festgelegt. Er gilt während der Laufzeit als „statisch“. Windows geht also davon aus, dass der Wert korrekt gesetzt wurde und verändert ihn während der Laufzeit nicht.

Die Entwickler von Uroburos haben sich zur Deaktivierung des Treibersignierungszwangs neue Techniken zunutze gemacht. In unserem Fall haben sie eine Sicherheitslücke eines ordnungsgemäß signierten Treibers ausgenutzt, um die Richtlinie zu deaktivieren! Bei der Installation von Uroburos wird der VirtualBox-Treiber (Version 1.6.2) von Oracle auf dem Zielsystem installiert. Dieser Treiber (VBoxDrv.sys) ist signiert:

Dann wird eine Sicherheitslücke innerhalb des Treibers (CVE-2008-3431) ausgenutzt, um eine Adresse im Speicherbereich des Kernels aus dem Userland heraus (unter Nutzung von DeviceIoControl()) mit dem Wert 0 zu überschreiben. In unserem Fall haben die Angreifer diese Sicherheitslücke dazu genutzt, bei laufendem System g_CiEnabled zu überschreiben und den Treibersignierungszwang somit zu deaktivieren. Dadurch wurde der Wert von 1 (= wahr) auf 0 (= falsch) geändert. Windows wird dadurch in den Testmodus versetzt, obwohl beim Systemstart der Testmodus deaktiviert war. Im Testmodus ist es dann kein Problem mehr, den Rootkit-Treiber unbemerkt zu laden.

Wie bereits gesagt, handelt es sich bei Uroburos um sehr komplexe, besonders raffinierte Malware, die von Experten programmiert wurde. Diese Annahme bestätigt sich ein Mal mehr durch die oben erfolgte Analyse der Installationstechnik von Uroburos.
Die Entwickler mussten das Sicherheitskonzept von Microsoft Windows umgehen. Sie mussten Methoden zur Umgehung der Kernel-Patch-Schutztechnologie und des Treibersignierungszwangs finden. Die zur Umgehung des Kernel-Patch-Schutzes verwendete Technik ist im Internet dokumentiert und somit nicht ganz neu.
Was jedoch den Treibersignierungszwang angeht, ist es hier unseres Wissens zum ersten Mal der Fall, dass eine Malware eine Sicherheitslücke eines ordnungsgemäß signierten Treibers ausnutzt, um die Richtlinie zu deaktivieren!

Dieses Beispiel zeigt Grenzen des Signaturverfahrens auf. Im Allgemeinen ist das Ablaufdatum der Signatur so eingestellt, dass es mehrere Jahre nach der Erstellung eintritt. Falls eine Sicherheitslücke festgestellt wird, wird ein Patch bereitgestellt. Doch die alte Binärdatei ist noch verfügbar und gültig, es sei denn, das Zertifikat wird vom Autor/Signierer widerrufen und auf die Zertifikatsperrliste (CRL) gesetzt.
Doch das Sperren einer Signatur ist nur der erste Schritt des Schutzprozesses, da jedes System, das eine Signatur überprüfen muss, Zugang zu einer aktuellen Zertifikatsperrliste benötigt.

Auch wenn das System über eine aktuelle Zertifikatsperrliste verfügt, ist sicherlich davon auszugehen, dass die Entwickler von Uroburos gewieft genug sind, das vom Betriebssystem verwendete Prüfverfahren zu manipulieren, ohne dass der Benutzer darauf aufmerksam gemacht wird.

Erstmalig sehen wir hier also in der Praxis, wie mit diesen beiden Techniken die Schutzmechanismen von Windows ausgehebelt werden. Wir gehen natürlich davon aus, dass diese Techniken künftig auch von anderer Malware genutzt werden.

Sollten Sie als Leser einen Befall feststellen, der vom Rootkit Uroburos ausgelöst wurde, und in diesem Fall Hilfe benötigen, weitere technische Informationen wünschen oder Informationen zu diesem Fall beisteuern wollen, freuen wir uns über Ihre Kontaktaufnahme per E-Mail an folgende Adresse: intelligence@remove-this.gdata.de