ARP-Spoofing

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von ARP-Poisoning)
Zur Navigation springen Zur Suche springen

ARP-Spoofing (vom engl. to spoof – dt. täuschen, reinlegen) oder auch ARP Request Poisoning (zu dt. etwa Anfrageverfälschung) bezeichnet das Senden von gefälschten ARP-Paketen. Es wird benutzt, um die ARP-Tabellen in einem Netzwerk so zu verändern, dass anschließend der Datenverkehr zwischen zwei (oder mehr) Systemen in einem Rechnernetz abgehört oder manipuliert werden kann. Es ist eine Möglichkeit, einen Man-in-the-Middle-Angriff im lokalen Netz durchzuführen.

Ziel eines derartigen Angriffes kann auch IP-Telefonie sein, um Telefonate abzuhören.

Trotz der Bekanntheit und des Alters des Angriffes bieten gängige Betriebssysteme keinen Schutz vor ARP-Spoofing an. Dieser muss in der Regel nachgerüstet werden.

Funktionsweise[Bearbeiten | Quelltext bearbeiten]

Ein Ethernet-Rahmen. Ein verfälschter Rahmen kann beispielsweise eine falsche Quell-MAC Adresse beinhalten

Um den Datenverkehr zwischen Host A und Host B abzuhören, sendet der Angreifer an Host A eine manipulierte ARP-Nachricht zur Zuordnung einer bestimmten IP-Adresse. In dieser Nachricht ist seine eigene MAC-Adresse anstelle der von Host B enthalten, so dass Host A zukünftig die Pakete, die eigentlich für Host B bestimmt sind, an den Angreifer sendet. Dasselbe geschieht mit Host B, so dass dieser Pakete statt direkt an A nun ungewollt zum Angreifer sendet. Der Angreifer muss nun die von A und B erhaltenen Pakete an den eigentlichen Empfänger weiterleiten, damit eine abhörbare Verbindung zustande kommen kann. Ist dies geschehen, so arbeitet der Angreifer unbemerkt als Proxy. Man spricht dabei von einem Man-in-the-Middle-Angriff. Der Angreifer kann selbstverständlich auch den Netzwerkverkehr verwerfen, um eine Kommunikation zwischen bestimmten Hosts unmöglich zu machen oder aber den Datenverkehr verändern.

Während ein reines Abhören des Netzwerkverkehrs mit Hilfe eines Sniffers nur in ungeswitchten Netzwerken funktioniert, ist dieser Angriff auch in geswitchten Netzwerken erfolgreich. Software, die diese Proxy-Funktion implementiert, ist für alle gängigen Betriebssysteme kostenlos im Internet zu erhalten und relativ leicht zu bedienen (siehe Ettercap, Wireshark).

Konsequenzen[Bearbeiten | Quelltext bearbeiten]

Damit hat ein Angreifer bei ungeschützten Verbindungen, wie sie beim Senden von E-Mails oder Betrachten von Webseiten früher verwendet wurden, fast freie Hand zum Mitlesen und Manipulieren. Heute übliche verschlüsselte und authentifizierte Verbindungen sind tendenziell sicherer; sie verwenden oft sichere kryptografische Algorithmen und digitale Zertifikate zur Authentifizierung der Gegenstelle.

Klinkt ein Angreifer sich zum Beispiel in eine HTTPS-Verbindung ein, um das Homebanking zu manipulieren, so erkennt der Anwender dies an einer Warnmeldung des Browsers über ein ungültiges Zertifikat. Ein Angreifer kann allerdings in praktischen Szenarien Benutzer daran hindern, TLS-Verbindungen aufzubauen und dann die angeforderten HTTPS-Verbindungen durch solche über HTTP ersetzen. So ist es möglich, Daten, die sonst verschlüsselt versendet würden, trotzdem abzufangen.

SSH-Verbindungen sind dann als sicher einzustufen (SSH Version 1 nicht), wenn ein veränderter Fingerprint zum Abbruch des Verbindungsaufbaus führt. Oft wird der Benutzer nach Anzeige der Fingerprints aufgefordert, zu entscheiden, ob er mit dem Verbindungsaufbau fortfahren möchte.

ARP-Spoofing erkennen[Bearbeiten | Quelltext bearbeiten]

ARP-Spoofing zu erkennen oder zu verhindern ist nicht einfach. Dazu gibt es mehrere Möglichkeiten. Eine davon ist, das ARP ganz außen vor zu lassen und mit statischen Tabellen zur Umsetzung von IP-Adressen zu Hardware-Adressen zu arbeiten. Diese Möglichkeit ist nicht sehr effizient, weil die ARP-Tabellen ständig aktualisiert werden müssen. Besser ist es, am Grundproblem anzusetzen: Jede ARP-Antwort, ob angefordert oder nicht, ob sinnvoll oder nicht, wird von fast allen Betriebssystemen akzeptiert. Hier kann es helfen, das Verarbeiten von ARP-Antworten Programmen mit größerer Intelligenz zu überlassen. Diese überwachen, wer die Antworten wann schickt und welche Informationen die Antworten enthalten. Offensichtlich gefälschte ARP-Pakete lassen sich so erkennen und verwerfen. Durch Anbindung an ein Intrusion Detection System lässt sich eine entsprechende Warnung an den Systemverwalter ausgeben.

