Sniffing mit Ettercap

Bei Ettercap handelt es um ein recht mächtiges Werkzeug, mit welchem ein Angreifer in der Lage ist eine Man-in-the-Middle-Attack (MITM) durchzuführen. Hierfür muss natürlich der Datenstrom erst mal zum Angreifer umgeleitet werden. Dazu sind andere Tools vorhanden, die diese Aufgabe durchführen können. Auf diese Weise können auch Verbindungen in einem geswitchten LAN angegriffen werden.

Meist interessiert sich der Angreifer für Passwörter. Schließlich möchte er Zugang zu persönlichen geschützten Bereichen erlangen, die ihm so erst mal verwehrt sind. Einfaches Mitschneiden der Datenverbindung ist auch eine durchaus lohnenswerte Angelegenheit, jedoch werden Kennwörter sehr häufig mithilfe SSL verschlüsselt übertragen. Und genau an dieser Stelle kommt der Angreifer mit beispielsweise Wireshark vorerst nicht so weit. Es muss also eine Möglichkeit geschaffen werden, sich genau dazwischen zu setzen, so dass die SSL Verbindung beispielsweise durch den Computer des Angreifers durch geschleift wird. An dieser Stelle wiederum, lässt sich das Kennwort einfach auslesen und der Zugriff auf die Daten wird im späteren Fall möglich. Dazu kann einfach der verschlüsselte Datenstrom mitgelesen werden, sollte sich der Angreifer nur die übertragenen Daten interessieren. Mit Ettercap kommt der Angreifer seinem gewünschten Ziel soweit recht nahe.

Wir gehen davon aus, dass der Angreifer sich Zugriff auf das Netzwerk des Opfers verschafft hat. Gerade in der heutigen Zeit, wo viele Benutzer WLAN nutzen, lässt sich oft ein Einfallstor finden, bzw. mit etwas Aufwand aufhebeln. Einige Nutzer schützen ihr WLAN gar überhaupt nicht mit einer Verschlüsselung (WEP, WPA oder WPA2) oder verwenden nur einen MAC-Filter, der sich auch recht leicht austricksen lässt. Der Angreifer muss also das Opfer dazu bewegen seine Verbindungen nicht zum Zielsystem aufzubauen, sondern zum Angreifer. Wurde die Verbindung zum Angreifer aufgebaut, wird sie entsprechend weitergeleitet zum eigentlichen Zielsystem. Und schon hängt der Angreifer dazwischen und kann Daten entsprechend ausspähen.

Eine Methode, um Verbindungen zu einem anderen Ziel-Host zu leiten kann das DNS-Spoofing sein. Wer zuerst antwortet, wird erhört, so ungefähr. Der Angreifer fälscht DNS Antworten (Spoofing) und sendet entsprechend eine Antwort, die auf seine dortige IP-Adresse verweist. Das Opfer baut nun eine Verbindung zum Angreifer auf. Antworten lokale DNS Server im LAN zu schnell, können diese mit einer DOS Attack entsprechend ausgebremst werden.

Eine weitere Möglichkeit ist das ARP Spoofing. Hier genauer ARP Cache Poisoning. Im LAN und auch genauso natürlich im WLAN werden Computer nicht direkt über IP adressiert, sondern über die MAC Adressen. Jeder Host, also angeschlossener Netzwerkcomputer jeder Art, besitzt einen kleinen Puffer, in dem er die Verknüpfung zwischen IP Adresse und MAC Adresse abspeichert. Ist die MAC Adresse bereits im Puffer so braucht das System keinen ARP Request zu senden und kann gleich loslegen. Existiert die MAC Adresse noch nicht, so fragt das System mit einem Broadcast nach. Dieser Broadcast wird von allen Maschinen empfangen und die Maschine, die gemeint ist, antwortet entsprechend. Das erste einlaufende Antwortpacket wird wieder genommen und entsprechend wird die Tabelle im Hostsystem erweitert. Dieser ARP Cache wird oft auch dann aktualisiert, wenn kein Request vorher abgesendet worden ist. Die Implementierungen variieren an dieser Stelle.

