Der 25. Januar 2003 wird vielen Administratoren und Internet-Nutzern in bleibender Erinnerung bleiben. An diesem Samstag brach um etwa 6:30 Uhr Mitteleuropäischer Zeit eine Computervirenepidemie in einem bis dato unbekannten Ausmaßes aus, die innerhalb weniger Minuten den Datenverkehr im gesamten Internet stark beeinträchtigte.
Der Virus
Der Virus mit der unscheinbaren Bezeichnung "WORM_SQLP1434.A" gehört zur Kategorie der Würmer, also einem Virus, der einzig und allein als Aufgabe hat, sich selbst zu replizieren und weiterzuverbreiten. Dazu nutzt der SQL-Slammer ein Sicherheitsloch der populären Datenbanksoftware SQL Server 2000 von Microsoft aus. Der Wurm geht dabei mit einer bis dato nicht gekannten Präzision und Effizienz ans Werk.
Der Programmcode des SQL-Slammer selbst ist nur 376 Bytes groß und besteht aus einigen, wenigen Zeilen. Der Programmcode selbst nutzt ein Sicherheitsloch im SQL Server 2000 aus, in dem er dort einen so genannten Buffer Overflow auslöst. Das ist Versuche, einen zu kleinen Speicherbereich mit zu großen Datenmengen zu beschreiben, um damit zu provozieren, dass dahinter liegende Speicherbereiche mit überschrieben werden. Im Falle des SQL-Slammer ermöglicht der betreffende Pufferüberlauf, dass der Virus die Berechtigungen der ausgeführten SQL-Server-Instanz erbt. Der Virus legt sich selbst im Arbeitsspeicher ab und nutzt die so gewonnenen Berechtigungen aus, um sofort zur Tat zu schreiten.
Sein Schadpotential ist einfach und wirkungsvoll: Er verbreitet sich weiter. Dazu versucht er sich mit anderen Rechnern über den UDP-Port 1434 zu verbinden. Dieser Port ist auf vielen Rechnern, auf denen der SQL Server installiert ist, freigeschaltet, da dieser dazu dient, dass Anwendungen per IP mit dem SQL Server kommunizieren kann. Um Empfänger zu generieren, geht der SQL-Server einen unkonventionellen Weg, in dem Zieladressen per Zufallsgenerator erzeugt werden.
Zwei fatale Eigenschaften treffen hier zusammen: Zum einen besitzt der Versand über UDP die Eigenart, dass UDP verbindungslos arbeitet. Dies bedeutet im Gegensatz zu TCP, dass abgesendete Pakete keinen Empfangsquittung benötigen und deshalb die meisten Gerätschaften erheblich mehr UDP-Pakete versenden können, als TCP-Pakete. Zum anderen ist der SQL-Slammer derartig klein, dass er in einem einzigen UDP-Paket vollständig übertragen werden kann. Der unkonventionelle Weg der Generierung von Zieladressen tut dann sein übriges, dass befallene SQL-Server-Installationen innerhalb weniger Sekunden zu wahren Virenschleudern werden.
Die Epidemie
Spätere Nachforschungen ergaben, dass der SQL Slammer vermutlich gegen 6:30 Mitteleuropäischer Zeit freigesetzt wurde und die ersten SQL-Server-Installationen befiel. Innerhalb der ersten Stunde verbreitete sich der Virus rapide, so dass gegen 7:30 Uhr bereits zwischen 100.000 und 130.000 Rechner weltweit infiziert waren.
Bereits nach den ersten 20 Minuten, also kurz vor 7 Uhr Mitteleuropäischer Zeit, waren weite Teile des Internet bereits vorübergehend lahmgelegt: Durch die gigantische Zahl an Datenpaketen waren selbst großzügig überdimensionierte Backbone-Anbindungen überlastet, so dass Paketlaufzeiten und -verluste weltweit im Internet dramatisch anstiegen. Werden normalerweise zwischen 0 und 5 Prozent aller Datenpakete im Internet verloren, sprang diese Zahl innerhalb der ersten 20 Minuten auf teilweise dramatische 20 Prozent, in kurzfristigen und regional begrenzten Spitzenwerten teilweise sogar weit darüber. Vor allem in weniger gut ausgebauten Internet-Regionen brach die Konnektivität teilweise vollständig zusammen, da Router und Switches extrem überlastet waren.
Verschärft wurde die Epidemie fatalerweise durch die Fehlertoleranz der Internet-Transportprotokolle. Viele Zieladressen, die SQL-Slammer-Instanzen zufällig erzeugten, existierten entweder überhaupt nicht oder hatten keine SQL-Server-Installation, so dass entsprechende Fehlermeldungen per ICMP erzeugt und an den absendenden Rechner gesendet wurden. Dieser zusätzliche Datenverkehr belastete die Infrastruktur noch zusätzlich stark.
Bekämpft werden konnte die Epidemie nur mehrgleisig: Einerseits mussten Administratoren von betroffenen SQL-Server-Systemen zunächst einmal die befallenen Systeme wieder in Griff bekommen (was durch die Installation des aktuellen Service Packs zwar kein Problem war, zunächst aber in vielen Fällen daran scheiterte, dass viele Administratoren über die Gründe der Netzwerkstörungen noch gar nicht informiert waren) und zum anderen mussten Administratoren ihre Netzwerke schützen und entsprechenden Datenverkehr möglichst weit frontseitig filtern. Dies ging sogar so weit, dass einige Internet Service Provider schon in ihren Netzen den Datenverkehr auf dem UDP-Port 1434 vorübergehend reglementierten, um die eigenen Netze zu schützen.
Diese Sofortmaßnahmen sorgten dafür, dass die Epidemie von Anfang an bekämpft werden konnte, allerdings war das Internet für nahezu vier Stunden in weiten Teilen lahm gelegt. Administratoren des chinesischen Teiles des Internet griffen zur härtesten Maßnahme und nahmen China vorübergehend praktisch vollkommen vom Netz. Aber auch in kleineren Umfeldern gab es massive Störungen. Beispielsweise fielen Netzwerke von Bankautomaten aus und in den USA war vorübergehend sogar die Steuerung eines Kraftwerks beeinträchtigt. All diese Umstände brachten es fertig, dass der SQL Slammer es sogar in die Nachrichten schaffte - ein bis dato exotischer Anblick.
Manöverkritik
Zweifellos kann gesagt werden, dass der SQL Slammer sicherlich zu den interessantesten und wirkungsvollsten Computerviren aller Zeiten gehört. Da es sich um einen so genannten Proof-of-concept-Virus handelt, also ein Virus, der vor allem dazu dient, eine bestehende Theorie in der Praxis in freier "Wildbahn" auf Funktionsfähigkeit zu prüfen, halten sich die wirklichen Schäden in Grenzen; betroffene Systeme sind im Falle einer Infektion zwar stark ausgelastet, der Spuk ist jedoch nach einem Neustart des Systems vorbei, da der Virus sich ausschließlich im Arbeitsspeicher aufhält und sich nicht auf Datenträger schreibt.
Zur besonderen Effizienz der SQL-Slammer-Epidemie 2003 trugen weitere Punkte bei:
- SQL-Server-Installationen waren (und sind nach wie vor) vor allem auf Systemen zu Hause, die meist eminent wichtig für Unternehmensprozesse sind (da sie wichtige Datenbanken speichern), aber oft nur stiefmütterlich gewartet werden. Das beginnt schon damit, dass das Betriebssystem und die installierten Applikationen solcher Server nur gelegentlich aktualisiert werden und Update-Zyklen nicht eingehalten werden, weil die Systeme ja in der Regel meist problemlos laufen. Diese Schlamperei rächt sich bei Sicherheitslöchern, die eigentlich nur Service Packs oder einzelne Aktualisierungen behoben werden, letztere jedoch nicht installiert werden.
- Der Wochentag und die Uhrzeit der vermutlich ersten Infektionen waren clever gewählt: Der Samstag gehört in weiten Teilen der Erde zu den eher arbeitsschwächeren Tagen. Um 6:30 Uhr Mitteleuropäischer Zeit ist es zudem in den USA im Osten 0:30 Uhr und im Westen 21:30 Uhr, also ebenfalls weitgehend arbeitsfreie Zeiten, so dass eine ausbrechende Computervirenepidemie zunächst durchaus ungestört beginnen kann.
Nachwirkungen
Erfahrungsgemäß sind einmal im Internet aufgetauchte Schädlinge über Jahre immer wieder zu beobachten, dies gilt auch und vor allem für den SQL-Slammer. Durch seine einfache Übertragung mit nur einem UDP-Paket ist eine befallene SQL-Server-Installation hochinfektiös, weil sie den SQL-Slammer in kürzester Zeit massiv weiterverbreitet.
Eigentlich ist es unabdingbar, eine neue Softwareinstallation vor dem Produktivstart auf den aktuellen Stand zu setzen und diesen Systemaufbau möglichst in einem abgeschotteten Netzbereich vorzunehmen. Dazu reicht es nicht nur, die Software von den Originaldatenträgern zu installieren, sondern dazu gehört auch, eventuell später veröffentlichte Softwareupdates einzuspielen und das System regelmäßig dahingehend zu überprüfen. Diese elementaren Aufgaben werden von vielen Administratoren jedoch unterschätzt oder schlicht und einfach ignoriert.
Auch für Microsoft war der SQL Slammer eine wichtige Zäsur in der Unternehmensgeschichte. Lange Zeit war in der Computerindustrie das Thema Updates eine Angelegenheit, die vor allem dazu diente, kosmetische Fehler bei Gelegenheit zu beheben. Größere Programmierfehler störten - wenn überhaupt - meist nur den Benutzer des Programms und stellten selten eine größere Gefahr dar. Das Internet änderte dies, denn durch die weltweite Vernetzung waren Computer nicht einfach mehr nur nomadisch abgeschirmte Gerätschaften, sondern konnten sehr schnell in Verbünden geschaltet werden und damit ein eventuelles Schadpotential vervielfachen.
Diese und andere Vorfälle zwangen Softwarehersteller, das Thema Sicherheit und Updating grundlegend neu zu bewerten und die Verteilung von Updates über das Internet neu und planmäßig zu organisieren, um es Administratoren und auch Endkunden zu ermöglichen, ihre Systeme mit möglichst wenig Aufwand aktuell halten zu können.
