Kapitel 17:
Lauschangriffe & Man-in-the-Middle

Auch wenn Wireshark der Platzhirsch unter den Netzwerk-Sniffern ist, so gibt es gute Gründe, auch andere, spezialisierte Tools zusätzlich oder alternativ zu verwenden. In diesem Kapitel werden wir unsere Toolsammlung um weitere wichtige Programme ergänzen, die im Rahmen der Informationsgewinnung und -auswertung, aber auch der Manipulation von Daten sehr effektiv sind.

In diesem Zusammenhang geht es auch um eine häufig eingesetzte Angriffstechnik im Netzwerk: Man-in-the-Middle. Dabei platziert sich der Angreifer Mallory so, dass er die Kommunikation zwischen Alice und Bob abfangen, abhören und ggf. manipulieren kann. Wir schauen uns in diesem Kapitel verschiedene Möglichkeiten an, wie Mallory in diese Position gelangen kann – natürlich inklusive entsprechender Praxisszenarien zum Mitmachen.

Darüber hinaus werden wir noch einige andere Programme vorstellen, die als Vorbereitung für einen Angriff bzw. für den Angriff selbst verwendet werden können. Hier sind die Themen:

Während Wireshark so eine Art »Eier legende Wollmilchsau« ist und viele Funktionen in sich vereint, werden Sie in diesem Kapitel mit der Dsniff-Suite auch Sniffer-Tools kennenlernen, die teilweise hoch spezialisiert sind und nur eine ganz bestimmte Funktion erfüllen. Dieser Ansatz entspricht der Unix/Linux-Philosophie, wonach die Kombination einzelner, spezialisierter Tools in geeigneter Art und Weise extrem leistungsfähige Lösungen hervorbringt. Zudem sind diese Programme größtenteils kommandozeilenbasiert und können sehr gut mittels Scripting (beispielsweise mit Shell-Skripts oder Python) für den jeweiligen Zweck optimiert eingesetzt werden.

17.1   Eavesdropping und Sniffing für Hacker

Haben wir Ihnen im vorhergehenden Kapitel Network Sniffing mit Wireshark & Co. eher allgemein und in Bezug auf die Features, Fähigkeiten und Bedienung der Tools vorgestellt, wollen wir den Fokus hier ganz klar auf die Angriffsszenarien im Rahmen eines Hacking-Angriffs legen. Klären wir zunächst einmal die Angriffsvektoren und Terminologie.

17.1.1   Eavesdropping und Wiretapping

Grundsätzlich gehen wir davon aus, dass das Abhören von Netzwerk-Traffic mithilfe von Sniffern geschieht. Einige der bekanntesten Sniffer haben Sie bereits kennengelernt. Natürlich gibt es auch Hardware-Sniffer bzw. Appliances, die auf professioneller Ebene eine riesige Bandbreite an Kommunikation mitschneiden und in Echtzeit auswerten können. In den meisten Hacking-Szenarien gehen Angreifer allerdings gezielter vor und versuchen, eine bestimmte Kommunikation oder zumindest klar definierte Kommunikationsformen mitzuschneiden, um relevante Informationen abzugreifen.

In jedem Fall handelt es sich um das Abhören von Kommunikation ohne Einverständnis der beteiligten Kommunikationspartner. Optimal hierfür wäre für den Angreifer, wenn er sich – wie im vorhergehenden Kapitel angenommen – direkt auf einem der kommunizierenden Systeme befindet und dort den Sniffer starten kann. Das allerdings ist in der Praxis die Ausnahme. Meistens ist er irgendwo als unauffälliger, zusätzlicher Teilnehmer im Netzwerk angebunden und muss zunächst die Voraussetzungen dafür schaffen, um mitzuhören.

Während »Eavesdropping« ein allgemeiner Begriff für das Abhören von Gesprächen ist und auch den Lauscher hinter einer verschlossenen Tür umfasst, bezeichnen wir als »Wiretapping« das konkrete Abhören von Telekommunikationsverbindungen, also Telefon und Internet-Traffic. Dabei unterscheiden wir zwischen

Neben klassischen Hackern gibt es auch andere Interessengruppen, die in diesem Sinne aktiv werden. Insbesondere staatliche Behörden wie Geheimdienste, Staatsschutz oder auch polizeiliche Institutionen zapfen die Leitungen häufiger an, als manch einer vermuten würde. Internet- und Telefon-Provider (heutzutage meistens identisch) müssen regelmäßig Anschlussmöglichkeiten schaffen, um ein »Kabel mit drei Enden« für die Behörden bereitzustellen. Diese Variante wird im englischsprachigen Bereich als »Lawful interception« bezeichnet.

17.1.2   Sniffing als Angriffsvektor

Das Sniffing ist der konkret implementierte Prozess des Eavesdropping bzw. Wiretapping im Netzwerk. Er ermöglicht das Mitschneiden von sämtlichem Netzwerkverkehr, der über einen bestimmten Punkt im Netzwerk geht. Dies kann entweder ein Endgerät, ein Router, Switch oder eine andere Komponente im Netzwerk sein.

Beim Sniffing unterscheiden wir ebenfalls in zwei Varianten:

Bitte beachten Sie, dass die Begriffe Aktiv und Passiv in unterschiedlicher Bedeutung genutzt werden; je nachdem, ob sie im Kontext von Wiretapping oder Sniffing verwendet werden.

Ist ein Angreifer in der Lage, den Netzwerk-Verkehr abzuhören, kann er theoretisch alle Frames mitschneiden, die über die Verbindung geleitet werden, die er angezapft hat. Dadurch kann er diverse Informationen erhalten, die ihm im nächsten Schritt, nämlich bei der Vorbereitung eines zielgerichteten Angriffs, hilfreich sind. Hierzu gehören insbesondere:

Es gibt eine Reihe von Protokollen, die besonders interessant beim Sniffing sind, weil sie zumindest teilweise in Klartext kommunizieren. Hier eine Auswahl:

Während die Protokolle NNTP und Rlogin als Legacy-Protokolle heutzutage nur noch eine untergeordnete Rolle spielen, existieren für die meisten anderen Protokolle mittlerweile kryptografisch gesicherte und verschlüsselte Varianten, die zunehmend zum Einsatz kommen. Auch wenn es für den Angreifer in modernen IT-Umgebungen immer schwieriger wird, an Informationen zu gelangen, so lohnt sich der Einsatz von Sniffern trotz allem noch immer, da auch alte, ungeschützte Protokolle leider noch zu oft eingesetzt werden und zudem Netzwerk-Informationen wie IP-Adressen, Portnummern und andere Daten in den Protokoll-Headern wertvolle Informationen über die Netzwerk-Infrastruktur und eingesetzten Systeme liefern können.

17.2   Man-in-the-Middle (MITM)

Kennen Sie den römischen Gott Janus? Er ist der Gott des Ursprungs, des Anfangs und des Endes. Nach ihm wurde auch der Monat Januar benannt. Jetzt ergibt das irgendwie Sinn, oder? Sehen Sie? Wieder etwas für das Leben gelernt. Aber was hat das mit Man-in-the-Middle zu tun?

Nun, das Entscheidende ist: Janus hat zwei Gesichter, wie in Abbildung 17.1 zu sehen.

[Bild]

Abb. 17.1: Janus-Statue im Vatican Museum (Quelle: Wikipedia, Public Domain)

Diese zwei Gesichter versinnbildlichen das Prinzip eines Man-in-the-Middle-Angriffs, kurz: MITM. Denn bei dieser Angriffsform hat der Angreifer auch zwei Gesichter. Eines zeigt er dem Sender und das andere dem Empfänger der Kommunikation. Daher wird dieser Angriff häufig auch als »Janus-Angriff« bezeichnet.

Erinnern Sie sich an unsere Protagonisten Alice, Bob und Mallory aus dem Kryptografie-Kapitel. Mallory war regelmäßig der Man-in-the-Middle, der versucht hat, die Kommunikation zwischen Alice und Bob abzuhören und ggf. zu manipulieren. Nun wird es Zeit, einmal genauer zu betrachten, welche Möglichkeiten Mallory hat, um sich in die Kommunikation von Alice und Bob einzuklinken und den Netzwerkverkehr abzufangen.

Auch für den Einsatz von Sniffern ist es unter Umständen notwendig, einen Weg zum Mitsniffen zu finden, wenn das Programm weder auf dem Client noch auf dem Server platziert werden kann. Dies kann entweder durch einen Abhörkanal oder auch durch eine MITM-Attacke realisiert werden.

17.2.1   Was bedeutet Man-in-the-Middle?

Bei einer MITM-Attacke platziert sich der Angreifer Mallory so, dass er die relevante Kommunikation zwischen Alice und Bob über ein von ihm kontrolliertes System leitet und somit den gesamten Traffic mitlesen und ggf. sogar manipulieren kann. Dies geschieht für Alice und Bob komplett transparent. Das bedeutet, dass Alice glaubt, mit Bob direkt zu kommunizieren, und umgekehrt. Tatsächlich aber gibt sich Mallory gegenüber Alice als Bob aus und gegenüber Bob tut er so, als wäre er Alice. Abbildung 17.2 zeigt das Prinzip.

In einigen Fällen ist das ein relativ einfacher Prozess für Mallory. Je schlichter die Kommunikation bzw. das Kommunikationsprotokoll aufgebaut ist, desto einfacher wird es ihm gelingen, sich einzuklinken. In anderen Fällen muss Mallory sich einiges einfallen lassen, um in eine geeignete Position zu gelangen. Dies hängt von einer ganzen Reihe von Faktoren ab. Ist die Kommunikation z.B. kryptografisch gesichert, wird es schwer für Mallory, oftmals aber nicht unmöglich. Auch andere Sicherheitsmechanismen wie starke Authentifizierung, der Einsatz von VLANs oder virtuelle Routing-Instanzen, physische Absicherung der Kommunikation und vieles mehr können den Zugang für Mallory zusätzlich erschweren.

[Bild]

Abb. 17.2: Ein Man-in-the-Middle-Angriff

Weiterhin hängt es davon ab, welche Voraussetzungen Mallory selbst mitbringt: Über welche Mittel verfügt er? Welches Wissen über die Kommunikation hat er? Welchen Zugang zu den beteiligten Komponenten (oder ggf. Personen, siehe Social Engineering) hat er? Diese und andere Faktoren bestimmen letztlich, wie erfolgversprechend ein MITM-Angriff ist.

17.2.2   Was erreichen wir durch einen MITM-Angriff?

Ein Man-in-the-Middle-Angriff ermöglicht grundsätzlich zwei Dinge:

  1. Mallory kann die Kommunikation zwischen Alice und Bob abhören. Dies bezeichnen wir auch als »Eavesdropping« bzw. Wiretapping, wie Sie gelernt haben.

  2. Mallory kann die Kommunikation zwischen Alice und Bob darüber hinaus manipulieren. Dies führt dazu, dass andere Daten empfangen werden, als der Kommunikationspartner gesendet hat. Auf diesem Weg kann Mallory diverse Angriffe starten.

Hinweis: MITM ist in erster Linie Mittel zum Zweck

