Bruteforcing der Telefonnummer beliebiger Google-Nutzer

 (brutecat.com)
1 Punkte von GN⁺ 2025-06-10 | 1 Kommentare | Auf WhatsApp teilen
  • Das Formular Google-Konto finden kann umgangen werden, um zu prüfen, ob eine mit einem bestimmten Nutzernamen verknüpfte Telefonnummer existiert
  • Auch in einer Umgebung mit deaktiviertem JavaScript lässt sich durch gezieltes Einfügen eines BotGuard-Tokens eine Angriffsmethode umsetzen, die IP-Beschränkungen umgeht
  • In einigen Ländern wie den Niederlanden gibt es aufgrund des Telefonnummernformats weniger als 1 Million Kombinationen, sodass groß angelegte Brute-Force-Angriffe über Proxy- und IPv6-Rotation praktisch möglich sind
  • Der Anzeigename eines Google-Kontos lässt sich über Looker Studio ohne beliebige Aktion des Opfers leicht offenlegen
  • Die Schwachstelle wurde an Google gemeldet und gepatcht; die reale Angriffskette kann Telefonnummern per Automatisierung in sehr kurzer Zeit verifizieren

Überblick

Dieser Beitrag behandelt einen realen Fall im Detail: wie sich die Telefonnummer eines Google-Kontos per Brute-Force-Angriff ermitteln ließ, wie der Ablauf funktionierte und wie die Abwehrseite reagierte. Normalerweise verhindern Konto-Such-/Wiederherstellungsformulare Missbrauch mithilfe einer JavaScript-Umgebung und Bot-Schutzmechanismen. Hier wird jedoch gezeigt, dass sich dieses System in einer Umgebung mit deaktiviertem JS plus einem bestimmten Muster umgehen ließ.

Hintergrund der Untersuchung und Vorgehensweise

  • Es wurde entdeckt, dass Googles Formular zum Auffinden des Kontobenutzernamens ohne JavaScript funktioniert
  • Das Formular kann in zwei HTTP-Anfragen prüfen, ob eine mit einem bestimmten Namen (Display Name) verknüpfte Telefonnummer existiert
      1. Anfrage: Abruf eines ess-Werts (Session-Token) auf Basis der Telefonnummer
      1. Anfrage: Prüfung, ob ein Konto existiert, über ess und die Parameter für den Namen (GivenName/FamilyName)
  • Existiert das Konto, erfolgt eine Weiterleitung zu usernamerecovery/challenge, andernfalls zu noaccountsfound

Umgehung von IP-Limits (mit Proxys und IPv6)

  • Anfangs war Brute-Forcing wegen Rate Limits pro IP und Captchas nicht möglich
  • Bei niederländischen Mobilnummern ist das mit 1 Million Kombinationen (feste Anfangsziffern) unter Einsatz von Proxys praktikabel
  • Mit /64-IPv6-Blöcken aus Clouds wie AWS/Vultr lässt sich für jede Anfrage eine andere Adresse rotieren; auch der Server unterstützt IPv6

Umgehung des BotGuard-Tokens

  • Im JS-Formular ist ein BotGuard-Token erforderlich
  • Wird im No-JS-Formular statt des Parameters bgresponse=js_disabled ein im JS-Formular gesammeltes Token eingefügt, sind unbegrenzte Übermittlungen möglich
  • Es wurde ein Multithread-Tool erstellt, das massenhaft Telefonnummern einspeist und so vorhandene Konten schnell erkennen kann

Fehlalarme herausfiltern

  • Bei gleichem Namen und gleicher Bedingung der letzten zwei Ziffern einer Nummer können mehrere Personen als Treffer erscheinen
  • Durch erneutes Testen mit einem zufälligen Nachnamen wurde eine Logik ergänzt, die False Positives automatisch herausfiltert

Länderspezifische Telefonnummernformate und Sammlung von Namensinformationen

  • Das Wiederherstellungsformular liefert nur teilweise das Maskierungsformat der Telefonnummer
  • Nationale Telefonnummernmuster der einzelnen Länder lassen sich über Informationen aus Googles libphonenumbers ermitteln
  • Der Anzeigename des Opfers ließ sich in Looker Studio durch Missbrauch der Funktion zur Eigentumsübertragung auch ohne Aktion des Nutzers ermitteln

