Grand Slam

Die Folgen des Wurms ‘SQLSlammer’

Trends & News | News

Noch nie zuvor hat sich ein Wurm so schnell verbreitet wie SQLSlammer. Das resultierte nicht nur in zahlreichen Server-Ausfällen und lahmenden Internet-Verbindungen, sondern führte bei Betroffenen auch zu immens hohem Traffic-Aufkommen. Doch zumindest die deutschen Provider zeigen sich kulant.

Viele Nutzer, die am 25. Januar in ihre E-Mail sahen, wunderten sich nicht schlecht. Nanu, heute gar kein Spam? In der Tat wurde an diesem Samstag nicht viel Spam-Mail versendet, denn Süd-Korea, das Ursprungsland vieler Spam-Mails, war an diesem Tage vom Internet quasi abgeschnitten.

War das noch eine eher angenehme Konsequenz für die Spam-geplagten Internet-Nutzer, lernten Sie im Laufe des Tages weitaus unangenehmere Effekte kennen: Internetverbindungen in allen Teilen der Welt lahmten, viele Server waren überhaupt nicht mehr erreichbar. Über 10 000 Geldautomaten in den USA versagten den Dienst, weil ihnen die Internetverbindung zum Abgleichen der Kontostände fehlte. Bei Continental Airlines gab es Flugverzögerungen, und am folgenden Montag war eine spürbare Beeinträchtigung des Börsenhandels zu verzeichnen.

Und das alles bewirkten gerade mal 376 Byte Programmcode - nicht viel mehr Zeichen als dieser Absatz enthält. ‘SQLSlammer’ heißt das Programm, ein Wurm, dessen einzige Funktion es ist, sich selbst auf möglichst viele Server zu kopieren, die anfällig für ein bestimmtes Sicherheitsloch in Microsofts SQL-Server sind.

Die Funktionsweise des SQLSlammer-Wurms ist simpel: Er verschickt sich selbst als UDP-Paket auf Port 1434 an zufällig ausgewählte IP-Adressen. Läuft auf der Gegenstelle ein Microsoft SQL-Server, auf dem ein seit Juli erhältlicher Patch nicht eingespielt wurde, bewirkt das Paket einen Buffer Overflow im SQL-Server. Dadurch ist der entsprechende Rechner infiziert und verschickt fortan ebenso besagte UDP-Pakete, um weitere Rechner zu infizieren.

Dass sich SQLSlammer sogar schneller und effizienter verbreitet hat als seinerzeit Code Red oder Nimda, liegt an mehreren Faktoren. Entscheidender Unterschied zu allen anderen Würmern ist, dass sich SQLSlammer über UDP statt TCP verbreitet. UDP ist ein verbindungsloses Protokoll, das heißt der sendende Server braucht nicht auf Bestätigung zu warten, sondern jagt die Pakete quasi blind hinaus. Die Größe eines UDP-Pakets ist begrenzt, doch der komplette Wurm ist klein genug, um hineinzupassen. So nutzte SQLSlammer auf infizierten Rechnern die gesamte zur Verfügung stehende Bandbreite, um sich weiterzuversenden - ein einziger Rechner konnte binnen Sekunden hunderttausende Slammer-Pakete in alle Welt verschicken.

Neben dem hohen Traffic-Aufkommen hat SQLSlammer keine Schäden verursacht; er weist gar keine Schadroutine auf. Der Wurm greift auch nicht auf die Festplatte zu, er liegt lediglich im Speicher vor. Ein simpler Reboot genügt also, um den Parasiten wieder loszuwerden.

In Deutschland traf der plötzliche Wurmbefall besonders kleinere Hosting-Rechenzentren schlimm, deren Kunden ungepatchte MS SQL Server betrieben. Die Außenanbindung war bisweilen völlig überfordert vom unerwarteten UDP-Paketsturm. Zum Beispiel bei der Gunzenhausener Hetzner Online AG. Bereits drei Stunden nach Ausbruch der Attacke informierte der Hoster seine Kunden im Supportforum über den Ausfall der Upstream-Anbindung: ‘Unser Systemmonitoring hat heute kurz vor sieben Uhr eine Störung unseres Backbones registriert. Leider war das Problem remote nicht zu analysieren. Deshalb konnten wir den Ausfall erst nach Ankunft eines Technikers im RZ beheben. Der Ausfall wurde durch fünf Server innerhalb unseres RZ verursacht, welche gleichzeitg jeweils UDP Floods generiert haben.’ Zu diesem Zeitpunkt hatten die Newsticker noch nicht über den SQL-Slammer informiert - die Techniker standen recht ratlos da.