In diesem Kapitel geht es primär um die Möglichkeit, Informationen abzufangen und mitzuschneiden – nicht aber um deren anschließende Manipulation. Derartige Angriffe werden wir in späteren Kapiteln im Rahmen verschiedener Szenarien noch vorstellen. Auch wenn ein MITM-Angriff grundsätzlich auch schon als konkreter Angriff betrachtet werden kann, ist er in der Regel nur Mittel zum Zweck. Die Positionierung als Man-in-the-Middle ist meist nur eine Voraussetzung für den eigentlichen Angriff.

17.3   Active Sniffing

Während ein MITM-Angriff mit Manipulation der Datenpakete darauf beruht, dass sich Mallory direkt im Kommunikationskanal befindet und die Kommunikation zwischen Alice und Bob stellvertretend entgegennimmt und weiterleitet, muss für einen Sniffing-Angriff nur sichergestellt sein, dass Mallory die übertragenen Datenpakete bzw. Frames irgendwie abgreifen kann. Dies ist im Zweifel einfacher zu erreichen. In diesem Abschnitt werfen wir einen Blick auf Möglichkeiten, den Traffic-Fluss so zu manipulieren, dass die Voraussetzungen für Sniffing- oder MITM-Angriffe gegeben sind. Dabei geht es in erster Linie darum, dass ein zusätzlicher Datenfluss zum Angreifer erstellt wird, nicht aber der echte Datenverkehr komplett umgeleitet werden muss.

17.3.1   Mirror-Ports: Ein Kabel mit drei Enden

Eine entscheidende Frage ist, wie der Angreifer in eine Position gelangt, um die übertragenen Datenpakete mitschneiden zu können. Hierzu stellen professionelle Switches und Router einen sogenannten Mirror-Port bereit, an dem die Datenpakete gespiegelt, also zusätzlich übermittelt werden. Das wird oft auch als Monitoring-Port bezeichnet. Dort kann der Angreifer einen Laptop oder ein anderes Gerät anschließen und z.B. über Wireshark alle Datenpakete mitschneiden, die über andere Ports gelaufen sind.

Aber warum stellen Netzwerkgeräte eine derartige Funktionalität bereit? Der Hintergrund hierzu ist oftmals ein ganz reguläres Troubleshooting oder Monitoring durch den Administrator. Diese Technologie kann jedoch auch durch einen Hacker genutzt und missbraucht werden. Auf der Website zum Buch unter www.hacking-akademie.de/buch/member haben wir ein kleines Tutorial zur Konfiguration eines Mirror-Ports auf Cisco-Switches bereitgestellt und gehen daher aus Platzgründen an dieser Stelle nicht näher darauf ein.

17.3.2   Aus Switch mach Hub – MAC-Flooding

Wie einfach die Welt für Mallory doch war, als es noch Hubs anstelle von Switches gab. Da machte das Mitsniffen noch Spaß: einfach anstecken, Sniffer einschalten und alles mitlesen, was über den Hub übertragen wurde ... Dass dies möglich war, liegt daran, dass ein Hub die eingehenden Signale über alle anderen Ports weiterleitet. Somit erhalten alle angeschlossenen Geräte eine Kopie des gesendeten Frames (siehe Abbildung 17.3).

[Bild]

Abb. 17.3: Der Hub »schießt aus allen Rohren« ...

Ein Switch entscheidet dagegen aufgrund der Ziel-MAC-Adresse über die Weiterleitung und leitet den eingehenden Frame, wenn möglich, nur an dem Port weiter, an dem die Ziel-MAC-Adresse registriert ist. Damit geht Mallory aber leer aus, wenn er an einem anderen Port hängt als das Ziel, also Alice bzw. Bob. Abbildung 17.4 verdeutlicht dies.

[Bild]

Abb. 17.4: Frames von Alice an Bob werden nur an dessen Port weitergeleitet.

Damit Mallory nun trotzdem die Kommunikation mithören kann, hat er verschiedene Möglichkeiten. Eine Chance besteht darin, den Fallback-Modus auszunutzen, den viele Switches einsetzen. Demnach fällt ein Switch in den Hub-Modus zurück, wenn seine MAC-Adresstabelle an ihre Grenzen stößt. In der MAC-Adresstabelle speichert der Switch die Zuordnung von gesammelten Absender-MAC-Adressen zu den Ports, an denen sie entdeckt wurden. Dabei gibt es eine maximale Anzahl von Einträgen, sprich: MAC-Adressen, die der Switch in seiner Zuordnungstabelle speichern kann. Die konkrete Anzahl hängt vom Switch-Typ ab. Der Befehl auf einem Cisco Catalyst-Switch für die Anzeige der aktuellen Adresstabelle lautet show mac address-table. Die Ausgabe zeigt Abbildung 17.5.

Sendet Mallory nun endlos Pakete mit verschiedenen, gefälschten Absender-MAC-Adressen, flutet er damit die MAC-Adresstabelle des Switches. Dieser Angriff wird daher auch »MAC-Flooding« genannt. Im Ergebnis kann der Switch keine zusätzlichen MAC-Adressen mehr speichern. Er wechselt damit in den sogenannten Failopen Mode und leitet darauf alle Frames über alle Ports weiter, außer an dem, von dem er den Frame empfangen hat. Mit anderen Worten arbeitet er wieder wie ein Hub aus alten Tagen, sodass Mallory an einem beliebigen Port die Kommunikation abhören kann.

In der Dsniff-Suite, die Sie in Abschnitt 17.5 kennenlernen werden, findet sich mit macof ein Tool, das einen solchen Angriff ermöglicht. Natürlich schauen wir uns das dann auch noch in der Praxis an. Am Ende dieses Kapitels lernen Sie zudem, wie Sie sich relativ einfach und effektiv gegen derartige Angriffe schützen können.

[Bild]

Abb. 17.5: Die MAC-Adresstabelle eines Cisco Catalyst-Switches

17.3.3   Auf dem Silbertablett: WLAN-Sniffing

Noch einfacher wird die Sache, wenn die Kommunikation nicht über kabelgebundene Medien stattfindet, sondern via Funkwellen übertragen wird. Es liegt in der Natur der Sache, dass z.B. bei Wireless-LAN-Netzwerken (WLAN) ein Lauscher sich ganz bequem ein »lauschiges Plätzchen« (welch Wortwitz) in der Nähe des Access Points suchen und fast beliebig Pakete mitschneiden kann. Manchmal reicht sogar der Parkplatz vor dem Haus aus, um die Kommunikation abhören zu können. Abbildung 17.6 verdeutlicht das Szenario.

[Bild]

Abb. 17.6: WLAN-Sniffing ist im Empfangsradius des Access Points möglich.

Daher ist WLAN auch ganz besonders gefährdet und ein bevorzugtes Angriffsziel. Erschwerend kam in der Vergangenheit hinzu, dass die angebotenen Verschlüsselungstechnologien (allen voran WEP) teilweise eklatante Schwächen aufwiesen. Mittlerweile sind die Algorithmen ausgereifter. WLAN-Angriffe sind jedoch so relevant, dass wir diesem Thema in Kapitel 28 WLAN-Hacking einen eigenen Platz in diesem Buch gewidmet haben. Daher gehen wir an dieser Stelle zunächst nicht näher darauf ein.

17.3.4   Weitere physische Abhörmöglichkeiten

Hat Mallory keinen Zugriff auf aktive Netzwerk-Komponenten, so kann er alternativ auch das Übertragungsmedium – sprich Kabel – direkt anzapfen. Im Gegensatz zur landläufigen Meinung ist dies übrigens nicht nur mit einem elektrischen Medium, sondern auch bei Glasfaser problemlos möglich. In beiden Fällen wird das Kabel aufgetrennt und eine Abhörstation dazwischengehängt. Die Technologie zur konkreten Umsetzung variiert zwischen den Medien.

Dies spielt auch auf internationaler Ebene eine große Rolle, da ein erheblicher Teil der Internet-Kommunikation über Datenkabel läuft, die durch das Meer verlaufen. Hier ist es nur sehr bedingt möglich, sicherzustellen, dass nicht irgendwann einmal ein U-Boot vorbeikommt und eine Abhörstation installiert.

Das physische Einklinken in eine Verbindung ist übrigens nicht erst im Internet-Zeitalter entstanden, sondern wurde auch früher bereits ausgiebig für das Anzapfen von Telefonleitungen genutzt. Da weder Alice noch Bob in der Regel die Kontrolle über die gesamte Kommunikationsstrecke haben, können sie also grundsätzlich auch nie sicher sein, dass Mallory nicht irgendwo lauscht.

17.4   Die Kommunikation für MITM umleiten

Nun kommen wir zu einem klassischen Weg, einen MITM-Angriff einzuleiten. Damit Mallory sich in die Kommunikation von Alice und Bob einklinken kann, muss er bei einem MITM-Angriff dafür sorgen, dass die Kommunikation über ein System geleitet wird, das er unter seiner Kontrolle hat. Je nach Ausgangslage hat er dazu diverse Möglichkeiten. Gehen wir einige wichtige durch.

17.4.1   Physische Umleitung

Hat der Angreifer physischen Zugriff auf ein Übertragungskabel, so kann er das Kabel so »umpatchen« (also umstecken), dass die Kommunikation über einen Kanal bzw. ein System läuft, das er kontrolliert. Dies funktioniert in erster Linie in lokalen Netzwerken und bedingt, dass die Kommunikation kabelgebunden ist. Im einfachsten Fall wird das Opfer-System direkt mit dem Computer des Angreifers verbunden. Dieser wiederum hat einen zweiten Anschluss an einen Switch, ggf. hängt er zwischen dem Opfer-Endgerät und dem Switch, an dem normalerweise das Opfer angeschlossen gewesen wäre, wie Abbildung 17.7 zeigt.

Das ist insbesondere in Unternehmensnetzwerken möglich, wenn die Gebäudeverkabelung über Patch-Schränke verläuft und Mallory Zugang zu den Serverräumen hat. Dort befinden sich normalerweise nur im Bedarfsfall Mitarbeiter, sodass Mallory hier unauffällig Patchverbindungen ändern kann.

[Bild]

Abb. 17.7: Umleitung durch einen physischen Eingriff in die Verkabelung

17.4.2   Umleitung über aktive Netzwerk-Komponenten

Hat Mallory die Kontrolle über einen Router oder einen Switch auf dem Übertragungsweg, kann er die Kommunikation durch entsprechende Konfiguration auf den Geräten problemlos umleiten. Auf einem Switch könnte Mallory z.B. den Port, an dem der Computer von Alice hängt, in ein separates VLAN legen. In dasselbe VLAN platziert Mallory einen Router, der an einem anderen Port des Switches hängt. Dieser dient nun als Standard-Gateway statt des echten Systems. Damit sendet Alice alle Pakete, die zu Kommunikationspartnern außerhalb ihres eigenen Subnetzes gehen, über den Router von Mallory. Abbildung 17.8 zeigt das beschriebene Szenario.

[Bild]

Abb. 17.8: Umleitung über VLANs

Wenn Mallory Kontrolle über das Standard-Gateway hat, stehen ihm grundsätzlich alle Wege offen. Über eine Manipulation der Routing-Tabelle kann er den Traffic nach Belieben umleiten, sodass der Next Hop z.B. ein Router ist, auf dem er den kompletten Traffic mitschneiden kann. Noch einfacher ist es, wenn er auf dem gefakten Standard-Gateway von Alice direkt eine Abhörsoftware installieren kann.

