Phishing 2.0

Beim klassischen Phishing versuchen Cyber-Kriminelle statische Zugangsdaten zu stehlen, mit denen sie dann Dienste im Namen des bestohlenen Opfers nutzen können. Statisch sind diese Zugangsdaten deshalb, weil sie immer wieder genutzt werden können (bis das Passwort geändert wird). Gelingt dem  Angreifer dies, kann er diese also jederzeit nutzen, ohne dass der legitime Eigentümer das bemerken muss.

Mit einem dynamischen Teil, einem 2. Faktor (SMS, Authenticator App, OTP), funktioniert das nicht mehr. Bei jedem Anmeldeversuch muss zusätzlich der 2. Faktor verwendet werden und dieser ändert sich dynamisch. Zudem ist der zweite Faktor so ausgelegt, dass er nicht kopiert werden kann. Typischerweise basiert er heute auf einem Smartphone (SMS oder App). Benutzername und Passwort sind also für den Angreifer ohne den 2. Faktor wertlos.

Man in the Middle

Im Normalfall verbindet sich der Nutzer einer Web-Applikation über seinen Browser mit dem Server, auf dem der gewünschte Dienst angeboten wird (z.B. www.shop.com). Im ersten Schritt wird die Seite vom Server geladen und im Browser angezeigt. Der Nutzer gibt dann seinen Benutzernamen und sein Passwort ein. Der Server bearbeitet die Anmeldung und fordert den zweiten Faktor an, in dem er z.B. einen Code per SMS an das Smartphone des Nutzers schickt. Dieser gibt dann den Code im Browser ein, der ihn zum Server übermittelt. Ist die Authentifizierung erfolgreich, schickt der Server ein sogenanntes Security Token zum Browser (in Form eines Cookies). Dieses Security Token wird danach bei jedem weiteren Schritt vom Browser zum Server übermittelt, wodurch der Server den Nutzer wiedererkennt und weiss, dass dieser angemeldet ist. Die Kommunikation zwischen Server und Browser ist verschlüsselt (https) und daher von Dritten nicht abzuhören. Der Vorgang ist im oberen Teil der Abbildung dargestellt.

Beim Man in the Middle (MitM) Angriff schaltet sich der Hacker zwischen den Server, den das Opfer eigentlich nutzen möchte und dessen Browser. Der Server des Hackers (rot) gibt gegenüber dem Opfer vor, der Dienstanbieter zu sein. Gegenüber dem effektiven Dienstanbieter gibt er sich als Browser des Opfers aus. Wenn das Opfer jetzt den Service nutzen möchte, versucht er beim Server des Hackers die gewünschte Seite zu laden. Dieser holt die sich die Seite beim richtigen Server und leitet sie an den Browser des Opfers weiter. Danach geht es mit der Anmeldung weiter wie oben beschrieben, der Server des Hackers gibt die Daten einfach weiter. Wenn die Anmeldung erfolgreich war, wird wiederum das Security Token zurückgegeben. Dieses wird jetzt jedoch nicht vom Hacker an das Opfer weitergegeben. Vielmehr wird ihm eine Fehlermeldung angezeigt, dass etwas schief gelaufen ist und man es doch bitte später nochmals versuchen soll. Der Hacker hat nun aber das Security Token und kann damit im Namen des Opfers den Dienst nutzen. Dieser Ablauf ist im unteren Teil der Abbildung aufgezeigt.

Vermeintlich sichere Verbindung

Wie kann der Hacker das Security Token auslesen, wenn die Verbindung zwischen Browser und Server doch verschlüsselt ist?

Der Browser prüft, ob die Verbindung mit Hilfe eines von einer vertrauenswürdigen Stelle (CA) ausgestellten Zertifikates gesichert ist. Beim MitM Angriff gibt es zwei getrennte Verbindungen, eine vom Browser zum Server des Hackers und eine vom Server des Hackers zum richtigen Server. Da beide Verbindungen auf dem Server des Hackers terminieren, werden die übertragenen Daten dort zuerst entschlüsselt und danach wieder verschlüsselt.

Die Herausforderung des Hackers besteht nun darin, dem Opfer eine falsche URL für den Zugriff auf den gewünschten Service ‘unterzujubeln’. Im vorliegenden Fall www.shop.net statt www.shop.com. Für die falsche URL kann er sich einfach ein gültiges Zertifikat besorgen. Mit einem Phishing-Mail lockt er dann das Opfer auf seinen Server. Greift das Opfer auf diese Seite zu, wird ihm trotzdem die Originalseite angezeigt und der Browser weist die Verbindung als sicher aus. Das zu erkennen, ist für das Opfer sehr schwierig.

