Mitternachtshacking

Gil Dabah, u.a. Autor des diStorm Disassembler hat in diesem Vortrag die Möglichkeiten des Binary Patchings am Beispiel von zwei Microsoft Lücken (VML, ANI) vorgestellt und dabei ein wenig Werbung für seinen Arbeitgeber ZERT (Zeroday Emergency Response Team) gemacht. Insgesamt war der Vortrag aber sehr ausgewogen, er hat nicht nur auf Vorteile des Binary Patchings hingewiesen sondern auch auf die möglichen Probleme und Gefahren und es den Teilnehmern überlassen, daraus ihren Schluss zu ziehen. Der Vortrag hat mir auch aus diesem Grund recht gut gefallen.

Patching wird von Gil definiert als Änderung von Daten oder Code, die das Verhalten eines Programms verändern. Das vielleicht bekannteste Beispiel von Binary Patching sind Game Cracks, nach deren Anwendung sich ein Spiel ohne zugehörige CD bzw. Registrierungscode spielen lässt.

Typische Probleme beim Patchen von Binaries sind:

• verschiedene Binary Versionen
• Code Änderungen / Verschiebungen des Programmcodes im Binary
• Kein Platz im Binary für Zusatzcode
• Konkurrierendes Hot Patching von Microsoft
• Windows File Protection, das Änderungen an Systembibliotheken verhindert
• Virenscanner Probleme (modifizierte Binaries)

Insgesamt ist daher das Ändern von Systemdateien gar nicht so einfach. Der Binärpatch kann auf verschiedene Art erzeugt werden:

PE-Patching

• Ein Portable Executable Binary ist ein komplettes ausführbares Programm unter Windows.
• Beim PE-Patching wird das komplette Programm angepasst, was auch Änderungen der PE-Struktur erfordert
• In kurzer Zeit nicht verläßlich durchzuführen, da meist größere Änderungen erforderlich sind
• Insgesamt sehr aufwendig

Per-Version Patching

• Jede einzelne Version eines Binaries wird passend gepatcht
• Benötigt alle vorhandenen Programmversionen
• Wenn einzelne Versionen unbekannt sind, kann der Patch nicht angewandt werden

Hot Patching Bytes

• Möglich, wenn der Patch nur an wenigen Stellen angewandt werden muss
• 7 Bytes sind oft nicht genug

Spot Patching

• Einfach, da lediglich Search & Replace verwendet wird
• Geht nicht, wenn z.B. die Patch-Signatur nicht statisch ist

Eine Lücke, für die ZERT einen Patch entwickelt hat ist die VML (Vector Markup Language) Lücke, ein Zeroday, der am 19.09.2006 von Adam Thomas von Sunbelt Software gefunden wurde. Die Lücke wurde zu diesem Zeitpunkt aktiv im Internet genutzt, um in Systeme einzubrechen. der VML-Bug ist ein einacher Stack-based Buffer Overflow in der Datei VGX.DLL, die von allen Internet Explorer 6 Versionen in Windows XP SP2 verwendet wird. DEP (Data Execution Prevention) würde vor dem Exploit schützen, wird jedoch standardmäßig beim IE nicht verwendet. Der Angriff benötigt lediglich fehlerhafte Attribute in der VML-Fill-Methode und ist daher einfach auszuführen. Ein typischer „surf and geht owned“-Exploit.

<v.rect><v.fill method=“AAAAAAA…“></v.fill></v.rect>

Das Patchen des VML-Binaries ging relativ einfach vonstatten, da VGX.DLL eine In-proc DLL ist die registriert und deregistriert werden kann. Der Ablauf erfolgt dann wie folgt:

1. Einlesen der VGS.DLL
2. Finden der Signatur
3. Patchen des Binaries
4. Speichern der gepatchten PATCHEDVGX.DLL
5. Deregistrieren der VGX.DLL
6. Registrieren der PATCHEDVGX.DLL

Beim ANI-Fehler musste zum Patchen eine andere Methode angewandt werden, da die USER32.DLL sich so nicht ändern lässt. Die verwendete Technik nennt sich in-memory patching:

1. Mittels knownDLLs die Patch-DLL jedem Prozeß hinzuladen
2. Im RAM die USER32.DLL finden und patchen

Allerdings wird diese Technik in 64 Bit Vista nicht mehr funktionieren, da nur signierte Bibliotheken geladen werden können.

Fazit und Risikomanagement:

• Don’t use 3rd-party patches!
• Do you trust patches from people that don’t own the source code?
• What about liability and vendor support?
• If not patched, you are already vulnerable!
• Do you want to stay unprotected?
• ZERT supplies source code of the patches

Am Ende bleibt es halt doch immer dem Sicherheitsbeauftragten und dem Administrator überlassen zu entscheiden, was sie tun wollen.