Anders sah es bei Betreibern von sehr großzügig angebundenen Rechenzentren aus. Bei 1&1 in Karlsruhe etwa wurde der UDP-Traffic fleißig weiter nach außen durchgeroutet, obwohl dort nach Angaben von Firmensprecher Michael Frenzel immerhin 30 bis 40 ungepatchte Kunden-Server ein Paket-Feuerwerk starteten. Vereinzelt hätten diese Server binnen weniger Stunden weit über 100 GByte Outgoing-Traffic erzeugt, der vom RZ-Accounting regulär erfasst wurde. Frenzel wies darauf hin, dass 1&1 die Windows-Server nicht mit aktiviertem SQL-Server ausliefere; gemäß den Allgemeinen Geschäftsbedinungen sei es Sache der Kunden, ihre Systeme Up-to-Date zu halten. Nach der Attacke habe man jeden betroffenen Kunden angerufen und über die Lage informiert. 1&1 werde sich kulant zeigen und für die entsprechenden Server pauschal nur 1 GByte für den Zeitraum des Befalls abrechnen.

Auch der Fürther Hoster Netdiscounter zeigt sich kulant: ‘Wir werden Einzelfall-Agreements mit den Kunden treffen. auf keinen Fall aber müssen sie den normalen Traffic-Preis bezahlen’, sagte Firmensprecher Sascha Köhler zu c't.

SQLSlammer hat erneut bewiesen, dass es kein sicheres Mittel gegen Würmer gibt. Selbst dann nicht, wenn die ausgenutzte Sicherheitslücke und sogar der Mechanismus vorher bekannt sind. So ist schon lange vor dem Hinweis und dem Patch von Microsoft ein ‘Proof-of-Concept-Exploit’ für die SQL-Lücke auf der Sicherheitsmailingliste Bugtraq erschienen. David Litchfield, Verfasser dieser Mail, erkennt seinen Code ohne Zweifel wieder. Teile davon wurden offenbar mittels Copy & Paste im SQLSlammer-Wurm übernommen. Litchfield hat inzwischen Zweifel, ob solche Veröffentlichungen überhaupt nutzen, wenn sie letztlich nur dazu führen, dass damit Schädlinge erstellt und verbreitet werden.

Firewalls, die Zugriffe auf den SQL-Port von außen unterbinden, bieten zwar einen gewissen Schutz, sind aber keine zuverlässige Lösung. Das musste auch Microsoft schmerzlich feststellen: Wie aus Firmenkreisen bekannt wurde, waren die Microsoft-eigenen öffentlich erreichbaren SQL-Server zwar auf dem neuesten Stand und mit allen Patches versehen, jedoch nicht das interne Netzwerk. Dort arbeitet auf zahlreichen Rechnern das Microsoft SQL Desktop Environment (MSDE) - eine abgespeckte Variante des SQL-Servers, die dieselbe Schwachstelle aufweist. So konnte sich der Wurm auch im internen Microsoft-Netz ausbreiten - wie er dort hineingelangte, bleibt Spekulation. Möglicherweise über RAS-Zugänge, die normalerweise nicht durch eine Firewall geschützt sind, oder durch ein infiziertes Notebook eines Mitarbeiters.

Der Befall des Microsoft-Netzwerkes entbehrt nicht einer gewissen Ironie, hatte aber prekäre Folgen für andere Betroffene: Anwender konnten am 25. Januar fast den gesamten Tag lang den Patch gegen die Sicherheitslücke gar nicht herunterladen - erst gegen 22 Uhr hatte Microsoft das Problem im Griff und die Server waren wieder erreichbar. Natürlich liegt die Hauptschuld bei den Administratoren, die den seit über einem halben Jahr erhältlichen Patch nicht eingespielt haben - zumal Microsoft die Sicherheitslücke schon damals als kritisch einstufte.

Aber Microsoft bringt jährlich mehrere hundert Patches heraus, einige sind in Service Packs enthalten und andere nicht, bestimmte Patches erfordern die Einspielung eines Service Pack und andere wiederum beruhen auf vorherigen Patches, die installiert sein müssen. Dass man selbst bei Microsoft nicht in der Lage war, alle Sicherheitspatches einzuspielen, spricht für sich. (pab)