Bewertung

Die Vorstellung mit einer starken Authentifizierung (2FA, MFA) die Sicherheitsprobleme von Web-Applikationen nachhaltig lösen zu können ist leider illusorisch. Die Angreifer werden sich darauf einstellen, dass immer mehr Konten mit MFA geschützt sind und sie mit dem Diebstahl von statischen Anmeldedaten nicht mehr erfolgreich sind. Man in the Middle Angriffe sind relativ einfach umzusetzen, es gibt auch Frameworks, mit denen das auch technisch wenig versierten Hacker möglich ist.

Durch die vorschreitende Digitalisierung werden immer mehr Vorgänge im täglichen Leben über solche Web-Applikationen abgewickelt. Starke Authentifizierungsmittel kommen dabei zum Einsatz, aber sie bieten keinen wirklichen Schutz, wie wir hier aufgezeigt haben. Das gilt leider für alle Authentifizierungsmittel, die auf mobilen Geräten basieren. Wenn man an Anwendungen wie elektronisches Gesundheitsdossier, eVoting oder digitale rechtsverbindliche Signaturen denkt, muss dringend diskutiert werden, wie diese wirklich sicher genutzt werden könnten.

Technischer Hintergrund

Das Hauptproblem liegt hier in der Tatsache, dass es keine feste (physische oder logische) Verbindung zwischen dem Browser auf einem PC und dem Authentifizierungsmittel auf dem Smartphone gibt. Es gibt zwar sichere Kanäle zwischen dem Server und dem Browser und zwischen dem Server und dem für die Authentifizierung genutzten mobilen Gerät. Für den Server ist aber nicht erkennbar, ob die beiden sicheren Verbindungen beide bei der gleichen Person enden oder ob sich irgendwo ein Angreifer dazwischengeschaltet hat.

Betroffen sind alle Lösungen, bei denen das Authentifizierungsmittel nicht physisch oder logisch mit dem Endsystem verbunden ist, also z.B. auch VPN Lösungen, die ein externes Authentifizierungsmittel verwenden.

Gegenmassnahmen

Eine sehr gute Sicherheit würde man erreichen, wenn Browser und Authentifizierungsmittel denselben sicheren Kanal zum Server nutzen würden. Dies liesse sich mit Smartcards oder anderen physischen Authentifizierungsmitteln, die direkt am Computer mit dem Browser angeschlossen sind, realisieren. Da solche Lösungen komplex sind und sich in der Praxis als nicht massentauglich erwiesen haben, wurden Alternativen entwickelt, die auf den heute sehr weit verbreiteten mobilen Geräten basieren.

Reine Apps, die auf mobilen Geräten laufen, sind ebenfalls auf einem hohen Sicherheitslevel, wenn der Zugriff auf das Gerät entsprechend gesichert ist. Allerdings ist da der Bedienungskomfort geringer als mit dem Browser auf einem grossen Bildschirm.

Beim Onlinebanking wird das Problem der unsicheren Authentifizierung kompensiert, indem Transaktionen auf einem zweiten Kanal bestätigt werden müssen. Ein Angreifer könnte dadurch zwar das Onlinebanking übernehmen, könnte aber keine Transaktionen ausführen, da diese durch das Opfer bestätigt werden müssten. Solche Massnahmen müssten daher bei kritischen Operationen wie elektronisch Abstimmen oder dem Leisten von digitalen Unterschriften ebenfalls implementiert werden. Wichtig dabei ist, dass der Nutzer vor der Bestätigung einer Operation die Details (Kontonummer, Betrag, zu signierendes Dokument, …) nochmals überprüfen muss.

Zusammenfassung

Starke Authentifizierung bietet leider nicht die oft versprochene hohe Sicherheit. Es besteht die Gefahr, dass immer mehr Dienste des täglichen Lebens digitalisiert werden und dabei die Sicherheit auf der Strecke bleibt. Initiativen, die ein einziges Authentifizierungsmittel für alle Services auf Basis von Smartphones propagieren (Apple, Google, Microsoft, eID, Swiss-ID, …), sollten die Man in the Middle Problematik beachten und entsprechende kompensierende Massnahmen ergreifen. Dabei wird auch weiterhin die human firewall eine zentrale Rolle spielen müssen.

Über den Autor

Thomas Gusset

Thomas Gusset hat über 25 Jahre Erfahrung in Netzwerksicherheit und ist CEO & CTO der NetSec.co AG