Schutz vor Kontoübernahmen: Warum MFA nur ein erster Schritt ist

Einleitung

Die Multi-Faktor-Authentifizierung (MFA) beseitigt nicht die Gefahr einer Kontoübernahme. Sie schafft zwar zusätzliche Hürden, doch entschlossene Angreifer haben raffinierte Wege gefunden, sämtliche verfügbaren Authentifizierungsfaktoren zu umgehen. Statt MFA als Lösung für die Authentifizierung zu betrachten, sollten wir sie als Erweiterung der Angriffsfläche verstehen: Jeder Faktor bringt ein neues System von Abhängigkeiten, neue Fehler- und Schwachstellenquellen sowie neue Möglichkeiten für Social Engineering mit sich. Leider betrachten viele Sicherheitsorganisationen MFA ähnlich wie früher den Netzwerkperimeter: als Bollwerk gegen eine Vielzahl von Angriffen. Der Trugschluss eines sicheren Perimeters, den die Befürworter von Zero-Trust-Sicherheit aufgedeckt haben, ermöglichte es Angreifern, Schwachstellen innerhalb von Netzwerken auszunutzen, sich lateral auszubreiten und ihre Berechtigungen auszuweiten. Ebenso hindert der Irrglaube, MFA verhindere Kontoübernahmen, Sicherheitsorganisationen daran, die Schwächen von MFA und die zahlreichen verbleibenden Systemschwachstellen zu erkennen, durch die Benutzerkonten von Kriminellen übernommen werden können. Anhand der Methoden, mit denen Angreifer MFA umgehen, zeigt dieses Whitepaper, dass MFA bestimmte andere Sicherheitsmaßnahmen noch wichtiger macht – insbesondere die Abwehr von Bots, den Schutz der JavaScript-Lieferkette und die Überwachung kontextbezogener Risiken. Diese Verfahren stärken die Sicherheitsvorteile von MFA und verringern zugleich die damit verbundenen Hürden für Benutzer.

Die treibenden Faktoren für MFA

Trotz ihrer Schwächen wird die Multi-Faktor-Authentifizierung (MFA) bleiben – und das aus gutem Grund: Eine ausschließlich passwortbasierte Authentifizierung ist eindeutig gescheitert.

Wir Menschen können uns lange, zufällige Zeichenfolgen schlichtweg nicht merken. Deshalb greifen wir zu Abkürzungen: Wir wählen leicht zu merkende, vorhersehbare Passwörter, verwenden dieselben Passwörter für verschiedene Anwendungen und notieren sie auf Haftzetteln. Unternehmen mindern dieses Risiko zwar, indem sie Anforderungen an die Länge und Komplexität von Passwörtern stellen, doch das menschliche Gedächtnis hat seine Grenzen. Selbst angesichts solcher Komplexitätsanforderungen finden wir Wege, vorhersehbar zu bleiben: Wir schreiben nur den ersten Buchstaben groß, ersetzen alphanumerische Zeichen durch ähnlich aussehende Sonderzeichen ($ statt S) oder hängen leicht zu erratende Ziffern wie 123 an ein Passwort an. (Siehe Forschungsergebnisse zur Vorhersehbarkeit von Passwörtern.)

Wir Menschen haben außerdem Schwächen, die uns anfällig für Social Engineering machen. Wir geben unsere Passwörter preis, wenn Angreifer unser Vertrauen, unseren Wunsch nach Anpassung, unseren Respekt vor Autoritäten und unsere Hilfsbereitschaft ausnutzen. Wie sich herausstellt, geben Menschen manchmal ihre Passwörter preis, wenn man sie einfach danach fragt. Das können Sie in diesem amüsanten Video von Jimmy Kimmel Live selbst sehen.

Angesichts dieser Schwachstellen der passwortbasierten Authentifizierung treiben Regierungsbehörden und Branchenverbände die Einführung von MFA voran. Im Mai 2021 erließ Präsident Biden eine Durchführungsverordnung, die Bundesbehörden dazu verpflichtete, MFA innerhalb von 180 Tagen einzuführen. Zudem fördert die Cybersecurity and Infrastructure Security Agency (CISA) MFA in Privatunternehmen. Der Payment Card Industry Security Standards Council schreibt mit seinem Datensicherheitsstandard v4.0 vor, dass Unternehmen bis zum 31. März 2025 MFA für sämtliche Zugriffe auf Kreditkarteninhaberdaten implementieren.

Da die klaren Vorteile von MFA gegenüber einer reinen Passwortauthentifizierung ihre Verbreitung vorantreiben, müssen Sicherheitsexperten den Nachteilen von MFA zunehmend Aufmerksamkeit schenken – insbesondere der Frage, wie MFA die Angriffsfläche vergrößert und neue Schwachstellen schafft, die es Angreifern ermöglichen, Authentifizierungskontrollen zu umgehen.

Die erweiterte Angriffsfläche durch MFA

MFA ist definiert als die Verwendung von zwei oder mehr Faktoren im Authentifizierungsprozess. Unter einem Faktor verstehen wir eine Möglichkeit, nachzuweisen, dass Sie tatsächlich die Person sind, für die Sie sich ausgeben. Dies kann erfolgen durch:

  • Wissen: etwas, das Sie wissen, wie etwa ein Passwort oder eine persönliche Identifikationsnummer (PIN)
  • Besitz: etwas, das Sie besitzen, z. B. ein Mobilgerät, eine Smartcard, ein Hardware-Token oder einen USB-Stick
  • Inhärenz: etwas, das Sie sind und das anhand biometrischer Merkmale wie Fingerabdrücken, Gesichtsscans und Irismustern bestimmt wird

Es gibt unzählige Möglichkeiten, MFA zu implementieren. Viele davon eröffnen entweder neue Angriffsflächen oder setzen Anwendungen denselben Schwachstellen aus, die für eine reine Passwortauthentifizierung charakteristisch sind.

SMS-basierte MFA