Optimierung und Automatisierung

  • Mit libphonenumbers wurde ein Wörterbuch für Prefixe, Längen und Regeln zur Gültigkeitsprüfung je Land erstellt
  • Auf Basis von Go und chromedp wurde eine API zur automatischen Ausgabe von BotGuard-Tokens erstellt, wodurch der reale Angriff automatisierbar wurde

Praktischer Angriffsablauf

  1. Den Namen (Display Name) des Opfers über eine Eigentumsübertragung in Looker Studio ermitteln
  2. Im Ablauf „Passwort vergessen“ die teilweise maskierte Telefonnummer der betreffenden E-Mail sammeln
  3. Mit dem gpb-Tool den Brute-Force-Angriff auf Basis von Name, Maskierung und Ländercode ausführen

Zeit und Effizienz

  • Auf einem Server mit 16 vCPU und 3000 Threads lassen sich etwa 40.000 Prüfungen pro Sekunde durchführen
  • Je nach länderspezifischen Zahlenkombinationen und Länge des Hinweises reichen etwa USA (20 Minuten), Großbritannien (4 Minuten), Niederlande (15 Sekunden), Singapur (5 Sekunden)
  • Wenn ein anderer Dienst vollständige Hinweise liefert (z. B. PayPal), verkürzt sich die Zeit weiter

Google und Patch-Timeline

  • 14.04.2025: Meldung an Google, am 25.04. Dank im Panel
  • Mitte Mai 2025: Auszahlung einer Bug-Bounty von 5.000 US-Dollar
  • Mai 2025: schrittweise Abschaltung des No-JS-Formulars und Anwendung von Gegenmaßnahmen
  • 09.06.2025: offizielle Veröffentlichung der Schwachstelle

Fazit

Dieser Fall zeigt, dass groß angelegte automatisierte Angriffe allein durch die Kombination aus Konto-Wiederherstellungsablauf, Telefonnummern-Maskierung und Anzeigename möglich sind. Google hat reagiert, indem Schwachstellen im Ablauf behoben und die betreffenden Formulare geschlossen wurden.

