Zusammenfassung

  • Microsoft veröffentlichte den Fix für den SQL Server 2000 Resolution Service im Juli 2002; trotzdem infizierte Slammer laut CAIDA im Januar 2003 mehr als 90 Prozent der erreichbaren verwundbaren Hosts innerhalb von zehn Minuten.
  • Der Vorfall trennte vier Zuständigkeiten: Der Hersteller konnte Code korrigieren, Distributoren mussten eingebettete MSDE-Kopien offenlegen, Anwendungsverantwortliche mussten laufende Instanzen ändern, und Netze brauchten vorab genehmigte Eindämmung unterhalb menschlicher Reaktionszeit.

Was ein Bulletin tatsächlich beweist

Microsoft veröffentlichte MS02-039 am 24. Juli 2002. Das Bulletin beschrieb ungeprüfte Puffer im SQL Server 2000 Resolution Service. Dieser Dienst lauschte auf UDP 1434, damit Clients den Netzwerkendpunkt einer benannten Datenbankinstanz finden konnten. Eine präparierte Anfrage konnte den Stack überschreiben und Code mit den Rechten des SQL-Server-Dienstkontos ausführen. Betroffen waren SQL Server 2000 und Microsoft Desktop Engine 2000.

Das Bulletin enthielt einen Patch, eine prüfbare Dateiversion und den Hinweis, UDP 1434 an der Firewall zu sperren, wenn der Dienst nicht gebraucht wurde. Der kumulative Patch in MS02-061 vom 16. Oktober enthielt die Korrektur ebenfalls. Über fehlende Vorwarnung lässt sich der Ausbruch daher nicht erklären.

Ein Veröffentlichungsdatum belegt jedoch nur den Zustand beim Hersteller. Microsoft konnte Binärdateien und Installationshinweise liefern. Das Unternehmen konnte nicht jede durch Drittsoftware installierte MSDE-Komponente finden, nicht jedes Wartungsfenster wählen und nicht jeden unabhängig betriebenen Prozess neu laden. Wo der alte Dienst weiterlief und erreichbar blieb, besaß der alte Code die operative Autorität.

Running-Code Primacy trennt Absicht und Zustand. Das Bulletin eröffnete eine neue Möglichkeit. Erst die geladene Version entschied, ob sie angenommen worden war.

Das Paket musste auf niemanden warten

Slammer, auch Sapphire genannt, begann sich kurz vor 05:30 UTC am Samstag, dem 25. Januar 2003, auszubreiten. Sein Wurmkörper war 376 Byte groß; einschließlich Header beschreibt CAIDA ein 404 Byte großes UDP/IP-Paket. Traf es auf einen verwundbaren Resolution Service, löste es den Überlauf aus. Der neu infizierte Host schickte denselben Körper anschließend an pseudorandom gewählte Adressen auf UDP 1434.

Keine Verbindung musste aufgebaut, keine Antwort abgewartet werden. Ein TCP-Scanner verbringt Zeit mit Sitzungsaufbau und Timeouts. Slammer sendete einfach weiter. Nicht die Netzwerklatenz, sondern Rechenleistung und Ausgangsbandbreite des kompromittierten Hosts begrenzten die Schleife.

CAIDA beobachtete bei einem Host rund 26.000 Sonden pro Sekunde und schätzte in der frühen Phase durchschnittlich etwa 4.000 pro infizierter Instanz. Nach ungefähr drei Minuten lag die aggregierte Rate über 55 Millionen Sonden pro Sekunde. Innerhalb von zehn Minuten waren mehr als 90 Prozent der erreichbaren verwundbaren Population infiziert.

Die Zahl von 74.856 verschiedenen infizierten IP-Adressen in den ersten 30 Minuten ist ausdrücklich eine Untergrenze. Fehler im Pseudozufallsgenerator ließen manche Adresszyklen aus einer Messperspektive unsichtbar werden; eine wichtige frühe Aufzeichnung fiel nach etwa zwei Minuten und vierzig Sekunden aus. Eine exakte weltweite Zahl wäre erfunden. Die zeitliche Aussage bleibt belastbar: Die entscheidende Ausbreitung endete, bevor eine normale menschliche Eskalation greifen konnte.

Der Engpass lag im eigenen Standort

Slammer war kein Reflexionsangriff. Der Wurm fälschte keine Opferadresse, um einen Dritten zu einer größeren Antwort zu bewegen. Ein infizierter SQL Server erzeugte seine Scans selbst. Die analysierte Variante trug keine zusätzliche zerstörerische Nutzlast; ihr Sendemuster genügte für Ausfälle.

An vielen Standorten füllten ein oder wenige infizierte Rechner den ersten gemeinsamen Flaschenhals. Andere Systeme verloren Konnektivität, obwohl sie nicht verwundbar waren. Die Kombination aus hohem Volumen, sehr vielen kleinen Paketen und ständig wechselnden Zielen belastete Bandbreite, Warteschlangen, Speicher und CPU von Netzgeräten. Schließlich konkurrierten die infizierten Instanzen sogar miteinander um die knappe Kapazität.

Ein Schutzmodell, das nur eingehende Angriffe betrachtet, verfehlt diesen Schaden. Ein übersehenes internes Laufzeitsystem kann den gesamten Ausgang monopolisieren. Relevante Kontrollen liegen daher nahe am betroffenen Netz: Segmentierung, Beobachtung ausgehender Flüsse, faire Warteschlangen, Ratenbegrenzung oder die gezielte Isolation eines Hosts. Ein externer Scrubbing-Dienst kann den lokalen Link nicht retten, den der eigene Server bereits belegt.