Hinweis: Isolation des Clients und die Rückroute

Einer der Nachteile ist, dass Alice nicht mehr mit anderen Systemen im selben Subnetz interagieren kann. Da viele Clients allerdings nur mit Systemen in externen Netzwerken (z.B. dem Internet), nicht aber mit anderen Systemen im selben Subnetz kommunizieren, fällt dies unter Umständen zunächst gar nicht auf.

Gravierender allerdings ist, dass Mallory dafür sorgen muss, dass auch der Rückweg über ihn geht, da Alice ja in einem anderen VLAN ist als das echte Default-Gateway. Mallory müsste also das echte Gateway komplett aussperren und durch sein eigenes Gateway ersetzen. Dies ist ziemlich auffällig und weckt schnell die Aufmerksamkeit der Administratoren und Monitoring-Systeme. Daher ist dieser Weg oftmals nicht der beste. Besser wäre es da schon, das echte Gateway direkt unter seine Kontrolle zu bringen und dort die Daten abzufangen.

Doch es geht auch mit weniger Aufwand und Risiko. Schauen wir uns einen etwas eleganteren und unauffälligeren Weg an.

17.4.3   Umleiten mit ARP-Spoofing

Sie erinnern sich: Im lokalen Netzsegment kommunizieren die Knoten untereinander über ihre MAC-Adresse. Dazu wird ARP, das Address Resolution Protocol, verwendet. Über einen ARP-Request wird eine Auflösung einer IP-Adresse in eine MAC-Adresse angefragt. Im ARP-Reply liefert das Zielsystem seine zugehörige MAC-Adresse, die der anfragende Knoten dann in seinem ARP-Cache für einen gewissen Zeitraum speichert.

Im lokalen Subnetz kann Mallory damit die Kommunikation umleiten, indem er die MAC-Adresse »spooft«, sprich: fälscht. Dabei bombardiert er das Netzwerk mit ARP-Reply-Paketen, um allen echten Antworten bei einem ARP-Request zuvorzukommen und dem anfragenden Knoten seine eigene MAC-Adresse für eine bestimmte Ziel-IP-Adresse unterzujubeln. Häufig handelt es sich dabei um die IP-Adresse des Default-Gateways. Dieser Angriff wird auch als ARP-Cache-Poisoning bezeichnet.

Die Dsniff-Toolsammlung stellt mit arpspoof ein passendes Tool bereit, um einen derartigen Angriff effektiv durchzuführen. Das schauen wir uns in Abschnitt 17.5.3 noch einmal ausführlich und in der Praxis an. Auch in Abschnitt 17.6 werden wir ARP-Spoofing nutzen.

17.4.4   ICMP-Typ 5 Redirect

ICMP ist ein kleines, aber wichtiges Protokoll im TCP/IP-Stack. Es gibt Firewall-Administratoren, die ICMP grundsätzlich verteufeln und komplett sperren. Damit geht den Netzwerk-Admins allerdings auch ein grundlegendes Arbeitsmittel beim Troubleshooting verloren, nämlich der Ping. Er basiert auf ICMP-Typ 8 (Echo Request) und ICMP-Typ 0 (Echo Reply). Während diese ICMP-Typen zumindest im lokalen Netz eines Unternehmens eine wertvolle Unterstützung für eine effektive Eingrenzung von Kommunikationsproblemen sind, so gibt es andere ICMP-Typen, die eine nicht zu unterschätzende Gefahr darstellen.

Hierzu gehört ICMP-Typ 5 Redirect. Erhält ein Router ein Paket zur Weiterleitung, stellt aber fest, dass er selbst das Paket über einen anderen lokalen Router im selben Subnetz weiterleiten würde, so sendet er dem Absender ein ICMP-Typ-5-Redirect-Paket. Darin teilt er dem Absender den besseren Weg aus dem lokalen Subnetz mit (siehe Abbildung 17.9).

[Bild]

Abb. 17.9: R1 würde R2 als Next Hop für die Paketzustellung an Bob nutzen.

Der Absender sendet nun die nachfolgenden Pakete über die IP-Adresse, die ihm der suboptimale Router per ICMP genannt hat. Wenn nun aber ICMP-Typ-5-Nachrichten gefälscht werden, so kann Mallory die Pakete grundsätzlich über einen von ihm kontrollierten Router leiten, was zu einer perfekten MITM-Ausgangssituation führt.

17.4.5   DNS-Spoofing oder DNS-Cache-Poisoning

Das Domain Name System, kurz: DNS, gehört zu den wichtigsten Konzepten im Internet und in Netzwerken allgemein. Viele Technologien sind ohne funktionierendes DNS nicht lauffähig, dazu gehört z.B. auch Microsofts Active Directory. Täglich nutzen wir DNS und haben uns schon längst daran gewöhnt: Statt 172.217.18.227 geben wir einfach www.google.de ein und landen auf der gewünschten Suchmaschine. Auch die Webpräsenz unserer Bank, das News-Portal oder unseren Webmailer erreichen wir über einen DNS-Namen, anstatt die IP(v4)-Adresse oder womöglich noch eine IPv6-Adresse eingeben zu müssen.

Dementsprechend interessant ist DNS als Angriffsziel, da die Namensauflösung eine Schwachstelle ist, die eine Sollbruchstelle darstellt: Wenn Alice den Namen von Bobs Computer auflösen möchte, muss Mallory ihr lediglich eine falsche IP-Adresse zurückliefern, und schon landet Alice bei der Verbindungsaufnahme auf einem von Mallory kontrollierten System. Dieser Angriff wird als »DNS-Spoofing« oder »DNS-Cache-Poisoning« bezeichnet, da – analog zum ARP-Cache – auch ein DNS-Cache existiert, der kürzlich vorgenommene Auflösungen zwischenspeichert. Es gibt verschiedene Szenarien, in denen DNS-Namensauflösungen angegriffen werden können. Einige wichtige stellen wir Ihnen im Folgenden vor.

Konfigurierte DNS-Server-Einträge manipulieren

Gelingt es Mallory, die DNS-Server-Einträge der IP-Konfiguration auf Alice’ Computer zu manipulieren, kann er dort IP-Adressen eintragen, die zu DNS-Servern führen, die er unter seiner Kontrolle hat. Fragt Alice nun nach der IP-Adresse von Bobs Webserver (z.B. www.bobs-server.tld), so liefert Mallory eine IP-Adresse zurück, die auf einen von ihm kontrollierten Webserver führt, von dem aus er verschiedene Angriffe auf den Browser oder den Anwender, z.B. via Social Engineering starten kann. Die Manipulation der DNS-Servereinträge bei Alice kann entweder manuell oder über eingeschleuste Malware erfolgen.

Dem echten DNS-Server zuvorkommen

Mallory kann entweder dem echten DNS-Server mit seinen DNS-Antworten zuvorkommen oder er kann den echten DNS-Server durch eine Denial-of-Service-Attacke lahmlegen und bei DNS-Requests seine eigenen Antworten senden. Hierbei ist zu beachten, dass die DNS-Kommunikation durch eine 16-Bit-Transaktionsnummer gesichert ist. Kann Mallory den Request im Netz mitsniffen, kennt er diese und kann sie in seiner DNS-Antwort einbetten. Ansonsten muss er die Transaktionsnummer erraten. Dies erfordert im Durchschnitt rund 32.000 Versuche (insgesamt stehen rund 65.000 mögliche Werte zur Verfügung), wobei er problemlos mehrere Antworten gleichzeitig senden kann, um seine Chancen zu erhöhen.

Hat er keinen Erfolg und landet der echte DNS-Eintrag im DNS-Cache von Alice, muss er die DNS-TTL (oft eine Stunde) abwarten, bevor er diesen Eintrag erneut angreifen kann. Ist er andererseits erfolgreich, so wird Alice für den TTL-Zeitraum (TTL = Time to live) immer den gefälschten Eintrag nutzen. Mit dnsspoof liefert die Dsniff-Toolsammlung ein Programm, das für DNS-Angriffe verwendet werden kann. Wir kommen etwas später darauf zurück.

DNS-Cache-Poisoning über die Additional Section

Ein Angriff, der mittlerweile bei den gängigen DNS-Servern nicht mehr funktioniert, basiert auf der hierarchischen Struktur von DNS und darauf, dass in der Additional Section des DNS-Protokolls zusätzliche, nicht angefragte Namensauflösungen mitgeliefert werden können. Dies ermöglichte einen klassischen DNS-Cache-Poisoning-Angriff.

Dabei hat Mallory einen DNS-Server unter seiner Kontrolle und liefert auf Anfragen nach anderen DNS-Namen einen zusätzlichen Eintrag für eine kritische Webseite, z.B. für die Webpräsenz einer Bank www.meinebank.tld, für die er gar nicht zuständig ist und die so auch gar nicht angefragt wurde. Dieser Eintrag wird nun trotzdem vom anfragenden DNS-Server ungeprüft übernommen und seinerseits im Cache abgelegt. Fragt ein Client zu einem späteren Zeitpunkt nach www.meinebank.tld, so liefert dieser DNS-Server nun für eine gewisse Zeit den falschen Eintrag, sprich die gefälschte IP-Adresse der Bank. Heute ignorieren alle gängigen DNS-Server diese zusätzlichen Einträge.

DNS-Hijacking

Eine weitere Angriffsvariante stellt das DNS-Hijacking dar. Es wird klassischerweise von Providern eingesetzt, um z.B. bei einer DNS-Anfrage nach einer nicht existierenden Domain keine Fehlermeldung zurückzuliefern, sondern den Browser auf eine Seite des Providers umzuleiten. Auch wenn dies bei den großen Providern deaktiviert werden kann, so ist es natürlich auch möglich, dieses Konzept in anderer Weise einzusetzen. So werden z.B. DNS-Anfragen, die über chinesische Netze geleitet werden, im Rahmen des Projekts »Goldener Schild« grundsätzlich geprüft und ggf. die Antworten manipuliert. Die Manipulation der Antwort wird in diesem Zusammenhang auch als DNS-Injection bezeichnet.

DNS-Angriffe werden häufig für Phishing- und Pharming-Angriffe eingesetzt. Dennoch eignen sie sich auch für Man-in-the-Middle-Angriffe, um die Daten über ein vom Angreifer kontrolliertes System zu leiten.

17.4.6   Manipulation der hosts-Datei

Ein sehr direkter Angriff auf die DNS-Namensauflösung besteht darin, die lokale Namensauflösung über die hosts-Datei zu manipulieren. Bevor es die DNS-Architektur gab, wurde die Datei hosts (auf Unix-artigen Systemen in der Regel /etc/hosts) zur Namensauflösung verwendet. Sie existiert heute noch unter Windows und unter Linux, macOS und anderen Unix-Derivaten. Oftmals ist sie der erste Anlaufpunkt für die Namensauflösung, bevor DNS involviert wird – obwohl sie heutzutage eigentlich nicht mehr genutzt wird.

[Bild]

Abb. 17.10: Die Datei hosts

