Trend Micro: Analyse der Duqu-2.0-Zero-Day-Sicherheitslücke
Blog von Jack Tang (Threat Analyst), Trend Micro
Die aktuellen, gezielten Duqu-2.0-Angriffe nutzten mehrere Zero-Day-Sicherheitslücken aus. Eine dieser Lücken war CVE-2015-2360, die von Microsoft mit dem Patch MS15-061 als Teil des „Patch Tuesday“ im Juni geschlossen wurde. Wie bei CVE-2015-1701 der Fall, handelt es sich auch hier um eine Lücke in der Win32k.sys-Datei, die von Angreifern gemeinhin dazu missbraucht wird, bestehende Techniken zum Schutz vor Sicherheitslücken zu umgehen.
Die Sicherheitslücke betrifft die Art und Weise, wie das Betriebssystem (OS) mit Fenstern umgeht. Um das zu verstehen, sind ein paar Hintergrundinformationen nötig:
- Will eine Anwendung ein Fenster anzeigen, muss sie zwei Schritte ausführen:
- Registrierung einer Fenster-Klasse. Dies veranlasst den Kernel des Betriebssystems, ein Window-Class-Objekt zu erstellen, das im Kernel-Space existiert und auf das ein Anwendungsprogramm nicht direkt vom Benutzermodus aus zugreifen kann. Die Struktur hat die Bezeichnung tagCLS. Das Window-Class-Objekt definiert Aussehen und Verhalten des Fensters.
- Erstellung eines Fensters mit dem Objekt der Klasse Fenster (Window Class Object), das im vorherigen Schritt registriert wurde. Im Verlauf des Prozesses erstellt der OS-Kernel ein Fenster-Objekt, das im Kernel-Space existiert und auf das ein Anwendungsprogramm nicht direkt vom Benutzermodus aus zugreifen kann. Diese Struktur hat die Bezeichnung tagWND.
- Jedes Fenster verfügt über eine “Fenster”-Prozedur (window procedure), um mit Window-Nachrichten (Messages) umzugehen. Die Prozedur wird entweder im Benutzer- oder Kernelmodus ausgeführt. Dies hängt vom Feld CSF_flags im Window-Class-Object ab. Wenn im CSF_flags-Feld “Server Side Proc” gesetzt ist, lässt sich die Window-Prozedur des Fensterobjekts im Kernelmodus ausführen. Fehlt dieses Flag, läuft die Window-Prozedur des Fensterobjekts im Benutzermodus ab. Stellt ein Anwendungsprogramm seine eigene Fensterprozedur bereit, die nicht mit der Standardprozedur übereinstimmt, wird sie ausschließlich im Benutzermodus ausgeführt: Entsprechend fehlt das Flag „Server Side Proc“ im CSF_flags-Feld des Window-Class-Objekts.
Abbildung 1: tagCLS-Struktur
Aus Abbildung 1 wird ersichtlich, dass das CSF_flags-Feld der tagCLS-Struktur eine 32-bit-Zahl darstellt. Jedes einzelne Bit steht dabei für eine ganz bestimmte Eigenschaft. Das erste Bit ist der Bezeichner für das „Server Side Proc“-Flag.
- win32.sys hat die Eigenschaft, in den Benutzermodus zu wechseln, um bestimmte Callback-Funktionen des Benutzermodus auszuführen und damit Aufgaben zu erledigen, die zum Benutzermodus passen. Diese Eigenschaft ist es, die häufig von Angreifern missbraucht wird.
Werfen wir einen Blick auf die Sicherheitslücke. Diese lässt sich in folgender Abbildung schematisch darstellen:
Abbildung 2: Angreifbarer Message-Handling-Prozess
Sobald der Kernel eine Window-Message (zum Beispiel von WM_Setlcon) erhält, bearbeitet er sie. Der Prozess ist recht lang. In die obige Abbildung habe ich daher nur diejenigen Teile aufgenommen, die mit der Sicherheitslücke im Zusammenhang stehen. Die Lücke besteht in Schritt 4: Es wird nicht überprüft, ob das tagCLS-Objekt gültig ist, nachdem es vom Benutzer- in den Kernelmodus zurückgewechselt ist und weiterhin Operationen auf dem tagCLS-Objekt ausführt. Dies stellt ein ernstes Sicherheitsproblem dar.
Wie die Sicherheitslücke ausgenutzt wird
Zwar ist diese Art Sicherheitslücke nicht einfach auszunutzen, da der Angreifer mit dem Funktionsmodell von win32k.sys sehr gut vertraut sein muss. Dennoch lässt sie sich mit mehreren verbreiteten Techniken missbrauchen, von denen ich eine mögliche hier aufführen will:
Abbildung 3: Mögliche Exploit-Methode
Nach Schritt 7 kann der Angreifer ein Fenster mit dem modifizierten tagCLS-Objekt erstellen, das den Bezeichner “Server Side Proc” hat. Folglich läuft die Fensterprozedur im Kernelmodus ab. Dadurch können Angreifer eigenen Code mit den größeren Rechten des Kernelmodus ausführen, was letztendlich dazu führt, dass das betroffene System vollständig übernommen werden kann.
Lösungen
Die effektivste Lösung für dieses Problem besteht im Einspielen des entsprechenden offiziellen Patches. Es sollte hier aber erwähnt werden, dass es sich bei dieser Lücke „lediglich“ um eine so genannte „Escalation-of-Privileges“-Sicherheitslücke handelt. Andere Angriffstechniken sind nötig, um fremden Code auf dem Zielsystem auch tatsächlich auszuführen. Lösungen, die Letzteres zu verhindern und zu entdecken versuchen, dürften für Administratoren von Nutzen sein.