MSDE passte nicht zur Einkaufsbezeichnung

MSDE 2000 konnte als Datenbankmodul in einer anderen Anwendung mitgeliefert werden. Ein Inventar ohne Eintrag „SQL Server“ konnte deshalb trotzdem den verwundbaren Resolution Service enthalten. CERT/CC wies ausdrücklich darauf hin, dass Produkte mit eingebettetem MSDE 2000 betroffen waren.

Das Wissen lag bei verschiedenen Parteien. Microsoft kannte die Komponente. Der Distributor kannte die Bündelung. Der Anwendungsverantwortliche kannte die Geschäftsfunktion. Das Netzteam sah UDP 1434. Keine dieser Listen allein ergab die Wahrheit.

Die richtige Einheit ist die ausführbare Identität: welcher Prozess lauscht, welche Dateiversion ist geladen, welches Produkt installierte sie, wer trägt das Wartungsrisiko und von welchen Pfaden ist der Dienst erreichbar? Erst diese Antworten bilden einen Nachweis der Adoption.

Auch die spätere Neuveröffentlichung von MS02-061 zeigt den operativen Konflikt. Microsoft integrierte einen zusätzlichen, nicht sicherheitsbezogenen Fix und einen neuen Installer, nachdem die ursprüngliche Kombination SQL-Server-Betrieb unter bestimmten Umständen beeinträchtigen konnte. Das rechtfertigt kein offenes Risiko. Es erklärt, weshalb der lokale Betreiber die Änderung testen, terminieren und ihren laufenden Zustand bestätigen muss.

Eine Stunde war nützlich und trotzdem zu langsam

Viele Standorte begannen laut CAIDA innerhalb einer Stunde, Pakete mit Ziel UDP 1434 zu filtern. Slammer bot ungewöhnlich günstige Bedingungen: klares Muster, enger Port und in vielen Netzen wenig legitimer Internetverkehr. Trotzdem begann die früheste menschliche Filterung erst, nachdem fast alle erreichbaren verwundbaren Hosts infiziert waren.

Für die Erholung blieb sie wichtig. Filter reduzierten die weitere Scanlast, konnten aber keine bereits erfolgte Infektion rückgängig machen. Eine Regel am Internet-Rand erfasst außerdem nicht zwingend Verkehr zwischen internen Segmenten. Cisco unterschied deshalb Router-ACLs von Kontrollen innerhalb eines VLAN und berücksichtigte Unternehmen, die UDP 1434 geschäftlich benötigten.

Die Folgerung lautet nicht, jede Entscheidung zu automatisieren. Eine lokale Regel darf eng begrenzt handeln, wenn präzise Merkmale zusammenkommen: passendes Paketmuster, plötzlich breite Zielstreuung und eine für die Rolle des Hosts unmögliche Ausgangsrate. Sie kann zeitweise drosseln oder isolieren. Schwellen, Segmente, Ausnahmen, Beweissicherung und Rücknahme bleiben beim Netzbetreiber.

Die gemeinsame Mindestspezifikation beschreibt Ergebnisse: das betroffene Laufzeitsystem kennen, unbegründete Erreichbarkeit entfernen und verhindern, dass ein Knoten eine gemeinsame Ressource übernimmt. Die Technik dafür wird lokal gewählt.

Vier Nachweise statt eines Häkchens

Der Hersteller weist eine eindeutig korrigierte Version und einen tragfähigen Installationsweg nach. Der Distributor verbindet eingebettete Komponenten mit Produkten und Kunden. Der Anwendungsverantwortliche zeigt geladene Version, Abhängigkeit und Erreichbarkeit. Der Netzbetreiber zeigt in Flüssen und Übungen, dass ein Endpunkt nicht den gesamten Link verbrauchen kann.

Kein Nachweis ersetzt einen anderen. Eine Firewall kann verwundbaren Code verbergen, ohne ihn zu reparieren. Ein Patch kann neben unnötiger Öffentlichkeit existieren. Ein Inventar kann veralten. Eine zu breite Quarantäne kann im Ernstfall unbrauchbar sein.

Diese Arbeitsteilung verlangt keine zentrale Herrschaft. Microsoft musste Kundennetze nicht verwalten, um einen Fix zu liefern. Netzbetreiber mussten SQL Server nicht umschreiben, um Kapazität zu schützen. Jede Partei macht den Zustand sichtbar, den die nächste für ihre Entscheidung braucht; die Ausführung bleibt bei der Partei, die Schaden und Rücknahme trägt.

Grenzen der Belege

Belegt sind ein vor dem Ausbruch verfügbarer Fix, ein Wurm in einem UDP-Datagramm, mindestens 74.856 beobachtete infizierte Adressen und eine Ausbreitung in Minuten. Nicht belegt ist, dass jede SQL-Server- oder MSDE-Installation öffentlich, die Untergrenze vollständig oder jede berichtete Störung identisch verursacht war.

Die untersuchte Variante brauchte weder Quelladressfälschung noch Reflexion; Datendiebstahl und eine zusätzliche zerstörerische Nutzlast sind ebenfalls nicht belegt. Der belastbare Befund ist enger: Ein veröffentlichter Patch entzieht dem laufenden alten Binärprogramm keine Autorität. Ist die Ausbreitung schneller als menschliche Zustimmung, müssen begrenzte automatische Rechte vorher festgelegt und durch Versionen, Sockets, Flüsse und Übungen kontrolliert werden.

Quellen