Ein Eintrag in der Datei %Systemroot%\System32\Drivers\etc\hosts auf einem Windows-System wird sofort in den lokalen DNS-Cache eingetragen und daher bevorzugt für die Namensauflösung verwendet. Abbildung 17.10 zeigt ein Beispiel. Hier werden alle Anfragen an www.hacking-akademie.de auf 8.8.8.8 umgelenkt. Abbildung 17.11 zeigt das Ergebnis.

Gelingt es Mallory also, diese Datei zu manipulieren, kann er beliebige DNS-Namen in IP-Adressen auflösen lassen, die zu von ihm kontrollierten Systemen führen.

Tipp: Änderung nur durch den Administrator!

Es ist gar nicht so einfach, die Datei hosts auf einem Windows-System zu ändern. Ihre Zugriffsberechtigungen sind so gesetzt, dass Sie den Editor, z.B. Notepad.exe, explizit mit Administrator-Privilegien starten müssen und die Datei erst dann in den Editor laden können. Sonst wird der Schreibzugriff verweigert. Darüber hinaus schützen einige Virenschutzprogramme ebenfalls vor einer Änderung an der Datei.

[Bild]

Abb. 17.11: Ein DNS-Name wird auf eine falsche IP-Adresse umgeleitet.

17.4.7   Umleiten via DHCP-Spoofing

Bezieht ein Knoten im Netzwerk seine IP-Konfiguration per DHCP, so liefert der DHCP-Server neben der IP-Adresse und der Subnetzmaske mindestens auch das Default-Gateway sowie in der Regel auch die DNS-Server. Gelingt es Mallory, einen DHCP-Server im lokalen Netz von Alice einzuschleusen und schneller zu sein als der echte DHCP-Server, so kann er dem Computer von Alice eine falsche IP-Konfiguration zuweisen. Wenn Mallory sichergehen möchte, kann er auf den echten DHCP-Server noch eine DoS-Attacke durchführen, sodass dieser außer Gefecht gesetzt ist. Abbildung 17.12 zeigt das Prinzip.

Möchte Alice nun mit Bob kommunizieren, so läuft die Kommunikation immer über das Default-Gateway, das natürlich von Mallory kontrolliert wird. Zudem kann Mallory auf diesem Weg noch eigene DNS-Server ins Spiel bringen, um einen der früher erwähnten Angriffe durchzuführen.

Wichtig: Rogue DHCP-Server!

Ein nicht autorisierter DHCP-Server wird als rogue DHCP-Server (engl. rogue = bösartig oder Schurke) bezeichnet. Er stellt eine große Gefahr für die Stabilität und Sicherheit eines Netzwerks dar. Oftmals kann ein rogue DHCP-Server allerdings auch nur das Ergebnis einer Fehlkonfiguration sein, jedoch eine Menge Ärger verursachen, da die Knoten, die falsche DHCP-Leases erhalten, nicht im Netzwerk kommunizieren können.

[Bild]

Abb. 17.12: Mallory installiert einen eigenen DHCP-Server im Netzwerk.

So, an dieser Stelle wird es nun Zeit, sich einmal mit der praktischen Seite zu beschäftigen, damit Sie einige einschlägige Tools kennenlernen. Wir beginnen mit der altehrwürdigen Dsniff-Suite und werden anschließend noch weitere Programme zeigen, mit denen Lauschangriffe und Man-in-the-Middle-Attacken durchgeführt werden können.

17.5   Die Dsniff-Toolsammlung

Dsniff wurde von Dug Song entwickelt und hat schon einige Jahre auf dem Buckel. Obwohl seit vielen Jahren keine aktive Weiterentwicklung erfolgt, sind die Dsniff-Tools immer noch eine wertvolle Ressource, die gerade in lokalen Netzwerken sehr effektiv eingesetzt werden können.

Dsniff ist zum einen ein eigenständiges Programm, zum anderen der Namensgeber für eine Tool-Suite, die aus diversen kleineren Programmen besteht, die verschiedene Funktionen erfüllen. Hauptsächlich dienen sie zum Abhören des Netzwerks, also dem Sniffing. Im Gegensatz zu Wireshark lauschen sie nur auf ganz bestimmte Daten, wie z.B. Passwörter oder Mails.

Andere Tools aus der Sammlung ermöglichen es, den Netzwerk-Traffic umzuleiten und einen Man-in-the-Middle-Angriff oder sogar einen Denial-of-Service-Angriff zu starten. Nachfolgend werfen wir einen Blick auf die Toolsammlung und betrachten einige ausgewählte Tools genauer.

17.5.1   Programme der Dsniff-Suite

Verschaffen wir uns zunächst einen Überblick. Die Dsniff-Toolsammlung umfasst die folgenden Programme:

Tabelle 17.1: Die einzelnen Programme der Dsniff-Sammlung

Programmname

Funktion

dsniff

Passwort-Sniffer, unterstützt zahlreiche Klartext-Protokolle, unter anderem FTP, Telnet, SMTP, HTTP, POP, IMAP, SNMP und viele mehr.

filesnarf

Ermöglicht es, Dateien aus einem NFS-Datenstrom im Netzwerk herauszufiltern und zu speichern. Unterstützt ausschließlich das bei Unix/Linux verwendete Network File System (NFS).

mailsnarf

Filtert Mails aus dem Datenstrom. Unterstützt die Protokolle SMTP und POP. Der Traffic darf für diesen Angriff nicht verschlüsselt sein.

msgsnarf

Filtert bestimmte Chat-Nachrichten aus AOL Instant Messenger, ICQ 2000, IRC, MSN Messenger und Yahoo Messenger.

urlsnarf

Liest URLs aus einem Datenstrom aus und gibt diese, zusammen mit dem verwendeten Browser, aus.

webspy

Kopiert die mitgelesenen URLs eines Zielsystems in den eigenen Browser.

arpspoof

Ermöglicht es, MAC-Adressen-Auflösungen durch gefälschte ARP-Replies zu manipulieren.

dnsspoof

Liefert gefälschte DNS-Antworten, um die Kommunikation umzuleiten.

macof

Flutet einen Switch mit beliebigen MAC-Adressen, um die MAC-Adresstabelle zu füllen und ihn in den Hub-Modus zu versetzen.

webmitm

Ermöglicht einen Man-in-the-Middle-Angriff (MITM), arbeitet als transparenter Proxy und schneidet HTTP-Traffic (und eingeschränkt auch SSL-Traffic) mit.

sshmitm

Analog zu webmitm ermöglicht dieses Tool das Abhören von SSHv1-Sessions. Es ist allerdings auf die Version 1 von SSH beschränkt.

In der Dsniff-Suite sind einige Tools enthalten, die heutzutage nicht mehr ganz so nützlich sind (z.B. msgsnarf), und andere, die in bestimmten Szenarien auch heute noch effektive Angriffe ermöglichen. Auf Kali Linux müssen Sie ggf. die Dsniff-Suite zunächst nachinstallieren:

apt install dsniff

Sie steht nur für Unix-artige Systeme zur Verfügung, nicht für Windows. In Kali Linux werden die Tools unter /usr/sbin abgelegt. Die Anwendung erfolgt als Benutzer root bzw. mittels sudo.

17.5.2   Abhören des Netzwerk-Traffics

Alle Programme der obigen Liste mit Abhör-Funktion erfordern es, dass der zu analysierende Netzwerk-Verkehr an der lokalen Schnittstelle ankommt. Wir haben hierzu im Laufe dieses Kapitels drei Ansätze identifiziert:

  1. Die Netzwerkkommunikation startet oder terminiert auf dem lokalen System, sodass die Daten direkt abgehört werden können.

  2. Auf einer Netzwerk-Komponente auf dem Übertragungsweg existiert ein weiterer Ausgang, auf dem die übermittelten Pakete abgehört werden können. Dies kann z.B. ein Mirror-Port auf einem Switch oder Router sein, auf dem die betreffenden Netzwerk-Pakete gespiegelt werden. Im Falle von WLAN oder anderen Funknetzen ist dies natürlich gar kein Problem, da die Signale hier problemlos abgefangen werden können, solange der Angreifer in Reichweite ist.

  3. Der Netzwerkverkehr wird (unbemerkt) so umgeleitet, dass ein Angreifer eine MITM-Attacke starten kann und der Traffic über ein von ihm kontrolliertes System läuft.

Während die erste Option im Rahmen eines Netzwerk-Angriffs leider nur selten gegeben ist und wir dann in der Regel auch über andere, effektive Möglichkeiten der Manipulation verfügen, haben Sie die Variante 2 in Form des Mirror-Ports bereits kennengelernt. Beim Umleiten des Netzwerkverkehrs zur Realisierung von Option Nummer 3 haben wir eine ganze Reihe von Möglichkeiten, die wir Ihnen etwas früher in Abschnitt 17.4 bereits in der Theorie ausführlich erläutert haben. Bei der praktischen Umsetzung unterstützt uns die Dsniff-Suite mit verschiedenen Programmen. Das schauen wir uns im Folgenden einmal genauer an.

17.5.3   MITM mit arpspoof

Möchte ein System mit einem anderen System im selben Subnetz über IPv4 kommunizieren, so wird zunächst die bekannte IP-Adresse über ARP, das Address Resolution Protocol, in eine MAC-Adresse aufgelöst. Die Systeme kommunizieren innerhalb ihres Netzsegments auf Ethernet-Ebene (dies gilt auch für WLAN) über ihre MAC-Adresse, also ihre physische Adresse.

Mittels arpspoof können wir den ARP-Cache eines Opfer-Systems mit falschen MAC-Adressen füllen, was dazu führt, dass das Opfer, ohne es zu bemerken, mit einem anderen Zielsystem kommuniziert als geplant. Dazu liefert arpspoof zu einer bestimmten IP-Adresse die MAC-Adresse eines Systems, das unter der Kontrolle des Angreifers steht. Da eine Kommunikation bidirektional verläuft, sendet Mallory in der Regel gefälschte ARP-Replys für beide beteiligten Systeme im lokalen Subnetz. Abbildung 17.13 zeigt das Prinzip.

[Bild]

Abb. 17.13: Der Angreifer gibt sich für den Kommunikationspartner aus.

In vielen Fällen wird Mallory versuchen, das Default-Gateway zu »spoofen«, da der Großteil der Netzwerkkommunikation Ziele in externen Netzwerken, insbesondere das Internet, betrifft. Damit sitzt Mallory wie eine Spinne im Netz und kann eingehende Daten analysieren und ggf. manipulieren, bevor er sie weiterleitet.

Das Programm arpspoof wird – wie alle anderen Tools der Dsniff-Suite auch – über die Kommandozeile aufgerufen. Die vereinfachte Syntax sieht folgendermaßen aus:

arpspoof [-i <interface>] [-t <target>] [-r] <host>

Mit -i geben Sie also optional das Interface an, über das das ARP-Spoofing stattfinden soll. Der Parameter -t gibt optional das Opfer des ARP-Poisoning-Angriffs an. Wird der Parameter weggelassen, so wird das ARP-Cache-Poisoning auf alle Systeme im lokalen Subnetz ausgeführt. Mit -r können Sie – wiederum optional – auch den nachfolgend anzugebenden Host, dessen MAC-Adresse gefälscht werden soll, ebenfalls über arpspoof angreifen, sodass die Kommunikation in beide Richtungen umgeleitet wird. Das ist in der Regel gewünscht.

