David gegen Goliath?
Der Qaz-Wurm und die Implikationen für Microsoft
Copyright (C) 11/2000 by Howard Fuhs
Alles begann eigentlich am 10.09., als sich in Fachkreisen die Anzeichen mehrten, dass ein seit August als "W32/QAZ.Worm" identifizierter Wurm sich bei Anwendern und Unternehmen ausbreitete. Der Wurm verbreitete sich als Notepad.exe über Windows-Shares und suchte nach weiteren Notepads, nistete sich bei Ausführung in der Registry von Windows ein und versucht eine Verbindung zu einer IP-Adresse im Internet herzustellen. Da der Wurm bereits seit einiger Zeit bekannt war, sollte er eigentlich von jedem guten Antiviren-Produkt zuverlässig erkannt werden.
Am 26.10 kamen dann plötzlich beunruhigende Nachrichten aus den USA. Das Wall Street Journal vermeldete, dass es unbekannten Hackern gelungen war, in das Computernetzwerk von Microsoft einzudringen und über einen Zeitraum von Wochen, vielleicht sogar Monaten, Zugriff auf Sourcecode von zukünftigen Microsoft-Produkten zu erlangen. Durch den W32/QAZ.Worm, der einem Mitarbeiter von Microsoft per E-Mail zugesandt worden war, gelang es den Hackern Programme zu installieren welche die Passwörter von Microsoft-Mitarbeitern ausspionierten. Bei der Auswertung von Log-Dateien, nachdem der Einbruch bemerkt worden war, konnte u.a. festgestellt werden, dass Sourcecode an eine E-Mail-Adresse in St.Petersburg in Rußland geschickt worden war. Kurz darauf bestätigte Microsoft-Chef Steve Ballmer den Angriff, erklärte aber auch, dass man sich sicher ist, dass der Quellcode nicht manipuliert worden sei. Um den Netzwerkeinbruch aufzuklären hat Microsoft umgehend die amerikanische Bundespolizei FBI eingeschaltet.
Doch damit nicht genug. Am 6.11. erreichte die Nachricht Deutschland, dass es Hackern erneut gelungen war in das Microsoft-Netzwerk einzudringen. Durch eine seit Mitte Oktober bekannte Sicherheitslücke im Microsoft Internet Information Server IIS konnte ein holländischer Hacker mit dem Pseudonym "Dimitri" auf mehrere Webserver Zugriffsberechtigung auf Dateiebene erhalten. Microsoft hatte schlicht vergessen, gegen das bekannte Sicherheitsloch einen entsprechenden Patch einzuspielen, der von Microsoft selbst programmiert und auf deren Web-Seite zur Verfügung gestellt wird. Bei dem erfolgreichen Angriff erhielt der Hacker nach eigenen Angaben nicht nur einen guten Einblick in die Server-Struktur von Microsoft sondern auch Zugriff auf die Download-Bereicher der Server. In einem Interview behauptete er, es hätte für Ihn kein technisches Problem dargestellt in den Download-Bereichen die vorhandenen Dateien gegen manipulierte Dateien auszutauschen.
Auch wenn von Seiten von Microsoft nach bekanntwerden der Vorfälle kräftig versucht wurde die Öffentlichkeit zu beruhigen und die Vorfälle herunterzuspielen, so bleiben doch einige, für Microsoft unangenehme Fragen und Schlußfolgerungen. Zwar kann man die Argumentation verstehen und nachvollziehen, dass Microsoft eines der größten Netzwerke betreibt und deshalb immer irgendwo Sicherheitslücken auftauchen können. Sicherlich, Netzwerksicherheit ist kein statischer Zustand sondern ein dynamischer Prozess und die Unübersichtlichkeit eines Intranets bestehend aus vielen tausend Servern und noch mehr Clients ist kaum sicher zu kontrollieren. Doch trotzdem stellt sich die schwerwiegende Frage wie es passieren konnte, dass Hacker Zugriff auf das wertvollste eines Softwareunternehmens, den Sourcecode, erhalten konnten? Dabei ist es fast schon unerheblich, um welchen Sourcecode es sich handelt, die Tatsache des unerlaubten Zugriffs über einen längeren Zeitraum alleine ist schon schwerwiegend genug.
Was, wenn der Sourcecode von den Hackern tatsächlich unbefugt verändert oder manipuliert wurde? Wenn nicht sicher und zweifelsfrei festgestellt werden kann, wann die Hacker zum erstenmal Zugriff auf den Sourcecode hatten, kann aus Integritätsgründen nicht einmal auf Sicherungskopien zurückgegriffen werden, denn man kann nicht sicher sagen, welche Sicherungskopie eine noch nicht manipulierte Version des Sourcecodes enthält.
Warum war kein funktionierender und aktueller Virenschutz vorhanden? Wie bereits anfangs erwähnt war der QAZ-Wurm für AV-Produkte kein unbekannter Wurm und hätte zuverlässig entdeckt werden müssen.
Wie kann es passieren, dass der Microsoft-eigene Patch auf dem IIS-Webserver nicht eingespielt war? Es ist die Aufgabe eines jeden Systemadministrators dafür zu sorgen, dass Patches auf den Systemen eingespielt werden um deren Sicherheit und Systemstabilität zu gewährleisten.
Kann man als IT-Verantwortlicher eines Unternehmens in Zukunft sein IT-Startegie weiter auf Microsoft-Produkten aufbauen, wenn bereits beim Hersteller die Sourcecode-Integrität eventuell nicht gewahrt ist? Damit müssen als ernste Alternative Softwareprodukte mit einer Open-Source-Lizenzierung in Betracht gezogen werden, denn hier wird der Sourcecode zur Überprüfung gleich mitgeliefert.
Gerade im Hinblick auf diese Vorfälle wird es Microsoft schwer haben weltweit Unternehmen und Anwender davon zu überzeugen, die .NET-Strategie von Microsoft auch auf ihre Anwendungen und System zu adaptieren, schließlich hat sich Microsoft das ergeizige Ziel mit der .NET-Strategie gesetzt, eine komplette Vernetzung der Betriebssysteme und der Programme über das Internet zu erreichen, wobei die vorhandene Internet-Infrastruktur Schritt für Schritt durch Microsoft-Produkte ersetzt wird.
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar.
Copyright (C) 11/2000 by Howard Fuhs