Im heutigen Artikel geht es um das Thema ARP (Address Resolution Protocol) und die möglichen Angriffsvektoren in diesem Kontext.
Beim ARP-Spoofing sendet ein Angreifer ARP-Antwort Pakete an gewählte Netzwerkteilnehmer und verändert so deren ARP-Tabelle um jeglichen Netzwerkverkehr mitlesen und ggf. manipulieren zu können.
Das Address Resolution Protocol wird in Broadcast-Domänen genutzt um MAC-Adressen die passende IPv4-Adresse zuzuordnen. Die Zuordnung wird lokal beim jeweiligen Netzwerkteilnehmer in einer ARP-Tabelle gespeichert.
Das Problem des Address Resolution Protocols liegt an der ARP-Anfrage und der ARP-Antwort. Beim ARP-Spoofing flutet ein Angreifer, mittels gefälschter ARP-Antworten die ARP-Tabellen aller Netzwerkteilnehmer. Sollte ein Netzwerkteilnehmer nun beispielsweise eine Verbindung zum Server aufbauen wollen, schaut er zuerst in seiner ARP-Tabelle nach, ob für die IP-Adresse des Servers eine MAC-Adresse hinterlegt ist. Da in der ARP-Tabelle des Clients jede IP-Adresse auf die MAC-Adresse des Angreifers zeigt, wird die Verbindung nicht zum Server sondern zum Angreifer aufgebaut.
Für einen klassischen Man-in-the-Middle Angriff, leitet der Angreifer die ankommenden Anfragen einfach weiter und kann den Netzwerkverkehr mitlesen und ggf. manipulieren. Er fungiert quasi als transparenter Proxy.
Für den Man-in-the-Middle Angriff können unter anderem die Tools Ettercap und Bettercap verwendet werden. In diesem Beispiel wird in der Konsole Bettercap verwendet und Ettercap als Alternative mit grafischer Benutzeroberfläche.
In dem gezeigten Beispiel kommuniziert Client A (192.168.1.3) mit einem Client B (192.168.1.2) und der Angreifer (192.168.1.5) führt eine Man-in-the-Middle Attacke mittels ARP-Spoofing aus. Es wird gezeigt wie der Angreifer den Netzwerkverkehr mitschneiden kann. So wird auch die Anmeldung des Clients auf der vom Server gehosteten Website mitgeschnitten, bei der Authentifizierung handelt es sich hierbei um eine HTTP Basic Authentifizierung.
Man in the Middle Angriff mit grafischer Oberfläche:
Es werden folgende Schritte ausgeführt:
1. Start des Programms Ettercap.
2. „Accept“ auswählen in der Leiste oben rechts.
3. Über die Lupe oben links können Hosts im Netzwerk über ARP gefunden werden und werden anschließend in der Host List (rechts neben der Lupe) angezeigt.
4. Mit dem Button „MITM Menu“ kann über das Dropdown Menü „ARP-Spoofing“ ausgewählt werden.
5. Werden nun unverschlüsselte Daten von einem gespooften Client verschickt, werden z.B. eingegebene Anmeldedaten im unteren Teil des Fensters angezeigt.
Zum Ausführen von Bettercap in der Konsole, wurde von uns der folgende Command verwendet:
timeout 60 bettercap -iface eth0 -eval "set http.proxy.sslstrip true; set net.sniff.verbose true; set net.sniff.output /root/mitm.pcap; set arp.spoof.fullduplex true; set arp.spoof.internal true; net.recon on; net.probe on; arp.spoof on; http.proxy on; net.sniff on"
timeout
Mit dem Zusatz timeout kann die Dauer des Man-in-the-Middle Angriffs festgelegt werden.
Dies ist besonders in umfangreichen Netzwerken vorteilhaft falls sich das für den Angriff verwendete System aufhängen sollte und der Angriff nicht mehr manuell gestoppt werden kann.
iface
Hiermit kann das Interface ausgewählt werden, welches für den Angriff verwendet werden soll.
eval
Mit diesem Flag, kann ein String an Settings an Bettercap direkt beim Start mitgegeben werden, sodass diese nicht manuell, eins nach dem anderen, gesetzt werden müssen.
net.sniff on
Dieses Modul ist ein Netzwerk-Paket-Sniffer und Fuzzer, der sowohl die BPF-Syntax als auch reguläre Ausdrücke zum Filtern unterstützt. Es ist auch in der Lage, mehrere wichtige Protokolle zu zerlegen, um Anmeldeinformationen zu sammeln.
http.proxy on
Ein vollwertiger transparenter HTTP-Proxy, der mit Javascript-Modulen programmiert werden kann. Wenn er zusammen mit einem Spoofer verwendet wird, wird der gesamte HTTP-Verkehr dorthin umgeleitet und es werden bei Bedarf automatisch Portumleitungen vorgenommen.
arp.spoof on
Dieses Modul täuscht ausgewählte Hosts im Netzwerk mit gefälschten ARP-Paketen vor, um einen MITM-Angriff durchzuführen.
net.probe on
Wenn dieses Modul aktiviert ist, sendet es verschiedene Arten von Probe-Paketen an jede IP-Adresse im aktuellen Subnetz, damit das net.recon-Modul sie erkennen kann.
net.recon on
Dieses Modul ist für das regelmäßige Auslesen der ARP-Tabelle des Systems zuständig, um neue Hosts im Netz zu erkennen.
arp.spoof.fullduplex on
Wenn auf „true” gesetzt, werden sowohl die Ziele als auch das Gateway angegriffen, andernfalls nur das Ziel (wenn der Router jedoch über einen ARP-Spoofing-Schutz verfügt, schlägt der Angriff fehl).
net.sniff.output
Wenn diese Option gesetzt ist, schreibt der Sniffer die erfassten Pakete in diese pcap-Datei.
net.sniff.verbose
Wenn auf „true” gesetzt, wird jedes erfasste und analysierte Paket an den „events.stream” zur Anzeige gesendet, andernfalls nur die auf der Anwendungsschicht (sni, http usw.) analysierten Pakete.
http.proxy.sslstrip
Aktivieren oder deaktivieren Sie SSL-Stripping.
Um das SSL zu “strippen”, greift ein Angreifer in die Umleitung des HTTP- auf das sichere HTTPS-Protokoll ein und fängt eine Anfrage des Benutzers an den Server ab. … Bei einem SSL-Strip leitet der Angreifer seinerseits die Anfrage des Opfers an den Server des z.B. Online-Shops weiter und erhält die sichere HTTPS-Bezahlseite.
arp.spoof.internal
Wenn auf „true“ gesetzt, werden auch lokale Verbindungen zwischen Computern des selben Subnetz gefälscht, ansonsten nur Verbindungen, die über das eingetragene Gateway aus dem Subnetz geroutet werden (Im Falle des Fullduplex-Angriffes, werden auch die Pakete vom Gateway zu den Clients über den Angreifer geleitet).
Anbei ein Screen des, vom Bettercap generierten, PCAP Files in dem man die Basic-Auth wiederfindet.
Um den Angriff erkennen und auch verhindern zu können setzt man auf einen Service der in einem Großteil von Netzwerken vorhanden ist: der DHCP Server.
Der DHCP Server hat eine Übersicht über alle dynamisch vergebenen IP-Adressen (und deren MAC-Adressen) im Netzwerk. Im Zusammenhang der Defense and Detection von ARP-Spoofing Angriffen zeigt sich, warum auch statische IP-Adressen mithilfe des DHCP-Server gepflegt werden sollten.
Um nicht direkt auf die Daten des DHCP-Servers zugreifen zu müssen, bieten einige Switche eine Funktionalität an, die wir uns für die Verteidigung von ARP-Spoofing zunutze machen.
DHCP Snooping ist eine Funktionalität die dazu dient DHCP-Angriffe zu verhindern.
Beim DHCP Snooping werden an Switchen „Trusted Ports“ konfiguriert, von dem DHCP-Offers akzeptiert werden. An einem dieser „Trusted Ports“ ist der DHCP-Server angeschlossen, da dieser der einzige ist, der IP-Adressen dynamisch vergeben sollte. Auch Trunk-Ports müssen den „trusted“ Status im Kontext des DHCP-Snoopings haben, da hier valide DHCP-Offers übertragen werden. Stellt der Switch fest, das ein DHCP-Offer über einen anderen Port stattfindet, verwirft er das Paket.
Ein Nebeneffekt des DHCP Snoopings ist die DHCP Snooping Database in der alle IP-und MAC-Adressen vermerkt sind die durch den DHCP-Server am „Trusted Port“ vergeben wurden.
Anbei der Link zur Erläuterung / Konfiguration von Cisco: DHCP Snooping
configure terminal
ip dhcp snooping vlan
interface
ip dhcp snooping trust
exit
Die Dynamic ARP Inspection wird nun genutzt um Traffic von IP-/MAC-Adress Kombinationen zu verwerfen, die nicht in der DHCP Snooping Database stehen.
Sollte ein Angreifer nun einen ARP-Spoof Angriff durchführen, würde der Switch feststellen, dass an dem Port ARP-Pakete in das Subnetz gesendet werden, die nicht mit den Informationen aus der DHCP-Snooping-Tabelle übereinstimmen und diese Pakete dann verwerfen. Ist zudem ein Ratelimit für ARP-Pakete am jeweiligen Interface konfiguriert, würde das Interface bei Überschreitung des Limits deaktiviert werden.
configure terminal
ip arp inspection vlan
interface
ip arp inspection trust
exit
Im oben genannten Beispiel von DHCP Snooping im Zusammenspiel mit Dynamic ARP Inspection werden vorerst nur dynamisch vergebene DHCP-Leases bedacht. Es kommt natürlich immer wieder vor, dass Systeme mit statischen IP-Adressen konfiguriert werden. Hier besteht zum einen die Möglichkeit auch „feste“ IPs über IP-Reservierungen durch den DHCP-Server zu verteilen. Dies hat den Vorteil, dass auch diese „statisch“ über DHCP vergebenen IP-Adressen in der DHCP-Snooping-Tabelle auftauchen und die DAI somit auch hier funktioniert. Bei manuell vergebenen statischen IP-Adressen funktioniert die Dynamic ARP Inspection nicht. Es gibt aber fast immer die Möglichkeit ARP ACLs (Access Control Lists) am Switch zu konfigurieren, die auch für statische IPs Anwendung finden. Diese ARP-ACLs haben bei der Prüfung Vorrang gegenüber der Prüfung durch die DAI.
An dem gezeigten Beispiel wird die DHCP Snooping Database auf dem Switch gespeichert und genutzt, in großen Infrastrukturen stoßen Switche schnell an die Ressourcengrenze. Hierfür kann man beispielsweise bei Cisco die DHCP Snooping Database zentral auf einem FTP/TFTP Server ablegen und jedem Switch zur Verfügung stellen. Hierbei ist darauf zu achten, die Management-Ports der Switche und den FTP/TFTP Server in einem eigenen abgetrennten Netzbereich zu platzieren, damit nicht jeder Client Zugriff auf diese hat.
Da der Angriff nur auf Broadcast Traffic basiert, ist eine elegante Lösung die Client Isolation. Über private VLANs können so Clients voneinander getrennt werden und der Broadcasttraffic kann nicht einfach durch einen Angreifer im Netzwerk mitgelesen und manipuliert werden.
Bei der Host basierten Erkenneung macht man sich die Übersicht aller IP-Adressen des DHCP Servers zu Nutze. Die Übersicht der IP-Adressen kann man den Clients beispielsweise auf einer Freigabe zur Verfügung stellen.
Um einen ARP-Spoofing Angriff zu erkennen, müssen die Clients in regelmäßigen Abständen, automatisiert, ihre ARP-Tabelle anhand der DHCP Übersicht überprüfen um Unregelmäßigkeiten festzustellen. Sollten Unregelmäßigkeiten festgestellt werden, können diese in eine Datei ausgegeben werden und, beispielsweise mit Hilfe von OSSEC, überprüft werden.
Die Network IDS Lösung basiert ebenfalls auf einer Liste des DHCP Servers, die alle bekannten IP- und MAC-Adressen beinhaltet. Mithilfe von Tools wie Snort – einem IPS / IDS – können IDS-Regeln geschrieben, die bekannte MAC-Adressen mit den MAC-Adressen der eingehenden Verbindungen vergleichen und melden, wenn Unstimmigkeiten erkannt werden. IPS Regeln können nun, je nach Konfiguration, IP-Adressen blockieren oder weitere Schritte ausführen.
Einen ARP Spoof Angriff kann man auch über die Verteidigung mittels DHCP Snooping und Dynamic ARP Inspection erkennen. Hierzu können die Switche beispielsweise über SNMP an ein Monitoring angebunden werden und man sieht so einen vereitelten Angriff.
Switche sollten bei Erkennung von ARP-Spoofing über die Dynamic ARP Inspection den verantwortlichen Port abschalten. Jegliche Fehlermeldungen der Switche können über SNMP (Simple Network Management Protocol) überwacht werden.
Das verursachende Gerät sollte isoliert und auf Kompromittierung untersucht werden.
Bei der Befassung mit den folgenden ISMS-Framework-Controls spielt die Schwachstelle und deren Behebung eine Rolle:
ISO 27001:
A. 9.1.2 Zugang zu Netzwerken und Netzwerkdiensten
A.13.1.2 Sicherheit von Netzwerkdiensten
BSI Grundschutz:
NET.1.1.A7
@font-face
{font-family:“Cambria Math“;
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:3 0 0 0 1 0;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-469750017 -1073732485 9 0 511 0;}@font-face
{font-family:“Helvetica Neue“;
panose-1:2 0 5 3 0 0 0 2 0 4;
mso-font-charset:0;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:-452984065 1342208475 16 0 1 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:““;
margin:0cm;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:“Times New Roman“,serif;
mso-fareast-font-family:“Times New Roman“;}p.li1, li.li1, div.li1
{mso-style-name:li1;
mso-style-unhide:no;
margin:0cm;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:“Helvetica Neue“;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-bidi-font-family:Calibri;}.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:“Calibri“,sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:“Times New Roman“;
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}
Für die Schwachstelle gibt es einen Eintrag im MITRE ATT&CK Framework:
Attack.mitre.org
Die Schwachstelle ist unter der folgenden CVE beschrieben:
CVE-1999-0667
PSN-ID: PS-TN-2020-0001
