Wie Angreifer die moderne Zwei-Faktor-Authentifizierung umgehen und wie Sie Ihre Benutzer schützen

In diesem Artikel werfen wir einen Blick auf Tools und Techniken als Beispiel dafür, wie Angreifer die meisten herkömmlichen Zwei-Faktor-Authentifizierungsmethoden (2FA) umgehen können, von SMS-OTP bis hin zu verschlüsselten Push-Benachrichtigungen an eine mobile App. Nicht ausschließlich durch “Brute-Force”-Angriffe können die heutzutage eingesetzten 2FA-Methoden, einschließlich der Out-of-Band-Authentifizierung, leider oft erfolgreich umgangen werden. Wir werden auch erörtern, welche Art von Gegenmaßnahmen Banken ergreifen können, um das Risiko solcher Angriffe zu mindern und ihre Kunden vor Hackern und Cyberkriminellen zu schützen, die Kontoübernahmebetrug begehen, sensible Informationen stehlen oder Ransomware- oder Person-in-the-Middle-Angriffe (auch bekannt als Man-in-the-Middle oder MITM) durchführen.

Was ist die Zwei-Faktor-Authentifizierung genau?

Die 2FA ist mehr als eine zusätzliche Sicherheitsebene: Für die Authentifizierung beim Zugriff auf ein Online-Konto werden zwei Faktoren abgefragt, im Gegensatz zur Multifaktor-Authentifizierung, bei der zwei oder mehr Faktoren zur Authentifizierung herangezogen werden. Zu den genutzten Authentifizierungsfaktoren gehört etwas, das sie haben (z. B. ein sechsstelliger einmaliger Passcode), etwas, das Sie wissen (z. B. das Kennwort der Benutzer, ihre Anmeldedaten oder Sicherheitsfragen), oder etwas, das Sie sind (z. B. biometrische Daten). Bei der typischen 2-Faktor-Verifizierung geben Benutzer zuerst ihre Anmeldedaten ein. Daraufhin sendet die Webanwendung, die mobile App oder das Tool einen Verifizierungscode oder Sicherheitsschlüssel per Textnachricht an die Telefonnummer der Benutzer. Diese geben den 2FA-Code auf der Anmeldeseite ein und erhalten damit Zugriff auf das Benutzerkonto oder führen eine Wiederherstellung eines Kontos oder ein Zurücksetzen ihres Passworts aus. Alternativ können diese Zwei-Faktor-Verifizierungscodes, Sicherheitscodes und Wiederherstellungscodes auch über eine Authentifizierungs-App, ein Authentifizierungs-Token oder ein anderes Authentifizierungssystem übermittelt werden.

Wie Einmalkennwörter umgangen werden: Vorbereitung eines Angriffs

Um diesen Angriff auszuführen, kombinieren wir zwei Tools, nämlich Muraena und Necrobrowser. Muraena ist ein sogenannter transparenter Reverse Proxy, der unsere Phishing-Website betreibt. Die Phishing-Seite ersetzt die ursprüngliche Website, mit der das Opfer interagiert. Sobald das Opfer die Sitzung authentifiziert hat, leitet Muraena die Sitzung an Necrobrowser weiter, wodurch der Angreifer die Kontrolle über die Sitzung übernimmt oder die nächsten Schritte des Angriffs automatisieren kann. Da Muraena als Reverse Proxy fungiert, gibt es außer der URL keinen Unterschied zwischen unserer schädlichen Website und der ursprünglichen Website. Muraena kann mit SSL und legitimen Zertifikaten konfiguriert werden, beispielsweise über LetsEncrypt. Aus der Sicht des Opfers erscheint der gesamte Vorgang legitim, da alles so aussieht, als würde man mit der echten Website interagieren. Sogar der reguläre Authentifizierungsprozess, einschließlich des 2FA-Vorgangs, wird durchlaufen. Wenn die 2FA aus einem regulären Einmalkennwort besteht, das per SMS, Hardware- oder Software-Token übermittelt wird, gibt das Opfer dieses Kennwort wie gewohnt ein. Selbst moderne Methoden wie eine Push-Benachrichtigung an ein mobiles Gerät oder das Scannen eines QR-Codes auf dem Bildschirm können bei einer solchen Attacke umgangen werden. 

