Dynamic ARP Inspection gegen ARP-Poisoning

Das Adress Resolution Protocol (Kurz ARP) hat die Aufgabe Adressen aus der Internetschicht einer Hardware-Adresse zu zuordnen. Anhand dieser Zuordnung führen Clients, unabhängig voneinander, eine eigene ARP-Tabelle auf. Diese Tabelle wird später für Verbindungen innerhalb des eigenen Subnet gebraucht. Man kann sich lange darüber unterhalten, ob ARP jetzt auf Layer-2 oder Layer-3 agiert. Für meine Begriffe ist es ein reiner Layer-2 Protokoll.

Wie funktioniert die Kommunikation von ARP im Netzwerk?

Wir gehen davon aus, dass unser Client mit der IP 192.168.1.104 eine Verbindung zum 192.168.1.32 aufbauen möchte. Für Verbindungen innerhalb des Subnet verwedent der Client sein eigenes ARP-Cache. Ist die Ziel IP-Adresse nicht zu finden, dann sendet er einen ARP-Broadcast (ARP-Request) an die Adresse FF:FF:FF:FF:FF:FF mit der Frage „Welche MAC-Adresse hat die IP-Adresse 192.168.1.32?“. Da die Zielmaschine innerhalb des selben Subnet ist, sieht sie den Broadcast und fühlt sich angesprochen, darauf antwortet sie mit einem ARP-Unicast (ARP-Reply): „Die IP-Adresse 192.168.1.32 is at AB:BB:3D:F3:C6:07“. Im selben Zug speichert die Zielmaschine die Daten aus dem ARP-Request in seiner Tabelle, um zukünftige ARP-Broadcast zu vermeiden. Die Maschine mit der IP-Adresse 192.168.1.104 erhält die Antwort und ergänzt seine ARP-Tabelle.

Um das klar zu stellen, es ist Standardmässig so vorgesehen, dass alle entgegen genommene ARP-Replies in den Cache aufgeführt werden.Es ist genau so einfach wie es aussieht.

Aber was passiert, wenn ein Rechner im Netz seine IP-Adresse verändert? Dann müsste alle Clients im Netz warten, bis ARP den Cache nach der Zeitüberschreitung von Dynamischen Einträge leert. Bei älteren Windows Versionen kann es bis zu 2 Minuten dauern. Auf meiner Windows 10 Maschine ist der Wert auf 20500ms festgelegt.

Dennoch, das ist viel zu Lange, um eine Verbindung wieder aufzunehmen. Dafür gibt es sogenannte Gratuitous-ARP-Pakete. Nach einer Veränderung am Interface kann der Client freiwillig einen Paket schicken, um die Teilnehmer im Netz mitzuteilen, dass seine eigene Netzwerkkonfiguration geändert hat.

Es gibt kein Mechanismus auf ARP-Ebene, dass eine Überprüfung der Legitimität einer Maschine vorzieht. Also muss die Maschine daran glauben, wenn er eine solche Information erhält.

Das heisst konkret, dass jeder im eigenen Subnet behaupten kann das Gateway zu sein und die jenigen die diese Antwort erhalten, werden das so notieren und handhaben. Diese Art von Verfälschung nennt man ARP-Spoofing, fällt der Client darauf ein, dann heisst es ARP-Poisoning.

ARP-Posoning unter Kali Linux

Um einen ARP-Poisoning Angriff unter Kali Linux zu starten, brauchen wir nur zwei Eingriffe.

In einer Konsole als root müssen wir dafür sorgen, dass unsere Netzwerkanschluss in der Lage ist Pakete weiterleiten zu können. Diese Option wird lediglich über eine Datei gesteuert. In der Datei kann man zwei Zustände schreiben = 0 oder 1 (Aus oder An).

echo 1 > /proc/sys/net/ipv4/ip_forward

Da jetzt das Verhalten der Kali Maschine günstig für eine ARP-Spoofing Attacke ist, können wir nun den Angriff lancieren. Dafür benötigen wir der name unseres Interface worüber den Angriff gestartet wird, die IP-Adresse des Routers/Gateway und die vom Opfer.

Interface: eth0
Router/Gateway: 192.168.1.1
Opfer: 192.168.1.104

Befehl + Syntax sieht wie folgt aus.

arpspoof -i eth0 -t 192.168.1.104 -r 192.168.1.1

Wenn man arpspoof unter Kali Linux nicht findet, dann muss man das Paket „DSNIFF“ installieren.

sudo apt-get install dsniff