Anfragen sind über Signal/E-Mail möglich (siehe Originaltext).

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-10
Hacker-News-Kommentare

  • Interessant an diesem Beitrag ist, dass die meisten Rate Limits oder IP-Sperren immer noch auf einzelne IPs angewendet werden, obwohl die meisten Hosting-Anbieter oder ISPs mindestens einen /64-IPv6-Block bereitstellen. In einer IPv6-Umgebung sollten Rate Limits oder Sperren meiner Meinung nach für den gesamten /64-Block gelten

    • Selbst Unternehmen, die für das Management solcher Probleme verantwortlich sind oder damit Geld verdienen, reagieren beim IPv6-Management oft völlig daneben. Die Firma, bei der ich arbeite, nutzt einen bekannten CDN-Dienst, und selbst wenn man sich aus demselben /64-Block verbindet, bekommt man manchmal absurde Sicherheitswarnungen wie „Anmeldung von einer seltsamen IP“

    • Seit der Einführung von IPv6 sind die bisherigen Methoden der IP-Sperrung meines Erachtens weitgehend wirkungslos geworden. Selbst normale Privatkunden erhalten per DHCPv6 Prefix Delegation automatisch /56- oder /48-Blöcke. Ich bekomme zum Beispiel über Comcast ein /56, das sich in bis zu 65536 /64-Blöcke aufteilen lässt. Um unter IPv6 wirksames IP-Filtering zu betreiben, reicht es nicht, einfach die bisherige Einzel-IP-Basis durch /64 zu ersetzen

    • Selbst Rate Limits auf /64-Basis reichen womöglich nicht aus. Es ist zu einfach, einen /48-Block zu bekommen. Für eine optimale Kontrolle müsste man nach ASN klassifizieren und die Granularität daran anpassen, wie die jeweiligen Anbieter ihre IPs vergeben

    • Rate Limits auf /64-Basis sind bei IPv6 in der Branche längst bekannt, und Google setzt sie bei anderen Diensten auch ein. Ich halte das für ein Ergebnis davon, dass man bei der IPv6-Einführung die bestehenden Richtlinien nicht sauber aktualisiert hat

    • Selbst billige Hosting-Anbieter wie BuyVM geben beim günstigsten Produkt Adressen auf /48-Basis aus ($2/Monat, aktuell ist nur noch $7/Monat auf Lager). Deshalb werden sie von fragwürdigen Betreibern gern genutzt

  • Ich habe früher bei Facebook mit einer ähnlichen Methode versucht, die Telefonnummer einer bestimmten Person herauszufinden. Im Passwort-zurücksetzen-Prozess zeigte Facebook einen Großteil der Telefonnummer an, also habe ich die Zahlen in einer vcard-Datei organisiert, in mein Handy importiert und dann über das Foto abgeglichen. Das funktionierte überraschend gut

    • Google-Profilfotos und auch Google-Apps haben ähnliche Schwachstellen. Wenn bei Google-Maps-Bewertungen zum Beispiel John Smith steht, kann man verschiedene E-Mail-Varianten hinzufügen (johnsmith@gmail.com, smithjohn@gmail.com usw.) und in Hangouts die Profilfotos prüfen, um dieselbe Person nachzuverfolgen

    • Deshalb gebe ich niemals meine echte Telefonnummer an. Für den Betrieb des Dienstes ist sie ohnehin nicht zwingend nötig

  • Beeindruckend ist, dass selbst dann, wenn eine Person über längere Zeit 40.000 Requests pro Sekunde an den Server geschickt hat, die Ressourcennutzung nicht stark angestiegen ist und kein Alarm losging

    • Es kann gut sein, dass tatsächlich ein Alarm ausgelöst wurde, das Verhalten aber schnell aufhörte oder die Lage rasch wiederhergestellt war, sodass zum Zeitpunkt, an dem ein Engineer aufs Dashboard schaute, schon wieder alles normal war. 40.000 QPS fallen im Verkehrsvolumen von Focus oder der Google API nicht besonders auf, und wenn die Requests auf verschiedene IPs und IPv6-/64-Blöcke verteilt sind, gehen sie womöglich unbemerkt durch. Der Kern dieses Falls ist meiner Ansicht nach nicht das Monitoring, sondern dass es im deaktivierten-JS-Flow überhaupt kein Rate Limiting gab (unter Verwendung eines Tokens aus dem früheren aktivierten-JS-Flow)

    • Ich frage mich auch, ob vielleicht ein Botnet verwendet wurde, es wirkt aber auch so, als sei bei jedem Request eine andere IP genutzt worden

  • Bei dieser Art von Bug Bounty ist die Auszahlungssumme oft lächerlich niedrig. Schade

    • Wenn man die Belohnungen immer weiter kürzt, schießt man sich am Ende nur selbst ins Bein

    • Für ein solches Sicherheitsproblem weniger als 100.000 Dollar zu zahlen, ist wirklich armselig

  • Ich merke oft, was für eine enorme Last es ist, Legacy-Webseiten weiter zu pflegen und zu betreiben. Viele Sites müssen noch Jahrzehnte alten Code und uralte Seiten mitschleppen, und alle Kombinationen zu testen ist faktisch unmöglich. Wenn man tief genug in die Gmail-Einstellungen eintaucht, stößt man immer noch auf uralte Pop-ups im Stil von 2004

    • Bug-Bounty-Programme wirken wie eine sehr effiziente Nutzung von Geld. Schon mit ein paar tausend Dollar kann man freiwillige Kräfte mobilisieren, die extreme Edge Cases finden. Mit internem Personal wären die Kosten vermutlich deutlich höher gewesen

    • Genau deshalb versuchen Unternehmen, alte Dienste und Produkte so aggressiv einzustellen. Auf die Frage „Kann man es nicht einfach so lassen?“ lautet die Antwort letztlich, dass jeder Legacy-Dienst irgendwann zu einem Sicherheitsloch wird. Der einzig wirklich sichere Code ist Code, der gar nicht existiert

    • Ich frage mich immer, wer bei Facebook so etwas wie die „Poke“-Funktion betreut

    • Auch in großen Unternehmen laufen intern ähnliche Legacy-Infrastrukturen weiter. Ein Freund von mir wartet zum Beispiel in einem globalen Großkonzern eine interne Link-Shortener-App. Trotz enormer Nutzungsspitzen gibt es bei Dingen wie Node-Versionsupdates jedes Mal nur ein oder zwei Tickets, aus sehr simplen Gründen. Es kommen sogar so selten Bugreports, dass nicht einmal auffällt, wenn das Monitoring nicht richtig funktioniert

    • Vor Kurzem bin ich bei Google auch auf eine Seite mit einem alten (~2013) Catull-Logo gestoßen

  • Es wurde erwähnt: „2025-05-15 – Das Panel zahlte $1,337 + Swag. Begründung: geringe Exploitierbarkeit (lol)“, aber ich halte die tatsächliche Exploitierbarkeit für sehr hoch. Vielleicht ist die Zahl der Betroffenen, deren Telefonnummer offengelegt wird, nicht riesig, aber wenn Bedarf besteht, würden Privatdetektive, Kriminelle, Ermittler und andere diese Schwachstelle ganz sicher tatsächlich ausnutzen

  • Mir ist durch diesen Fall neu klar geworden, dass es in Wirklichkeit ein Sicherheitsrisiko ist, im Passwort-Wiederherstellungs-Flow Teile einer Telefonnummer als Hinweis anzuzeigen. Wenn mehrere Dienste unterschiedlich maskierte Hinweise für Telefonnummern oder E-Mails liefern, steigt das Risiko noch weiter

    • Ob das beruhigend ist, weiß ich nicht, aber aus den verschiedensten Gründen wie 2FA haben bereits Hunderte oder Tausende Dienste meine Telefonnummer gesammelt, und ein erheblicher Teil davon ist unabhängig von meiner Zustimmung schon geleakt. Kombinationen aus Klarnamen, E-Mail und Telefonnummer sind fast zwangsläufig bereits in öffentlichen Datendumps gelandet

    • Es gibt auch Telegram-Bots, die solche Informationen aufspüren. Wenn solche Bruteforce-Schwachstellen bekannt werden, scheint selbst Nutzern unwohl zu werden, die sonst automatisierte Tools verwenden (ein typisches Beispiel ist der EoG-Bot)

    • Kostenpflichtige Dienste, die solche personenbezogenen Daten automatisch aggregieren, gibt es ebenfalls schon lange. E-Mails, Telefonnummern und andere Informationen sammeln sich aus vielen Quellen an, und weltweit gibt es genug Anreize, Sicherheitslücken in Diensten gezielt anzugreifen. Am Ende führt diese Struktur zu massenhaften Leaks

    • Früher gab es auch Social-Engineering-Fälle, bei denen jemand beim Kundendienst eines Unternehmens nach den letzten 4 Ziffern einer Karte fragte und damit dann bei einem anderen Unternehmen die Identitätsprüfung aushebelte

    • Ich erinnere mich auch, während meiner Studienzeit einen Vortrag eines Sicherheitsforschers gehört zu haben, der zeigte, dass sich Kreditkarteninformationen auf diese Weise beschaffen lassen

  • 2025, 2023 und 2021 erschienen wiederholt Artikel und riesige Datenlecks nach dem Muster „Es gibt keine Möglichkeit, das zu verhindern“. Die Version von 2025, die Version von 2023 und die Version von 2021 wiederholen sich ständig. Ich überlege, welche Version am komischsten ist

  • Ich finde diesen Fall sehr kreativ und stark. Brutecat hat wieder zugeschlagen

  • Google wirkt inzwischen wirklich wie ein Geisterschiff. Eine Bug Bounty von $5.000 ist eine Beleidigung, und dass man überhaupt mit so einem kleinen Betrag angefangen hat, wirkt wie ein entscheidender Beleg dafür, dass Google es mit dem Schutz von Nutzerdaten nicht ernst meint

    • Die Teilnahme an Bug-Bounty-Programmen ist nicht verpflichtend. Wenn einem die Belohnung nicht gefällt, muss man eben nicht mitmachen. Letztlich haben auch diese Programme Grenzen als nachhaltiges Modell