Netzwerksicherheit WS 2007/08

Falko Dressler,Tobias Limmer,Martin Gründl,Thomas Schneider
Netzwerksicherheit WS 2007/08
ARP-Spoofing
18.12.2007
In dieser Übung wird ein Angriff auf das ARP-Protokoll behandelt, mit dem Verbindungen mitgelesen und die übertragenen Daten verändert werden können. Diese Kategorie von
Angriffen wird häufig auch als Man-In-The-Middle-Angriff bezeichnet.
Übungsablauf
1. Gruppen mit jeweils mindestens 3 Teilnehmern bilden. Um alle Vorgänge beobachten
zu können, sollten alle Teilnehmer in einer Reihe sitzen und sich jeweils auf einem der
drei beteiligten Rechner einloggen.
2. Jeweils über die faui7t1 auf einem der drei beteiligten Rechner einloggen:
• ssh -Y <Login>@faui7t1
– ssh -Y root@pc<Gruppe>-1
– ssh -Y root@pc<Gruppe>-2
– ssh -Y root@router<Gruppe>-1
3. Mit dem Kommando arp kann die aktuelle ARP-Tabelle eines Rechners ausgegeben
werden.
4. Auf den Rechnern das Programm Wireshark starten und Sniffing auf dem Interface
eth1 starten.
wireshark &
5. Nun die Rechner untereinander pingen, die jeweiligen Pakete(ARP und ICMP) in Wireshark beobachten und den Betreuer rufen.
ping 192.168.10<gruppe>.(1|2|254)
6. Einen HTTP-Request auf den Webserver eines anderen Rechners starten und im Sniffer
beobachten.
wget http://192.168.10<gruppe>.(1|2|254)
1
7. Mit dem Werkzeug arpspoof einen Angriff auf pc1 starten und die Kommunikation zu
pc2 auf router1 umleiten.
arpspoof -i eth1 -t <IP von PC1> <IP von PC2>
Was passiert nun, wenn man ein Ping oder einen HTTP-Request von pc1 auf pc2 startet? Warum sieht pc2 die Pakete nicht? Was kommt bei router1 an? Warum bekommt
der Client auf pc1 keine Antwort? Die Ergebnisse diskutieren und den Betreuer rufen.
8. router1 als IP-Router konfigurieren, Pakete auf Port 80 annehmen und an den lokalen
Webserver(ebenfalls Port 80) weiterleiten.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 80
Die Umleitung muss nach dem Experiment wieder mit iptables -t nat -F entfernt
werden, um später ungewollte Seiteneffekte zu vermeiden!
9. Den manuell ausgeführten Angriff nun automatisiert mit Hilfe von Ettercap ausführen.
Dazu muss Ettercap auf dem Router der Gruppe gestartet werden.
Die Menüs von Ettercap können jeweils durch Eingabe von <Shift>+<Anfangsbuchstabe
des Menütitels> aufgerufen werden. In den Menüs selbst kann mit den Pfeiltasten navigiert werden.
ettercap -C
• Sniff → Unified Sniffing..., Interface eth1 auswählen
• Hosts → Scan for hosts
• Targets → Select TARGET(s)
– /192.168.10<gruppe>.1/
– /192.168.10<gruppe>.2/
• Start → Start Sniffing
• Mitm → Arp Poisoning
– keine Parameter angeben
• View → Connections
10. Nun einen HTTP-Request mit beliebigem Username und Passwort von pc<gruppe>-1
auf pc<gruppe>-2 starten.
In Ettercap wird die Verbindung angezeigt und in dem Fenster User Messages werden
der Benutzername und das Passwort angezeigt.
wget http://<Benutzername>:<Passwort>@192.168.10<gruppe>.2
11. Ettercap beenden.
• Start → Exit
Leider funktioniert das automatische “Aufräumen” der Forwarding-Tabelle nicht. Daher bitte nach dem Beenden von Ettercap das Kommando iptables -t nat -F ausführen,
um die entsprechenden Einträge zu entfernen.
2
Hausaufgabe
Implementieren Sie einen HTTPS-Proxy, mit dem gezeigt werden kann, dass Man-In-TheMiddle Attacken (z.B. via ARP-Spoofing) auch auf HTTPS (z.B. Online-Banking) möglich
sind, wenn Zertifikate nicht sauber geprüft werden (z.B. wenn einem self-signed Root-Zertifikat
leichtsinnig vertraut wird).
Der HTTPS-Proxy soll auf dem in der vergangenen Übung erweiterten wserver und wclient
basieren, ebenfalls hierarchische Zertifikate unterstützen und mit folgenden Argumenten aufgerufen werden:
wproxy -p clientPort -i serverIP -c attackcert.pem
Der HTTPS-Proxy führt client-seitig ein “SSL-listen” auf dem “clientPort” (im Bsp. 4444)
aus und verwendet als gefälschtes Serverzertifikat das Zertifikat aus “attackcert.pem”. Für jede “accept”-ierte SSL Verbindung vom HTTPS-Client (wclient) wird eine neue SSL-Verbindung
zum HTTPS-Server (wserver) unter der IP “serverIP” aufgebaut. GET-Request des Clients
und darauffolgende HTTP-Response des Servers werden transparent weitergeleitet, auf dem
Proxy auf “stdout” ausgegeben und beide SSL-Verbindungen ordnungsgemäß beendet.
Client
Server
wclient -h proxyIP -p 4444 -v
wserver
SSL
Proxy (Attacker)
IP: serverIP
Port: 4433
SSL
IP: proxyIP
Port: 4444
wproxy -p 4444 -i serverIP -c attackcert.pem
Technische Hinweise:
• Die Aufgaben sind in C/C++ mit OpenSSL oder Java (no support !) zu erstellen.
• Der Code muss auf dem Betriebssystem Debian/Linux im CIP-Pool der Informatik mit
der dort installierten Version des GNU C/C++- oder Java-Compilers kompilieren und
lauffähig sein.
• Es ist ein Makefile oder ein ausführbares Skript zu bereitzustellen, welches temporäre
Daten löschen (Target clean“) und eine Binärdatei (Target all“) erstellen kann.
”
”
• Es ist eine Dokumentation im ASCII-Format zu erstellen, welche einen typischen Programmstart dokumentiert und über Besonderheiten des Programms berichtet.
Fragen und Abgabe der Lösungen bis Montag, den 7.1.2008 als Archiv im Format
.tar.(gz|bz2) oder .zip per Mail an [email protected]
und [email protected].
Frohe Weihnachten und einen guten Rutsch ins neue Jahr !
3