Der Unterschied zwischen Feature und Bug ist oftmals eine Frage der Betrachtungsweise. So bieten Protokolle wie ARP (Address Resolution Protocol) und ICMP (Internet Control Message Protocol) - auch wenn sie völlig korrekt implementiert sind - Mißbrauchsmöglichkeiten, die aus Sicht der Netzwerksicherheit geradezu fatale Folgen haben können.

Die fehlende Absicherung der unteren Protokollschichten gegen gezielte Angriffe resultiert noch aus der Entstehungszeit der Netzwerke. Nach der damaligen Grundannahme gehörten zumindest die Systemverwalter der angeschlossenen Rechner zu den 'Good Guys'. Damit konnte man sich auf IP-Adressen, Routing-Einträge et cetera verlassen, da sie nur dem Administrator zugänglich waren.

Durch die Vernetzung von Einzelplatzrechnern, die unter der vollständigen Kontrolle des jeweiligen Benutzers stehen, fielen die Barrieren gegen den Mißbrauch der unteren Protokollschichtcn: Das Fälschen von IP-Adressen mutierte von einer theoretischen Möglichkeit zum 'Volkssport' [1, 2].

Noch unterhalb der Transport- und Netzwerkschicht ist der sogenannte Link-Layer angesiedelt. Er ist die letzte Instanz für die Übertragung der Daten, die im lokalen Netz meist über ein Ethernet erfolgt. Bevor ein IP-Paket übertragen wird, versieht es der zuständige Treiber mit den MAC-Adressen (Media Access Control) von Sender und Empfänger. Diese 48-Bit-Zahl wird auch als Hardware-Adresse des Rechners bezeichnet, da sie eindeutig einer Ethernet-Karte zugeordnet ist (abgesehen von wenigen Karten, bei denen sie konfigurierbar ist). Anhand der eigenen MAC-Adresse im Ethernet-Header erkennt die Netzwerkkarte des Adressaten, daß sie gemeint ist, nimmt das Paket entgegen und reicht dessen Inhalt - also das IP-Datagramm - an den IP-Stack weiter.

Um die Hardware-Adresse des Zielrechners zu ermitteln, sendet der Absender einen ARP-Request (Address Resolution Protocol) an das gesamte LAN (Broadcast). Der angesprochene Rechner antwortet darauf mit einem ARP-Reply, der seine MAC-Adresse enthält. Aus Performance-Gründen und zur Reduzierung der Netzwerkbelastung verfügt jeder Host über einen Cache, in dem er die Hardware-Adressen bis zu zehn Minuten zwischenspeichert. Findet er beim nächsten Paket eine gültige MAC-Adresse im Cache, kann er sie direkt verwenden, und die Lebenszeit des Eintrags verlängert sich. Das Kommando arp -a gibt auf Windows95-, NT-, OS/2- und Unix-Rechnern den aktuellen Inhalt des Cache aus.

In einem einfachen Szenario befinden sich die Rechner Hugo, Emil und Otto im selben Netzwerk (vergleiche Abbildung). Der Angreifer auf Otto weiß, daß Hugo Emil vertraut. Das kann zum Beispiel bedeuten, daß Hugo gelegentlich interessante Daten auf Emil kopiert. Könnte Otto sich als Emil ausgeben, hätte der Angreifer sofort Zugang zu diesen Informationen.

Die einfachste Variante, sein eigenes Netzwerk-Interface auf Emils IP-Adresse zu konfigurieren, scheitert an den eingebauten Logging-Mechanismen (abgesehen davon, daß es ein klassisches Wettrennen ohne eindeutigen Sieger ergibt). Antworten zwei Rechner auf einen ARP-Request, erkennen dies die meisten Systeme als Fehlkonfiguration und beschweren sich auf irgendeine Art, worauf der Cracker sicher keinen Wert legt.

Deshalb macht Otto sich eine Schwäche von ARP zunutze: Als zustandsloses Protokoll akzeptiert es auch unangeforderte ARP-Antworten und übernimmt diese in den Cache. Füttert Otto den ARP-Cache von Hugo regelmäßig mit gefälschten Paketen, die seine eigene Hardware-Adresse mit Emils IP-Adresse assoziieren, sendet Hugo niemals ARP-Requests ins Netz: Es treten keine Kollisionen auf. Außerdem versieht der Angreifer seinen eigenen ARP-Cache mit entsprechenden statischen Einträgen und desaktiviert ARP für dieses Interface, um keine verräterischen Pakete entkommen zu lassen - es könnte schließ1ich ein anderer Rechner einen ARP-Request stellen.

Hugo ist nun der festen Überzeugung, daß er Emil unter der MAC-Adresse von Otto erreichen kann und baut beispielsweise eine ftp-Verbindung zu Ottos Rechner auf - jedes beliebige andere Protokoll funktioniert natürlich genauso. Otto meldet sich mit der richtigen (also Emils) IP-Adresse und nimmt die gesendeten Daten dankbar in Empfang.

Hugos einzige Chance, zu erkennen, daß es sich beim Gegenüber nicht um Emil handeln kann, besteht darin, die MAC-Adressen im ARP-Cache zu überprüfen. Aber wer merkt sich schon zwölfstellige Hexadezimalzahlen?

Die Reichweite dieser Angriffe ist auf das lokale Netz beschränkt, da ARP-Pakete nicht ' geroutet werden. Aber auch ' Router oder gar Firewalls lassen ;. sich nach diesem Muster täuschen, so daß Otto - mit Hilfe des Firewalls - nach außen jeden beliebigen Rechner im Netz verkörpern kann.