1. Der Benutzer besucht die Phishing-Seite, auf der SSL aktiviert ist.
2. Der Reverse Proxy (Muraena) stellt dem Opfer die legitime Bankseite als Kopie zur Verfügung.
3. Das Opfer des Cyberbetrugs versucht, sich auf der Seite anzumelden und wird zur Zwei-Faktor-Authentifizierung aufgefordert.
4. Nachdem das Opfer den Authentifizierungsprozess abgeschlossen hat, leitet der Reverse Proxy (Muraena) die Sitzung an den Angreifer (Necrobrowser) weiter, der dann die Kontrolle übernimmt.

Im Bild unten sehen Sie Muraena beim Hosten von Google auf der Domain phish.anti. Zu Demonstrationszwecken habe ich ein lokales DNS eingerichtet, das in meine Testcomputer-IP aufgelöst wird, und Zertifikate mit meiner eigenen Zertifizierungsstelle ausgestellt, der der Browser vertraut. Genau so würde es aus Sicht des Opfers aussehen, wenn dies mit gültigen Zertifikaten auf Ihrer eigenen Domain erfolgen würde.

Schutz vor Angriffen: Cybersicherheit

Nachdem wir nun verstanden haben, wie ein Angriff funktioniert, können wir ermitteln, welche Cybersicherheitsstrategien und Mechanismen zur Erkennung und dem Schutz vor dieser Art von Angriffen wirksam sind.

Die dynamische Verlinkung bietet eine gute erste Verteidigungsschicht gegen eine Vielzahl von Angriffen. Die dynamische Verlinkung besteht aus einer Zwei-Faktor-Authentifizierung zum Zeitpunkt der Transaktion, bei der die Details der Transaktion in den Signaturprozess eingebunden werden. Dies wird oft als „What you see is what you sign“ (WYSIWYS) bezeichnet, da dem Endbenutzer die Transaktionsdetails angezeigt werden, bevor der Signaturprozess abgeschlossen wird. Die Signatur sollte nur für diese bestimmte Transaktion, jedoch für keine Folgetransaktionen gültig sein, was das Umgehen von Sicherheitsvorkehrungen für den Angreifer schwieriger macht. Typischerweise wird die dynamische Verlinkung über Hardware-Token, Software-Token oder als Teil einer Banking-App integriert. Im Folgenden finden Sie zwei Beispiele für dynamische Verlinkungen: die erste beschreibt eine legitime Zahlung und die zweite beschreibt einen Angriff, bei dem versucht wird, die Zahlungsdetails zu ändern.

1. Der Benutzer erstellt eine Transaktion mittels Online-Banking.
2. Der Benutzer übermittelt die Transaktion.
3. Die Bank sendet die Transaktionsdetails an das Mobiltelefon des Benutzers.
4. Der Benutzer überprüft die Details der Überweisung und autorisiert die Zahlung mit einem biometrischen (oder einem anderen zweiten) Faktor.
5. Die mobile App generiert ein Einmalkennwort unter Verwendung der Transaktionsdetails und des Token-Schlüssels in der mobilen App.

1. Der Benutzer versucht, eine Zahlung im Online-Banking-System zu erstellen.
2. Der Angreifer ändert die Zahlungsdetails auf ein neues Empfängerkonto bzw. einen neuen Betrag.
3. Die Bank sendet die Transaktionsdetails an das Mobiltelefon des Benutzers.
4. Dem Benutzer werden die geänderten Zahlungsinformationen angezeigt und er lehnt die Zahlung ab.

Die obigen Beispiele veranschaulichen auch die Bedeutung der Verwendung der End-to-End-Verschlüsselung bei der Implementierung dynamischer Verlinkungen. Darüber hinaus wird deutlich, dass die mobile App selbst geschützt werden sollte, da der Angreifer möglicherweise versucht, die App anzugreifen, um die geänderten Zahlungsdetails vor dem Benutzer zu verbergen.