Nachfolgend in Abbildung 17.14 ein Beispiel, wie arpspoof eingesetzt wird, um das System mit der IP-Adresse 192.168.8.1 (dies ist das Default-Gateway) zu spoofen, wenn der Computer mit der IP-Adresse 192.168.8.117 anfragt. Da wir auf die Option -r verzichten, geben wir uns nur gegenüber der Adresse 192.168.8.117 als Default-Gateway aus, nicht jedoch umgekehrt gegenüber dem Default-Gateway als 192.168.8.117.

[Bild]

Abb. 17.14: arpspoof bei der Arbeit

Wie zu sehen, sendet arpspoof nun regelmäßig und kontinuierlich ARP-Reply-Nachrichten mit den gefälschten Zuordnungen. Im Ergebnis hält das Opfer nun eine falsche MAC-Adresszuordnung im ARP-Cache vor, wie Abbildung 17.15 zeigt.

[Bild]

Abb. 17.15: Der ARP-Cache auf dem Opfer-System

arpspoof beenden Sie mit Strg+C. Das Programm räumt dann noch den ARP-Cache der Opfer-Systeme auf und sendet einige ARP-Replys mit den echten MAC-Adressen, bevor es sich beendet (siehe Abbildung 17.16).

Damit Mallory nun eine echte Man-in-the-Middle-Attacke durchführen kann, müssen drei Bedingungen erfüllt sein:

  1. Beide Seiten (das Opfer und das Default-Gateway) müssen die MAC-Adresse des Angreifers nutzen, um Pakete an den jeweiligen Kommunikationspartner zuzustellen, damit auch die Antworten über Mallorys System laufen. Hierzu dient die Option -r bei arpspoof.

  2. Mallorys Computer muss das »IP-Forwarding« aktiviert haben, damit auch die Pakete weitergeleitet werden, die nicht an ihn direkt gerichtet sind. Mit anderen Worten: Aus Mallorys System muss ein Router gemacht werden.

  3. Zudem muss Mallory unterbinden, dass sein System ICMP-Typ-5-Redirect-Meldungen sendet, da er selbst ja auch dasselbe Gateway (192.168.8.1) verwendet wie das Opfer und Kali Linux in seiner Eigenschaft als Router sonst dem Opfer zurückmeldet, dass das lokale System nicht das optimale Gateway darstellt.

[Bild]

Abb. 17.16: arpspoof räumt auf.

Sorgen wir also dafür, dass Kali Linux für die MITM-Aufgabe vorbereitet wird. Dazu geben Sie zunächst im Terminal den folgenden Befehl ein:

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

Ab sofort leitet unser Angriffssystem eingehende Pakete weiter, die eine fremde Ziel-IP-Adresse haben. Um Redirects auf der Schnittstelle eth0 zu unterbinden, können Sie die folgende Anweisung nutzen:

echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

Stellen Sie sicher, dass arpspoof wie oben beschrieben gestartet ist (inklusive Option -r). Nun können Sie mit Wireshark beobachten, wie z.B. ein Ping auf die IP-Adresse 8.8.8.8 auf dem Opfer-System über das Angreifer-System (also unser Kali Linux) geleitet wird, das die Ping-Requests und -Replys empfängt und weiterleitet. Abbildung 17.17 zeigt den Mitschnitt.

[Bild]

Abb. 17.17: Wireshark zeigt den erfolgreichen MITM-Angriff.

Vergleichen Sie die verwendeten MAC-Adressen im Ethernet-Header, um sich davon zu überzeugen, dass tatsächlich das lokale Kali-System das Ziel der Ethernet-Frames ist.

Herzlichen Glückwunsch! Sie haben Ihren ersten Man-in-the-Middle-Angriff erfolgreich durchgeführt! Sie können nun zum einen den kompletten Traffic passiv mitlesen, den das Opfer über das Gateway sendet, und zum anderen den Traffic manipulieren. Das erfordert allerdings weitergehende Tools und Vorbereitungen. Ein solches MITM-Tool lernen Sie mit Ettercap in Abschnitt 17.6 kennen.

17.5.4   Die ARP-Tabelle des Switches mit macof überfluten

Um zumindest passiv den Datenaustausch zwischen zwei Systemen mitlesen zu können, provozieren wir den Failopen-Mode auf einem Switch, wie in Abschnitt 17.3.2 beschrieben. Das Tool der Wahl heißt macof und es funktioniert denkbar einfach. Auch wenn es einige optionale Schalter hat, reicht es in der Regel aus, macof ohne jegliche Optionen zu starten, wie in Abbildung 17.18 dargestellt. Es benötigt allerdings Root-Rechte.

[Bild]

Abb. 17.18: macof bei der Arbeit ...

Nach dem Start erzeugt macof eine Vielzahl von rohen IP-Paketen mit zufälligen IP- und MAC-Adressen. Die Grenze der Kapazität der MAC-Adresstabelle des Switches ist also nach sehr kurzer Zeit bereits erreicht und aufgrund der hohen Sendefrequenz (weit über 10.000 Pakete pro Sekunde) kommen andere Systeme kaum noch zum Zug, sodass keine echten, neuen MAC-Adressen registriert werden können. Je nachdem, wie anfällig der Switch auf diesen Angriff reagiert, flutet er nun alle Ports oder sendet zumindest alle Frames an unbekannte Ziel-MAC-Adressen (die nun tendenziell immer mehr werden, da die alten, echten irgendwann aufgrund des Entry-Timeouts herausgeworfen werden) an alle anderen Ports weiter.

Das Programm macof können Sie über Strg+C abbrechen und beenden. Grundsätzlich sollte es während eines Flooding-Angriffs laufen, aber es erzeugt natürlich auch einiges an Traffic und Aufmerksamkeit durch Monitoring-Systeme. Auch hier erfahren Sie am Ende des Kapitels, welche effektiven Schutzmaßnahmen Sie treffen können, um derartige Angriffe zu unterbinden.

17.5.5   DNS-Spoofing mit dnspoof

Kann Mallory den Traffic mitlesen, dann kann er die DNS-Antworten mit dnsspoof fälschen. Dazu können Sie eine der beiden bereits vorgestellten Methoden verwenden. Die MITM-Position ist Voraussetzung dafür, dass dnsspoof arbeiten kann.

Grundlagen von dnsspoof

Wird das Programm ohne Parameter aufgerufen, so lauscht es auf beliebige DNS-Host-Anfragen (Ressource Record vom Typ A) und gibt DNS-Antworten unter Verwendung der korrekten Transaktions-ID mit der eigenen IP-Adresse zurück. Abbildung 17.19 zeigt ein Beispiel.

[Bild]

Abb. 17.19: dnsspoof liefert Namensauflösung auf die eigene IP-Adresse.

Der Client fragt in diesem Szenario seinen regulären DNS-Server 192.168.8.1 nach der Auflösung für www.alice.local und www.bob.local. Dass diese Adressen in Wirklichkeit gar nicht existieren, spielt in diesem Szenario gar keine Rolle, da dnsspoof eine Antwort liefert, die eine Auflösung auf seine eigene IP (192.168.8.101) enthält, wie Wireshark in Abbildung 17.20 offenbart.

[Bild]

Abb. 17.20: Der DNS-Spoofing-Angriff enttarnt

Wie zu sehen, fälscht dnsspoof zunächst die Absender-IP-Adresse, damit die Antwort vom regulären DNS-Server zu kommen scheint. Die MAC-Adresse verrät jedoch, dass es sich um das lokale Kali-System handelt (vergleichen Sie den Wert mit der MAC-Adresse, die arpspoof in Abschnitt 17.5.3 geliefert hat).

Einsatz in der Praxis

Möchten Sie nur Anfragen auf bestimmte DNS-Namen mittels dnsspoof fälschen, können Sie eine Liste im Format der hosts-Datei angeben. Dabei muss jeder Eintrag in einer eigenen Zeile stehen. Abbildung 17.21 zeigt ein Beispiel.

[Bild]

Abb. 17.21: Eine Datei für dnsspoof

Nach dem Start mit dnsspoof -f dnsspoof-hosts.txt wird das Programm nur noch Anfragen an einen der genannten Namen spoofen. Das Ergebnis sehen Sie auf dem Client mit nslookup, wie in Abbildung 17.22 dargestellt.

[Bild]

Abb. 17.22: Selektives DNS-Spoofing

Je nachdem, welcher DNS-Name angefragt wird, erfolgt die Auflösung durch dnsspoof. Da www.google.de nicht in der DNS-Spoofing-Liste enthalten ist, wird diese IP-Adresse original aufgelöst.

Troubleshooting

Die Namensauflösung wird bei Ihnen nicht korrekt umgebogen? Dann ist Ihr DNS-Server vermutlich zu schnell. Das Kali-System leitet aufgrund seiner Eigenschaft als Router die Anfragen an die IP-Adresse des auf dem Client konfigurierten DNS-Servers weiter und auch dessen Antworten. Das Programm dnsspoof liefert zwar ebenfalls Antworten mit den gefälschten IP-Adressen, jedoch blockiert es nicht die Originalantworten des DNS-Servers, sodass die gefälschten Antworten häufig später eintreffen und dann vom Client verworfen werden.

Um dies zu verhindern, müssen Sie die Antworten des DNS-Servers abfangen – und zwar für alle Adressen, die Sie fälschen wollen. Dies tun wir mit einer ausgeklügelten Firewall-Regel mit iptables auf dem MITM-System, also Kali Linux. Nehmen wir an, Sie möchten www.hacking-akademie.de spoofen. Die Adresse ist 159.69.24.22. Sie muss zunächst Oktett für Oktett in Hexadezimalwerte umgewandelt werden, was z.B. dank des Programmierer-Modus der Windows-App Rechner kein Problem darstellt. Für (Kali) Linux können Sie z.B. das Paket galculator installieren und das gleichnamige Programm zur Umrechnung nutzen. Der Wert lautet 9f 45 22 16. Die folgende Befehlszeile erzeugt eine passende iptables-Regel:

iptables --append FORWARD --match string --algo kmp --hex-string '|9f 45 22 16|' --jump DROP

Ab sofort werden eingehende, weiterzuleitende Pakete, die den angegebenen Hexadezimalwert (sprich: die übersetzte IP-Adresse) enthalten, verworfen. Diesen Schritt müssen Sie für alle zu spoofenden IP-Adressen durchführen.

Wichtig: Nur bei realen Adressen möglich!

Dieses Vorgehen funktioniert für Adressen, die der DNS-Server auflösen kann. Fake-Namen, wie www.alice.local, erzeugen eine NXDOMAIN-Rückmeldung, die Sie in der beschriebenen Art leider nicht abfangen können. Für dieses und die nachfolgenden Beispiele im Rahmen von Ettercap müssen Sie also ggf. die Ziele so ändern, dass sie auflösbar sind.

17.5.6   Dsniff

