SMS für Zwei-Faktor-Authentifizierung: eine noch schlechtere Sicherheitsmethode als ihr Ruf

 (ccc.de)
2 Punkte von GN⁺ 2024-07-12 | 1 Kommentare | Auf WhatsApp teilen
  • Der CCC konnte durch eine Exposure bei IdentifyMobile Einmalpasswort-SMS in Echtzeit einsehen; dabei wurden mehr als 198 Millionen SMS von über 200 Unternehmen offengelegt
  • 2FA per SMS ist zwar ein zusätzlicher Schutz gegen Fälle, in denen nur das Passwort gestohlen wurde, die tatsächliche Sicherheit hängt aber auch stark vom Sicherheitsniveau des SMS-Versanddienstleisters ab
  • IdentifyMobile legte Verifizierungscodes, Empfänger-Telefonnummern, Absendernamen und einige Kontoinformationen im Internet offen; der Zugriff war allein durch das Erraten einer Subdomain namens idmdatastore möglich
  • Google, Amazon, Facebook, Microsoft, Telegram, Airbnb, FedEx und DHL waren betroffen; schon allein mit dem Echtzeit-Feed waren die Übernahme von WhatsApp-Nummern oder Versuche bei Finanztransaktionen und Service-Logins möglich
  • SMS als zweiter Faktor ist besser als nur ein Passwort, aber appbasierte Einmalpasswörter oder Hardware-Token, die weniger von Mobilfunknetz und SMS-Anbietern abhängen, sind sicherer

Die durch die IdentifyMobile-Exposure offengelegte Schwäche von 2FA-SMS

  • 2FA per SMS verlangt sowohl ein Passwort, das der Nutzer kennt, als auch einen SMS-Code, der den Zugriff auf die Telefonnummer nachweist
    • Es dient als zusätzliche Schutzschicht, um Kontoübernahmen zu verhindern, wenn nur das Passwort kompromittiert wurde
    • SMS können kurzzeitig gültige Codes enthalten, etwa WhatsApp-Bestätigungscodes oder TANs für Banküberweisungen
  • SMS-basierte Authentifizierung ist bereits über mehrere Angriffswege verwundbar
  • In diesem Fall musste ein Angreifer weder direkt das Mobilfunknetz noch die Nutzer angreifen, weil der SMS-Versanddienstleister selbst zum schwachen Glied der Authentifizierungskette werden konnte
    • IdentifyMobile ist ein Anbieter für den Massenversand von SMS für verschiedene Unternehmen und Dienste
    • Dieser Anbieter hatte Zugriff auf die Inhalte der SMS, und darin befanden sich die Verifizierungscodes
    • Der CCC konnte allein durch das Erraten der Subdomain idmdatastore in Echtzeit auf die Daten zugreifen

Umfang der Offenlegung und tatsächliches Risiko

  • Die offengelegten Daten enthielten nicht nur den SMS-Inhalt, sondern auch Empfänger-Telefonnummern, Absendernamen und in manchen Fällen weitere Kontoinformationen
  • Betroffen waren mehr als 200 Unternehmen, darunter auch solche, die IdentifyMobile direkt oder über andere Dienstleister mit der Absicherung ihrer Verifizierung betraut hatten
    • Google, Amazon, Facebook, Microsoft
    • Telegram, Airbnb, FedEx, DHL
    • Insgesamt wurden mehr als 198 Millionen SMS offengelegt
  • Schon allein mit dem Echtzeit-Feed waren verschiedene Missbrauchsszenarien möglich
    • Übernahme von WhatsApp-Nummern
    • Wenn das Passwort bekannt war, Durchführung von Finanztransaktionen ohne Zugriff auf das Telefon
    • Wenn das Passwort bekannt war, Logins bei verschiedenen Diensten
  • Für einen tatsächlichen Missbrauch war in der Regel weiterhin das Passwort nötig, aber in den Daten waren auch 1-click login-Links enthalten
    • Bei einigen großen betroffenen Unternehmen war der von IdentifyMobile geschützte Bereich auf einzelne Dienste beschränkt
    • Die Fahrlässigkeit von IdentifyMobile setzte Unternehmen und Kunden erheblichen Risiken aus
    • Der CCC hat die Daten nicht gespeichert, kann aber nicht ausschließen, dass andere darauf zugegriffen haben

