Original-URL des Artikels: https://www.golem.de/1012/80357.html    Veröffentlicht: 28.12.2010 12:20    Kurz-URL: https://glm.io/80357

Wurm

40 Stunden gegen Stuxnet

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.

Infektion per Tastaturlayout

Auf Windows-XP-Systemen gibt es diese Lücke nicht, dennoch konnte der Wurm auch hier das Rootkit installieren. Dang fiel bei der Analyse unter Windows XP auf, dass Stuxnet in der Datei Win32k.sys etwas suchte. Dann entdeckte er, dass Stuxnet über NtVirtualAllocateMemory Speicher alloziert und dass Tastaturlayouts geladen werden. Während ab Windows Vista die Layouts nur aus dem %system%-Pfad lädt, können sie unter Windows XP überall liegen.

Im Kernel-Modus wird aus den Layoutdateien ein Integerwert geladen, der als Index dient. Dabei wurde die Feldgrenze des geladenen Index aber nicht überprüft. Durch den daraus resultierenden Pufferüberlauf konnte Code mit erhöhten Rechten ausgeführt werden.

Drucker-Spooler als Wurmträger

Zudem verbreitete sich der Wurm unkontrolliert über das Netz. Hier kamen die Entwickler auf eine weitere Schwachstelle im Drucker-Spooler unter Windows XP. Da auch Gäste auf freigegebene Drucker im Netz zugreifen können, sie aber eigentlich nicht genügend Rechte besitzen, um den Druckauftrag auszuführen, übernimmt der Spooler den Auftrag und führt ihn als Systembenutzer aus.

Stuxnet gab über den Spooler den Befehl aus, Druckaufträge in eine Datei zu schreiben und verbreitete so eine EXE- und MOF-Datei. Diese Schwachstelle wurde mit Hilfe der zuständigen Programmierer ebenfalls behoben.

Zeitfresser Patcherstellung

Für die Analyse von Stuxnet haben Dang und seine Kollegen etwa 40 Stunden gebraucht, verteilt auf einen Zeitraum von drei bis vier Tagen. Sie wurden immer wieder von den neuen Sicherheitslücken überrascht - was Dang in seinem Vortrag häufig mit "What the fuck, dude." kommentierte. Eine große Hilfe war zudem das Moskauer Kaspersky-Team, das auf die Spooling-Lücke hingewiesen hatte, sagte Dang. Microsoft und Kaspersky haben ihr Wissen während der gesamten Zeit geteilt, obwohl Microsoft darauf aus war, zuerst mit der Analyse von Stuxnet fertig zu werden.

Die Entwicklung und das Testen der Patches hat dann allerdings länger gedauert. Die letzte Sicherheitslücke von Stuxnet wurde erst Mitte Dezember 2010 beseitigt. Hin und wieder wurde auch ein Patch verworfen, denn er hätte zu Kompatibilitätsproblemen führen können. Nachdem die letzte Lücke geschlossen wurde, darf Dang auch offen über die Sicherheitsprobleme sprechen - was er unumwunden tat.

Wer war's?

Dang wollte sich an den Spekulationen rund um den Urheber von Stuxnet nicht beteiligen. Er verwies scherzhaft auf Wikileaks und Co, deren Aufgabe es sei, herauszufinden, wer es war. Zudem hat Dang den SCADA-Payload von Stuxnet nicht analysiert. Er und die anderen Mitglieder des MSRC haben nur den Windows-Teil begutachtet, der, grob von Dang geschätzt, 30 bis 40 Prozent der gesamten Binärdatei ausmachte. Er und seine Kollegen hatten die Binärdatei so weit analysiert, dass sie ihn in C bis zu 80 Prozent nachbauen konnten.

Immerhin deutete er an, dass Stuxnet von Profis erstellt wurde, die ein ganz bestimmtes Ziel hatten: Die Druckersicherheitslücke ist etwa nur in bestimmten Netzwerkkonfigurationen überhaupt sinnvoll. Eine Standardkonfiguration, die auf diese spezielle Lücke anfällig ist, gibt es nicht. Zudem war der Angriff breit gefächert. Es wurden Eigenarten von Windows Vista und neuer genauso berücksichtigt wie Windows XP und älter.

Stuxnet stürzte nicht ab

Dang sagte außerdem, dass er ein Ausnutzen von Sicherheitslücken mit maximaler Zuverlässigkeit so nicht kannte - insbesondere überraschte ihn die Anzahl und das Zusammenspiel der verwendeten Sicherheitslücken. Einige seiner Analysevorgänge scheiterten schlicht an dem Umstand, dass er davon ausgegangen war, dass eine Stuxnet-Infektion irgendwann zu einem Absturz führen musste, was nicht der Fall war. Dang geht davon aus, dass mehrere Personen an Stuxnet gearbeitet haben müssen.

Die Macher von Stuxnet, davon kann ausgegangen werden, kannten ihr Ziel vorher sehr genau.

Die Zuschauer fanden den Microsoft-Vortrag besonders fesselnd: Dang bekam viel Applaus, was auf diesem Kongress recht selten passiert. Und so gab ein Hacker am Ende des Vortrags in der Frage-und-Antwort-Runde noch offen zu, dass er nie gedacht hätte, dass ihm ein Microsoft-Vortrag so gut gefallen würde. [Von Andreas Sebayang und Jörg Thoma]  (jt)


Verwandte Artikel:
Security: Malware mit legitimen Zertifikaten weit verbreitet   
(07.11.2017, https://glm.io/130997 )
Analyse von Symantec: Stuxnet greift nur bestimmte Industrieanlagen an   
(15.11.2010, https://glm.io/79400 )
Smartphones: Broadpwn-Lücke könnte drahtlosen Wurm ermöglichen   
(28.07.2017, https://glm.io/129169 )
Pyeongchang: Olympic Destroyer ist eine lernende Malware   
(14.02.2018, https://glm.io/132772 )
HDMI über Powerline auch von Allnet   
(04.03.2009, https://glm.io/65705 )

© 1997–2020 Golem.de, https://www.golem.de/