Ein weiterer wirksamer Weg, um eine Vielzahl von Angriffen zu erkennen und zu verhindern, ist die kontinuierliche Überwachung Ihrer digitalen Plattformen insgesamt. Durch Überwachen der Sitzung vom Anfang bis zum Ende können wir, basierend auf den Handlungen eines Benutzers und den verknüpften Geräten oder Konten, mehr Kontext einbeziehen. Die kontinuierliche Überwachung unter Berücksichtigung des gesamten Kontexts der eingesetzten Authentifizierungsgeräte lässt sich perfekt mit anderen Ebenen wie 2FA oder dynamischer Verlinkung kombinieren.

Die Bank kann nach typischen Indikatoren für bislang bekannte Angriffe suchen, also nach unbekannten Geräten, Standorten, der Anwesenheit von Proxys oder anderen Anzeichen. Diese Informationen können über die gesamte Benutzerbasis hinweg korreliert werden, um das Risiko dieser Elemente besser zu verstehen. Wir können dann auch die Vorgänge berücksichtigen, die der Benutzer während seiner gesamten Sitzung selbst ausführt, und dies mit seinem üblichen Verhalten vergleichen. Dieser Ansatz erstellt ein kontinuierliches Risikoprofil für Sitzungen, wobei zu beachten ist, dass sich dieses Risikoprofil mit jeder vom Endbenutzer gesetzten Handlung ändern kann. Auf diese Weise kann die Bank nicht nur automatisierte Aktionen in Echtzeit ausführen, sobald Anomalien festgestellt werden, sondern auch insgesamt das Benutzererlebnis reibungsloser gestalten, indem die Anzahl der für legitime Vorgänge erforderlichen Authentifizierungen verringert wird.

Fazit

Während die in diesem Artikel beschriebenen Attacken Technologien und Konzepte nutzen, die es schon seit Ewigkeiten gibt, sehen wir, dass eine korrekte Umsetzung dieser Angriffe durch Cyberkriminelle nach wie vor zu großem Erfolg führen und verschiedene heute eingesetzte Authentifizierungsmethoden zunichte machen kann. Für Banken ist es wichtig, einen mehrschichtigen Ansatz zu verwenden, da die meisten einzelnen Schichten weiterhin angegriffen oder komprimittiert werden können. Bei der Implementierung dynamischer Verlinkungen ist eine gesicherte Kommunikationslinie zwischen der Bank und dem Endbenutzer unerlässlich. Die Verifizierung durch SMS-Nachrichten hat sich beispielsweise als unzuverlässig erwiesen, da die Nachrichten vom Angreifer entwendet, gefälscht oder abgefangen werden können. Auch im Zusammenhang mit der Einführung mobiler Apps sollten Banken berücksichtigen, dass diese Apps ein Angriffsziel sind, die vor externen Angriffen geschützt werden müssen. Das Hauptziel dieses Artikels ist es, zu demonstrieren, dass Phishing-Angriffe sich ständig weiterentwickeln und auch eine Zwei-Faktor-Authentifizierung bei der Anmeldung gegebenenfalls umgangen werden kann. Die Implementierung von 2FA allein bietet also keinen vollständigen Schutz vor Phishing mehr. Schließlich haben wir einige Authentifizierungsebenen vorgestellt, die von Banken implementiert werden können, um ihre Endbenutzer besser zu schützen, und beschrieben, welche potenziellen Fallstricke dabei zu vermeiden sind. Kurz zusammengefasst:

• Implementieren Sie eine dynamische Verlinkung mit End-to-End-Verschlüsselung.
• Setzen Sie serverseitige Analysen ein, um Endbenutzer-Sitzungen, Geräte und Benutzerverhalten auf potenzielle Angriffe hin zu überwachen.
• Schützen Sie Ihre mobilen Apps vor Schadsoftware und anderen externen Bedrohungen.