[#anfang Seitenanfang]


Bruce Schneier, Gründer und CTO von Counterpane Internet Security, ist ein international anerkannter Sicherheits-Experte und gilt als Koryphäe im Bereich der Kryptographie.

c't: Einige Leute argumentieren, dass Microsoft an dem Ausbruch von SQLSlammer keine Schuld habe, wenn die Administratoren einen Patch nicht einspielen, den Microsoft bereits vor einem halben Jahr zur Verfügung gestellt hat.

Schneier: Es bleibt mehr als genug Schuld übrig. Microsoft ist für Software mit hunderten von Sicherheitslücken verantwortlich, sodass sie so viele Patches hinterherreichen müssen, dass die Kunden keine Chance haben, da noch hinterherzukommen.

c't: Was gibt es denn für Alternativen zum derzeitigen Patch-Modell von Microsoft?

Schneier: Ich denke, dass das augenblickliche Modell der völlig falsche Ansatz ist. Es beruht auf der Annahme, dass ein Netzwerk absolut sicher sein kann: Eine Schwachstelle in diesem Netzwerk ist ein Loch in dieser absoluten Sicherheit und wenn man einen Patch dagegen installiert, ist man wieder absolut sicher. Das ist Unsinn. In diesem Moment gibt es tausende von Sicherheitslücken in Netzwerken. Einige sind bekannt, andere unbekannt. Einige sind gepatched und andere nicht. Ich glaube an Sicherheit in der Tiefe. Natürlich soll man Patches installieren, aber sich auch darüber im Klaren sein, dass man Kontrollinstanzen, Erkennungs- und Verteidigungssysteme braucht, sodass man die Sicherheit auch dann noch gewährleisten kann, wenn vorhandene Schutzmaßnahmen versagen. Das ist genau so, wie Sicherheit im richtigen Leben funktioniert; niemand glaubt, dass sein Heim uneinnehmbar ist.

c't: Was halten Sie von der Idee, Patches automatisiert zu verteilen?

Schneier: Was passiert, wenn Würmer diesen Mechanismus ausnutzen um sich automatisch zu verbreiten? Oder, noch wahrscheinlicher, wenn Microsoft automatisch Patches installieren lässt, die die Zielrechner oder Netzwerke der Kunden verwundbar machen oder lahm legen? Die Idee funktioniert nicht, weil die Patches selbst nicht zuverlässig sind, ebensowenig wie der automatische Prozess des Installierens. Es verlagert nur das Sicherheitsproblem.

c't: Bereits vor einem Jahr haben Adam Shostack und Sie in einem Paper einen Sicherheitsratgeber für Microsoft veröffentlicht. Was hat Microsoft denn diesbezüglich falsch gemacht, dass SQLSlammer derartigen Schaden hervorrufen konnte?

Schneier: Der ursprüngliche Exploit-Code für das Sicherheitsloch ist älter als das Advisory von Microsoft. Wenn Microsoft absolut zuverlässigen und sicheren Code geschrieben hätte, wäre SQLSlammer gar nicht möglich gewesen. Aber es ist unmöglich, absolut sicheren Code zu schreiben - wir wissen nicht mal wissenschaftlich, wie das geht - Schwachstellen wird es immer geben. Daher ist es auch so wichtig, die Kontrollmechanismen, also Erkennung und Gegenmaßnahmen, zu haben.

Außerdem ist in der etablierten Computer-Architektur der Datenspeicher nicht vom Programmspeicher getrennt - das macht die Aufgabe, vor Schädlingen aller Art zu schützen auch um einiges schwieriger.

c't: Was ist in Ihrer Ansicht die wichtigste Aufgabe, um künftig solchen Bedrohungen wie SQLSlammer zu vermeiden und wer muss etwas tun?

Schneier: Die wichtigste Aufgabe ist es, zu erkennen, dass zukünftigen Bedrohungen nicht aus dem Weg gegangen werden kann. Es gibt da einen seltsamen Irrglauben, dass Technologie auf irgendeine magische Weise dieses Problem lösen kann. Ich habe keine technische Lösung für Mord, Raub oder Terrorismus. Ich habe auch keine technische Lösung für Viren und Würmer.

c't: Glauben Sie, dass TCPA/Palladium gegen diese Problematik helfen kann?

Schneier: TCPA and Palladium sind irrelevant für solche Bedrohungen. Das Problem sind Fehler in der Software. Ob diese Fehler in SQL oder Palladium bestehen, macht keinen Unterschied.

Kommentare

Anzeige
Anzeige