Es gibt unzählige Möglichkeiten, MFA zu implementieren. Viele davon eröffnen entweder neue Angriffsflächen oder setzen Anwendungen denselben Schwachstellen aus, die auch für eine reine Passwortauthentifizierung charakteristisch sind.

Bei der am weitesten verbreiteten Implementierung von MFA wird den Benutzern per SMS ein Einmalpasswort (OTP) gesendet, das grundsätzlich den Besitz eines Smartphones nachweist. In der Regel beginnt ein Benutzer die Anmeldung mit einem Benutzernamen und einem Passwort, woraufhin die App die SMS versendet. Anschließend ruft der Benutzer das OTP ab und gibt es in die App ein. Damit wird die Authentifizierung abgeschlossen und ein Sitzungstoken generiert, das für einen festgelegten Zeitraum gültig ist.

Verbleibende Schwachstellen der SMS-basierten Authentifizierung

Die Implementierung des Besitzfaktors per SMS beseitigt mehrere wesentliche Schwachstellen nicht. Da der Benutzer das Einmalpasswort (OTP) und das Passwort in die Anwendung eingibt und die Anwendung das OTP über denselben Kommunikationskanal, den sie selbst nutzt, an den Server zurücksendet, kann ein Angreifer, der entweder die Anwendung, das Gerät oder das Netzwerk kompromittiert hat, auf das Passwort, das OTP und das Sitzungstoken zugreifen.

Angriff auf den Endpunkt

Mithilfe zahlreicher bewährter und nach wie vor verbreiteter Techniken übernehmen Angreifer Geräte, indem sie diese mit Malware infizieren, was zu einem Man-in-the-Browser-Angriff (MitB) führt. Durch die Ausführung von Code im Browser können Angreifer das Passwort und das Einmalpasswort (OTP) abgreifen und sich damit im Namen des Benutzers authentifizieren. Alternativ kann der Angreifer die Authentifizierung abschließen lassen und anschließend die Sitzungskennung stehlen, mit der sich die Authentifizierung umgehen und auf das Konto eines Benutzers zugreifen lässt. (Informationen zu aktuellen Trends bei Malware, die Endgeräte infiziert, finden Sie im Bericht von F5 Labs über BlackGuard Infostealer.)

Kompromittierung der App

Durch die Infizierung einer Anwendung können Angreifer massenhaft Benutzerkonten übernehmen. Kriminelle können nicht nur die Infrastruktur eines Unternehmens durch Schadsoftware kompromittieren, sondern auch auf Anwendungsdaten zugreifen, indem sie eine der Codebibliotheken kompromittieren, aus denen die Anwendung besteht. Diese Taktik wird als Supply-Chain-Angriff bezeichnet.

Bei einem Angriff auf die Software-Lieferkette nimmt der Angreifer in der Regel einen vertrauenswürdigen Drittanbieter oder ein Open-Source-Repository ins Visier, der bzw. das der angegriffenen Organisation Softwarekomponenten (Bibliotheken, Frameworks, Dienste) bereitstellt. Der Angreifer schleust Schadsoftware in die Komponente ein, die anschließend in die Anwendung integriert wird. Ein solcher Angriff kann erfolgreich sein, da nicht jeder Anbieter und jedes Open-Source-Team über die erforderlichen Kompetenzen und Ressourcen verfügt, um sichere Programmierpraktiken durchzusetzen.

Web- und mobile Anwendungen sind besonders anfällig für Angriffe auf die Lieferkette, da sie in der Regel Dutzende Skripte von Drittanbietern enthalten, von denen viele durch Tag-Manager dynamisch zu Seiten hinzugefügt werden. Diese Skripte, die sich häufig und ohne Vorankündigung ändern, durchlaufen nicht die Sicherheitsprüfungen für den Code eines Unternehmens. Gelingt es einem Angreifer, eines dieser Skripte zu kompromittieren, erlangt er die vollständige Kontrolle über eine Anwendung. Dadurch kann er Benutzereingaben auslesen, auf Daten im Browserspeicher zugreifen oder den Nutzer unbemerkt auf eine schädliche App umleiten.

Diese Supply-Chain-Angriffe wie Magecart haben zu Sicherheitsverletzungen geführt, bei denen Hunderttausende von Zugangsdaten kompromittiert wurden. Ähnlich wie MitB-Angriffe können diese Supply-Chain-Angriffe jede MFA-Lösung umgehen, bei der das Token zum Nachweis des Besitzes in die Anwendung eingegeben wird, was bei den meisten Implementierungen mit Einmalkennwörtern (OTPs) der Fall ist. Da der Schadcode Benutzereingaben ausliest, könnte er sowohl das statische Passwort als auch das OTP sowie alle anderen von der Anwendung erfassten persönlichen oder finanziellen Informationen stehlen.

Abhören des Netzwerks

Da bei der SMS-basierten Authentifizierung das Passwort, das Einmalpasswort (OTP) und das Sitzungstoken über dieselbe Netzwerkverbindung übertragen werden, bleibt diese Form der Multi-Faktor-Authentifizierung anfällig für Man-in-the-Middle-Angriffe (MitM), bei denen typische Angriffsvektoren wie DNS-Poisoning, ARP-Poisoning und nicht autorisierte WLAN-Zugangspunkte zum Einsatz kommen.

Social Engineering

Bei einem der häufigsten und erfolgreichsten Angriffe auf SMS-basierte MFA wird Social Engineering eingesetzt, um mithilfe von Echtzeit-Phishing-Proxys (RTPP) einen MitM-Angriff durchzuführen.