Welche Authentifizierungsmethoden statt SMS infrage kommen

  • Wenn möglich, ist es sicherer, statt SMS appgenerierte Einmalpasswörter oder Hardware-Token zu verwenden
    • Diese Verfahren hängen nicht vom Mobilfunknetz ab
    • Sie hängen auch nicht von SMS-Versanddienstleistern wie IdentifyMobile ab
    • Trotzdem ist Zwei-Faktor-Authentifizierung besser, als nur ein Passwort zu verwenden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-12
Meinungen auf Hacker News

  • Kürzlich ist ein Bekannter auf Google-Ads-Phishing hereingefallen: Der Angreifer hatte Anzeigen für Suchbegriffe wie „BANKNAME login“ gekauft, die Login-Seite der Bank täuschend echt nachgebaut und im Hintergrund einen Relay-Angriff durchgeführt.
    Als er den 2FA-Code aus der Smartphone-App eingab, wurde er auf dem Bildschirm abgelehnt und ein neuer Code verlangt; tatsächlich war der zweite Code aber ein Bestätigungscode zum Hinzufügen eines neuen „Pay anyone“-Empfängers, womit das Geld abfloss.
    Ich dachte, SMS-2FA sei protokollbedingt schwach, aber in diesem Fall hätte das SMS-Verfahren der Bank, bei dem beim Hinzufügen eines neuen Empfängers eine andere Nachricht als beim Login gesendet wird, vielleicht besser sein können.
    Idealerweise sollte es keine einfache Token-Generator-App sein, sondern Tokens je Transaktionstyp geben, etwa einen Token für Logins und einen für das Hinzufügen von Empfängern, die nicht gegeneinander austauschbar sind. Ich frage mich, ob jemand eine Bank kennt, die 2FA auf diesem Niveau anbietet.
    Vielleicht machen Passkeys dieses Problem auch irrelevant, weil sie eine physische Bindung an lokale Hardware herstellen. Nebenbei: Das Opfer hat das Geld am Ende zurückbekommen.

    • Werbung ist nicht nur lästiger psychologischer Terror, der Bandbreite und Rechenressourcen frisst, sondern auch der wichtigste Verbreitungsweg für Betrug und Malware im Web.
      Eine der besten Maßnahmen zur Verbesserung der eigenen Sicherheitslage ist es, einen Adblocker zu installieren. Für technisch weniger versierte Freunde oder Familienmitglieder empfehle ich dringend, uBlock Origin einzurichten.
    • HSBC hat so eine Funktion tatsächlich. In den länderspezifischen Apps lassen sich unterschiedliche Sicherheitscodes für den Website-Login, die Transaktionsbestätigung (z. B. Überweisung an einen Empfänger) und die erneute Authentifizierung (z. B. Änderung persönlicher Daten wie der Telefonnummer) erzeugen.
      Den Bildschirm der australischen App sieht man hier; die US- und UK-Apps sind ähnlich: https://www.hsbc.com.au/content/dam/hsbc/au/images/ways-to-b...
      HSBC bietet das seit Jahren an, und ich verstehe nicht recht, warum es noch kein Standard ist oder warum andere US-Banken es nicht eingeführt haben.
    • Aus Neugier habe ich einmal Google-Anzeigen gekauft; ich habe es nur ausprobiert, weil es kostenloses Guthaben gab, musste aber schon vor der Freigabe der Anzeige unglaublich viele absurde Bedingungen und Richtlinien umschiffen.
      Deshalb verstehe ich nicht, warum Google bei normalen Anzeigen so streng ist, aber Anzeigen für Phishing-Seiten verkauft, die sich als Bank ausgeben und gezielt Leute ansprechen, die nach dieser Bank suchen.
    • Es ist auch erwähnenswert, Familie und Bekannten zu sagen, dass selbst das FBI empfiehlt, in Suchmaschinen Adblocker-Erweiterungen zu verwenden, um genau solche Betrugsmaschen zu vermeiden [0].
      „Verwenden Sie beim Durchsuchen des Internets eine Adblocker-Erweiterung. Die meisten Internetbrowser erlauben das Hinzufügen von Erweiterungen, darunter auch Adblocker-Erweiterungen. Solche Adblocker lassen sich im Browser ein- und ausschalten, sodass Anzeigen auf bestimmten Websites zugelassen und an anderer Stelle blockiert werden können.“
      [0] https://www.ic3.gov/Media/Y2022/PSA221221
    • Eine weitere Lehre daraus ist, die URL der Bank als Lesezeichen zu speichern oder auswendig zu kennen und nicht darauf zu vertrauen, dass eine Suchmaschine einen zur Bank bringt.

  • Ich hatte schon lange den Verdacht, dass Unternehmen, die SMS-2FA erzwingen, es mit Sicherheit nicht ernst meinen, sondern einfach Telefonnummern haben wollen und 2FA als Sicherheitstheater vorschieben, um an die Nummern zu kommen.

    • Das spielt sicher auch eine Rolle. Telefonnummern sind wie eine neue Sozialversicherungsnummer geworden: ein eindeutiger Identifikator, der sich fast nie ändert und Nutzer über mehrere Dienste hinweg verknüpft.
      Außerdem ist es ein Identifikator, den man jedem, den man trifft, direkt aushändigt; man kann also sagen, dass es wie ein schlechtes System aussieht.
    • Bei Diensten mit kostenlosen Konten hilft die Anforderung einer Telefonnummer bei der Betrugsprävention oder dabei, Missbrauch durch mehrere Konten einzudämmen.
      Sie erschwert es, Sperren zu umgehen, indem man neue Konten erstellt, und macht es leichter, schlechtes Verhalten über mehrere Konten hinweg zu verknüpfen.
    • Die meisten Unternehmen wollen Telefonnummern tatsächlich wegen der Spam-Abwehr.
      Ich denke, der Beitrag von Spammern zum Niedergang des Internets wird unterschätzt.
    • SMS-2FA wird erzwungen, weil die Annahme, dass ein Nutzer eine Telefonnummer hat, viel weniger Reibung erzeugt als die Annahme, dass er eine 2FA-App installiert hat und dieses Tool verwalten kann.
      Auch der Support ist einfacher.
    • Oder es könnte sein, dass ursprünglich 2FA per E-Mail genutzt wurde und ein Auditor sagte: „Das ist keine 2FA“, woraufhin man feststellte, dass die Benachrichtigungs-Middleware neben E-Mail auch SMS unterstützt.

  • NIST weist schon seit geraumer Zeit ausdrücklich darauf hin, SMS-2FA nicht zu verwenden.
    NIST SP 800-63B §5.1.3.3
    https://pages.nist.gov/800-63-3/sp800-63b.html#pstnOOB

    • Die Perspektive und Interessenlage von NIST deckt sich nicht unbedingt mit dem, worauf ein Diensteanbieter bei der Kunden- und Nutzererfahrung achten muss.
      Kunde: „Was meinen Sie mit 2FA-App? Kam der Code nicht auf mein Handy?“
      Support: „Ja, aber SMS-2FA wird jetzt nicht mehr unterstützt.“
      Kunde: „Aber als der Code aufs Handy kam, hatte ich doch keine Probleme.“
      Support: „Ja, aber NIST empfiehlt, SMS-2FA nicht zu verwenden.“
      Kunde: „Was ist NIST? Das ist extrem frustrierend. Ich muss in mein Konto.“

  • Leider zwingen einen fast alle Banken zur Nutzung von SMS. Denn ihre Banking-Apps verweigern auf gerooteten Smartphones den Start. Wirklich eine großartige Sicherheitsleistung.

    • Immerhin gibt es damit eine Alternative.
      In meinem Land erzwingen fast alle Banken app-basierte 2FA ohne SMS-Alternative.
      Wenn man kein separates Smartphone kaufen und mit sich herumtragen will, bleibt einem nur eine einzige Bank, die das nicht verlangt.
    • Das ist tatsächlich ein Sicherheitsgewinn.
      Auf einem gerooteten Smartphone besteht die Möglichkeit, dass andere Apps Bankdaten ausspähen und stehlen.
      Dass eine Banking-App auf einem kompromittierten Smartphone nicht läuft, wirkt ziemlich vernünftig.
    • Es ist umstritten, aber gerootete Smartphones sind grundsätzlich weniger sicher.
      GrapheneOS fällt allerdings nicht darunter, denn die offiziellen Builds von GrapheneOS haben keine Root-Rechte.

  • Der Beitrag vermischt zwei sicherheitstechnisch unterschiedliche Probleme
    1-click login-Links sind besorgniserregend, und Dienste wie WhatsApp können allein durch Zugriff auf SMS übernommen werden
    2FA-Codes sind dagegen relativ weniger bedenklich, weil sie der zweite Faktor sind und Angreifer daher auch das Passwort benötigen
    In solchen Fällen sehe ich die Nutzung von SMS und das Risiko des Abfangens deutlich weniger beunruhigt

    • Auf jede geleakte Datenbank mit SMS-Nachrichten kommen ungefähr 1000 geleakte Datenbanken mit Account-Zugangsdaten

  • In Großbritannien scheint inzwischen fast jede Online-Banking-Transaktion per SMS verifiziert zu werden. Es sieht so aus, als sei das gesetzlich vorgeschrieben, und es hat das frühere System aus Bankkarte + Kartenleser + PIN-Verifizierung ersetzt
    Die alte Methode war nicht nur sicherer, sondern hing auch nicht von einem funktionierenden Handy mit Empfang ab
    Ich hoffe, dass das eines Tages als schrecklicher Fehler anerkannt und korrigiert wird, erwarte aber nicht viel

    • Welche Bank das ist, würde mich interessieren. Ich nutze Lloyds, und Transaktionen werden nicht per SMS, sondern über die App verifiziert
    • Der erste Satz stimmt überhaupt nicht. SMS ist eine der Optionen, aber viele Banken unterstützen App-basierte 2FA
      Ich stimme zu, dass Kartenleser offline nützlich waren. Allerdings habe ich fast nie daran gedacht, das Gerät mitzunehmen, und war auf Reisen deshalb oft blockiert

  • Schweden hat dieses Problem schon vor langer Zeit mit BankID gelöst
    https://en.wikipedia.org/wiki/BankID
    Es ist erstaunlich, was öffentliche Stellen und private Institutionen mit ein wenig Zusammenarbeit erreichen können. Für Behördendienste und die meisten Banken ist es die einzige Methode für Login und 2FA, und sie funktioniert gut
    Es ist schwer zu glauben, dass nicht jedes Land so ein System hat – und erst recht, dass es kein solches System für die gesamte EU gibt

    • Die EU führt dafür die Digital Wallet ein. Ich hoffe, sie ist angenehmer zu nutzen als die finnische Version von BankID, und noch besser wäre es, wenn sie weniger von Banken oder anderen privaten Rent-Seeking-Akteuren abhängt
      Trotzdem halte ich meine Erwartungen nicht allzu hoch
      https://ec.europa.eu/digital-building-blocks/sites/display/E...
    • Wenn die Beschreibung im Wiki stimmt, frage ich mich, ob Linux wirklich nicht unterstützt wird. Die Kartenform könnte man wohl alternativ verwenden

  • Die Nachrichten im S3-Bucket scheinen alle 5 Minuten aktualisiert worden zu sein: https://www.zeit.de/digital/datenschutz/2024-07/it-sicherhei...
    Allerdings lag der CCC falsch damit, das als reines Problem von 2FA-SMS zu definieren. Betroffen war nicht nur Twilio Verify (2FA-API), sondern alle SMS, die über diesen Anbieter verschickt wurden

    • Mich würde interessieren, woher der Beleg zu Twilio Verify stammt. Es wird nirgends erwähnt

  • Das ist weniger ein Problem von SMS an sich, sondern eher ein Problem der Anbietersicherheit, weil ein Speicherort für sensible Daten nicht ordnungsgemäß geschützt wurde

    • OTPs und Hardware-Token müssen rotierende Geheimnisse nicht in einen Datenspeicher schreiben, der potenziell öffentlich lesbar ist; insofern ist das auch ein SMS-Problem
      Dieser konkrete Angriffsweg existiert bei diesen Technologien schlicht nicht

  • Mehrere Finanzinstitute, für die ich arbeite, verlangen SMS-2FA und bieten keine HOTP/TOTP-Option an. Es macht mich wahnsinnig