Man-in-the-Middle-Angriff (MitM)

Ein Man-in-the-Middle-Angriff (MitM) liegt vor, wenn ein Angreifer die Kommunikation zwischen zwei Parteien (z.B. Browser und Webserver) abfängt, ohne dass eine der Parteien davon weiß. Der Angreifer kann nicht nur mitlesen, sondern auch Nachrichten manipulieren.

Wie ein MitM-Angriff funktioniert

• Ohne MitM: Alice kommuniziert direkt mit Bob.
• Mit MitM: Alice ↔ [Angreifer Eve] ↔ Bob - Alice denkt, sie spricht mit Bob; Bob denkt, er spricht mit Alice; Eve liest und/oder verändert alles.

Das Grundproblem: Für Alice und Bob sieht die Verbindung normal aus - wenn keine kryptographische Authentifizierung die Identität der Gegenseite beweist.

MitM-Angriffsvarianten

ARP Spoofing / ARP Poisoning

Im lokalen Netzwerk (LAN) werden gefälschte ARP-Antworten gesendet, die die MAC-Adresse des Angreifers mit der IP-Adresse des Routers/Gateways verknüpfen. Alle Pakete fließen nun durch den Angreifer.

Typisch in: Unsichere WLAN-Netzwerke (Café, Hotel, Konferenz)

HTTPS Downgrade / SSL Stripping

Der Angreifer empfängt HTTPS-Verbindungen vom Server, leitet sie aber als HTTP an das Opfer weiter. Das Opfer kommuniziert unverschlüsselt - der Angreifer sieht alles im Klartext.

Gegenmaßnahme: HSTS (HTTP Strict Transport Security) - Browser verweigerungn automatisch HTTP, wenn HSTS-Header bekannt.

DNS Spoofing / DNS Cache Poisoning

Gefälschte DNS-Antworten leiten DNS-Anfragen auf IP-Adressen des Angreifers um:

• bank.de → IP des Angreifers statt echter Bank-IP
• Opfer landet auf täuschend echter Phishing-Seite

Gegenmaßnahme: DNSSEC, DNS over HTTPS (DoH)

Rogue Access Point / Evil Twin

Ein Angreifer erstellt ein gefälschtes WLAN mit gleichem Namen wie ein legitimes Netzwerk (z.B. “Airport_Free_WiFi”). Geräte verbinden sich automatisch - der Angreifer kontrolliert den gesamten Traffic.

Gegenmaßnahme: VPN immer in öffentlichen WLANs, WLAN-Verbindungsrichtlinien für Unternehmensgeräte.

BGP Hijacking

Auf Netzwerkebene: Falsche BGP-Routen werden annonciert, sodass Traffic über Netzwerke des Angreifers geroutet wird. Staatliche Akteure und große ISPs können dies ausführen. Bekannte Vorfälle: Russland (2017), Iran (2010).

AiTM-Phishing (Adversary-in-the-Middle)

Moderne Phishing-Kits (Evilginx2) agieren als Reverse Proxy: Angreifer sitzt zwischen Opfer und echter Website, leitet Credentials und MFA-Codes in Echtzeit weiter und stiehlt den Session-Cookie.

Dieser Angriff umgeht TOTP-MFA vollständig.

Warum TLS/HTTPS Schutz bietet (und warum nicht immer)

TLS schützt gegen klassische MitM:

• Server-Zertifikat wird von vertrauenswürdiger CA signiert
• Browser prüft Zertifikat: Stimmt es mit der Domain überein? Ist es von einer bekannten CA?
• Zertifikat kann nicht gefälscht werden ohne den Private Key der CA

TLS schützt NICHT, wenn:

• Ein gefälschtes Zertifikat von einer kompromittierten CA ausgestellt wurde
• Das Opfer eine Zertifikats-Warnung ignoriert (“Verbindung trotzdem fortsetzen”)
• In Corporate-Proxys, die SSL-Inspection betreiben (legitimes MitM im Unternehmenskontext)
• Gegen AiTM-Phishing (Opfer kommuniziert legitim mit echtem Server - aber Angreifer ist Proxy)

Schutzmaßnahmen

Für Unternehmen:

• TLS 1.3 überall durchsetzen (TLS 1.0/1.1 deaktivieren)
• HSTS mit includeSubDomains und preload aktivieren
• HPKP war Versuch für Certificate Pinning (veraltet, zu fehleranfällig)
• Certificate Transparency Monitoring
• VPN für externe Verbindungen von Unternehmensgeräten
• DNSSEC und DNS-Monitoring

Für Mitarbeitende:

• Niemals Zertifikats-Warnungen ignorieren
• Öffentliche WLANs nur mit VPN nutzen
• HTTPS-Verbindung und Domain-Namen immer prüfen

Phishing-resistente MFA (FIDO2): Einziger zuverlässiger Schutz gegen AiTM-Phishing - da der Schlüssel domain-gebunden ist und auf Fake-Seiten nicht funktioniert.