Last, but not least werfen wir nun noch einen Blick auf das namensgebende Tool für die gleichnamige Sammlung, also dsniff selbst. Bei diesem Programm handelt es sich um einen Passwort-Sniffer. Er unterstützt diverse Klartext-Protokolle, wie z.B. FTP, Telnet, SMTP, http oder POP, aber auch viele Datenbank-Authentifizierungsvorgänge und andere Produkte wie Symantec pcAnywhere und so weiter. Ein Blick in die Man-Page mit man dsniff zeigt die vollständige Liste.

Aus der Man-Page wird auch deutlich, dass dsniff eine ganze Reihe von Optionen und Parametern kennt. Grundsätzlich kommt dsniff aber mit wenigen Angaben aus, da es viele Default-Einstellungen gibt. Nachfolgend in Abbildung 17.23 ein sehr einfaches Beispiel:

[Bild]

Abb. 17.23: dsniff bei der Arbeit

Hier erkennt dsniff eine FTP-Authentifizierung und gibt die identifizierten Login-Daten auf dem Terminal aus. Dies wird ggf. übrigens erst beim Beenden der FTP-Session angezeigt. Aus bestimmten Gründen muss dsniff auch die gesamte Session mitbekommen und kann nicht mittendrin einsteigen.

Hinweis: Notationskonvention für Port-Angaben

Falls Sie sich wundern: Die IP-Adresse ist mitnichten und Neffen um ein Oktett gewachsen. Stattdessen wird der verwendete bzw. angesprochene Port als letztes Oktett ausgegeben. Diese Notation entspricht auch der Darstellung in tcpdump. In anderen Situationen werden die Ports durch Doppelpunkt von der IP-Adresse getrennt.

Ein kurzer Blick auf die wichtigsten Optionen: Mit -m aktivieren Sie die automatische Protokollerkennung. Sie ist relativ simpel und basiert auf dem klassischen Linux-Befehl file, der auf Basis verschiedener Systemquellen, -Dateien und Analysen die Art der Daten einer Datei ermittelt. Die Zuverlässigkeit dieser Art der Erkennung ist limitiert, reicht aber für die meisten Zwecke aus.

Mit -n verhindern Sie die Namensauflösung. Diese ist in der Regel nicht notwendig und kann daher getrost mit diesem Schalter deaktiviert werden. Ein Parameter, den Sie in der Praxis regelmäßig angeben werden, ist -w <Dateiname>, um die Ergebnisse von dsniff in die angegebene Datei zu speichern.

Wichtig: Dsniff versteht nur Klartext!

Das Programm dsniff unterstützt keine kryptografisch gesicherten Protokolle, sondern ausschließlich Authentifizierung in Klartext bzw. minimal codiert. In gut konfigurierten Rechnernetzen sollte heutzutage keine Klartext-Authentisierung mehr notwendig sein.

Im Umkehrschluss eignet sich dsniff hervorragend, um Schwachstellen aufzuzeigen. Die Praxis zeigt, dass es in vielen heutigen Netzwerken unerwarteterweise durchaus noch vereinzelt Klartext-Authentisierung gibt, die im Rahmen eines Penetrationstests dringend aufgezeigt werden muss.

17.6   Man-in-the-Middle-Angriffe mit Ettercap

Bei Ettercap handelt es sich um ein umfassendes Tool zur Durchführung von Man-in-the-Middle-Angriffen. Im Gegensatz zu den Dsniff-Tools ist Ettercap ein komplettes, monolithisches Programm mit verschiedenen Funktionen, die Sie zu einem Teil auch aus der Dsniff-Suite kennen. Der große Vorteil ist allerdings, dass Ettercap im Gegensatz zur Dsniff-Toolsammlung weiterentwickelt wird und dadurch aktueller und leistungsfähiger ist. Ettercap hat neben einer textbasierten Schnittstelle auch eine optionale GUI und ist für verschiedene Linux- und Unix-Derivate sowie für macOS und Windows verfügbar. In diesem Abschnitt geben wir Ihnen einen Überblick über Ettercap und dessen wichtigste Features und gehen ein praktisches Beispiel für eine klassische MITM-Attacke durch.

17.6.1   Einführung in Ettercap

Ursprünglich war Ettercap einfach nur ein Sniffer, der darauf ausgelegt war, in geswitchten LAN-Umgebungen Daten mitzulesen. Hierzu nutzt Ettercap das bereits bekannte ARP-Spoofing, sodass eine klassische Man-in-the-Middle-Situation entsteht. Vor diesem Hintergrund hat sich das Tool aber mittlerweile zu einem umfassenden MITM-Angriffstool weiterentwickelt. Es werden diverse Protokolle unterstützt und sogar via SSL verschlüsselte Verbindungen können abgehört werden – wenn auch mit entsprechenden Einschränkungen bzw. nur unter bestimmten Bedingungen.

Hinweis: IPv6-Support

Ettercap unterstützt sogar IPv6. Auch wenn wir uns hier auf den IPv4-Bereich beschränken, ist dies für zukünftige Netzwerk-Umgebungen sicherlich zunehmend interessant. Daraus ergeben sich auch Änderungen in der Syntax, zu denen wir etwas später noch kommen.

Ettercap unterstützt zwei Sniffing-Modi:

Während der Unified-Modus die einfachere Variante darstellt, erfordert der Bridged-Modus einen physischen Zugang zum Kommunikationspfad, um sich einklinken zu können. Der Man-in-the-Middle-Engine ist es darüber hinaus egal, in welchem Modus die Daten aufgenommen werden. Als MITM-Tool kann Ettercap dann diverse Funktionen erfüllen. Dazu gehören unter anderem:

Im Standard-Kali-Linux ist Ettercap bereits vorinstalliert. Über den Menüpunkt Sniffing & Spoofing finden Sie die grafische Version des Programms (siehe Abbildung 17.24). Wie bereits erwähnt, unterstützt Ettercap mehrere Darstellungsmodi. Grundsätzlich rufen Sie Ettercap im Terminal mit dem Programm gleichen Namens auf: ettercap <Darstellungsmode>. Hierzu können Sie zunächst die Identität von root mittels sudo su - annehmen. Alternativ verwenden Sie als Benutzer kali sudo vor dem Befehl.

[Bild]

Abb. 17.24: Ettercap im Anwendungsmenü

Den Textmodus aktivieren Sie mit der Option -T. Hier können Sie Ettercap wie ein normales Kommandozeilen-Tool verwenden. Im nächsten Abschnitt zeigen wir Ihnen dazu ein Beispiel. Mit ettercap -C aktivieren Sie eine Pseudo-GUI auf Basis von Ncurses, einer C-Bibliothek zur Darstellung von grafischen Elementen in einem Terminal (siehe Abbildung 17.25). Sie funktioniert in der Oberfläche von Xfce derzeit nicht besonders gut und hat mitunter Darstellungsfehler.

[Bild]

Abb. 17.25: Die pseudografische Oberfläche von Ettercap

Analog hierzu gibt es jedoch auch eine richtige GUI, die Sie über ettercap -G starten können. Sie stellt sich wie in Abbildung 17.24 dar. Zu den Details kommen wir gleich.

Eine weitere Möglichkeit, um Ettercap laufen zu lassen, ist der Daemon-Modus, den Sie mit -D aktivieren. Er bietet keine grafische Option. Stattdessen läuft Ettercap als Daemon im Hintergrund und kann seine Arbeit ungestört über einen längeren Zeitraum verrichten. Informationen, die normalerweise auf der Standardausgabe (Terminal) ausgegeben werden, schreibt Ettercap dann in Logfiles.

Im Folgenden schauen wir uns einmal ein kleines Beispiel für die Arbeit mit ettercap an, damit Sie ein Gefühl für das Tool bekommen. Machen Sie mit und lernen Sie durch die Praxis!

Wie bereits erwähnt, unterstützt Ettercap mehrere Darstellungsmodi. Grundsätzlich rufen Sie Ettercap im Terminal mit dem Programm gleichen Namens auf: ettercap <Darstellungsmode>. Hierzu können Sie zunächst die Identität von root mittels sudo su - annehmen. Alternativ verwenden Sie als Benutzer kali sudo vor dem Befehl.

17.6.2   DNS-Spoofing mit Ettercap

Im Rahmen der Dsniff-Tools haben Sie die Vorgehensweise beim DNS-Spoofing bereits kennengelernt. Hier wollen wir an diesem bekannten Szenario anknüpfen und uns anschauen, wie dies in Ettercap umgesetzt wird. Den folgenden Angriff führen wir in zwei Varianten aus: Einmal in der GUI und anschließend stellen wir Ihnen die Kommandozeilenversion vor.

Vorbereitung des Angriffs

Bevor wir loslegen, müssen wir noch einige Anpassungen an der Konfiguration von Ettercap vornehmen und unsere Webseite vorbereiten, auf die wir unser Opfer leiten wollen. Beginnen wir gleich mit Letzterem, um uns anschließend Ettercap zuzuwenden. Sie sind dran!

Die Website präparieren

Die Standard-Webpräsenz befindet sich unter /var/www/html. Zunächst benennen Sie die alte Startdatei der Webpräsenz index.html um:

root@kali:~# mv /var/www/html/index.html /var/www/html/index.html.old

Nun erstellen Sie mit einem Editor Ihrer Wahl (z.B. nano) eine neue Datei index.html z.B. mit folgendem Inhalt:

<html>
<head>
<title>Sie wurden umgeleitet!</title>
</head>
<body>
<h1 align=center>Sie wurden umgeleitet, das DNS-Spoofing hat funktioniert!</h1>
</body>
</html>

Listing 17.1: Unsere neue Datei /var/www/html/index.html

Es wird Zeit, Ihren Webserver zu starten, wenn noch nicht geschehen. Dies tun Sie folgendermaßen:

root@kali:~# service apache2 start

Starten Sie Firefox und geben Sie in der Adresszeile localhost ein. Sie sollten nun Ihre neue Webseite sehen, wie in Abbildung 17.26 dargestellt.

[Bild]

Abb. 17.26: Die neue Webseite ist am Start.

Ettercap-Konfiguration anpassen

So weit, so gut! Jetzt nehmen wir uns die Ettercap-Konfigurationsdatei vor: /etc/ettercap/etter.conf. Öffnen Sie diese mit einem Editor und passen Sie gleich oben unter der Sektion [privs] die folgenden beiden Zeilen an:

ec_uid = 0
ec_gid = 0

Dies dient dazu, Ettercap mit den notwendigen Berechtigungen auszustatten, um z.B. an beliebigen Stellen Logfiles erzeugen zu können. Standardmäßig wird Ettercap zwar mit Root-Rechten gestartet, dann aber auf minimale Rechte reduziert. Das ist an verschiedenen Stellen ein Problem, das wir so umgehen, da wir sowohl die User-ID als auch die Group-ID auf 0, also root, setzen und damit dem Programm umfassende Rechte einräumen. Dieses kalkulierte Risiko nehmen wir auf uns. Anschließend können Sie die Datei speichern und schließen.

Im nächsten Schritt müssen Sie noch dafür sorgen, dass die passenden DNS-Anfragen von Ettercap beantwortet werden. Dazu öffnen Sie bitte /etc/ettercap/etter.dns und fügen eine passende Zeile ein, analog zu den vorhandenen. Abbildung 17.27 zeigt den Eintrag in unserem Beispiel.