Befinden sich beispielsweise Hugo und Emil in verschiedenen Abteilungen, die durch einen Firewall getrennt sind, könnte Otto den Firewall überzeugen, daß er Emil sei. Paketfilter oder Application-Proxies, die aufgrund von IP-Adressen entscheiden, ob eine Verbindung zulässig ist, haben keine Chance, diesen Betrug zu bemerken: Der Firewall ist geknackt.

Eine einfache Variante dieses Angriffs versendet nur ARP-Pakete mit falschen MAC-Adressen und verhindert so gezielt die Kommunikation zwischen einzelnen Rechnern oder auch im ganzen LAN.

Zum Schutz gegen solche Attacken muß man mit einem statischen ARP-Cache arbeiten. Der Befehl

arp -s  <hostname> <HW-Adresse>

erzeugt einen entsprechenden Eintrag. Unter Unix ermöglicht die Option -f die Verwendung kompletter Konfigurationsdateien. OS/2- und Windows-Benutzer müssen sich mit entsprechenden Scripts behelfen. Anschließend verhindert

ifconfig eth0-arp

weitere ARP-Einträge (Windows kennt allerdings kein if-config). Das Auswechseln einer einzelnen Netzwerkkarte erfordert dann natürlich eine Anpassung aller Tabellen. Wer diesen mühsamen Vorgang abkürzt, indem er beispielsweise via NFS (Network File System) oder TFTP (Trivial File Transfer Protocol) zentrale ARP-Tabellen bereitstellt, treibt den Teufel mit dem Beelzebub aus. Aber das ist eine andere Geschichte.

Ein völlig anderer Angriff nutzt das Internet Control Message Protocol (ICMP), mit dem TCP/IP-Rechner Statusmeldungen versenden (siehe auch [3]). Stellt beispielsweise ein Router über seine Tabellen fest, daß ein Host einen kürzeren Weg zu seinem Ziel benutzen könnte, sendet er eine ICMP-RedirectNachricht an den Absender. Dieser modifiziert daraufhin seine. eigenen Routing-Tabellen entsprechend und wird in Zukunft das neue Gateway nutzen.

#!/bin/sh
#
# Poison ARP-Cache and steal IP-Adress
#
TARGET_IP=10.0.0.1
TARGET_MAC="AA:AA:AA:AA:AA:AA"
SPOOF_IP=10.0.0.2
MY_MAC="CC:CC:CC:CC:CC:CC:"
ifconfig eth0 down
# Set up Interface and add some ARP- and Routing-Entries
ifconfig eth0 $SPOOF_IP arp
route add $TARGET_IP $TARGET_MAC
arp -s $TARGET_IP $TARGET_MAC
sleep 1
# Turn off ARP answers
ifconfig eth0 -arp
while (true) do
  ./fake_arp $SPOOF_IP $MY_MAC $TARGET_IP $TARGET_MAC
  echo "ARP Cache updated"
  sleep 60
done

Mit diesem Mechanismus ist es möglich, komplexere Routing-Informationen nur auf dem Router vorzuhalten. Die Hosts verfügen anfangs nur über eine Default-Route und lernen im Lauf der Zeit die benötigten dynamischen Routen hinzu.

Damit ist auch schon klar, wie der Angreifer auf Otto sein Opfer 'diesmal hereinlegt: Er schickt Hugo eine gefälschte ICMP-Redirect-Nachricht, in der er p ich als neues Gateway für einen beliebigen externen Rechner - etwa den WWW-Proxy des Providers - ausgibt. Dabei muß er allerdings ein paar Regeln beachten. Die Absenderadresse muß Hugo bereits als Router bekannt sein. Dies erreicht Otto einfach, indem er die Header-Einträge des ICMP-Packets selbst erzeugt und über einen Raw-Socket versendet. Hugo muß das neue Gateway direkt - also über das lokale Netz - erreichen können. Das Ziel darf sich jedoch nicht im LAN befinden und Hugo darf selbst kein Router sein.

Im einfachsten Fall kann Otto dafür sorgen, daß Hugo keine Verbindungen nach außen mehr aufbauen kann. Oder er kann mehrere tausend Routen erzeugen, die Otto für jedes Paket durchsuchen muß: da viele Desktop-Betriebssysteme eine lineare Suche durchführen, summiert sich dieser Vorgang auf die Dauer. Leistungsfähigere IP-Implementierungen in Unix-Derivaten und Routern verwenden hochoptimierte Suchalgorithmen, die sich dadurch nicht beeindrucken lassen.

Für solche 'Denial of Service Attacks' muß sich der Angreifer nicht im lokalen Netz befinden; es genügt wenn er dem Opfer ICMP-Pakete zustellen kann. Bei einem komplexeren Szenario fungiert Otto tatsächlich als Gateway, indem er die Pakete - nachdem er sie protokolliert oder verändert hat - an den richtigen Router weiterleitet. Zumindest gegen Redirect-Angriffe von außen kann man sich relativ einfach mit einem Firewall schützen, der keine ICMP-Pakete herein läßt. Gegen den internen Mil3brauch der Kontrollmeldungen gibt es derzeit keinen vernünftigen Schutz.

Sowohl ARP-als auch ICMP-Angriffe basieren auf der Tatsache, daß sich Rechner allein durch ihre IP-Adresse als legitimer Absender eines Kontroll-Pakets ausgeben können. Diese einfache IP-basierte Authentifizierung wird der Situation in heutigen Netzwerken nicht mehr gerecht und sollte - wo möglich - vermieden werden. Die Übertragung sensibler Daten sollte auf jeden Fall mit , kryptographischen Methoden gesichert sein. Für den Rest hilft nur ein vernünftiges Gefahrenbewußtsein und vielleicht Sankt Florian.