Abb. 2: Fragment 2
Abb. 3: Zusammengesetztes Paket
original in fr Eric Detoisien
fr to de Viktor Horvath
Eric Detoisien ist IT-Sicherheitsexperte, leidenschaftlich an allen Gebieten des Themas Sicherheit interessiert und einer der Fachleute der rstack-Gruppe - www.rstack.org -
Dieser Artikel ist in einer Sonderausgabe zum Thema Sicherheit im Linux Magazine France erschienen. Der Herausgeber, die Autoren und die �bersetzer haben es freundlicherweise gestattet, da� alle Artikel dieser Ausgabe in loser Folge in LinuxFocus publiziert werden. So bietet Ihnen LinuxFocus diese Artikel einen nach dem anderen an, je nach ihrer �bersetzung ins Englische. Vielen Dank allen Personen, die sich mit dieser Arbeit besch�ftigen. Diese Zusammenfassung wird vor einem jeden dieser Artikel wiederholt.
Der Artikel beschreibt die verschiedenen Angriffsm�glichkeiten von au�en, die ein Pirat gegen ein Rechnernetzwerk benutzen kann. Wir kommen bei diesem Thema auf prinzipielle Netzattacken, auf Angriffe durch Programml�cken und auf Denial-of-Service-Attacken zu sprechen.
Netzattacken st�tzen sich auf Verwundbarkeiten, die direkt an die Protokolle oder an ihre Umsetzung gebunden sind. Davon gibt es eine gro�e Zahl. Dennoch sind die meisten von ihnen blo� Varianten der f�nf heutzutage bekanntesten Angriffe.
Gem�� RFC (Request For Comment) 791 (IP) m�ssen alle Internet-Knoten (Router) Pakete von 68 Bytes Gr��e �bertragen k�nnen, ohne sie der Optimierung wegen aufzusplitten. Tats�chlich betr�gt die minimale Headergr��e eines IP-Paketes 20 Bytes, wenn keine Optionen vorhanden sind, ansonsten ist das Maximum 60 Bytes. Das IHL-Feld (Internet Header Length) enth�lt die Headergr��e, gemessen in 32-Bit-Worten. Dieses Feld belegt 4 Bits, die Zahl der m�glichen Werte ist 2^4 - 1 = 15 (es darf den Wert 0000 nicht annehmen). Die Maximalgr��e des Headers betr�gt also wirklich 15*4 = 60 Bytes. Schlie�lich wird das Feld Fragment Offset, das den Abstand des ersten Bytes des Fragments vom vollst�ndigen Datagramm angibt, in Bl�cken zu 8 Byte geschrieben. Ein Datenfragment ist also mindestens 8 Bytes lang. Damit sind wir genau bei einer Gesamtsumme von 68 Bytes angekommen.
Die Attacke besteht darin, eine TCP-Verbindungsanfrage auf zwei IP-Pakete aufzuteilen. Das erste von 68 Bytes Gr��e enth�lt an Daten lediglich die ersten 8 Bytes des TCP-Headers (Herkunfts- und Zielport sowie die Sequenznummer). Die Daten des zweiten IP-Pakets enthalten folglich die TCP-Verbindungsanfrage (Flag SYN auf 1 und Flag ACK auf 0).
Nun wenden IP-Filter aber dieselbe Filterregel auf alle Fragmente eines Pakets an. Das Filtern des ersten Fragments (Fragment Offset gleich 0) bestimmt also die Regel, die auf die anderen (mit Fragment Offset gleich 1) angewandt wird, ohne jede weitere Art der Kontrolle. Bei der Zusammensetzung auf der IP-Ebene im Zielrechner wird so die Verbindungsanfrage wieder aufgebaut und an die TCP-Ebene geleitet. Die Verbindung kommt dann trotz des IP-Filters zustande.
Die Abbildungen 1 und 2 zeigen die beiden Fragmente, und die Abbildung 3 zeigt das auf dem Zielrechner zusammengesetzte Paket:
Abb. 1: Fragment 1
Abb. 2: Fragment 2
Abb. 3: Zusammengesetztes Paket
Abermals gem�� RFC 791 (IP) l�scht, wenn sich zwei IP-Fragmente �berlagern, das zweite das erste. Die Attacke besteht darin, ein IP-Paket in zwei Fragmenten zu bilden. Der IP-Filter akzeptiert das erste von 68 Byte L�nge (siehe Tiny Fragments), weil es keine TCP-Verbindungsanfrage enth�lt (Flags SYN und ACK = 0). Diese Akzeptanzregel wird wie zuvor auf weitere Fragmente des Pakets angewandt. Das zweite (mit einem Fragment Offset von 1), das die tats�chlichen Verbindungsdaten enth�lt, wird nun vom IP-Filter akzeptiert. Bei der Defragmentierung l�schen so die Daten des zweiten Pakets diejenigen des ersten vom Ende des achten Bytes an (denn der Fragment Offset ist gleich 1). Das zusammengesetzte Paket stellt folglich f�r den Zielrechner eine g�ltige Verbindungsanfrage dar. Die Verbindung kommt trotz des IP-Filters zustande.
Die Abbildungen 4 und 5 zeigen die beiden Fragmente, und die Abbildung 6 zeigt das auf dem Zielrechner zusammengesetzte Paket:
Abb. 4: Fragment 1
Abb. 5: Fragment 2
Abb. 6: Zusammengesetztes Paket
Das Ziel dieser Attacke ist der Klau der IP-Adresse einer Maschine, der es dem Piraten erm�glicht, die Herkunft seines Angriffs zu verschleiern (wird in den Denial-of-Service-Attacken gemacht, �ber die wir sp�ter sprechen). Oder er kann Nutzen aus einer vertraulichen Verbindung zweier Rechner ziehen. Dar�ber werden wir an dieser Stelle also sprechen.
Das zugrundeliegende Prinzip dieses Angriffs besteht darin, da� der Pirat die eigenen IP-Pakete umformt (mit Programmen wie hping2 oder nemesis) zu solchen, in denen er u.a. die IP-Herkunftsadresse �ndert. Die IP-F�lschung wird auch oft ein „blinder Angriff“ („Blind Spoofing“) genannt. In der Tat k�nnen m�gliche Antworten der versandten Pakete nicht auf der Maschine des Piraten ankommen, da die Quelle ja verf�lscht ist. Sie richten sich also an den vorget�uschten Rechner. Dennoch gibt es zwei Methoden, die Antworten zu erhalten:
Das Blind Spoofing wendet sich gegen Dienste vom Typ rlogin oder rsh. Deren Authentifikationsmechanismus gr�ndet sich n�mlich einzig auf die IP-Absenderadresse des Client-Rechners. Dieser recht gut bekannte Angriff (vor allem dank Kevin Mitnick, der ihn 1994 gegen den Rechner von Tsutomu Shimomura benutzte) vollzieht sich in mehreren Etappen:
showmount -e, das zeigt, wohin Dateisysteme exportiert werden, oder von rpcinfo, das zus�tzliche Informationen liefert;
echo ++ >> /.rhosts schicken, um weitere Rechte zu erlangen. Daf�r baut er ein Paket mit dem Flag TCP PSH (Push): die empfangenen Daten werden unmittelbar an die h�here Ebene weitergereicht, hier an den rsh-Dienst, damit der sie verarbeitet. Es ist dem Piraten dann m�glich, sich direkt �ber einen Dienst wie rlogin oder rsh ohne IP-F�lschung mit dem Rechner zu verbinden.
Die Abbildung 7 fa�t die Schritte der IP-F�lschung zusammen:
Abb. 7: IP-F�lschung, angewendet auf den Dienst rsh
Der Pirat benutzt den Rechner A, w�hrend C die vertraute Maschine bezeichnet. Die Notation A(C) bedeutet, da� das Paket von A mit der gef�lschten IP-Adresse von C geschickt wird. Erw�hnenswert ist die Existenz des Programms mendax, das diese verschiedenen Mechanismen der IP-F�lschung in die Tat umsetzt.
Das „Entf�hren einer TCP-Verbindung“ erm�glicht die Umleitung eines TCP-Flusses. Ein Pirat kann dadurch einen Pa�wortschutz (wie telnet oder ftp) umgehen. Die Notwendigkeit des passiven Lauschens (sniffing) beschr�nkt den Einsatzbereich dieser Attacke auf das physische Netzwerk des Zielrechners. Bevor wir in die Details gehen, werden wir einige fundamentale Prinzipien des TC-Protokolls erkl�ren.
Wir werden hier nicht die Geheimnisse des TC-Protokolls offenbaren, sondern lediglich die essentiellen Punkte zum Verst�ndnis des Angriffs pr�zisieren. Der TCP-Header besteht aus mehreren Feldern:
Die Abbildung 8 stellt einen TCP-Verbindungsaufbau schematisch dar (Three Way Handshake):
Abb. 8 : Three Way Handshake
In diesem Fall hat Rechner A eine TCP-Verbindung zum Rechner B angefordert. Dementsprechend zeigt die Abb. 9 einen TCP-Datentransfer:
Abb. 9 : Datenaustausch:
Die Sequenznummern werden sich je nach der Bytezahl der gesendeten Daten �ndern. Die Sequenznummer wird durch Seq dargestellt, die Best�tigungsnummer findet sich nach den PSH- und ACK-Flags, und die Bytezahl der gesendeten Daten steht in Klammern.
Dieser Angriff erzeugt einen Zustand der Desynchronisation auf jeder Seite der TCP-Verbindung, der den Diebstahl der Sitzung erm�glicht. Eine Verbindung wird desynchronisiert, wenn die Sequenznummer des n�chsten vom Rechner A geschickten Bytes sich von derjenigen des n�chsten vom Rechner B empfangenen Bytes unterscheidet. Und umgekehrt gibt es ebenfalls eine Desynchronisation, wenn die Sequenznummer des n�chsten von B geschickten Bytes sich von derjenigen des n�chsten von A empfangenen Bytes unterscheidet.
Im Beispiel der Abbildung 9 erwartet A am Ende der ersten Etappe, wenn B sein Paket empfangen hat, eines mit der Best�tigungsnummer x+60 Wenn das n�chste Paket, das B schickt, eine andere Nummer enth�lt, werden A und B demnach als desynchronisiert bezeichnet.
Ein konkreter Fall: Ein Pirat mit dem Rechner C will eine zwischen A und B hergestellte Telnet-Sitzung stehlen. Zuerst belauscht C den Telnet-Verkehr zwischen A und B. Sobald der Pirat glaubt, da� A genug Zeit hatte, um sich bei dem Telnet-Dienst von B zu authentifizieren, desynchronisiert er A in seiner Kommunikation mit B, weswegen er ein Paket mit der IP-Quelladresse von A und der von B erwarteten TCP-Best�tigungsnummer schn�rt. B akzeptiert daraufhin dieses Paket. Au�er der Desynchronisation der TCP-Verbindung gestattet es dem Piraten, ein Kommando durch die zuvor von A initiierte Telnet-Sitzung zu geben. Denn das Paket kann Daten transportieren (PSH-Flag gleich 1).
Die Abbildung 10 fa�t den Angriff zusammen:
Abb. 10: TCP Session Hijacking
B akzeptiert bereitwillig das von C geschickte Kommando, er quittiert den Paketempfang also mit einem Paket an A mit dem ACK-Flag. Wenn unterdessen A ein Paket an B geschickt hat, wird es nicht akzeptiert, da seine Sequenznummer nicht die von B erwartete ist.
Dann taucht ein Problem auf: der ACK-Sturm. Dabei handelt es sich um eine Masse ACKs, die erzeugt werden. Sie erscheinen, wenn A ein TCP-Paket mit ung�ltiger Sequenznummer schickt (denn A ist desynchronisiert), B es verwirft und A ein ACK mit der erwarteten Sequenznummer schickt. Auf seiner Seite empf�ngt A dieses ACK, und da die Sequenznummer nicht mit der erwarteten �bereinstimmt, schickt er seinerseits ein ACK an B, und B wiederholt das Ganze...
Das Problem des ACK-Sturms kann gel�st werden, wenn der Pirat die ARP-F�lschung benutzt. In diesem Fall verf�lscht er den ARP-Cache von B, indem er ihm sagt, da� die IP-Adresse von A von nun an zur MAC-Adresse von C geh�rt. Diese verschiedenen Techniken werden vom Programm hunt implementiert.
Dieser Angriff, auch ARP-Umleitung genannt, leitet den Netzverkehr einer oder mehrerer Maschinen zum Piratenrechner. Er vollzieht sich im physischen Netz des Opfers. Vorher erinnern wir uns des Nutzen und der Funktionsweise des AR-Protokolls.
Das AR-Protokoll (Address Resolution Protocol) f�hrt den Vorgang der Aufl�sung einer IP-Adresse in eine MAC-Ethernetadresse durch. Ger�te in einem Netzwerk kommunizieren, indem sie auf der Datenverbindungsebene Ethernet-P�ckchen austauschen (im Fall eines Ethernet-Netzes nat�rlich). Um diese Informationen austauschen zu k�nnen, m�ssen die Netzwerkkarten eine einzigartige Adresse auf Ethernet-Ebene besitzen; dabei handelt es sich um die MAC-Adresse (Media Access Control).
Sobald ein IP-Paket verschickt werden mu�, braucht der Absender die MAC-Adresse des Empf�ngers. Daf�r wird eine ARP-Anfrage an alle Maschinen des physischen lokalen Netzes rundgesendet. Diese Anfrage sagt: „Welche MAC-Adresse geh�rt zu dieser IP-Adresse?“. Die Maschine mit der zugeh�rigen IP-Adresse antwortet mit einem ARP-Paket, das dem Fragenden die gesuchte MAC-Adresse angibt. Von da an besitzt der Absender die MAC-Adresse, die mit der IP-Zieladresse des zu sendenden Pakets �bereinstimmt. Diese �bereinstimmung wird eine bestimmte Zeitlang in einem Puffer gespeichert (um zu vermeiden, f�r jedes zu sendende Paket eine neue Anfrage stellen zu m�ssen).
Dieser Angriff korrumpiert den Puffer des Opfers. Der Pirat schickt ARP-Antwortpakete zum Zielrechner, die besagen, da� die neue MAC-Adresse, die mit der IP-Adresse eines Gateways (z.B.) �bereinstimmt, die seinige sei. Der Piratenrechner empf�ngt demzufolge den ganzen Verkehr, der an das Gateway gerichtet wird, er braucht ihm dann also nur noch passiv zuzuh�ren (oder ihn zu modifizieren). Er leitet danach die Pakete zum tats�chlichen Bestimmungsort weiter.
Das ARP-F�lschen n�tzt dann, wenn ein lokales Netzwerk Switches benutzt. Diese leiten Ethernet-P�ckchen gem�� der MAC-Adresse auf die verschiedenen Ports um. Es ist also einem Lauscher unm�glich, P�ckchen jenseits seiner physischen Leitung zu fangen. Das ARP-F�lschen gestattet es damit, Verkehr zwischen Rechnern an verschiedenen Leitungen auf der Ebene des Switches abzuh�ren.
Um einen Angriff mittels ARP-F�lschung in die Tat umzusetzen, wird der Pirat einen ARP-Paketgenerator wie ARPSpoof oder nemesis benutzen. Sei das Opfer 10.0.0.171, sein Standard-Gateway 10.0.0.1 und der Piratenrechner 10.0.0.227. Vor dem Angriff gibt ein Traceroute folgendes Resultat:
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.1 (10.0.0.1) 1.218 ms 1.061 ms 0.849 ms
Und der ARP-Cache des Zielrechners ist:
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:b0:c2:88:de:65 C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
Der Pirat startet dann ARPSpoof:
[root@pirate -> ~]$ arpspoof -t 10.0.0.171 10.0.0.1 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f 0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
Was da geschickt wird, sind ARP-Pakete, die den ARP-Cache der Maschine 10.0.0.171 mit ARP-Antworten verf�lschen. Diese behaupten, da� die mit 10.0.0.1 assoziierte MAC-Adresse nunmehr 00:00:86:35:c9:3f sei.
Fortan ist der ARP-Cache der Maschine 10.0.0.171:
[root@cible -> ~]$ arp Address HWtype HWAddress Flags Mask Iface 10.0.0.1 ether 00:00:86:35:c9:3f C eth0 10.0.0.227 ether 00:00:86:35:c9:3f C eth0
Um zu pr�fen, ob der Verkehr jetzt �ber die Maschine 10.0.0.227 l�uft, gen�gt es, erneut eine Traceroute zum Gateway 10.0.0.1 aufzurufen:
[root@cible -> ~]$ traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets 1 10.0.0.227 (10.0.0.227) 1.712 ms 1.465 ms 1.501 ms 2 10.0.0.1 (10.0.0.1) 2.238 ms 2.121 ms 2.169 ms
Der Pirat kann k�nftig den Verkehr von 10.0.0.171 zu 10.0.0.1 abh�ren. Er darf nicht vergessen, das IP-Routing auf seinem Rechner 10.0.0.227 zu aktivieren (mittels IP-Forwarding - aktiviere den Schl�ssel net.ipv4.ip_forward in der /etc/sysctl.conf oder nimm fragrouter).
Das DNS-Protokoll (Domain Name System) konvertiert einen Dom�nennamen (z.B. www.test.com) in seine IP-Adresse (z.B. 192.168.0.1) und umgekehrt, d.h. eine IP-Adresse in ihren Dom�nennamen. Der Angriff besteht darin, falsche Antworten auf DNS-Anfragen, die ein Opfer schickt, ankommen zu lassen. Es gibt zwei prinzipielle Methoden, um das durchzuf�hren.
Der Header des DNS-Protokolls beinhaltet ein Identifikationsfeld, das es erlaubt, die Antworten passend zu den Anfragen zu machen. Ziel der DNS ID-F�lschung ist es, vor dem DNS-Server eine falsche Antwort auf eine DNS-Anfrage zu geben. Daf�r mu� er die ID der Anfrage vorwegnehmen. Lokal ist das einfach: man belauscht das Netz. Aus der Ferne gestaltet es sich komplizierter. Doch es gibt mehrere Methoden:
In allen F�llen ist es n�tig, vor dem DNS-Server zu antworten und ihn au�er Gefecht zu setzen - z.B. mit einem Denial-of-Service-Angriff.
Um sein Ziel zu erreichen, mu� der Angreifer einen DNS-Server kontrollieren (ns.attaquant.com), der wiederum die Dom�ne attaquant.com beherrscht. Der Ziel-DNS-Rechner (ns.cible.com) habe vorhersagbare Sequenznummern (Erh�hung um 1 bei jeder neuen Anfrage).
Die Attacke gliedert sich in vier Schritte:
www.attaquant.com an den DNS-Server der Dom�ne cible.com, wie Abbildung 11 zeigt;ns.cible.com
attaquant.com �bertragen;www.spoofed.com, das normalerweise die IP-Adresse 192.168.0.1 hat. Der Pirat emittiert eine DNS-Anfrage zur Namensaufl�sung von www.spoofed.com an ns.cible.com. Sofort danach sendet er eine Menge falscher DNS-Antworten (die als IP-Adresse diejenige des Angreifers, 10.0.0.1, angeben) auf ebendiese Anfrage, wobei er als IP-Quelladresse diejenige des DNS-Servers der Dom�ne spoofed.com vort�uscht. Die ID einer jeden Antwort wird um 1 inkrementiert, beginnend mit derjenigen, die beim zweiten Schritt ermittelt wurde (ID = 100) - um die Chance zu vergr��ern, da� darunter die richtige Nummer der ID-Antwort f�llt, falls ns.cible.com auf weitere Anfragen geantwortet und so seine DNS-ID erh�ht hat. Die Abbildung 12 zeigt die Details dieses Schrittes.
Abb. 12: DNS ID-F�lschung
www.spoofed.com verlangt, bekommt die IP-Adresse des Piratenrechners. Sie wird auf dessen Seite umgeleitet, die eine Kopie der echten Seite sein k�nnte, um Internet-Nutzer zu t�uschen und ihnen vertrauliche Informationen zu entlocken.
DNS-Server haben einen Cache, der w�hrend einer bestimmten Zeit lokal die Antworten auf vergangene Anfragen speichert, um zu vermeiden, da� jedes Mal zeitaufwendig der Nameserver der gew�nschten Dom�ne gefragt werden mu�. In der zweiten Art der DNS-F�lschung wird dieser Cache mit falschen Informationen gef�llt. Hier ein Beispiel von Cache-F�lschung:
Gleiche Umst�nde wie beim vorherigen Beispiel. Das sind die verschiedenen Stufen des Angriffs:
www.attaquant.com wird zum DNS-Server der Dom�ne cible.com geschickt;www.attaquant.com an den DNS-Server des Angreifers;www.cible.com einen falschen DNS-Eintrag haben, die die IP-Adresse von www.attaquant.com statt der richtigen IP-Adresse liefert.Angriffe �ber Applikationen st�tzen sich im wesentlichen auf L�cken, die es in verwendeten Programmen gibt. Dennoch k�nnen bestimmte Attacken in Klassen eingeordnet werden.
Eines der ersten Sicherheitsprobleme, das Applikationen verursachen, ist das der Konfigurationsfehler. Wir unterscheiden zwei Arten von Fehlern: die Standard-Installationen und die schlechten Konfigurationen im eigentlichen Sinne.
Programme wie Webserver haben, wenn sie standardm��ig installiert sind, h�ufig Beispielseiten, die von den Piraten genutzt werden k�nnen, um an vertrauliche Informationen zu kommen. Zum Beispiel kann es dort Skripte geben, die es erm�glichen, die Quellen von dynamischen Seiten zu erhalten oder Informationen �ber das benutzte System. Dar�ber hinaus ist bei einer solchen Installation evtl. standardm��ig ein Interface zur Fernadministration mit einem Login/Pa�wortschutz verf�gbar (zu finden im Administrationshandbuch der Applikation). Der Pirat hat also die Seite zu fassen und kann sie nach seinem Gutd�nken ver�ndern.
Die meisten Fehler, die aus einer schlechten Konfiguration entstehen, sind Zugriffslisten mit falschen Parametern. Der Pirat hat dann Zugang zu privaten Seiten und Datenbanken.
Ein klassisches Beispiel von Konfigurationsproblemen sind die h�ufigen Fehler in den Parametern des Webservers Lotus Domino. Denn w�hrend der Installation dieses Servers sind die Konfigurationsdatenbanken von Lotus ohne jegliche Zugriffsliste zug�nglich. Wenn konkret die Lotus-Datenbank names.nsf �ber einen Web-Browser ohne Authentifikation zug�nglich ist, kann man dadurch zahlreiche Informationen erhalten, etwa die Namen s�mtlicher Lotus-Nutzer. Diese Datenbank ist nur ein Beispiel, und Lotus Domino enth�lt davon eine betr�chtliche Zahl mit sensiblen Daten.
Schlechte Programmierung von Software f�hrt zwangsl�ufig zu Bugs. Sie sind die Quelle der wichtigsten Sicherheitsl�cken. Wenn diese Verwundbarkeiten entdeckt werden, erlauben sie es, nicht autorisierte Befehle auszuf�hren, den Quellcode dynamischer Seiten zu bekommen, einen Dienst auszuschalten, den Rechner zu �bernehmen etc. Die bekanntesten dieser Bugs und die interessantesten, was ihre Ausbeutung betrifft, sind die des Typs Buffer Overflow.
Der Speicher�berlauf ist eine L�cke, an der schlechte Programmierung schuld ist. Ein Buffer Overflow ereignet sich dann, wenn eine Variable einer Funktion als Argument �bergeben und in einen Speicherplatz kopiert wird, ohne da� ihre Gr��e gepr�ft wird. Es gen�gt, da� die Variable gr��er als der reservierte Speicherbereich ist, damit ein Buffer Overflow entsteht. Er wird ausgebeutet, indem in der Variable ein Programmfragment abgelegt wird, das f�hig ist, freundlicherweise eine Shell starten zu lassen, falls hier ein Buffer Overflow aufgetreten ist. Falls der Pirat Erfolg mit diesem Angriff hat, erh�lt er also ein Mittel, aus der Ferne Kommandos auf dem Zielrechner auszuf�hren mit den Zugriffsrechten der angegriffenen Applikation. Der Buffer Overflow und seine Nutzung sind Gegenstand einer Serie von Artikeln �ber die sichere Programmierung:
Schlechte Programmierung von Skripten schl�gt sich oft auf die Systemsicherheit nieder. Tats�chlich gibt es Wege, L�cken in Perl-Skripten auszunutzen, die es gestatten, Dateien aus dem Web-Wurzelverzeichnis zu lesen oder unerlaubte Programme auszuf�hren. Auf diese programmiertechnischen Probleme wird in einem der o.a. Artikel hingewiesen, der von den Fallen der Entwicklung in Perl und PHP handelt (Teil 6, „CGI-Skripte“).
Ziel dieses Angriffs ist die Umleitung des Verkehrs zwischen zwei Maschinen, um die im Laufe der Kommunikation �bertragenen Daten abzuh�ren, zu ver�ndern oder zu vernichten. Es handelt sich dabei mehr um ein Konzept als um eine vollst�ndige Attacke. Es gibt verschiedene Angriffe, die das Prinzip vom Mann in der Mitte umsetzen, etwa der DNS Man in the Middle, der DNS-F�lschung benutzt, um den Verkehr zwischen einem Client und einem Webserver umzulenken. Ebenso wurde k�rzlich eine Applikation erstellt, um SSH-Verkehr umzuleiten.
Dieser Angriff tr�gt seinen Namen zu Recht, denn er f�hrt zur Ausschaltung eines Dienstes (einer bestimmten Applikation) oder eines Zielrechners. Wir unterscheiden zwei Arten von Denial-of-Service; die eine hat ihren Ursprung in der Ausnutzung eines Programmfehlers, die andere r�hrt von einer schlechten Implementation eines Protokolls oder dessen Schw�chen her.
Genau wie L�cken in einer Applikation die M�glichkeit der Kontroll�bernahme eines Rechners nach sich ziehen (z.B. Buffer Overflow), k�nnen sie auch einen Denial-of-Service herbeif�hren. Die Anwendung steht also nicht mehr zur Verf�gung, weil die ihr zugeordneten Ressourcen nicht mehr ausreichen oder weil sie abgest�rzt ist.
Es gibt verschiedene Typen von Denial-of-Service, die die Protokollspezifikationen des TCP/IP-Stacks benutzen.
Wir haben gesehen, da� sich eine TCP-Verbindung in drei Phasen aufbaut (TCP Three Way Handshake). Die SYN-�berschwemmung nutzt diesen Mechanismus aus. Die drei Etappen sind die Aussendung eines SYN, der Empfang eines SYN-ACK und die Aussendung eines ACK. Das Prinzip ist, den Zielrechner auf eine gro�e Zahl von TCP-Verbindungen warten zu lassen. Daf�r schickt der Pirat sehr viele Verbindungsanfragen (SYN-Flag auf 1), der Zielrechner antwortet darauf mit SYN-ACKs. Der Pirat antwortet niemals mit einem ACK, und somit reserviert der Zielrechner f�r jedes empfangene SYN eine TCP-Verbindung. Weil diese halboffenen Verbindungen Speicherressourcen verbrauchen, ist der Rechner nach einer Weile belegt und kann keine Verbindungen mehr annehmen. Diese Art von Denial-of-Service beeinflu�t nur den Zielrechner.
Der Pirat benutzt einen SYN-Flooder wie synk4, w�hlt den anvisierten TCP-Port und ordnet die Verwendung zuf�lliger IP-Absenderadressen an, um jede Identifikation des Piratenrechners zu vermeiden.
Dieser Denial-of-Service nutzt den nichtverbundenen Modus des UD-Protokolls aus. Er erzeugt einen „UDP Packet Storm“ (gro�e Menge von UDP-Paketen), entweder in Richtung auf einen Rechner oder zwischen zwei Rechnern. Eine solche Attacke zwischen zwei Maschinen hat eine Netz�berlastung zur Folge sowie eine Ressourcens�ttigung der beiden Opfer. Die �berlastung ist wichtiger, da der UDP-Verkehr Priorit�t gegen�ber dem TCP-Verkehr hat. Wirklich besitzt das TC-Protokoll einen Mechanismus der �berlastungskontrolle; falls die Best�tigung eines Paketes erst nach einer langen Verz�gerung eintrifft, pa�t er die H�ufigkeit der TCP-Paketsendungen an, der Absatz sinkt. Das UD-Protokoll hat keinen solchen Mechanismus, nach einer Zeitlang besetzt der UDP-Verkehr die ganze Bandbreite und l��t nur eine winzige Menge TCP-Verkehr zu.
Das bekannteste Beispiel von UDP-�berschwemmung ist der Chargen Denial of Service Attack. Seine praktische Umsetzung ist einfach, es reicht aus, den Dienst chargen eines Rechners mit dem Dienst echo eines anderen kommunizieren zu lassen. chargen erzeugt Buchstaben, w�hrend echo sich damit begn�gt, die empfangenen Daten wieder zur�ckzuschicken. Der Pirat braucht also nur UDP-Pakete zum Port 19 (chargen) eines seiner Opfer zu schicken und seine IP-Adresse und Quellport zu f�lschen. In diesem Fall ist der Quellport der UDP-Port 7 (echo). Die UDP-�berschwemmung f�hrt zur Auslastung der Bandbreite zwischen den beiden Maschinen. Ein ganzes Netzwerk kann also Opfer einer UDP-�berschwemmung werden.
Denial-of-Services vom Typ „Packet Fragment“ nutzen die Schw�che einiger Implementationen des TCP/IP-Stacks auf der Ebene der IP-Defragmentation (Wiederzusammensetzung der IP-Fragmente) aus.
Eine bekannte darauf basierende Attacke ist Teardrop. Der Fragmentierungsabstand des zweiten Fragments ist kleiner als die Gr��e des ersten, ebenso der Abstand plus die Gr��e des zweiten, d.h. das zweite Fragment ist im ersten enthalten (overlapping). Bei der Defragmentation behandeln manche Systeme diese Ausnahmesituation nicht, und das f�hrt zum Denial-of-Service. Es gibt Varianten des Angriffs: bonk, boink und newtear zum Beispiel. Der Denial-of-Service namens „The Ping of Death“ nutzt ein schlechtes Verhalten der Defragmentation auf der ICMP-Ebene aus, indem er eine Datenmenge schickt, die gr��er ist als die Maximalgr��e eines IP-Pakets. Diese verschiedenen Denial-of-Service-Attacken enden in einem Absturz des Zielrechners.
Dieser Angriff verwendet das Protokoll ICMP. Sobald ein Ping (eine ICMP ECHO-Botschaft) an eine Rundsendungs-Adresse (z.B. 10.255.255.255) geschickt wird, wird sie �bersetzt und an jede Maschine des Netzwerks geschickt. Das Wesen der Attacke ist die F�lschung der gesendeten ICMP ECHO REQUESTs, indem als IP-Absenderadresse diejenige des Zielrechners benutzt wird. Der Pirat schickt einen kontinuierlichen Ping-Strom zur Rundsendungs-Adresse eines Netzes, und s�mtliche Rechner antworten mit einem ICMP ECHO REPLY an den Zielrechner. Der Strom wird also von der Zahl der Rechner im Netz vervielfacht. Hier erleidet das ganze Netz die Denial-of-Service-Attacke, weil die enorme Quantit�t des von ihr erzeugten Datenverkehrs das Netz verstopft.
Verteilte Denial-of-Services �berf�llen das Opfernetzwerk. Das Prinzip ist, verschiedene Quellen (Daemons) f�r die Attacken und h�here Instanzen (Master), die jene kontrollieren, zu benutzen. Die bekanntesten Werkzeuge des DDoS (Distributed Denial of Service) sind Tribal Flood Network (TFN), TFN2K, Trinoo und Stacheldraht. Die Abbildung 13 zeigt ein typisches DDoS-Netz:
Abb. 13: DDoS-Netz
Der Pirat benutzt „Dienstherren“, h�here Instanzen, um leichter die Quellen kontrollieren zu k�nnen. Denn er mu� sich mit den Dienstherren (mit TCP) verbinden, um sie zu konfigurieren und die Attacke vorzubereiten. Die Dienstherren begn�gen sich damit, Kommandos per UDP zu den Quellen zu senden. H�tte er die Dienstherren nicht, m��te sich der Pirat zu jeder Quelle verbinden. Der Ursprung der Attacke w�rde viel leichter entdeckt und ihre Umsetzung dauerte viel l�nger.
Jeder Daemon kommuniziert mit seinem Master, indem er spezifische Botschaften austauscht, je nach dem verwendeten Werkzeug. Diese Kommunikation kann sogar verschl�sselt oder authentifiziert erfolgen. Um die Daemons und Master aufzustellen, benutzt der Pirat bekannte L�cken (Buffer Overflow in den Diensten RPC, FTP oder anderen). Der Angriff selbst ist eine SYN-�berschwemmung, UDP-�berschwemmung oder sonstige Smurf-Attacke. Das Ergebnis eines Denial-of-Service ist es somit, das Netzwerk unzug�nglich zu machen.
Heute verst�rkt sich die Sicherheit gegen entfernte Attacken mehr und mehr, im Gegensatz zur internen Sicherheit. Dieser „arme Verwandte“ der Schutzvorkehrungen gegen Piraten l��t immer noch lokalen Attacken wie dem TCP Session Hijacking, der ARP-F�lschung und der DNS-F�lschung gute Chancen. Zudem tauchen die Vorhersage von Sequenznummern (das Herzst�ck der IP-F�lschung) und die Varianten der Fragment Attacks einzig und allein wegen Fehlern auf Betriebssystemebene der Netzrechner auf. Was die Angriffe durch Applikationen betrifft, so haben jene noch gute Zukunftsaussichten dank der unaufh�rlich wachsenden Komplexit�t von Web-Applikationen und dank der immer k�rzer werdenden Fristen f�r Entwickler und Administratoren. Die Denial-of-Service-Attacken werden in ihrer verteilten Form ebenfalls sehr gef�hrlich bleiben, solange nicht alle auf den Schutz ihrer eigenen Rechner achten.