[Bild]

Abb. 17.27: Die DNS-Auflösung verbiegen

Für unseren Proof-of-Concept-Workshop leiten wir die Auflösung von www.hacking-akademie.de auf unser lokales Kali-System um. Speichern Sie die Änderung und beenden Sie den Editor. Auf Ihrem Opfer-System sollten Sie lediglich sicherstellen, dass die Firewall deaktiviert ist und dieses von Ihrem Angriffssystem erreicht werden kann, damit der Poisoning-Test durchgeführt werden kann. Nun sind wir startklar.

Den DNS-Spoofing-Angriff mit Ettercap durchführen

Starten Sie die GUI über Eingabe von ettercap -G. Ettercap präsentiert sich zunächst recht schlicht, wie Abbildung 17.28 zeigt.

[Bild]

Abb. 17.28: Die Ettercap-Startseite

Rechts oben sind die Optionen in der Regel bereits richtig voreingestellt. Klicken Sie auf den Button mit dem Häkchen, um das Unified sniffing zu starten. Wählen Sie ggf. das passende Interface aus, bei einer VM ist das regelmäßig die LAN-Schnittstelle eth0 bzw. enp0s3 oder ähnlich. Nun stellt sich die Oberfläche so dar wie in Abbildung 17.29 zu sehen. Sie wurde in Version 0.8.3 (ab Kali 2020.1) stark gegenüber der Version 0.8.2 verändert und basiert jetzt nicht mehr auf einem klassischen Menü, sondern auf einzelnen, nicht selbsterklärenden Buttons, die jedoch glücklicherweise mit Tooltips versehen sind.

[Bild]

Abb. 17.29: Nach der Auswahl der Sniffing-Methode bietet Ettercap viele Optionen.

Über Scan for Hosts lassen Sie Ettercap verfügbare Opfer-Systeme im lokalen Subnetz finden. Anschließend können Sie diese über Hosts list anzeigen lassen, siehe Abbildung 17.30.

Wählen Sie Ihr Default-Gateway (in unserem Beispiel 192.168.1.254) durch Anklicken aus und klicken Sie auf Add to Target 2. Anschließend markieren Sie das Opfer (hier Windows 10 mit 192.168.1.210) und klicken auf Add to Target 1. Über Ettercap Menu|Targets|Current targets können Sie sich vergewissern, dass die richtigen Ziele ausgewählt wurden.

[Bild]

Abb. 17.30: Die Liste der identifizierten Hosts

Wenn Sie möchten, können Sie nun noch das Logging unter Ettercap Menu|Logging|Logging all packets and infos aktivieren. Hier können Sie einen Speicherort und den Namen für das Logging auswählen (siehe Abbildung 17.31).

[Bild]

Abb. 17.31: Logging-Speicherort festlegen

Es werden zwei Dateien mit den Endungen .eci und .ecp erstellt, die die Daten binär protokollieren. Wie erwähnt, dieser Schritt ist optional, bietet sich aber im Rahmen eines Penetration-Tests zur Dokumentation an.

Die Logdaten können Sie später mit dem Tool etterlog auswerten. Aus Platzgründen gehen wir an dieser Stelle nicht näher darauf ein. Die Man-Page hilft Ihnen, die richtigen Optionen auszuwählen.

Jetzt wird es Zeit, die MITM-Position einzunehmen. Über Mitm Menu|ARP poisoning geben Sie sich für beide Targets als der jeweils andere aus. Wählen Sie die Option Sniff remote connections, wie in Abbildung 17.32 dargestellt.

[Bild]

Abb. 17.32: Wir werden Man-in-the-Middle.

Als Nächstes aktivieren Sie die DNS-Spoofing-Funktion. Dazu klicken Sie auf Ettercap Menu|Plugins|Manage the plugins. Klicken Sie doppelt auf das Plug-in dns_spoof, siehe Abbildung 17.33. Ein Stern vor dem Eintrag zeigt an, dass es aktiviert wurde – dies ist auch im unteren Bereich in der Ausgabe zu lesen.

[Bild]

Abb. 17.33: Wir aktivieren das DNS-Spoofing.

Stellen Sie über Start/Stop sniffing (ganz links oben) sicher, dass Ettercap arbeitet. Klicken Sie im Zweifel auf den Button, bis das übliche, quadratische Stopp-Symbol dargestellt wird. Im Meldungsfenster erscheint ggf. Starting Unified sniffing. Anschließend können Sie im Register Plugins über Doppelklick auf das Plug-in chk_poison den Status des ARP-Poisoning-Angriffs testen. Im Meldungsfenster unten sollte folgende Meldung erscheinen:

chk_poison: Checking poisoning status ...
chk_poison: Poisoning process successful!

Hinter chk_poison steckt ein simpler Ping mit gespoofter Absender-IP-Adresse an die jeweiligen Target-Hosts. Gelangen die Ping-Antworten zurück zum Angreifer, hat das ARP-Spoofing funktioniert und Sie sind MITM. Ist allerdings eine Firewall auf einem der Opfer-Systeme aktiv, die die Ping-Anfragen verwirft, so gibt das Modul No poisoning between 192.168.1.210 -> 192.168.1.254 aus (Adressen stammen aus unserem Szenario). Trotzdem kann der Angriff funktionieren, da eine Firewall in der Regel kein ARP-Spoofing verhindert.

Sie können sich auch auf dem Opfer-System davon überzeugen, indem Sie arp -a in der Eingabeaufforderung eingeben, wie in Abbildung 17.34 gezeigt.

[Bild]

Abb. 17.34: Das ARP-Poisoning war erfolgreich.

In der Abbildung ist sehr gut zu erkennen, dass die MAC-Adressen für das Kali-Linux-System und das Default-Gateway identisch sind.

Nun wird es spannend! Funktioniert das DNS-Spoofing? Starten Sie zunächst Wireshark auf dem Kali-System mit einem Mitschnittfilter auf port 53. Schließlich wollen wir hinter die Kulissen blicken. Geben Sie anschließend www.hacking-akademie.de im Browser auf dem Opfer-System ein und schauen Sie, was passiert. Wenn alles geklappt hat, sehen Sie nun unsere selbst gebaute Webseite auf dem Opfer-Rechner, wie in Abbildung 17.35 gezeigt.

[Bild]

Abb. 17.35: Quod erat demonstrandum (lat. für: Was zu beweisen war)

Geben Sie nun im Browser auf dem Opfer-System www.google.de ein. Die Seite sollte normal angezeigt werden. Betrachten Sie anschließend unseren Wireshark-Mitschnitt (siehe Abbildung 17.36).

[Bild]

Abb. 17.36: Wireshark zeigt, was hinter den Kulissen passiert.

Der Mitschnitt zeigt hier sehr schön, dass die Anfrage unseres Opfer-Systems nach www.hacking-akademie.de von Ettercap abgefangen und direkt beantwortet wurde. Ettercap geht dabei intelligenter als dnsspoof vor und leitet die Original-Pakete für zu spoofende DNS-Namen nicht parallel weiter, es ist also kein Workaround via iptables notwendig.

Die Anfrage nach www.google.de leitet Ettercap dagegen brav an den echten DNS-Server 8.8.8.8 weiter. Daher sehen Sie die DNS-Anfragen und Antworten scheinbar jeweils doppelt. Vergleichen Sie die Absender- und Empfänger-MAC-Adressen in den einzelnen Paketen: Hier wird deutlich, dass wir Man-in-the-Middle sind. Die MAC-Adresse 08:00:27.1f:30:76 gehört dem Angreifer, also dem Kali-System.

Die Kommandozeilenversion

Keine Frage, die GUI von Ettercap ist zweckmäßig und macht einen guten Job. Es erforderte allerdings einige Einstellungen in verschiedenen Menüs, bis wir startklar waren. Schauen wir nun, wie die Befehlszeilenvariante aussehen würde, um denselben Angriff zu starten:

ettercap -T -q -i eth0 -M arp:remote -P dns_spoof /192.168.1.210// /192.168.1.254//

Dies sieht deutlich komprimierter aus als die GUI-Operationen. Schauen wir uns die Optionen und Parameter im Detail an:

  • -T: Aktiviert den Textmodus von Ettercap. Wird in der Regel mit weiteren Optionen und Parametern kombiniert.

  • -q: Aktiviert den Quiet-Mode. Damit wird verhindert, dass Pakete im Terminal angezeigt werden.

  • -i eth0: Legt eth0 als Interface fest, auf dem Ettercap sniffen soll.

  • -M: Aktiviert den Man-in-the-Middle-Angriff, der im Folgenden angegeben wird. Es sind hier auch mehrere Angaben möglich und häufig sinnvoll bzw. erforderlich.

  • arp:remote: Wird als Parameter von -M angegeben. Startet einen ARP-Spoofing-Angriff auf die angegebenen Ziele (Targets). Die optionale Angabe von remote ist notwendig, wenn ein Router als einer der Ziele angegeben wird, damit Ettercap nicht nur die Kommunikation zwischen genau diesen Zielen mitschneidet, sondern auch die Kommunikation, die über den Router in externe Netze bzw. das Internet geht. Neben arp gibt es zahlreiche weitere MITM-Angriffsformen, wie z.B. icmp, dhcp, port und so weiter. Alle Varianten haben eigene Angaben, die sie benötigen. Die Syntax können Sie man ettercap entnehmen.

  • -P dns_spoof: Aktiviert das Plug-in dns_spoof. Dieses greift auf die Datei /etc/ettercap/etter.dns zu, um zu ermitteln, welche DNS-Anfragen auf welche IP-Adressen aufzulösen sind. Dies haben wir bereits in der Vorbereitung zu diesem Workshop gezeigt. Es können weitere Plug-ins mit -P <Plugin> angegeben werden. Auch während der Laufzeit bietet Ettercap im Textmodus das dynamische Hinzufügen von Plug-ins an.

  • /192.168.1.210//: Gibt das erste Ziel an. Die Zielangabe erfolgt nach der Syntax MAC/IPv4/IPv6/Ports. Es können auch mehrere Adressen angegeben werden. Mit /192.168.1.1-100//20,21,25 wird z.B. eine IPv4-Range von 192.168.1.1 bis 192.168.1.100 angegeben, mit der zusätzlichen Bedingung, dass der Zielport 20, 21 oder 25 ist. Dabei sind sowohl die verwendeten MAC-Adressen als auch eventuelle IPv6-Adressen beliebig. Mit 00:11:22:aa:bb:cc///80 wird festgelegt, dass die angegebene MAC-Adresse auf Port 80 bei beliebigen IPv4/IPv6-Adressen angesprochen werden muss.

Vorsicht: IPv6 kann zur Falle werden!

Mittlerweile ist IPv6 in Ettercap dokumentiert. In älteren Man-Pages zu Ettercap und in vielen älteren Beispielen aus anderen Quellen wird vorausgesetzt, dass IPv6 nicht aktiviert ist. In diesem Fall lautet die Syntax MAC/IPv4/Ports. Somit wird z.B. das Ziel 192.168.1.254 als /192.168.1.254/ angegeben. Dies erzeugt bei aktiviertem IPv6 aber eine Fehlermeldung, da ein weiterer Schrägstrich (/) erwartet wird – böse Falle! Schauen Sie auf jeden Fall einmal gründlich in man ettercap, um sich einen guten Überblick zu verschaffen – die zeitliche Investition lohnt sich!

