Kann Bill Gates hellsehen? "Nie war eine sichere IT-Plattform so wichtig wie heute, da wir zunehmend auf das Internet angewiesen sind, um zu kommunizieren und unsere Geschäfte abzuwickeln", schrieb er am 23. Januar 2003 in einem Executive Newsletter seinen Kunden ins Stammbuch. "Die verbesserte Kommunikation bringt zwar erhebliche Vorteile mit sich, aber auch Sicherheitsrisiken in einem Ausmaß, das nur wenige in unserer Industrie vorausgesehen haben."
Keine 48 Stunden später, in den frühen Morgenstunden des 25. Januar 2003, brach innerhalb von 30 Minuten das Internet für mehr als vier Stunden praktisch völlig zusammen. Fünf der dreizehn Root-DNS-Server fielen völlig aus, die anderen ließen sich auf Grund von Paketverlustraten bis zu 64 Prozent zeitweilig nicht mehr ansprechen. Auch auf den Backbones der großen Provider ging ständig rund ein Drittel der Pakete verloren.
In den USA musste die Bank of America feststellen, dass ein Großteil ihrer 13.000 Bankautomaten wegen der Netzausfälle den Betrieb einstellte. Der AmEx-Kundendienst war durch fehlenden Datenzugriff ebenfalls vorübergehend außer Gefecht gesetzt. Schlimm traf es Südkorea, das Land mit der höchsten Online-Quote der Welt: Zeitweilig ging der wichtigste Provider KT Corp. komplett vom Netz, speziell der Online-Börsenhandel litt dramatisch. Die ausfallenden Geschäfte rissen das Seouler Handelsvolumen in ein Dreizehn-Monats-Tief, der Index sank um knapp drei Prozent. Die ebenfalls schwer betroffene VR China riegelte angesichts der Krise ihr nationales Netz gleich komplett nach außen ab.
Verursacher der Aufregung: Sapphire alias MS-SQL Slammer alias WORM_SQLP1434.A - ein gerade mal 376 Byte großer Schädling. Der vielfach auch schlicht und treffend SQL Hell titulierte Wurm infizierte innerhalb einer guten halben Stunde mindestens 75.000 Microsoft SQL-Server und brachte mit einer wahren Flut von UDP-Paketen auf Port 1434 das Internet innerhalb von 30 Minuten nahezu zum Stillstand.
Der Wurm
Zum ersten Mal scheint MS-SQL Slammer am 25. Januar um 5:30 Uhr UTC im Netz aufgetaucht zu sein. Der Wurm nutzt eine seit dem 24. Juli 2002 bekannte Sicherheitslücke in MS SQL Server 2000 aus. Betroffen sind neben dem SQL Server selbst alle Produkte, welche die SQL-Desktop-Engine MSDE (Microsoft Data Engine) verwenden. Dazu zählen hauseigene Produkte wie Office, Visio, Project oder Visual Studio .NET, aber auch Third-Party-Software wie Security-Produkte von ISS (sic!) oder Kommunikations- und CRM-Software von Cisco.
Slammer nutzt die Tatsache aus, dass SQL Server auf mehreren Ports nach eingehenden Anfragen lauscht. Clients können entweder Named Pipes via NetBIOS (139/tcp und 445/tcp) nutzen oder sich über Port 1433/tcp mit dem Server in Verbindung setzen. Um den korrekten Verbindungsweg zu erfragen, klopfen sie zunächst am Microsoft SQL Monitor Port 1434/udp an. Allerdings lässt sich durch Manipulation des Anfragepakets ein Buffer Overflow auf dem Stack des SQL-Servers erzeugen.
Auf diesem Weg legt der Wurm seinen Code auf dem Server ab und kann ihn im Systemkontext ausführen. Slammer verzichtet dabei auf eine "echte" Schadfunktion. Er generiert "lediglich" zufällige IP-Adressen und versucht, sich wiederum an den Port 1434/udp der jeweiligen Adresse zu versenden. Dazu nutzt er jedoch die gesamte Performance des Systems sowie die volle Bandbreite der zur Verfügung stehenden Internet-Connection: In der Praxis wurden an Einzelmaschinen Durchsätze von mehr als 50 Mbit/s gemessen.
Eine befallene Maschine erzeugt aber nicht nur direkt eine erhebliche Datenlast, sondern produziert auch reichlich sekundären Datenverkehr. Da eine Vielzahl der zufällig erzeugten Ziel-IPs entweder nicht existiert oder dort Port 1434/udp geschlossen ist, generieren die angesprochenen Router eine Flut resultierender ICMP-Unreachable-Messages.
Der Effekt
Alles in allem erwies sich MS-SQL Slammer als äußerst effektiver DDoS-Schädling - ein echtes One-Packet-Wonder. Da der 376 Byte große Slammer in ein IP-Paket passt, verbreitete er sich nach der Freisetzung blitzartig auf den anfälligen Maschinen. Nach ersten Einschätzungen infizierte der Wurm innerhalb der ersten 60 Minuten bis 6:30 Uhr UTC zwischen 100.000 und 130.000 Maschinen, ein Großteil des Internet-Verkehrs kam schlagartig zum Erliegen.
Zwischen 20 und 30 Prozent Paketverluste auf den Backbones waren die Regel, wie Statistiken des Web-Dienstleisters Matrix Net Systems zeigen. In einzelnen Fällen wurden jedoch erheblich höhere Ausfälle beobachtet. "Wir verzeichnen hier in Los Angeles massive Netzstörungen", postete etwa ein entsetzter Administrator am Mittag des 25. auf Bugtraq. "Im Moment liegt der Paketverlust bei etwa 95 Prozent. (Das ist kein Vertipper. Ich meine *fünfundneunzig Prozent* Verlust.)"
Nach den Statistiken des Internet Storm Center griffen bis zum 26. Januar in insgesamt knapp 20 Millionen gemeldeten Einzelvorfällen rund 193.000 infizierte Maschinen knapp 640.000 existierende Ziel-IPs an. Mit seiner gnadenlosen Effizienz stellte sich MS-SQL Slammer jedoch schließlich selbst ein Bein. Viele Switches und Router stellten unter der immensen Datenlast schließlich den Betrieb ein, und auch zahlreiche SQL-Server hängten sich mit wegbrechenden Services auf.
Aufgeschreckte Administratoren - nicht zuletzt diejenigen US-amerikanischer Provenienz, die oft einen terroristischen Überfall vermuteten - nahmen zudem sehr schnell ihre SQL-Maschinen offline und sperrten die fraglichen Ports. Noch einen Schritt weiter ging die VR China, die ihr Netz komplett von den internationalen Backbones abhängte. Nach mehr als vier Stunden begann sich das Netz wieder zu beruhigen, um etwa 16.30 UTC war das Gröbste überstanden.
Die Entseuchung
Zur raschen Schadensbegrenzung haben nicht zuletzt zwei Tatsachen beigetragen: Zum einen ist MS-SQL Slammer kein Schädling im engeren Sinne: Er residiert lediglich im Speicher, lagert sich aber nicht auf die Festplatte ein. Er zerstört weder Daten, noch späht er sie aus; er birgt auch keine Backdoor-Routine. Das alles legt den dringenden Verdacht nahe, dass es sich hier lediglich um einen Proof-of-Concept-Wurm handelt.
Zum anderen ist die Lücke, die Slammer ausnutzt, seit einem halben Jahr bekannt. Am 24. Juli 2002 hat Microsoft die entsprechende Vulnerability zum ersten Mal im Security Bulletin MS02-039 beschrieben und einen Patch zur Verfügung gestellt. Seit dem 16. Oktober 2002 offeriert Redmond auch einen Bugfix für die MSDE, dessen Beschreibung sich im Security Bulletin MS02-061 findet. Seit dem 17. Januar 2003 schließlich gibt es den kumulativen SQL Server Service Pack 3, der die Vulnerability ebenfalls beseitigt.
Zur Desinfektion eines befallenen Systems reicht es also aus, den Rechner offline zu nehmen und herunterzufahren. Um sich beim Wiederanschluss ans Netz nicht sofort erneut zu infizieren, muss vorher einer der oben beschriebenen Patches eingespielt werden. Dann kann der SQL-Rechner wieder online gehen. Zudem empfiehlt es sich dringend, Port 1434/udp auf der Firewall sowohl Inbound als auch Outbound zu sperren.
Die Kritik
Wohl zum ersten Mal in der Geschichte der durch Bugs in Microsoft-Produkten verursachten Rechnerseuchen bezieht im Fall von MS-SQL Slammer nicht der Software-Gigant aus Redmond die symbolischen Prügel für den Vorfall. Stattdessen schanzen vor allem die amerikanische Presse und US-Politiker diesmal vorrangig den Systemadministratoren den Schwarzen Peter zu.
Von "reaktiv" über "nachlässig" bis schlicht "faul" reichen die Beurteilungen. Ja, ja, wird da noch eingeräumt, Microsoft habe tatsächlich ein fehlerhaftes Produkt ausgeliefert. Aber schließlich hätten die pflichtvergessenen Admins lediglich den seit sechs Monaten existierenden Patch einzuspielen brauchen, und nichts wäre passiert. Aber leider mangele es in der IT-Branche offenbar an Verantwortungsbewusstsein.
Dabei übersehen die Kritiker jedoch geflissentlich ein paar Details. Microsoft hat im Juli 2002 einen Hotfix für das Problem geliefert. Trotz der gravierenden Gefährdung hat sich das Unternehmen jedoch erst wenige Tage vor dem Zwischenfall durchgerungen, den Bugfix auch in einem Service Pack zu veröffentlichen. Zwar gab es seit Oktober 2002 auch einen Patch für die MSDE, doch liefert Microsoft den erst seit dem 26. Januar 2003 - also nach Slammer - auch mit einem Installer aus (V 2.0), der ihn für Desktop-User erst anwendbar macht.
Die Gegenkritik
Schon in Zeiten optimaler IT-Konjunktur war es für Administratoren praktisch unmöglich, jeden einzelnen Microsoft-Hotfix erst auszutesten, um sicherzustellen, dass ein Rechner seine vorgesehene Funktion auch nach dem Patchen noch erfüllen kann. Und dass ohne solches Staging jeder Bugfix das Risiko birgt, anschließend mit einer disfunktionalen Maschine dazustehen, stellt kein großes Geheimnis dar.
Daher ist es gängige Praxis, solche Updates bis zum Release des nächsten Service Pack aufzuschieben, für das man dann die Mühen des Staging notgedrungen in Kauf nimmt. Das weiß auch Microsoft ganz genau. Und ebenso gut müsste man sich in Redmond darüber im Klaren sein, dass sich solche Probleme bei den heutigen, auf Grund der Konjunkturkrise unterbesetzten und unterbudgetierten IT-Abteilungen multiplizieren.
In dieser Situation entblödet sich Microsoft nicht, die Opfer der Redmondschen Inkompetenz auch noch dumm anzumachen: "Es ist recht unglücklich, wenn man vorher gewusst hat, da ist ein Problem, und die Kunden machen keine Updates. Das ist ein wenig frustierend", tönte noch am 26. Januar lauthals Microsofts Security-Chefstratege Scott Carney. Dabei muss er zu diesem Zeitpunkt schon gewusst haben, dass auch die eigenen Server längst von MS-SQL Slammer befallen waren.
Seuchenherd Microsoft
Dass auch die SQL-Server in Redmond befallen waren, zeigen interne E-Mails, die dem Nachrichtendienst Cnet news.com zugespielt wurden. "Unser Netzwerk ist praktisch mit Verkehr geflutet, und das macht es schwierig, Details der Auswirkungen festzustellen", schrieb schon am 25. um 8 Uhr morgens Mike Carlson, der Rechenzentrums-Direktor von Microsofts Information Technology Group an seine Kollegen.
Nicht einmal Microsoft selbst kommt also mit den ständigen Hotfixes und Patches für seine eigene Software zurecht. Wenn schon der Entwickler eines Produkts dessen gravierende Sicherheitsmängel nicht im Griff behalten kann, wie soll das dann sein Kunde bewerkstelligen? Markige Sprüche und vorschnelle Schuldzuweisungen an die Anwender wirken da wie Hohn.
Treten bei einem beliebigen anderen Industrieprodukt - sagen wir einmal Automobile - gravierende Sicherheitsprobleme auf, muss der Hersteller sein Produkt zurückrufen und den Mangel beseitigen. Microsoft dagegen verweist in einem solchen Fall lässig auf irgendwelche Hotfixes. Das ist, als ob nach Massenkarambolagen einer Autoserie mit defekten Bremsen der Kfz-Hersteller darauf plädierte, man habe doch vor Monaten den Kunden einen Do-It-Yourself-Kit mit neuen Bremsleitungen angeboten.
Fazit
Der Zwischenfall mit MS-SQL Slammer demonstriert einmal mehr augenfällig, dass die elektronische Gesellschaft am Anfang des 21. Jahrhunderts an einem Scheideweg steht. Neuen Technologien wird am Anfang ihres Lebens notgedrungen ein gewisses Fehlerpotenzial eingeräumt. Vor hundertfünfzig Jahren waren gelegentlich explodierende Dampfmaschinen und einstürzende Brücken noch tragbar. Vor hundert Jahren fielen Zeppeline halt gelegentlich brennend vom Himmel, und Linienschiffe hatten halb so viele Plätze in Rettungsbooten wie Passagiere an Bord. Vor fünfzig Jahren waren Sicherheitsgurte in Automobilen die Ausnahme und Airbags pure Science-Fiction. Keinen von diesen Zuständen würden wir heute noch dulden.
Wir sollten auch nicht länger dulden, dass die Grundlage unserer elektronisch gestützten Volkswirtschaften, die Server- und Client-Software, voller Funktions- und Sicherheitslücken vom Hersteller kommt und von den Benutzern mühsam über ständiges Flickwerk am Laufen gehalten werden muss. Dazu sind unsere Ökonomien heutzutage zu volatil, und die Abhängigkeit von einer reibungslosen elektronischen Datenkommunikation ist zu groß.
Es kann nicht die Aufgabe von Millionen Benutzern sein, laufend mit unzulänglichem Werkzeug den Pfusch der Hersteller auszubügeln. Der Gesetzgeber ist gefragt - vorzugsweise der europäische. Er sollte schnellstens für kommerzielle Software eine volle Produkthaftung mit allen Konsequenzen einführen. Baut ein Hersteller grob fahrlässig eine gefährliche Sicherheitslücke (wie einen Buffer Overflow) in ein Produkt ein, muss er auch dafür verantwortlich gemacht werden können. (jlu)