Wurm

40 Stunden gegen Stuxnet

27C3

Vier der fünf Sicherheitslücken, die der Stuxnet-Wurm ausnutzte, waren für Microsoft eine Überraschung - Zeroday-Exploits. Dennoch gelang es den Mitarbeitern des Konzerns recht schnell, eine zur Verfügung gestellte Probe auseinanderzunehmen.

Bruce Dang vom Microsoft Security Response Center (MSRC) hat auf dem 27. Chaos Communication Congress die Sicht des Windows-Entwicklers auf Stuxnet dargelegt. Er benötigte mit Hilfe seiner Kollegen etwa 40 Mannstunden, um den Wurm zu analysieren und die Schwachstellen in den betroffenen Windows-Systemen zu beseitigen.

Der erste Hinweis auf die Malware kam von dem weißrussischen Sicherheitsanbieter Virusblokada, der Dang den 1 MByte großen Wurm auf einem USB-Stick zur Verfügung stellte. Weitere Hinweise zu der Verbreitungsform des Wurms im Netzwerk kamen von den Sicherheitsexperten von Kaspersky.

Wurm von links

Stuxnet nutze zunächst die LNK-Schwachstelle bei der Verarbeitung von Verknüpfungen (.lnk) in Verbindung mit dem Nachladen der dazugehören Icons durch die Windows Shell, über die eine speziell präparierte Verknüpfung zur Ausführung von Schadcode verwendet werden kann - selbst bei deaktiviertem Autostart, was bei Windows 7 normalerweise der Fall ist. Dabei lädt die Funktion Loadlibrary() Icons über das LoadCPLModule.

Zunächst fanden die Microsoft-Mitarbeiter eine Lösung für die LNK-Schwachstelle: Künftig müssen Applets registriert sein, bevor sie Icons laden können. Microsoft veröffentlichte einen entsprechenden, außerplanmäßigen Patch im August 2010.

Rootkit als Überraschung

Die beiden Entwickler, die an der Analyse von Stuxnet arbeiteten, bemerkten kurz darauf, dass auf ihren jeweiligen Systemen - Windows XP und Windows 7 - ein neuer Treiber installiert war. Zunächst konnten sie sich nicht erklären, wie die Rootkits auf ihre jeweiligen Rechner gelangten.

Die Analyse der Prozess- und Event-Logs ergab, dass über den Task-Scheduler XML-Dateien erstellt, gelesen und neu geschrieben wurden - und zwar mit erhöhten Rechten von Localsystem. Dangs damalige Reaktion auf den Fund waren die Worte: "Holy shit, that's not good".

Der Fehler lag in unzureichenden Hash-Werten, die über das veraltete CRC32 für jede XML-Datei erstellt wurden. Ein einfaches Padding der XML-Datei und ein erneutes Hashing, bis der neue Hashwert wieder dem Original entsprach, trickste den Task-Scheduler so aus, dass er auch veränderte Dateien akzeptierte.

Zusammen mit den Task-Scheduler-Entwicklern kam man auf die Lösung, künftig Hash-Werte mit SHA256 zu erstellen.