ARP-Spoofing lässt sich zumeist gut erkennen, wenn man die ARP-Tabellen anschaut. Im folgenden Beispiel führt der Rechner mit der MAC-Adresse c5:cb:df:56:b5:f2 ein ARP-Spoofing durch, bei dem er allen Hosts im Netzwerk sagt, er sei jeder andere: Er gibt seine MAC-Adresse für jede IP an (sodass ihn der Netzwerkverkehr an alle Hosts erreicht). Er leitet den Traffic allerdings transparent weiter, sodass die Attacke für alle anderen Hosts eigentlich unbemerkbar ist (wobei natürlich auch jeglicher Traffic verworfen werden kann und somit eine vollständige Blockade jeglichen Traffics entstehen würde). Gezeigt wird die ARP-Tabelle eines der Opferrechner im Netzwerk. Es ist nicht erkennbar, wer der Angreifer ist; hierfür müsste der Administrator alle MAC-Adressen absuchen. Das könnte allerdings durch ein MAC-Spoofing verhindert werden.

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.6              ether   c5:cb:df:56:b5:f2   C                     eth0
192.168.1.8              ether   c5:cb:df:56:b5:f2   C                     eth0    Der Angreifer!
192.168.1.1              ether   c5:cb:df:56:b5:f2   C                     eth0
192.168.1.9              ether   c5:cb:df:56:b5:f2   C                     eth0

Im folgenden Beispiel ist der Angreifer genügsamer: er fängt nur Verkehr vom und ins Internet ab (192.168.1.1 ist der Gateway).

Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.6              ether   00:15:af:43:90:de   C                     eth0
192.168.1.8              ether   c5:cb:df:56:b5:f2   C                     eth0    Der Angreifer!
192.168.1.1              ether   c5:cb:df:56:b5:f2   C                     eth0    Eigentlich Router, wird aber durch gefälschte MAC-Adresse zum Angreifer geleitet
192.168.1.9              ether   a8:7b:39:dc:78:a3   C                     eth0

192.168.1.1 ist der Gateway des Netzwerks; der Angreifer (.8) liest also auch den Verkehr ins Internet mit.

Auf dem Opferhost des ersten Beispiels sähe ein traceroute zu einem Nachbarrechner so aus:

traceroute to 192.168.1.9 (192.168.1.9), 30 hops max, 60 byte packets
 1  192.168.1.8 (192.168.1.8)  2.629 ms  2.615 ms  2.604 ms      Der Angreifer, der alle Pakete weiterleitet!
 2  192.168.1.9 (192.168.1.9)  77.776 ms  78.261 ms  79.246 ms   Der Zielrechner

Ohne ARP-Spoofing müsste die Ausgabe so aussehen:

traceroute to 192.168.1.9 (192.168.1.9), 30 hops max, 60 byte packets
 1  192.168.1.9 (192.168.1.9)  134.356 ms  134.824 ms  135.314 ms

Am Anfang der Attacke sieht der Paketverkehr des Angreifers so aus (aufgenommen mit tcpdump):

13:17:27.376957 ARP, Reply 192.168.1.9 is-at c5:cb:df:56:b5:f2 (oui Unknown), length 28
13:17:27.387128 ARP, Reply 192.168.1.8 is-at c5:cb:df:56:b5:f2 (oui Unknown), length 28
13:17:27.387432 ARP, Reply 192.168.1.7 is-at c5:cb:df:56:b5:f2 (oui Unknown), length 28
13:17:27.388654 ARP, Reply 192.168.1.6 is-at c5:cb:df:56:b5:f2 (oui Unknown), length 28
13:17:27.388995 ARP, Reply 192.168.1.5 is-at c5:cb:df:56:b5:f2 (oui Unknown), length 28

Die Traceroute-Methode ist freilich nutzlos, wenn der Angreifer den Verkehr nicht weiterleitet, sondern verwirft, und der gesamte Netzwerkverkehr unterbunden wird. Die Methode, in der ARP-Tabelle nachzusehen ist zumeist hilfreicher, da es eigentlich nicht vorkommen sollte, dass sich mehrere IP-Adressen eine MAC-Adresse teilen.

Legitime Anwendung[Bearbeiten | Quelltext bearbeiten]

Im Bereich der Linux- und BSD-basierten Hochverfügbarkeitscluster wird das gezielte Manipulieren der ARP-Pakete verwendet, um bei Ausfall des primären Servers keine Datenpakete zu verlieren und sofort zum neuen „Ansprechpartner“ im Cluster umzuleiten. Der sekundäre Server muss dann die gemeinsame IP-Adresse des Clusters übernehmen.

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]