Bei diesem Angriff verleitet der Betrüger einen Benutzer mithilfe von Phishing-E-Mails dazu, eine vom Angreifer kontrollierte Website aufzurufen und dort seine Anmeldedaten einzugeben. Bis zu diesem Punkt entspricht diese Vorgehensweise einem Phishing-Angriff zum Diebstahl von Anmeldedaten. Um jedoch die MFA zu umgehen, ist ein zusätzlicher Schritt erforderlich. Wenn der Benutzer seinen Benutzernamen und sein Passwort in die App eingibt, leitet der Angreifer diese Anmeldedaten an die Zielanwendung weiter, die daraufhin eine Anfrage für den zweiten Faktor an den Benutzer sendet. Der Benutzer wird die Anfrage sehr wahrscheinlich bestätigen, da er davon ausgeht, sich bei einer vertrauenswürdigen Anwendung zu authentifizieren. Er klickt auf die Schaltfläche zum Bestätigen oder gibt den Token wie aufgefordert in die App ein. In beiden Fällen erhält der Angreifer Zugriff auf die Anwendung. (Eine Demonstration des Angriffs finden Sie in diesem Video von Kevin Mitnick.)

Durch Automatisierung und die Neigung der Benutzer, auf Phishing-Betrugsmaschen hereinzufallen, können RTPP-Angriffe in großem Umfang erfolgreich sein. (Weitere Daten zur Zunahme von Echtzeit-Phishing-Proxys finden Sie im F5 Labs Phishing and Fraud Report.)

Neue Schwachstellen bei der SMS-basierten Authentifizierung

Die Verwendung von SMS als zweiten Faktor behebt nicht nur viele der bestehenden Schwachstellen einer reinen Passwortauthentifizierung nicht, sondern setzt eine Anwendung auch zusätzlichen Angriffsvektoren aus.

Diebstahl des physischen Geräts

Der wohl naheliegendste Angriff auf eine besitzbasierte Authentifizierung ist der Diebstahl eines physischen Geräts. Wer ein Smartphone stiehlt, könnte auf ein in einer Benachrichtigung angezeigtes Einmalpasswort zugreifen, selbst wenn das Smartphone gesperrt ist. Viele Opfer von Smartphone-Diebstahl mussten feststellen, dass das Guthaben auf ihren Bankkonten verschwunden war.

SIM-Swapping (Austausch des Teilnehmer-Identitätsmoduls)