Bei der Ausgabe habe ich bemerkt, dass aus irgendeinem Grund die MAC-Adresse der Kali Maschine wird fehlerhaft angezeigt. Das vierte Oktekt kann das 0b nicht darstellen und gibt nur b aus. Um die Ausgabe besser zu verstehen, werden wir die 1. und 2. Zeile erklären, denn alles was danach kommt ist endlos wiederholend.

Erste Zeile

Source MAC-Adresse 54:ee:75:0b:7f:de sendet ein ARP Reply an die MAC-Adresse f0:79:59:61:5c:29 mit der Information, dass die IP-Adresse 192.168.1.1 die MAC-Adresse 54:ee:75:0b:7f:de hat.

Somit teilt unsere Linux Maschine an dem Opfer, dass das Gateway die MAC-Adresse des Angreifers hat.

Zweite Zeile

Source MAC-Adresse 54:ee:75:0b:7f:de (Kali Linux) sendet ein ARP Reply an die MAC-Adresse d4:63:fe:8e:e0:44 (Gateway) mit der Information, dass die IP-Adresse 192.168.1.104 (Opfer) die MAC-Adresse 54:ee:75:0b:7f:de (Kali Linux) hat.

Somit teilt unsere Linux Maschine an dem Router, dass unser Opfer die MAC-Adresse des Angreifers hat.

Zusammengefasst bedeutet, dass Gateway und Opfer getäuscht werden und denken, dass deren Gegenüber Partner die Kali Linux Maschine ist.

Wie sieht der Angriff aus der Sicht des Opfers aus?

Für den Opfer ändert sich visuell wenig. Der bekommt gar nicht mit, dass im Netzwerk etwas im Gange ist. Aber, wenn wir auf Netzwerschicht Ebene schauen, sehen wir diverse Diskrepanzen vor und nach dem Angriff.

Hier ist die Ansicht der ARP-Tabelle vor und nach der Attacke. Wir sehen wie die MAC-Adresse des Gateways von einem Moment zum nächsten gewechselt hat.

Wenn wir auf der Maschine des Opfers Wireshark mit einem Filter für ARP und die MAC-Adresse des Angreifers, dann sehen wir das

arp && eth.addr == 54:ee:75:0b:7f:de

Wie wir auf dem nächsten Bild sehen können, erhaltet das Opfer immer wieder ARP-Replies vom Angreifer.

Hier ein detailliertes Paket

Netzwerkverkehr abhören

Pakete welche für das Gateway oder Opfer prädestiniert sind, laufen über die Kali Linux Maschine. Somit ist man in der Lage, die Pakete abzuhören.

Für dieses Beispiel habe ich eine Test Website im Internet ausgewählt, die HTTP-Verkehr zulässt. Hier können beruhigt sein, würden wir eine Website auswählen, die über HTTPS kommuniziert, dann wäre für uns der Traffic immer noch verschlüsselt.

Auf dieser Website gibt es einen kleinen Login Formular, wie wir ihn auf viele andere Websites kennen. Nun gebe ich Benutzer und Passwort ein (administrator & mysecretpassword) und klicke auf Submit.

Nun wird meine Angaben übermittelt und verarbeitet. Doch was das Opfer nicht weiss, ist dass der Angreifer die ganze Zeit die Verbindung abgehört hat.

Wireshark Analyse

Auf der Kali Linux Maschine läuft Wireshark und hört alles mit, was über das Interface „eth0“ läuft.

Man kann eine ganze Menge TCP-DupAck und TCP-Retransmissions Pakete erkennen. Ich bin noch nicht ganz zu 100% dahinter gekommen. Es wird sicher ein Update geben, wenn ich das noch genauer analysiere.

In der Aufnahme sehen wir Pakete die, in einem normalen Fall, überhaupt nicht für unseres Interface gedacht war.

Wir können uns ein HTTP-Frame aussuchen, Rechte Maustaste und unter „Follow Stream -> HTTP-Stream“ auswählen. Nun können wir, da wir eine Website mit Übertragung in Klartext gewählt haben, beide Variable: urs & pwd mit den jeweiligen Werte dargestellt.

Nun haben wir gesehen, wie einfach es ist die Geräte im Netzwerk zu täuschen.

Angriff beendet

Beim Ausschalten oder beenden des Dienstes (Durch CTRL+C), kann man folgendes betrachten

Der Angreifer shickt viele Replies zum Opfer und Gateway mit den ursprüngliche MAC-Adressen. Somit sind auf beiden Seiten die ARP-Tabelle wieder in Ordnung.