Zwei-Faktor-Authentifizierung (2FA bzw. MFA) ist ein wichtiger Sicherheitsmechanismus, der effizient gegen den Missbrauch von erratenen, ergaunerten oder kopierten Passwörtern schützt. Durch Googles Synchronisation in die Cloud wird der Schutz aber massiv geschwächt.
Bevor wir uns die Auswirkungen und Gegenmassnahmen anschauen, ein kleiner Rückblick, wieso 2FA eigentlich so wichtig ist.
Der zweite Faktor
Wieso reicht ein Passwort nicht (mehr)?
Das Passwort ist aus Sicht der Nutzerin die zentrale Hürde, wenn es darum geht, berechtigte von unberechtigten Zugriffen auf Computer zu trennen. Doch Angreifer haben die Verfahren, mit denen sie an unsere Passwörter kommen, in den letzten Jahren immer weiter verfeinert.
So wurden bis in die 1990er Passwörter standardmässig unverschlüsselt übers Netz geschickt, eine Praxis, die leider immer noch nicht ganz ausgerottet werden konnte. Das machte es dem Angreifer besonders leicht. Auch gibt es auch heute noch Systeme, in denen Passwörter unverschlüsselt gespeichert werden. Wenn zur Anmeldung häufige Passwörter und ihren Varianten verwendet werden, nützt aber auch die Verschlüsselung wenig.
Auch bei exzellenten Passwörtern können noch Fehler passieren:
- Man kann das gleiche Passwort bei verschiedenen Anbietern einsetzen (und einer davon geht damit unsorgfältig um)
- Jemand schaut Ihnen beim Eintippen über die Schulter (oder Sie werden dabei von einer Kamera erfasst oder jemand hat einen Keylogger installiert oder…)
- Sie tippen das Passwort auf der falschen Seite ein.
Letztere Methode ist (auch) Teil des Phishing-Workflows, bei dem die Angreifer Sie unter einem Vorwand auf ihre Webseite locken, um Ihnen dort das Passwort zu entlocken. Dieser ist heute einer der Hauptmechanismen für Passwortklau und spielt auch in dieser Geschichte eine zentrale Rolle.
Wenn man sich Passwörter nicht klauen oder erraten lassen will, hilft ein Passwortmanager oder ein Single-Sign-On-Mechanismus. Auch diese können nicht gegen alles schützen; abgesehen davon, dass es noch Personen und Dienste gibt, die diese nicht unterstützen.
Damit ein (irgendwann, irgendwo) geklautes Passwort nicht gleich Zugang zum Konto erlaubt, sollten weitere Vorkehrungen getroffen werden. Viele kann der Serverbetreiber selbst ergreifen; aber für einen der Wichtigsten ist er auf Ihre Mithilfe angewiesen: 2FA.
Wie wird 2FA umgesetzt?
Zu den ersten, die im Internet einen zweiten Faktor nutzen wollten, waren Banken. Für eBanking wollten sie sich nicht auf die Nutzer verlassen und deren manchmal unsicheren Umgang mit Passwörtern. Also führten sie TAN-Listen aus Papier fürs Login ein (die Älteren unter den Lesern erinnern sich noch daran).
Andere Mechanismen waren Sicherheitstoken in unterschiedlichen Ausführungen: Kartenleser (in Schweizer Haushalten insbesondere der gelbe von PostFinance); Schlüsselanhänger, bei denen sich regelmässig die dargestellte Geheimnummer änderte; oder USB-Token, welche sich gegenüber dem Server auf Knopfdruck ausweisen können; um nur einige zu nennen.
Wo der Kostendruck hoch ist, wird heute versucht, auf zusätzliche (teure) Hardware zu verzichten. Deshalb sind im Massenmarkt und im Low-Cost-Bereich Mechanismen beliebt, die keine anbieterspezifische Hardware benötigen.
Sie kennen sicher die Mails, mit denen überprüft wird, ob Sie auch wirklich Sie seien (oder zumindest jemand, der aktuell Zugang zum Mailkonto besitzt). Oder die SMS, die dem gleichen Zweck dient, aber das Telefon (bzw. die Mobilnummer) zuzuordnen versucht.
Daneben gibt es unzählige Möglichkeiten, mit denen ein Smartphone identifiziert wird: Push-Nachrichten an das Gerät (z.B. bei Apple oder Microsoft), oft mit der Möglichkeit, direkt zu bestätigen. Oder Einmal-Passworte (One-Time-Password, OTP), was dem oben erwähnten “Sicherheitstoken mit Display” entspricht, aber als reine App (Google Authenticator uvam.)
Missbrauch des zweiten Faktors
Natürlich ist auch das nicht perfekt. Jemand konnte die TAN-Liste abfotografieren oder auch die angezeigte Geheimzahl verwenden, wenn man genügend schnell war. Oder der Angreifer könnte unter falschen Angaben eine Ersatz-SIM bestellen, um SMS abzufangen. Aber das alles war aufwändig und risikoreich.
Da ist es einfacher, wenn man die rechtmässige Besitzerin einfach darum bittet, die letzte SMS vorzulesen. Wenn das Opfer unerfahren ist oder im Stress, kann das schon einmal passieren. So auch dem IT-Experten im unten beschriebenen Fall.
Niemals Passwörter oder 2FA-Informationen weitergeben!
Verlust des zweiten Faktors
Was passiert aber, wenn mir dieser zweite Faktor verloren geht, gestohlen wird, mit den Kleidern mitgewaschen wird, vom Bus überfahren wird oder er ganz einfach und langweilig “normal” kaputt geht? Also, wenn nicht jemand Unberechtigter Zugang zu diesem Geheimnis bekommt, sondern der oder die Berechtigte den Zugang zum Geheimnis verliert?
Falls es sich dabei um die Spezialhardware handelt, hat man da wahrscheinlich irgendeinen Vertrag mit dem Hersteller oder dem Betreiber des Systems. Häufig dürfte das eine kostenpflichtige Kundenbeziehung sein (z.B. zur Bank) oder eine Mitarbeiterbeziehung (angestellt beim Unternehmen). Dann dürfte es auch relativ einfach sein, zu beweisen, dass man sich selbst ist und ein Ersatzgerät bekommen.
Was aber, wenn das zur Authentisierung genutzte Mobiltelefon nicht mehr nutzbar ist? In den meisten Fällen dürften das Low-Cost- und Massenanbieter sein. Da kann man nicht einfach mit der Identitätskarte mal kurz im Büro oder beim Laden um die Ecke reinspazieren.
In diesen Fällen ist es extrem aufwändig, wieder Zugang zu den Konten zu bekommen sobald der zweite Faktor verloren geht. Also: Was tun?
Beim Aktivieren von 2FA bieten die meisten Services gleichzeitig den Download von sogenannten Backup-Codes an. Dies ist eine handvoll zusätzlicher Codes, mit denen man sich gegenüber dem 2FA-System ausweisen kann, auch wenn der 2FA-Client nicht verfügbar ist. Man sollte die Ausdrucken und wie die TAN-Liste oben sicher aufbewahren. Aber das ist mühsam, führt zu einem grösseren Papierkram und wird deshalb häufig nicht so ernst genommen. Leider.
Das Google-Authenticator-Problem
Backup!
Ein Backup ist immer eine gute Idee. Das dachte sich auch Google, als sie das automatische Cloud-Backup für die 2FA-Token im Google Authenticator aktivierten. Es klingt zu gut: Zugang zu den verlorenen 2FA-Codes ohne die Backup-Codes mühsam auf Papier auszudrucken und irgendwo geordnet ablegen zu müssen.
Aber genau diese Funktion wurde in einem aktuellen Fall von einem Angreifer benutzt, um Kontrolle über die Server eines IT-Dienstleisters zu bekommen, wie dieser selbst in einem lesenswerten Blog-Beitrag dokumentiert.
What we had originally implemented was multi-factor authentication. But through this Google update, what was previously multi-factor-authentication had silently (to administrators) become single-factor-authentication
Übersetzung: “Was wir eigentlich ursprünglich implementiert hatten, war Multi-Faktor-Authentisierung. Aber durch dieses Google-Update wurde das, was vorher Multifaktor-Authentisierung war, in aller Stille zu einer Single-Faktor-Authentisierung (für die Administratoren).”
Snir Kodesh, “When MFA isn’t actually MFA“, Retool, 2023-09-13
Was war passiert?
Hier die extrakurze Version des Berichts im Retool-Blog: Ein Angreifer, der sich mit Firmeninternas scheinbar sehr gut auskannte, hatte gezielte Phishingmails (Spearphishing) an verschiedene Mitarbeiter gesendet. Ein technisches Problem müsse diagnostiziert werden. Die meisten erkannten die Mail als Phishing und ignorierten sie.
Ein Mitarbeiter allerdings reagierte darauf und gab Benutzername/Passwort seines Google-Kontos auf der Phishingwebseite ein. Daraufhin rief der Angreifer mit DeepFake-Stimme an und bat “zu Diagnosezwecken” um den 2FA-Code, den der Angreifer ebenfalls bekam.
Mit diesen Daten konnte der Angreifer ein zusätzliches Gerät zu diesem Google-Konto registrieren. Da der Mitarbeiter die Authenticator-Synchronisation aktiviert hatte, waren alle 2FA-Token auch bei Google gespeichert und wurden auch automatisch auf das neue Gerät des Angreifers heruntergeladen.
Diese von Google “bereitwillig” bereitgestellten 2FA-Geheimnisse nutzte der Angreifer dann, um auf den Firmenservern mittels dieser Administratorenberechtigungen Zugangsdaten auf sich umzubiegen. (Diese Änderungen wurden rasch erkannt und korrigiert.)
Sicheres 2FA-Backup
Die betroffene Firma Retool teilt dankenswerterweise ihre Überlegungen zu 2FA-Cloud-Backup. Viele davon betreffen grundsätzliche Überlegungen, die eigentlich in jeder Firma von den entsprechend IT-Sicherheitsexperten angestellt werden sollten.
Eine Empfehlung betrifft aber alle: Retool rät von der Benutzung dieser Backupfunktion ab (und ich teile diese Einschätzung). Retool erklärt auch, wie man sie deaktiviert: Dazu muss man im Google Authenticator das “Google-Konto trennen” (“unlink Google account”). Retool beschwert sich über die Verführung der Nutzer zur Aktivierung dieser Funktion (“Dark Pattern“) und haben Google aufgefordert, dieses Problem zu addressieren.
Lessons Learned
Solange es keine einfache Möglichkeit gibt, dieses Backup der 2FA-Token durch ein zusätzliches Passwort zu sichern (welches man natürlich irgendwo sicher ablegen sollte), empfehle auch ich, die Synchronisation zu deaktivieren oder auf einen der anderen 2FA-Clients umzustellen, welche verschlüsselte Cloud-Backups seiner 2FA-Daten unterstützen.
Dazu zählt beispielsweise der Aegis Authenticator (Android) oder Authy (iOS+Android).
Und nicht vergessen: Die Backup-Codes ausdrucken und zuverlässig lagern.
Happy secure 2FA!
Weiterführende Texte
- Snir Kodesh, When MFA isn’t actually MFA, Retool, 2023-09-13.
Der Artikel, der alles ausgelöst hat. - Marcel Waldvogel: Ist 1234 ein gutes Passwort?, 2018-09-23.
Hintergründe, weiterführende Informationen und Anekdoten zu Passwörtern. - Phishing, Wikipedia, zuletzt abgerufen 2023-09-18.
Detaillierte Erklärung zu Phishing und ihren Varianten. - Transaktionsnummer, Wikipedia, zuletzt abgerufen 2023-09-18.
Verschiedene Verfahren mit Transaktionsnummern (TAN) erläutert. - Sicherheitstoken, Wikipedia, zuletzt abgerufen 2023-09-18.
Sicherheitstoken in Wort und Bild. - FIDO2, Wikipedia, zuletzt abgerufen 2023-09-18.
Der de-facto-Standard, mit dem sich Sicherheitstoken gegenüber Webseiten ausweisen. - Christian Braand: Google Authenticator now supports Google Account synchronization, Google Security Blog, 2023-04-24.
Erläuterung von Google über die neue Funktion. - Marcel Waldvogel: Was uns Ransomware zu Datenschutz und Datensicherheit lehrt, 2022-12-05.
Informationen zu den gängigsten Sicherheitsrisiken. Behandelt auch Passwortmanager und (verschlüsseltem) Backup. - Marcel Waldvogel: 2FA verschwindet in der Cloud, 2023-09-18.
Eine frühere Version dieses Artikels.
6 Antworten
MFA ist sowieso nur Pseudo-MFA, wenn man damit nur ein OAuth-Token holt. Ein Token zu klauen ist auch nicht viel schwieriger als ein Passwort zu klauen, und jede Malware kann das auch seit Jahren.
Teams ist berüchtigt dafür, dass es die Tokens unsicher speichert und die Zugriff auf komplett Office 354 geben. Die Bastler aus Redmond sehen keinen Handlungsbedarf.
https://www.heise.de/news/Sicherheitsluecke-in-Teams-Microsoft-Token-im-Klartext-gespeichert-7267922.html
Es kommt immer auf dein Angriffsszenario an. Bei Phishing geht man davon aus, dass der User die Schwachstelle ist. Einen durchschnittlichen Benutzer dazu zu bringen, dir sein Teams-Token zu geben, ohne misstrauisch zu werden, dürfte schwierig sein.
Wenn du aber davon ausgehst, dass der Angreifer Kontrolle über einen Rechner bekommt, dann ist der Schaden auf alle Fälle riesig.
Ich hatte vor einigen Tagen den Bericht von Retool schon gelesen und mich gefragt: Wenn ich im Google Authenticator die “Verbindung zum Account trenne”, wird dann das Backup gelöscht oder bleibt es liegen? Wenn es liegen bleibt, nützt die Trennung nur wenig. Daten in einem (TOTP-) Authenticator sind ja sehr statisch und ändern sich nur selten. Ich stehe gerade vor dem Transfer von einem alten Android-11 auf ein neues Android-13 Smartphone, und via dem Backup lässt sich so eine Migration natürlich sehr gut ohne viel Aufwand lösen. Ich habe im Google Drive mal versucht, solche Backups zu finden, aber Fehlanzeige – die scheinen in einem geschützten Bereich abgelegt zu sein (oder ich war blind, was nicht auszuschliessen ist).
Das sind gerade theoretische Überlegungen, ich habe von allen TOTP-Seeds eine Kopie in KeepassXC sowie, wo verfügbar, die Recovery-Codes abgelegt. Aber ich bin auch IT-Spezialist, wie geht der unbedarfte Nutzer mit solchen Aufgaben um? (hier sind iPhone Benutzer offenbar besser dran – aber auch dort wird alles irgendwie in der Apple-Cloud gelagert)
Ich weiss nicht, ob ein bestehendes Google-Backup bei “Verbindung zum Account trennen” gelöscht wird. Vielleicht kann das mal jemand mit Google-Verbindung sagen.
Die Backups sind wie die Einstellungen glaube ich nicht Teil von Google Drive. Ich glaube auch, dass das gute Gründe hat (Nutzer würden Dateien dort umbenennen oder löschen).
Die Frage ist, wie einfach die Daten neu synchronisiert werden. Bei Apple erhältst du (glaube ich) nochmals eine Zusatzfrage, wenn ein neues Gerät auf dein Konto zugreifen will. Auch das kann in der Hitze des Gefechts schiefgehen, aber scheint zumindest deutlich expliziter als bei Google.
Microsoft hat in seinem Authenticator, der für Azure Anmeldungen genutzt wird, wie im Text erwähnt eine Push-Notification implementiert. Das erfordert natürlich eine Netzwerkverbindung, der Authenticator kann nicht, wie bei TOTP (Google, Okta, Authy, …) offline genutzt werden.
Offenbar haben zu viele Menschen einfach verinnerlicht, solche Push-Notification einfach zu bestätigen, ohne darüber nachzudenken, ob sie jetzt gerade eine Anmeldung durchgeführt haben, die das auslöst.
Deshalb hat Microsoft vor einigen Jahren einen zusätzlichen Code eingeführt: Bei der Anmeldung, die die Notification auslöst, wird eine zweistellige Zahl angezeigt. Die Push Notification zeigt den (basierend auf der IP-Adresse) vermuteten Ort der Auslösung an, aber verlangt auch nach den zwei Ziffern. Dies verhindert effizient die unbedachte Bestätigung und ist für Endanwender immer noch relativ bequem.
Der Fehlerfaktor Nummer 1 bleibt der Mensch.
Deshalb ist es sogar mit solchen Massnahmen wichtig, die Mitarbeiter zu schulen, dass einfach niemand um die Bestätigung der Notification bitten wird und schon gar nicht, wenn er gleich noch die zwei Ziffern angibt. So, wie auch nie die Bank ein E-Mail schreiben wird, dass man sich aufgrund unbedingt auf der verlinkten “Bank-Seite” anmelden muss, um weiterhin Zugriff auf das Konto zu haben.
Ich freue mich, wenn Passkeys mittelfristig ausgereift ist und überall zum Einsatz kommen kann. Ich selber kann mit TOTP, Push-Notifications und den Recovery-Codes umgehen, aber ich bin nicht repräsentativ.
Ja, “MFA Fatigue” ist ein Problem. Das versuchen die Hersteller mittels (Kombinationen) diverser Techniken zu reduzieren (Fingerprinting, Geolocation, zwei Ziffern, …).
Schulung ist ein Aspekt, aber die Mechanismen müssen so sicher sein (und so selten vorkommen), dass eigentlich keine Schulung nötig wäre. Die “Lessons learned” aus der Schulung gehen vergessen, wenn man im Stress ist.