Grundlage für diesen Angriff bieten grundlegende Schwächen des TCP/IP.
Zum einem ist es möglich, eigene Datenpakete mit gefäschter
IP-Adresse zu versenden. So kann der Ziel-Host also Datenpakete erhalten, deren
Absender-Adresse auf einen Host hinweisen, der diese Pakete eigentlich gar
nicht abgeschickt hat. Zum anderen lässt sich die Sequenznummer ermitteln,
die für die Synchronisation der jeweiligen Rechnersysteme genutzt wird, um
eine TCP/IP Verbindung herzustellen.
Diese Schwächen nutzt ein Angreifer aus, um Dienste wie RLogin zu
unterwandern. Rlogin erlaubt dem User, ferngesteuert von einem Host zu einem
anderen einzuloggen unter der Vorraussetzung, dass ihm das entsprechende
Vertrauen gegeben wurde. Es geht hier also um die Ausnutzung des
Vertrauensverhältnisses, die einen unberechtigen Zugriff auf das
Netzwerk ermöglichen soll. Die Basis des Vertrauens wird durch eine
Authentifizierung des Klienten via Ursprungs-IP-Adresse vorgenommen. So
findet bei jedem eingehenden Datenpaket eine automatische Authentifizierung
statt, ohne jedesmal ein Passwort eingeben zu müssen.
Hier sollte eigentlich klar werden, dass diese IP adressenbasierte Authentifizierung
aufgrund der Eigenschaften des TCP/IP ein Risiko birgt. Gefälschte
Datenpakete mit kompromitierenden Anweisungen könnten an den Host
geschickt werden und dem Angreifer die Möglichkeit bieten, eine Hintertür
zu hinterlassen. Dies macht dann ein vereinfachtes Eindringen ins System
möglich. Da der Ziel-Host sich bei diesem Dienst nur auf die
adressenbasierte Authentifizierung verlässt, hegt dieser auch keinen
Zweifel daran, wenn Datenpakete empfangen werden, die allem Anschein nach von
einem anvertrauten Host (Trusted Host) herstammen.
Hier müssen nur noch zwei Gesichtspunkte bei diesem Angriff beachtet
werden. Das betrifft zum einem das Ermitteln der Sequenznummer
und zum anderen das Lahmlegen des anvertrauten Hosts. TCP
(Transmission Control Protocol) ermöglicht einen zuverlässigen
Transport der Datenpakete durch die Zuweisung von Sequenznummern an jedes zu
tranferrierende Datensegment und lässt deren Empfang durch sogenannte
"ACKs" (Acknowledgements) quittieren. Diese ACKs sind ebenfalls
mit einer Sequenznummer versehen. Aufgrund dieser Sequenznummer ermöglicht
TCP, verlorene Datenpakete wieder herzustellen, zu duplizieren, oder Fehler
zu erkennen. Soll also ein IP-gespooftes Datenpaket vom Ziel-Host akzeptiert
werden, muss also nicht nur die Absender-IP stimmen, sondern auch die dazu
entsprechende Sequenznummer.
Ermitteln der Sequenznummer
Die Sequenznummer ist in vielen Fällen relativ leicht zu ermitteln, da
diese in vielen Fällen nicht zufällig gewählt wird, sondern
sich nach konstanten Werten orientiert. Der Wert der Sequenznummer wird in
der Regel um 128000 in der Sekunde und um 64000 pro Verbindung erhöht.
Leichte Probleme macht nur noch das Ermitteln der RTT (round-trip time).
Der Angreifer muss sich ein Bild darüber machen, wie lange ein IP-Datagramm
braucht, um das Ziel-Host nach seiner Reise durchs Internet zu erreichen. Um
die nächst folgende Sequenznummer vorherzusagen, muss er also folglich
die RTT kennen.
Lahmlegen des vertrauten Hosts
Ein letztes Detail ist noch der vertraute Host (Trusted Host). Da der
Angreifer dem Ziel-Host weissmachen will, dass seine gefälschten
Datenpakete vom vertrauten Host stammen, darf der vertraute Host nichts von
diesem Zwischenspiel mitbekommen. Denn dieser würde schliesslich
ACKs erhalten, die eigentlich nicht erwartet werden und würde ein
Paket mit einem RST(Reset)-Flag im TCP-Header antworten. Der Empfang
eines RST würde dem Ziel-Host signalisieren, dass die andere Seite ein
Segment erhalten hat, dass mit der momentanen Verbindung nicht in Einklang
steht. Das hätte zur Folge, dass die gespoofte Verbindung unterbrochen
wird, und die entsprechende Sequenznummer sich ändert. Also muss der
vertraute Host durch eine
DOS-Attacke lahmgelegt werden.
Zu beachten ist, dass der Angreifer nichts von dem Datenstrom mitbekommt,
den der Ziel-Host an seinen vertrauten Host zurück sendet. Der Angreifer
sollte also so schlau sein zu wissen, was der Ziel-Host sendet und auch
wissen, was dieser für eine Antwort erwarten mag...