So sendet der Angreifer einfach gefälschte ARP Antworten des Zielsystems und schon wird entsprechend nach einiger Zeit der Cache des Opfersystems mit der Angreifer MAC Adresse vergiftet. Baut das System nun eine Verbindung zum Zielsystem auf, so werden die Pakete zur MAC Adresse des Angreifers gesendet. Wie bereits erwähnt wird in LANs mit MAC adressiert und nicht über IP. Somit empfängt der Angreifer die Daten. Der Angreifer wird somit zu einer Art Proxy Server. Diese kann er wiederum einfach nur mit Wireshark aufzeichnen und entsprechend einfach an den ursprünglichen Host weiterleiten oder er kann mit Ettercap entsprechend eine MITM Attack fahren.

Natürlich möchte der Angreifer möglichst etwas verschlüsseltes lesen, sonst könnte auch Wireshark einfach eingesetzt werden. Dazu erzeugt der Angreifer sich ein neues SSL Zertifikat. Das sollte natürlich möglichst so aussehen, wie das Zertifikat des zu fälschenden Zielsystems. Ettercap wird dieses nun verwenden, um die SSL Verbindung entsprechend entgegen zu nehmen. Damit wird sozusagen der SSL Datenstrom aufgebrochen und die entschlüsselten Daten werden ausgelesen. Also tippt der Angreifer in seiner Linux Konsole (Backtrack oder GRML sind als Live CD sehr empfehlenswert) folgendes ein: ettercap –newcert.

Beim Start von ettercap wird zunächst automatisch das Netzwerk nach vorhandenen Host abgesucht. Wenn dieser Vorgang abgeschlossen ist, zeigt Ettercap eine zweispaltige Tabelle jeweils mit allen gefunden Hostcomputern an. Der Angreifer wählt nun in der linken Spalte den anzugreifenden Client aus und in der rechten Spalte den entsprechenden anzugreifenden Server. Nun wählt der Angreifer die Schaltfläche ARP Sniff. Damit wird das ARP Poisoning eingeleitet und alle verschlüsselten Verbindungen lassen sich nun mitschneiden.

Das Opfer testet nun mithilfe der Shell mit arp -a (Windows Shell), ob das ARP Poisoning geklappt hat. Taucht die Angreifer MAC Adresse in Verbindung mit der Ziel IP des Fremdsystems auf, so hat das ARP Cache Poisoning geklappt. Nun entsprechend den Server mit einer SSL Verbindung ansprechend und sich dort einloggen. Da oft der Angreifer keine erweiterten Möglichkeiten hat, wird der Webbrowser sich beklagen, dass das Zertifikat nicht verifiziert werden kann, bzw. dem Zertifikat nicht vertraut wird. So kann das Opfer diesen Angriff alleine an dem nicht ganz korrekten Zertifikat erkennen. (Es sei denn der Angreifer lässt das Zertifikat von einem Trustcenter entsprechend korrekt signieren oder manipuliert die Root Zertifikate im Opferwebbrowser und signiert selbst)

Was kann das Opfer tun, um diese Manipulation zu erkennen? Erstens kann das Opfer prüfen, ob die URL mit der URL im Zertifikat übereinstimmt. Zweitens kann das Opfer überprüfen, ob die Chain of Trust verletzt wurde oder nicht. Also, ob das Zertifikat von einer autorisierten Stelle zertifiziert wurde. Der erste Punkt wird vom Angreifer korrekt erfüllt, da der Client davon ausgeht, dass er direkt mit dem Server kommuniziert. Die IP Adressen werden bei diesem Angriff nicht verändert. Der zweite Punkt allerdings ist schon weitaus schwerer. Aus diesem Grund sollte jeder Nutzer Warnungen dieser Art von seinem Browser sehr ernst nehmen.