So, nun testen Sie diesen Befehl auf jeden Fall auch noch einmal aus. Drücken Sie H, um die Inline-Hilfe zu erhalten. Die Ausgabe stellt sich sinngemäß dar wie in Abbildung 17.37 gezeigt.

Wie Sie erkennen können, haben Sie diverse Möglichkeiten, Ettercap zur Laufzeit weiter zu modifizieren. Probieren Sie das am besten gleich aus.

Aufgabe: Arbeiten mit Plug-ins und der Inline-Hilfe

Nutzen Sie für die folgenden Aufgaben die Inline-Hilfe. Aktivieren Sie das Plug-in chk_poison, um den Erfolg des ARP-Spoofings zu ermitteln, und lassen Sie sich anschließend die Host-Liste anzeigen. Finden Sie ein Plug-in, um das Default-Gateway zu ermitteln. Testen Sie dieses aus. Denken Sie an dieser Stelle daran, dass die angeforderte Remote IP außerhalb des eigenen Subnetzes liegen muss. Sind Sie fertig mit Ihren Experimenten, drücken Sie Q, um Ettercap zu beenden.

[Bild]

Abb. 17.37: Auch der Textmodus von Ettercap hat es in sich ...

An dieser Stelle wollen wir es bei dieser kleinen Einführung in Ettercap bewenden lassen. Sie sollten sich unbedingt tiefer gehend mit Ettercap beschäftigen, da dieses Tool eines der besten MITM-Tools ist, die Kali Linux mitbringt. Sie können es nicht nur als Komplettpaket nutzen, sondern auch in Kombination mit anderen Tools. So ist es z.B. möglich, über andere Tools (z.B. arpspoof) die MITM-Position zu erwirken und Ettercap für den eigentlichen Angriff zu nutzen. Andererseits macht Ettercap auch hier einen guten Job ...

Falls Sie noch weitere Tools dieser Art kennenlernen möchten, lohnt sich ein Blick auf Bettercap (www.bettercap.org). Es verfolgt weitgehend dieselben Zielstellungen wie Ettercap und ist eine interessante Alternative.

17.7   Schutz vor Lauschangriffen & MITM

Sie haben es sicher schon bemerkt: Bei allen obigen Szenarien und eingesetzten Tools ging es mit ganz wenigen Ausnahmen um Klartext-Protokolle und -Kommunikation. Damit sind wir bereits bei der wichtigsten Schutzmaßnahme gegen die in diesem Kapitel vorgestellten Angriffe: kryptografische Absicherung der Kommunikation. Denken Sie an das, was wir Ihnen in Kapitel 5 hinsichtlich der Kryptografie bereits vorgestellt haben:

Klartext-Kommunikation sollte in der heutigen Zeit so weit wie möglich vermieden werden. Es gibt für fast alle Protokolle und Kommunikationsformen auch verschlüsselte bzw. kryptografisch gesicherte Varianten. Der Aufbau der entsprechenden Infrastruktur mag zunächst aufwendig erscheinen, lohnt sich aber langfristig auf jeden Fall. Nutzen Sie möglichst aktuelle Algorithmen, um die Angriffsfläche zu minimieren.

Darüber hinaus gibt es diverse weitere Möglichkeiten, Schutzmaßnahmen zu implementieren. Die meisten Szenarien verlangen bestimmte Voraussetzungen, die Mallory zunächst erfüllen muss, um in eine Angriffsposition zu gelangen. Daher sollten Schutzmaßnahmen bereits an Stellen ansetzen, die grundsätzliche Schutzfunktionen bieten, also zum Beispiel:

Diese unvollständige (!) Liste zeigt, in welche Richtung Sie denken sollten, um zu verhindern, dass Mallory die Voraussetzungen für einen Lausch- oder MITM-Angriff erhält.

Auf technischer Ebene lassen sich – je nach Komponente und Funktionalität – ebenfalls diverse Sicherheitsmechanismen implementieren. Besondere Aufmerksamkeit sollte hier auf den Switch gelegt werden, da dieser die Endgeräte anschließt und damit auch in vielen Lausch- und MITM-Szenarien den Zugang für Mallory darstellt.

Je nach Produkt können Sie u.a. folgende Maßnahmen treffen:

Weitere mögliche Maßnahmen umfassen Network-Access-Control-Systeme (NAC) und ähnliche Technologien wie IEEE-802.1X-Zugangskontrolle. Eine relativ einfach zu implementierende Lösung ist z.B. ein Monitoring-System, das unbekannte MAC-Adressen sperrt, sozusagen als unternehmensweite Port-Security-Lösung.

Um DNS-Cache-Poisoning und DNS-Spoofing zu verhindern, bietet sich der Einsatz von DNSSEC an. Damit werden DNS-Antworten digital signiert und über Prüfsummen vor Manipulation geschützt. DNSSEC erfordert jedoch DNSSEC-fähige Komponenten, die nicht in allen Umgebungen verfügbar sind. Ein weiterer Ansatz zum Schutz vor DNS-Angriffen ist DNS over TLS. Hierbei wird die Kommunikation durch Verschlüsselung gesichert.

17.8   Zusammenfassung und Prüfungstipps

Werfen wir wieder einen Blick zurück: Was haben Sie gelernt, wo stehen Sie und wie geht es weiter?

17.8.1   Zusammenfassung und Weiterführendes

In diesem Kapitel haben Sie zum einen gelernt, wie Man-in-the-Middle-Angriffe durchgeführt werden können. Dabei haben Sie erfahren, dass es eine ganze Reihe von Möglichkeiten für Mallory gibt, in die passende Position zu gelangen.

Zum anderen haben wir uns mit der praktischen Umsetzung von Lauschangriffen beschäftigt. Auch wenn ein Lauschangriff nicht in jedem Fall einen MITM-Angriff erfordert, so werden diese beiden Techniken doch oftmals miteinander kombiniert, sprich: Im Rahmen eines MITM-Angriffs wird ein Lauschangriff (engl. Eavesdropping bzw. Wiretapping) durchgeführt. Ein MITM-Angriff geht dagegen weiter und zielt häufig darauf ab, Daten zu manipulieren und das Opfer dazu zu verleiten, auf gefakte Webseiten oder andere Dienste zu gehen, um dort vertrauliche Daten preiszugeben.

Die praktische Umsetzung derartiger Angriffe haben Sie anhand diverser Beispiele mit der Dsniff-Suite sowie mit Ettercap erfahren. Sie haben gesehen, wie einfach ARP-Spoofing funktioniert und dazu führt, dass die Kommunikationspartner Alice und Bob, ohne es zu wissen, mit Mallory kommunizieren. Dieser kann dann bestimmte Pakete abfangen und mit gefälschter Absenderadresse beantworten. So geschehen beim DNS-Spoofing, mit dem wir dafür sorgen konnten, dass das Opfer auf eine falsche Webseite gelockt wurde.

Neben der Dsniff-Toolsammlung und Ettercap gibt es noch zahlreiche weitere Tools, mit denen Lauschangriffe und MITM-Angriffe durchgeführt werden können. Hierzu zählen netsniff-ng und ngrep. Auch wenn wir an dieser Stelle erst einmal am Ende dieses Kapitels angelangt sind, ist dies noch lange nicht das Ende der Fahnenstange. Sowohl im Rahmen des WLAN-Hackings als auch beim großen Thema Web-Angriffe werden wir darauf zurückkommen und Ihnen z.B. Tools wie Aircrack-ng und die Burp-Suite vorstellen.

Das nächste Kapitel beschäftigt sich mit einem Aspekt, der artverwandt ist mit Sniffing- und MITM-Angriffen. Es geht um Session Hijacking. Dabei »entführen« wir eine bereits etablierte Sitzung zwischen zwei Systemen bzw. Anwendungen. Die Voraussetzung dafür ist in der Regel Sniffing bzw. eine MITM-Position.

17.8.2   CEH-Prüfungstipps

Neben den gängigen Tools für Sniffing und MITM, wie z.B. Wireshark, tcpdump, die Dsniff-Tools oder Ettercap, sollten Sie insbesondere auch die Konzepte hinter MAC-Flooding, ARP-Spoofing, DNS-Spoofing & Co. verstanden haben. Stellen Sie sicher, dass Sie die wichtigsten Mechanismen kennen, die zu einer Umleitung des Netzwerk-Traffics führen.

Darüber hinaus ist es wesentlich, auch die wichtigsten Verteidigungsmaßnahmen gegen die in diesem Kapitel vorgestellten Angriffe zu kennen, wobei der effektivste Schutz durch kryptografische Absicherung erreicht wird. Aber auch andere Mechanismen wie ARP-Inspection, DHCP-Snooping, Port-Security, IEEE-802.1X-Zugangssicherheit usw. sind wichtige Technologien, deren Funktionsweise und Wirkung Sie kennen sollten.

17.8.3   Fragen zur CEH-Prüfungsvorbereitung

Mit den nachfolgenden Fragen können Sie Ihr Wissen überprüfen. Die Fragestellungen sind teilweise ähnlich zum CEH-Examen und können daher gut zur ergänzenden Vorbereitung auf das Examen genutzt werden. Die Lösungen zu den Fragen finden Sie in Anhang A.

  1. Karl hat sich am DSLAM am Verteiler angeschlossen und lauscht einem Telefonat seines Opfers mit einer dritten Person, das über den Verteiler übertragen wird. Wie wird dieser Angriff genannt?

    1. Wiretapping

    2. Sniffing

    3. Eavesdropping

    4. Flooding

  2. Donna versucht, eine Kommunikation an einem Switch mitzuschneiden. Sie kann hierzu keinen Mirror-Port einrichten und hofft darauf, den Failopen-Mode des Switches ausnutzen zu können. Mit welcher Technik wird sie den Angriff durchführen?

    1. SYN-Flooding

    2. ARP-Spoofing

    3. MITM

    4. tcpdump

    5. MAC-Flooding

  3. Angus ist ein Black Hat Hacker, der einen MITM-Angriff durchführen möchte. Sein Ziel ist es, den Browser auf dem Opfer-System beim Aufruf einer bestimmten Webseite auf einen von ihm kontrollierten Webserver umzuleiten. Welche der nachfolgend genannten Varianten eignet sich hierzu nicht in erster Linie?

    1. ARP-Spoofing

    2. ICMP Redirect

    3. Manipulation der hosts-Datei

    4. Dsniff einsetzen

    5. DNS-Spoofing

  4. Welche der im Folgenden genannten Technologien wird im Rahmen eines Man-in-the-Middle-Angriffs eingesetzt?

    1. Nmap-Scan

    2. ARP-Spoofing

    3. Verwenden kryptografischer Protokolle

    4. DHCP-Snooping

  5. Mit welchem technischen Ansatz stellen Provider autorisierten Institutionen Möglichkeiten für das Mithören von Netzwerk-Kommunikation jeglicher Art zur Verfügung?

    1. MITM mittels ARP-Spoofing

    2. MAC-Flooding

    3. Mirror-Port

    4. WLAN-Sniffing

    5. Eavesdropping