Kriminelle müssen nicht im physischen Besitz eines Mobiltelefons sein, um Zugriff auf per SMS gesendete Einmalpasswörter (OTPs) zu erhalten. Durch SIM-Swapping (https://www.darkreading.com/edge/sim-swapping-attacks-what-they-are-how-to-stop-them), auch als SIM-Hijacking oder SIM-Portierung bezeichnet, können Angreifer die SMS-basierte Authentifizierung umgehen, die am häufigsten verwendete Form der Multi-Faktor-Authentifizierung (MFA) in kundenorientierten Apps. Bei einem SIM-Swapping-Angriff nutzt der Betrüger die Möglichkeit von Telekommunikationsanbietern aus, eine Telefonnummer auf ein anderes Gerät zu übertragen – eine Funktion, die bei Verlust oder Diebstahl eines Mobiltelefons hilfreich ist.

Der Betrüger sammelt zunächst durch Online-Recherchen, Phishing oder Social Engineering personenbezogene Daten über das Opfer. Mithilfe dieser Informationen bringt der Angreifer die Telefongesellschaft dazu, die Telefonnummer des Opfers auf die SIM-Karte des Betrügers zu übertragen. Alternativ könnte sich der Angreifer mittels Credential Stuffing, Brute-Force-Angriffen oder Wörterbuchangriffen Zugang zum Benutzerkonto beim Dienstanbieter verschaffen.

Sobald der Betrüger die Kontrolle über den Mobilfunkanschluss des Opfers erlangt hat, erhält er alle für das Opfer bestimmten SMS und Sprachanrufe. Dadurch kann er sämtliche per SMS gesendeten Sicherheitstoken abfangen.

Hardware-Token-Geräte

Hardware-Token sind spezialisierte, meist recht kleine Geräte, die ein Einmalpasswort (OTP) anzeigen, das der Benutzer zur Authentifizierung in eine Anwendung eingibt. Mit diesen Geräten lässt sich der Besitz nachweisen, ohne dass die Anwendung mit dem Benutzer kommunizieren muss. Dadurch entfällt eine der größten Schwachstellen der SMS-basierten Authentifizierung.

Anstatt sich darauf zu verlassen, dass dem Benutzer bei jeder Anmeldung ein OTP gesendet wird, erzeugt das Gerät mithilfe eines anfänglichen Startwerts und eines Algorithmus eine Folge von OTPs. Der Startwert selbst wird bei der Einrichtung zwischen dem Gerät und dem Authentifizierungsdienst ausgetauscht. Der Startwert wird um einen Zähler ergänzt, der entweder bei einem Ereignis, beispielsweise einer Anmeldeanforderung, oder nach Ablauf eines Zeitintervalls, beispielsweise 60 Sekunden, erhöht wird. Diese Verfahren werden als ereignisbasiertes OTP (EOTP) beziehungsweise zeitbasiertes OTP (TOTP) bezeichnet. EOTP und TOTP sind beides Arten von Hash-basierten OTPs (HOTP), da der Zähler und der Startwert gemeinsam an eine Hash-Funktion übergeben werden, die eine scheinbar zufällige Ziffernfolge erzeugt, die bei korrekter Implementierung kein vorhersehbares Muster erkennen lässt.

Da bei Hardware-Token kein Versand des OTP per SMS erforderlich ist, kann das OTP nicht durch Methoden wie SIM-Swapping abgefangen werden, bevor es den Benutzer erreicht. Da der Benutzer das OTP jedoch in die App eingeben muss, die es über denselben Kommunikationskanal wie das Passwort an den Authentifizierungsdienst übermittelt, bleiben die meisten anderen Schwachstellen der SMS-basierten Authentifizierung bestehen. Angreifer können sich Zugriff auf das Passwort und das OTP verschaffen, indem sie das Endgerät, das Netzwerk oder die Anwendung auf dieselbe Weise kompromittieren wie bei per SMS übermittelten OTPs.

Der häufigste Angriff auf die SMS-basierte Authentifizierung, nämlich Echtzeit-Phishing-Proxys, funktioniert bei auf Hardwaregeräten generierten Einmalpasswörtern genauso gut, da der Benutzer dazu verleitet wird, das Einmalpasswort auf der gefälschten Website einzugeben – unabhängig davon, ob es auf einem Smartphone oder einem speziellen Gerät angezeigt wird.

Hardwaregeräte verhindern zwar, dass Angreifer das OTP während der Übertragung an den Benutzer abfangen, sie basieren jedoch auf Startwerten, die kompromittiert werden können. Angreifer können auf den Startwert zugreifen, indem sie sich physischen Zugang zu den Geräten verschaffen (siehe die Erwähnung eines Angriffs mit einem Elektronenmikroskop in „Mehr als 12 Möglichkeiten, MFA zu hacken“), die vom Authentifizierungsdienst verwendete Datenbank kompromittieren oder den Einrichtungsprozess abfangen, bei dem der Startwert zwischen dem Gerät und dem Authentifizierungsdienst vereinbart wird.

Authentifizierungs-Apps

Authentifizierungs-Apps können ähnlich wie Hardware-Token funktionieren, indem sie auf Grundlage eines anfänglichen Startwerts und eines Algorithmus fortlaufend Einmalpasswörter (OTPs) generieren. Dadurch muss der Startwert nicht über einen unsicheren Kanal übertragen werden. Sie können jedoch noch einen Schritt weiter gehen und einen alternativen Kanal zur Übermittlung des OTP nutzen. In diesem Szenario sendet der Authentifizierungsdienst nach erfolgreicher Überprüfung von Benutzername und Passwort eine Push-Benachrichtigung an die Authentifizierungs-App, die den Benutzer auffordert, die Anfrage zu genehmigen. Nach der Genehmigung sendet die Authentifizierungs-App das OTP direkt an den Authentifizierungsdienst, ohne dass der Benutzer es in die Anwendung eingeben muss. Die Kommunikation zwischen der Authentifizierungs-App und dem Authentifizierungsdienst erfolgt über eine separate Verbindung.

Durch die Nutzung eines alternativen Kommunikationskanals kann ein Angreifer nicht auf das OTP zugreifen, indem er die Anwendung kompromittiert, da das OTP niemals in die Anwendung eingegeben wird. Auch ist es schwieriger, sowohl das Passwort als auch das OTP durch eine Kompromittierung der Netzwerkverbindung abzugreifen, da Passwort und OTP über getrennte, gesicherte Kanäle übertragen werden. Wird jedoch das Endgerät kompromittiert, könnte ein Angreifer sowohl auf das Passwort als auch auf das OTP zugreifen, wenn die Anwendung selbst und die Authentifizierungs-App auf demselben Gerät ausgeführt werden. (Siehe den Bericht über Schadsoftware von F5 Labs, die Google Authenticator kompromittiert.)

Leider verhindern Authentifizierungs-Apps nicht den Einsatz von Echtzeit-Phishing-Proxys. Der Benutzer wird weiterhin durch eine Phishing-Textnachricht dazu verleitet, seinen Benutzernamen und sein Passwort auf einer gefälschten Website einzugeben. Nach der Eingabe der Anmeldedaten löst die Anwendung eine Anfrage an die Authentifizierungs-App aus. Da der Benutzer glaubt, sich gerade bei einer vertrauenswürdigen Anwendung anzumelden, wird er die Anfrage wahrscheinlich bestätigen und damit die Authentifizierung abschließen. Obwohl der Angreifer das Einmalpasswort (OTP) nie zu Gesicht bekommt, erlangt sein Proxy nun die Kontrolle über eine authentifizierte Sitzung und damit Zugriff auf das Konto des Benutzers. (Weitere Informationen zu RTPP und zur Authentifizierung per Push-Benachrichtigung finden Sie in diesem Artikel über Phishing-Plattformen auf Hacker News.)

Darüber hinaus hat die einfache Bedienung von Authentifizierungs-Apps eine weitere Möglichkeit geschaffen, wie Angreifer die MFA durch Social Engineering umgehen können. Bei MFA-Bombing oder MFA-Fatigue-Angriffen bringt der Angreifer das Opfer dazu, ihm seinen Authentifizierungscode preiszugeben, indem er zahlreiche betrügerische Anfragen nach dem Code sendet. In der Regel verwendet der Angreifer automatisierte Tools, um eine große Anzahl von Anfragen zu generieren und das Opfer mit übermäßig vielen Benachrichtigungen oder Nachrichten zu überfluten, in denen es zur Eingabe seines Authentifizierungscodes aufgefordert wird.

MFA-Bombing kann Benutzer zwar dazu verleiten, ein Einmalpasswort aus einer SMS oder von einem Hardwaregerät einzugeben, ist jedoch besonders wirksam gegen Authentifizierungs-Apps, da Benutzer die Flut von Anfragen ganz einfach per Knopfdruck stoppen können.

Biometrische Authentifizierung

Für die Implementierung biometrischer Authentifizierung gibt es noch mehr Möglichkeiten als für die besitzbasierte Authentifizierung. Es existieren nicht nur zahlreiche Methoden, um die Authentifizierungsanfrage auszulösen und die entsprechenden Daten an den Authentifizierungsdienst zurückzuübermitteln, sondern auch viele verschiedene biometrische Verfahren – von Fingerabdrücken bis hin zu Iris-Scans. Die für den Scan benötigte Hardware kann in das Gerät integriert sein, auf dem die Anwendung ausgeführt wird, beispielsweise in Form einer Kamera mit Fingerabdrucksensor an einem Laptop, oder separate Hardware erfordern. Das biometrische Lesegerät kann vom Betriebssystem oder von einer speziellen Anwendung gesteuert werden. Angesichts dieser unterschiedlichen Implementierungsvarianten ist es schwierig, jede mögliche Schwachstelle abzubilden. Dennoch muss man sich bewusst machen, dass die biometrische Authentifizierung trotz ihres Rufs, mehr Sicherheit zu bieten, nach wie vor eindeutige Schwachstellen aufweist.

Tatsächlich lässt sich eine der gängigen Methoden zur Umgehung des Besitzfaktors – Echtzeit-Phishing-Proxys – ebenso gut zur Umgehung biometrischer Verfahren einsetzen. Meldet sich der Benutzer bei einer vom Angreifer kontrollierten Anwendung an, weil er sie für eine vertrauenswürdige Anwendung hält, verwendet diese die Anmeldedaten, um sich im Namen des Benutzers bei der eigentlichen Anwendung anzumelden, wodurch die Aufforderung zur biometrischen Authentifizierung ausgelöst wird. Solange der Benutzer glaubt, sich bei der echten Anwendung zu authentifizieren, wird er die biometrische Authentifizierung wahrscheinlich durchführen und dem Angreifer so Zugriff auf das Konto gewähren. (Der FIDO2-Standard WebAuthn, der vom W3C entwickelt wurde, bietet Schutz vor Phishing, wird von Webanwendungen bislang jedoch noch nicht flächendeckend unterstützt.)

Ob die biometrische Authentifizierung durch eine Kompromittierung des Endgeräts, der Anwendung oder des Netzwerks umgangen werden kann, hängt von der jeweiligen Implementierung ab. Wenn das biometrische Authentifizierungssystem auf demselben Gerät wie die Anwendung ausgeführt wird, könnte eine Kompromittierung des Endgeräts die Authentifizierung außer Kraft setzen. Wenn die Anwendung den biometrischen Authentifizierungsprozess verwaltet, könnte eine Kompromittierung der App die Authentifizierung außer Kraft setzen. Und wenn die biometrischen Authentifizierungsdaten über denselben Kommunikationskanal wie die Anwendung übertragen werden, könnte eine Kompromittierung des Netzwerks die Authentifizierung außer Kraft setzen. Kurz gesagt: Die biometrische Authentifizierung erfordert eine detaillierte, auf die jeweilige Implementierung zugeschnittene Bedrohungsmodellierung.

Die biometrische Authentifizierung birgt eine besondere Anfälligkeit für das Kopieren und Vortäuschen biometrischer Merkmale. Nehmen wir Fingerabdrücke als Beispiel. Wir hinterlassen sie überall, auf fast jeder glatten Oberfläche, die wir berühren. Wir hinterlassen sie auf Türklinken, in Restaurants und im Müll. Fingerabdrücke von diesen Oberflächen zu sichern, ist ein Kinderspiel; wir alle haben das schon unzählige Male in Polizeiserien gesehen. Ebenso einfach lassen sich Fingerabdrücke nachbilden – mit allem Möglichen, von einem 3D-Drucker bis hin zu Gummibärchen.

Bei anderen Formen biometrischer Authentifizierung findet ein fortwährender Wettstreit zwischen Sicherheitsforschern, die aufzeigen, wie sich biometrische Systeme täuschen lassen, und Anbietern statt, die Technologien zur Erkennung solcher Täuschungsversuche entwickeln. 3D-Masken haben Gesichtserkennungssysteme an Flughäfen getäuscht, allerdings können diese Masken durch Lebenderkennung und andere Methoden erkannt werden. Ebenso haben Angreifer Sprachaufnahmen in Verbindung mit Deepfake-Sprachsynthese verwendet, um Spracherkennungssysteme zu umgehen. Solche Täuschungsversuche lassen sich jedoch möglicherweise anhand der subtilen Verzerrungen erkennen, die durch Aufnahmegeräte entstehen. Selbst Irisbilder können reproduziert und mithilfe kosmetischer Kontaktlinsen oder eines künstlichen Auges vorgetäuscht werden. Verschiedene Verfahren zur Erkennung von Täuschungsversuchen – darunter die Auswertung von Unterschieden bei der Lichtreflexion zwischen menschlichem Gewebe und synthetischen Materialien – können solche Manipulationen jedoch erkennen. Kurz gesagt hängt die Sicherheit biometrischer Lesegeräte vom jeweiligen Stand der Technologien für Täuschungsversuche und deren Erkennung ab.

Selbst wenn wir wie Einsiedler lebten und es vermieden, Oberflächen zu berühren, könnten Angreifer unsere biometrischen Daten stehlen. Mithilfe von Schadsoftware, Social Engineering und der Ausnutzung ungepatchter Sicherheitslücken haben Angreifer bereits Milliarden von Benutzernamen und Passwörtern gestohlen. Wenn Angreifer in die Datenbanken eindringen können, in denen unsere Passwörter gespeichert sind, werden sie mit Sicherheit auch in die Datenbanken eindringen, in denen unsere biometrischen Daten gespeichert sind. Und sobald unsere biometrischen Daten durch ein einziges Datenleck offengelegt wurden, können wir sie möglicherweise nicht mehr sicher zur Authentifizierung verwenden – je nachdem, ob sich eine Fälschung erkennen lässt.

Das Sicherheitsrisiko durch Kopieren und Fälschen wird dadurch verschärft, dass wir die von biometrischen Verfahren erfassten Merkmale nicht ohne Weiteres ändern können. Wenn ein Angreifer ein Passwort stiehlt, können wir es ändern. Stiehlt ein Angreifer einen OPT-Dongle oder ein Mobiltelefon, können wir das Gerät ersetzen und den Seed zurücksetzen. Verschafft sich ein Angreifer jedoch Zugriff auf unseren Fingerabdruck, Handflächenabdruck, unser Gesichtsbild oder ein anderes biologisches Merkmal und findet heraus, wie sich dieses wirksam fälschen lässt, können wir diese körperlichen Merkmale nicht ohne erhebliche Schmerzen verändern.

Verbesserung der Sicherheit der Multi-Faktor-Authentifizierung

MFA stellt zwar eine Verbesserung gegenüber der Ein-Faktor-Authentifizierung mit Passwort dar, ist aber dennoch anfällig – zumindest in den derzeit gängigen Implementierungsformen. Betrachten Sie MFA daher nicht als das Ende des Weges zu mehr Sicherheit, sondern als einen Neuanfang. Bewährte Verfahren für die Anwendungssicherheit sind nach wie vor relevant, darunter Bedrohungsmodellierung, Code-Reviews, Schwachstellenscans, Penetrationstests und Red Teaming. Untersuchen Sie bei der Bedrohungsmodellierung jeden Aspekt des Authentifizierungs- und Sitzungsverwaltungsprozesses und berücksichtigen Sie dabei die zahlreichen Angriffspunkte – vom Identitätsspeicher bis hin zur physischen Sicherheit sowie zur Netzwerk- und Datensicherheit. Cyberangriffe zielen wahrscheinlich auf das schwächste Glied ab. Insbesondere weisen die Schwachstellen von MFA auf einige zentrale Problembereiche hin, die mehr Aufmerksamkeit erfordern: die Eindämmung automatisierter Angriffe, der Schutz vor JavaScript-Lieferkettenangriffen und die Berücksichtigung des Risikokontexts.

Entfernen Sie Bots aus Ihrem Netzwerk

Kriminelle setzen auf Bots, um mehrere zentrale Angriffe auf die Multi-Faktor-Authentifizierung (MFA) zu skalieren, darunter Credential Stuffing, Echtzeit-Phishing-Proxys und MFA-Bombing. Daher ist die Abwehr von Bots entscheidend für den Schutz aller Formen der MFA.

Bei Credential-Stuffing-Angriffen, wie sie von OWASP definiert werden, beschaffen sich Kriminelle gestohlene Zugangsdaten aus früheren Datenschutzverletzungen, in der Regel durch Käufe im Darknet, und testen diese Zugangsdaten bei den Anmeldesystemen anderer Anwendungen. Da durch Datenschutzverletzungen bereits Milliarden von Zugangsdaten offengelegt wurden, maximieren Kriminelle ihre Gewinne, indem sie die Tests mithilfe von Bots automatisieren und so eine enorme Anzahl von Zugangsdaten überprüfen können. Das Federal Bureau of Investigation, die Securities and Exchange Commission und der New York Attorney General haben vor den finanziellen Risiken von Credential Stuffing gewarnt. Die Global Privacy Assembly, ein Zusammenschluss von mehr als 130 Aufsichtsbehörden, erklärte Credential Stuffing zu einer globalen Bedrohung für den Datenschutz.

Die Verhinderung von Credential Stuffing ist bei MFA ebenso wichtig wie bei einer reinen Passwortauthentifizierung. Der Sinn von MFA besteht gerade darin, mehr als einen Faktor zu verwenden. Wird jedoch der erste Faktor nicht geschützt, bleibt nur noch ein einziger Faktor übrig. Sobald ein Angreifer das Passwort eines Benutzers herausgefunden hat, wird aus der Zwei-Faktor-Authentifizierung eine Ein-Faktor-Authentifizierung, und die mehrschichtige Sicherheitsstrategie geht verloren.

Darüber hinaus ist die Abwehr von Bots von entscheidender Bedeutung, da Kriminelle Bots nicht nur für Angriffe auf Passwörter einsetzen. Bots sind ein wichtiges Werkzeug für erfolgreiche Echtzeit-Phishing-Proxy-Angriffe, die zu den häufigsten Methoden zur Umgehung von MFA gehören. Wenn ein Benutzer Opfer einer Phishing-E-Mail wird, die ihn dazu verleitet, seine Anmeldedaten auf einer gefälschten Website einzugeben, muss der Angreifer diese Anmeldedaten an die Zielanwendung weiterleiten, um die MFA-Anfrage auszulösen – unabhängig davon, ob diese per SMS, über eine Authentifizierungs-App oder mithilfe hochentwickelter biometrischer Verfahren erfolgt. Um die Anfrage schnell und in großem Umfang weiterzuleiten, muss der Kriminelle den Vorgang automatisieren. Das bedeutet, dass die Anfrage von einem Bot an die Anwendung weitergeleitet wird. (Einen Überblick über Dienste, die Bots zur Umgehung von OTP verwenden, bietet der Beitrag von Krebs on Security „Der Aufstieg der Bots zum Abfangen von Einmalpasswörtern“.) Indem eine Organisation verhindert, dass unerwünschte Bots Anmeldedaten übermitteln, kann sie somit die Wirksamkeit von Echtzeit-Phishing-Proxys erheblich beeinträchtigen und sowohl besitz- als auch biometriebasierte Authentifizierungsfaktoren wirksamer schützen.

Eine weitere offensichtliche Methode, mit der Kriminelle Bots für Angriffe auf die Multi-Faktor-Authentifizierung (MFA) einsetzen, ist das sogenannte MFA-Bombing. Dabei werden massenhaft Anmeldeversuche erzeugt, um so viele Authentifizierungsanfragen auszulösen, dass der Benutzer schließlich versehentlich zustimmt oder einfach nur, um die ständigen Benachrichtigungen zu beenden. Damit sich der Angriff lohnt, müssen Kriminelle eine ausreichend große Anzahl von Anfragen für viele Benutzer erzeugen. Dazu ist eine Automatisierung erforderlich, was wiederum bedeutet, dass die auf Ihrer Website eingehenden Anmeldeversuche von Bots stammen.

Wie diese Beispiele zeigen, ist nahezu jeder Angriff auf MFA auf Bots angewiesen, um in großem Umfang erfolgreich zu sein. Unternehmen, die MFA implementieren, müssen daher den Schutz vor Bots ernst nehmen.

Leider unterschätzen viele Organisationen, wie ausgefeilt Bots sind und mit welcher Entschlossenheit Kriminelle sie immer wieder umrüsten, um der Erkennung zu entgehen. Stattdessen verlassen sich zu viele Unternehmen auf Techniken zur Bot-Abwehr, die nicht mehr funktionieren, darunter CAPTCHAs, Sperrlisten für IP-Adressen und Fingerprints von HTTP-Headern.

CAPTCHAs tragen kaum zum Schutz vor Bots bei und verärgern lediglich echte Kunden, da Bots diese Rätsel mithilfe kostengünstiger CAPTCHA-Lösungsdienste umgehen können, die auf maschinellem Lernen und Klickfarmen basieren. Suchen Sie im Internet einfach nach CAPTCHA-Lösungsdiensten, und Sie werden mindestens ein Dutzend Anbieter finden, die bei Preis und Geschwindigkeit miteinander konkurrieren. Einen lesenswerten Einblick in diese Dienste bietet ein Beitrag von Dan Woods, Head of Intelligence bei F5, mit dem Titel „Ich war ein menschlicher CAPTCHA-Löser“. Noch interessanter ist, dass ChatGPT ein CAPTCHA umgehen konnte, indem es eine Person mittels Social Engineering dazu brachte, das CAPTCHA für das System zu lösen.

Für Unternehmen, die zur Abwehr von Bots auf WAF-basierte IP-Sperrlisten setzen, ist die Aufgabe ebenso schwierig. Es gibt Dienste, die Bot-Entwicklern mehrere zehn Millionen private IP-Adressen zur Verfügung stellen, mit denen sich die Bot-Erkennung umgehen lässt. Diese Dienste werden als rotierende Residential Proxys angeboten. Dabei sendet der Bot HTTP-Anfragen an den Proxy – ähnlich wie viele Unternehmensbrowser Anfragen über Forward Proxys senden – und der Dienst wechselt fortlaufend die öffentliche IP-Adresse, über die die Anfrage an die Website oder API gesendet wird. Früher nutzten Bots in der Regel Rechenzentrums-Proxys, häufig von Cloud-Diensten, die allgemein bekannt und leicht zu erkennen sind. Diese neuen Proxy-Dienste verwenden hingegen private IP-Adressen aus derselben geografischen Region wie Ihre Kunden. Da jede IP-Adresse aufgrund von NAT durch Internetdienstanbieter (ISPs) gleichzeitig entweder für einen Bot oder einen legitimen Kunden stehen kann, lassen sich nicht alle diese IP-Adressen sperren, ohne auch echte Kunden abzuweisen. (Weitere Informationen dazu, wie diese Dienste an diese IP-Adressen gelangen, finden Sie in der Studie „Your Phone is My Proxy“.)

Auch der Versuch, Bots anhand von Unterschieden in der Reihenfolge der Header zu erkennen, funktioniert nicht mehr, da die Bots diesen Trick inzwischen durchschaut haben. Tatsächlich sorgen mehrere Open-Source-Projekte, darunter stealth-puppeteer und undetected-chromedriver, für die korrekte Reihenfolge der Header. Dadurch lassen sich Erkennungsmechanismen bei der Verwendung dieser beliebten Automatisierungs-Frameworks leicht umgehen.

Die Erkennung fortschrittlicher Bots erfordert heutzutage eine umfassende Signalerfassung, eine Überwachung rund um die Uhr, maschinelles Lernen und eine schnelle Reaktion auf Anpassungen der Bots. Ohne eine dedizierte Bot-Management-Lösung, die solche Anpassungen schnell erkennt und darauf reagiert, ermöglichen Bots es Kriminellen, Angriffe auf die Multi-Faktor-Authentifizierung (MFA) effektiv zu skalieren.

Schutz vor Angriffen auf die JavaScript-Lieferkette

Nahezu jede denkbare Form der Multi-Faktor-Authentifizierung (MFA) versagt, wenn eine Anwendung kompromittiert wird. Schleust ein Angreifer Code in eine Anwendung ein, ist es bereits zu spät. Er kann Anmeldedaten und andere MFA-Eingaben abfangen, Sitzungen durch den Diebstahl von Sitzungskennungen übernehmen oder Daten direkt aus der Anwendung ausschleusen. Da moderne Webanwendungen in der Regel aus mehr als 20 JavaScript-Dateien bestehen, die größtenteils von Drittanbietern stammen und nicht vom Anwendungssicherheitsteam des Unternehmens überprüft werden, ist das Risiko einer Anwendungskompromittierung durch Angriffe auf die JavaScript-Lieferkette höher, als häufig angenommen wird.

Bestehende clientseitige Sicherheitsprotokolle sind zu statisch, um heutige dynamische Webanwendungen zu schützen. Die Content Security Policy (CSP) schränkt die Aktionen von Skripten so ein, dass JavaScript-Lieferkettenangriffe verhindert werden könnten. Allerdings kann CSP die Funktionalität einer Website allzu leicht beeinträchtigen, wenn ein Drittanbieter ein Skript dynamisch auf eine Weise aktualisiert, die den CSP-Beschränkungen widerspricht. Zwar ist es möglicherweise erwünscht, dass ein Skript bei einem Verstoß gegen eine Sicherheitsrichtlinie nicht ausgeführt wird, doch ein solcher Ausfall in der Produktionsumgebung könnte erhebliche Auswirkungen auf Kunden haben. (Siehe Warum scheitert CSP?) Subresource Integrity (SRI), ein weiteres Websicherheitsprotokoll, ist für dynamische Inhalte von Drittanbietern sogar noch weniger praktikabel, da bei jeder Änderung eines Skripts die Skript-Tags mit dem entsprechenden Hashwert aktualisiert werden müssen. Das ist nicht möglich, wenn die Änderungen ohne Vorankündigung erfolgen. Tatsächlich soll SRI genau jene Art von Skriptaktualisierungen verhindern, auf die die meisten modernen Anwendungen angewiesen sind.

Da es keine eindeutigen Kontrollmechanismen zur Beseitigung von Schwachstellen in der JavaScript-Lieferkette gibt, müssen Unternehmen kreative Wege finden, um das Risiko zumindest zu überwachen. Unternehmen können die Skripte auf ihrer Website besser dokumentieren und ihr Risiko anhand der Quelle und der Änderungshäufigkeit einstufen. Über Tag-Manager hinzugefügte Skripte sollten regelmäßig auf Risiken überprüft werden. Es sind Monitoring-Tools erhältlich, die das Verhalten von Skripten mithilfe von synthetischem Monitoring, CSP im Berichtsmodus oder im Browser ausgeführten JavaScript-basierten Agenten nachverfolgen.

Da sich Skripte von Drittanbietern so häufig und ohne die Möglichkeit einer Sicherheitsüberprüfung ändern, ist es für Unternehmen wichtig, ihre Anwendungen kontinuierlich auf verdächtiges Verhalten zu überwachen, etwa darauf, ob Skripte sensible Daten auslesen und an nicht vertrauenswürdige Domains übertragen. Ohne diese Überwachung auf JavaScript-Lieferkettenangriffe kann keine Form der Multi-Faktor-Authentifizierung (MFA) die Sicherheit der Benutzer gewährleisten.

Vertrauenswürdige Benutzer erkennen und verdächtiges Verhalten überprüfen

Der Zweck von MFA sollte darin bestehen, die Sicherheit zu erhöhen, anstatt Kunden mit sinnlosen Sicherheitsmaßnahmen zu belasten. Indem Unternehmen die Anmeldeanforderungen an das jeweilige Risiko anpassen, können sie vermeiden, wertvolle wiederkehrende Kunden ständig mit MFA-Anforderungen zu behelligen. Stattdessen können sie ihnen den Zugang durch verlängerte Benutzersitzungen erleichtern und sie mit einem personalisierten, mühelosen Erlebnis willkommen heißen – ähnlich wie die TSA vertrauenswürdige Reisende mit TSA PreCheck schneller abfertigt.

Kontextbezogenes Risiko hat viele Dimensionen:

  • Geografie: Meldet sich der Benutzer laut IP-Adresse von seinem üblichen Standort aus an?
  • ASN (Autonomous System Number): Meldet sich der Benutzer anhand der IP-Adresse wie üblich über denselben Internetanbieter an, der möglicherweise mit seinem Zuhause, seinem Arbeitsplatz oder seinem Lieblingscafé verbunden ist?
  • Gerät: Meldet sich der Benutzer vom selben Gerät wie üblich an?
  • Uhrzeit/Tag: Meldet sich der Benutzer wie gewohnt zur gleichen Tageszeit oder am gleichen Wochentag an, beispielsweise morgens für Bankgeschäfte und abends zum Spielen?
  • Verhalten: Tippt der Benutzer mit der gleichen Geschwindigkeit wie üblich, bewegt er die Maus nach den gleichen Mustern und kopiert und fügt er Inhalte auf ähnliche Weise ein?
  • Funktionalität: Nutzt der Benutzer dieselben Funktionen wie üblich?

Wenn der Benutzer nachweislich ein unauffälliges Verhalten zeigt und von demselben Ort, mit demselben Gerät, zur selben Tageszeit, mit ähnlichem Verhalten und unter Nutzung der gewohnten Funktionen auf eine Website zugreift, ist es möglicherweise nicht einmal erforderlich, eine Anmeldung zu verlangen. Stattdessen kann eine kontinuierliche, unbemerkte Authentifizierung durchgeführt werden, um die Sitzung im Interesse des Benutzerkomforts zu verlängern. Weicht der Kontext vom Normalfall ab und deutet damit auf ein höheres Risiko hin, können Sie Ihrer Anwendung adaptive Richtlinien hinzufügen, um die Sicherheitsanforderungen schrittweise zu erhöhen: eine Anmeldung mit Passwort oder eine Zwei-Faktor-Authentifizierung verlangen, ein Konto zur Überprüfung markieren, den Benutzer per SMS oder E-Mail über die Anmeldung informieren oder das Konto sperren, sodass der Benutzer gezwungen ist, den Support zu kontaktieren.

Allzu oft wird die Sitzungsdauer unabhängig vom kontextbezogenen Risiko auf einen festen Zeitraum festgelegt. Dadurch kann jeder, der über ein Sitzungstoken verfügt, weiterhin auf Daten zugreifen, für die der Benutzer autorisiert ist, während das Risiko einer Sitzungsübernahme außer Acht gelassen wird. Ein sichererer Ansatz besteht darin, die Zero-Trust-Prinzipien zu befolgen: von einer Kompromittierung ausgehen und kontinuierlich überwachen. Ändert sich der Kontext während einer Sitzung, sollte die Sitzung vorzeitig beendet und eine zusätzliche Authentifizierung verlangt werden. Wie streng diese ausfällt, hängt davon ab, wie stark sich der Kontext verändert hat und wie sensibel die Daten sind.

Fazit

Ganz im Sinne des Klischees, dass Sicherheit eine Reise ist, hat MFA mehrere Weggabelungen geschaffen und damit zusätzliche Optionen eröffnet, die bei korrekter Implementierung die Sicherheit erheblich verbessern. Doch keine Form von MFA – unabhängig von der Anzahl der Faktoren, der Qualität der Implementierung oder den Kosten – ermöglicht es uns, die Reise zu überspringen und direkt ans Ziel zu gelangen. Wir werden mit Sicherheit weitere Verkündungen vom Tod des Passworts und noch mehr Wirbel um neue MFA-Techniken erleben, die die Authentifizierung ein für alle Mal sicher machen sollen. Dennoch wird es für entschlossene Angreifer weiterhin Möglichkeiten geben, neue Technologien zu umgehen.

Auf Ihrem Weg zu einer besseren Absicherung kritischer Anwendungen steht Ihnen F5 als Partner zur Seite. Zu den F5 Distributed Cloud Services gehören Bot Defense zur Abwehr von Bots, Client-Side Defense zur Überwachung von Angriffen auf die JavaScript-Lieferkette und Authentication Intelligence, um wiederkehrende Benutzer zu erkennen und kontextbezogene Risiken zu quantifizieren. Mit der Unterstützung von F5 können Sie die Sicherheit der MFA gewährleisten und gleichzeitig das Kundenerlebnis optimieren. Erfahren Sie mehr über die F5 Distributed Cloud Services und melden Sie sich an für ein Gespräch mit unserem Team.

VERÖFFENTLICHT AM 26. JUNI 2023