900 Websites, 125 Millionen Konten, 1 Schwachstelle

 (env.fail)
3 Punkte von GN⁺ 2024-03-19 | 1 Kommentare | Auf WhatsApp teilen
  • Eine einzige falsch konfigurierte Firebase-Sicherheitsregel führte zur Offenlegung von Nutzerdaten auf Hunderten von Websites; allein der bestätigte Umfang beträgt rund 124,6 Millionen Datensätze
  • Die Untersuchung begann damit, auf Websites und in geladenen JavaScript-Bundles nach Firebase-Konfigurationsvariablen zu suchen; wegen Speicherproblemen des Python-Scanners wurde er in Go neu geschrieben
  • Der Hilfsscanner Catalyst prüft automatisch, ob Firebase-Collections lesbar sind, und schätzt auf Basis von Beispieldaten Art und Umfang der offengelegten Informationen
  • Zu den zusammengefassten offengelegten Daten gehören 84.221.169 Namen, 106.266.766 E-Mail-Adressen, 33.559.863 Telefonnummern, 20.185.831 Passwörter im Klartext und 27.487.924 Zahlungsinformationen
  • Die Forschenden verschickten über 13 Tage hinweg 842 Melde-E-Mails, aber nur 24 % der Website-Betreiber korrigierten die Konfiguration, 1 % antworteten, und nur 2 Websites boten eine Bug Bounty an

Internetweite Firebase-Exposure-Scans

  • Nach dem Chattr.ai-Vorfall wurde ein Scan des gesamten Internets gestartet, um über falsch konfigurierte Firebase-Instanzen offengelegte PII zu finden
  • Der erste Python-Scanner prüfte auf Websites oder in geladenen .js-Bundles Firebase-Konfigurationsvariablen, doch bei rund 500 Threads stieg der Speicherverbrauch an, und innerhalb einer Stunde trat ein OOM auf
  • Der anschließend in Go neu geschriebene Scanner lief gegen 5,5 Millionen Domains und brauchte statt der zunächst erwarteten etwa 11 Tage 2 bis 3 Wochen
  • Schon die anfängliche manuelle Prüfung fand 136 Websites und 6,2 Millionen Datensätze, doch mit der stark wachsenden Kandidatenliste wurde vollständige Automatisierung nötig

Catalyst und die Abschätzung des Expositionsumfangs

  • Catalyst nimmt Kandidaten-Websites oder JavaScript-Bundles als Eingabe und prüft automatisch, ob gemeinschaftlich genutzte Firebase-Collections sowie direkt in JavaScript erwähnte Collections lesbar sind
  • Wird eine lesbare Collection gefunden, werden 100 Beispieldatensätze gesammelt, um die enthaltenen Informationstypen zu prüfen; daraus wird durch Hochrechnung auf die Gesamtgröße der Collection der Einfluss geschätzt
  • Als Ergebnisspeicher wurde das auf PostgreSQL basierende Open-Source-Firebase-Konkurrenzprodukt Supabase gewählt, und die aufbereiteten Daten wurden in nicht öffentliche Datenbanktabellen hochgeladen
  • Die zusammengefassten Zahlen lauten wie folgt; der tatsächliche Umfang der offengelegten Daten könnte noch größer sein als hier angegeben
    • Gesamte Datensätze: 124.605.664
    • Namen: 84.221.169
    • E-Mail-Adressen: 106.266.766
    • Telefonnummern: 33.559.863
    • Passwörter: 20.185.831
    • Zahlungsinformationen: 27.487.924, darunter Bankdaten und Rechnungen

Websites mit besonders großer Auswirkung

  • Silid LMS

    • Lernmanagementsystem für Schüler und Lehrkräfte
    • Mit 27 Millionen offengelegten Nutzerdatensätzen, darunter Namen, E-Mail-Adressen und Telefonnummern, war dies der größte Fund

  • Online-Glücksspiel-Netzwerk

    • Bestand aus 9 gegenseitig reskinnten Websites
    • Einige Spins waren so manipuliert, dass die Gewinnwahrscheinlichkeit 0 % betrug
    • Detaillierte Login-Informationen zu Bankkonten waren mit 8 Millionen Datensätzen am stärksten offengelegt
    • Auch 10 Millionen Passwörter im Klartext waren betroffen, der höchste Wert unter den betroffenen Websites
    • Beim Versuch, das Problem zu melden, machte der Kundensupport während des Gesprächs anzügliche Annäherungsversuche

  • Lead Carrot

    • Online-Service zur Lead-Generierung für Cold Calls
    • Beim Umfang der offengelegten Nutzerdaten auf Rang drei; betroffen waren 22 Millionen Menschen

  • MyChefTool

    • App zur Geschäftsverwaltung und POS-Anwendung für Restaurants
    • Bei der Zahl der offengelegten Namen auf Platz 1 und bei E-Mail-Adressen auf Platz 2; offengelegt wurden jeweils 14 Millionen bzw. 13 Millionen

Reaktionen nach den Meldungen

  • Die Forschenden verschickten über 13 Tage hinweg 842 E-Mails
    • 85 % wurden zugestellt, 9 % kamen als unzustellbar zurück
    • 24 % der Website-Betreiber korrigierten die Fehlkonfiguration
    • Nur 1 % der Website-Betreiber antworteten
    • Betreiber von 2 Websites, entsprechend 0,2 %, boten eine Bug Bounty an

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-19
Meinungen auf Hacker News

  • Ich habe lange bei Firebase gearbeitet, und Probleme mit den Security Rules haben das Produkt immer wieder geplagt.
    Wir haben verschiedene Ansätze ausprobiert, etwa standardmäßige Regeln mit automatischem Ablaufdatum und mehr Schulung, aber am Ende sieht man immer noch viele unsichere Datenbanken.
    Die Gründe sind komplex: Security Rules nach Firebase-Art sind noch immer ein ungewohntes Konzept, und neue Entwickler, die Daten an bestehenden Stellen hinzufügen, passen die Regeln oft nicht an geänderte Datenschutzanforderungen dieser Daten an.
    Außerdem fällt die „Security through obscurity“ weg, die selbstgebaute Backends boten, wodurch großflächige Scans einfacher werden.
    Besonders die Regeln der Realtime Database sind schwer zu schreiben und skalieren nicht gut, aber automatische Scans suchen meist nur nach offen zugänglichen Daten, sodass schon etwas Besseres als read write true ausreichen konnte, um sie abzuwehren.
    Technisch ist der Firebase-Ansatz selbst nicht falsch, aber weil es eines der wenigen Backends ist, das ein Modell rund um gespeicherte Daten und Security Rules nutzt, ist es besonders anfällig für Missverständnisse, Fehlbedienung und solche Vorfälle.

    • Ehrlich gesagt fand ich ein Modell, bei dem das Frontend direkt in die Datenbank schreiben kann, selbst mit Security Rules immer fragwürdig.
      Im Backend wirken Validierung und Sicherheitsregeln wie Teil der Spezifikation, während Firebase Security Rules ein separater Prozess sind, der leicht vergessen wird und bei jedem neuen Feature erneut bewertet werden muss.
    • Ich habe versucht, über die Google-Supportkanäle Kontakt aufzunehmen, um Hilfe zu bekommen oder die Websites über das Problem informieren zu lassen, bekam aber nur die Antwort, man könne auf Wunsch stattdessen einen Feature Request für mich erstellen.
      Um die Aufmerksamkeit von jemandem zu bekommen, der Projektinhaber benachrichtigen kann, hätte das innerhalb von Firebase vermutlich ziemlich weit eskaliert werden müssen.
    • Wenn man sich https://firebase.google.com/docs/rules/basics ansieht, frage ich mich, ob ein einfacher Sicherheitsmodus, bei dem man nur aus vordefinierten Security-Rule-Templates auswählt, praktikabel wäre.
      Zum Beispiel frage ich mich, ob Templates wie „nur der Eigentümer des Inhalts hat Zugriff“ oder „attributbasierter bzw. rollenbasierter Zugriff“ aus dem Artikel die Muster der meisten Apps abdecken könnten, oder ob wirklich viele maßgeschneiderte Regeln nötig sind.
      Das große Problem beim Schreiben von Security Rules ist, dass nahezu jeder Fehler zu einem Sicherheitsproblem wird, sodass man sie lieber nicht anfassen möchte, wenn es nicht nötig ist.
      Sind die Regeln zu restriktiv, funktioniert die App nicht und es fällt sofort auf; sind sie zu offen, merkt man es kaum, solange man den übermäßigen Zugriff nicht gezielt ausprobiert.
      In diesem Zusammenhang wäre auch ein Ansatz bedenkenswert, bei dem Entwickler gezwungen werden, für jede Security Rule Testfälle mit Beispielen für verweigerten Zugriff zu schreiben.
    • Uns hat ein einfacher Trick sehr geholfen: Ein Regel-Transpiler namens fireplan fügt allen Properties standardmäßig die Regel "$other": {".read": false, ".write": false} hinzu.
      Dadurch müssen neue Felder explizit hinzugefügt werden, sodass es fast unmöglich wird, dass neue Werte unbemerkt bestehende Regeln „erben“.
      Wir nutzen Firebase seit über zehn Jahren, daher weiß ich nicht, ob die aktuellen Rule-Tools das inzwischen auch so machen.
      Wirklich hilfreich wären: eine grundlegende Unterstützung für das Umbenennen von Feldern oder Änderungen an Datenstrukturen in Situationen mit vielen schwer kontrollierbaren Client-Versionen; eine leichte Möglichkeit, Regeln zu testen, ohne eine Datenbank hochzufahren; und bessere Debugging-Informationen bei Regel-Fehlschlägen in der Produktionsumgebung.
      Bei jedem Fehlschlag müssten alle Werte mitprotokolliert werden, auf die die Regel zugegriffen hat, damit sich sporadische Fehler durch veränderliche Daten debuggen lassen.
    • Ich habe Firebase und Firestore ziemlich oft verteidigt, stimme dem hier aber vollständig zu.
      Das ist ein konzeptionelles Modell, das nicht ausreichend erklärt wird.
      In Projekten sage ich, dass jede Collection ein Sicherheitsprofil haben sollte – etwa öffentlich, Nutzerdaten, nur für authentifizierte Nutzer öffentlich oder nur für Admins – und gehe so vor, dass diese Kategorien über Security-Rule-Funktionen erzwungen werden, statt für jede Collection maßgeschneiderte Bedingungen zu schreiben.
      Wenn man Sicherheit auf Collection-Ebene statt auf Feld-Ebene denkt, verringert das die Gefahr, in einem Dokument unterschiedliche Sicherheitsabsichten zu vermischen.
      Ist eine Collection öffentlich, dürfen darin keine nichtöffentlichen Felder enthalten sein; falls nötig, kann man mit Firestore-Triggern Daten aus einem sensiblen Kontext in einen öffentlichen Kontext replizieren, aber nicht umgekehrt.
      Das Problem ist, dass die Absicht der Regeln außerhalb der Regeln selbst dokumentiert werden muss und daher leicht falsch angewendet wird; früher war auch das Schreiben von Tests schmerzhaft, aber inzwischen ist es deutlich besser geworden.

  • Das erinnert an „How I pwned half of America’s fast food chains, simultaneously.“: https://mrbruh.com/chattr/
    HN: https://news.ycombinator.com/item?id=38933999

    • Beide Beiträge sind von mir, und dieser Beitrag ist die Fortsetzung dieses Blogposts.
    • Das ist korrekt. Das sechste Wort im Blogpost ist ein Link zu diesem Beitrag.
      After the initial buzz of [pwning Chattr.ai] had settled down, […]

  • Wenn ich das nicht falsch lese, heißt das doch, dass zum Ende des Artikels noch 75 % der Sites mit dieser Schwachstelle weiterhin offen und dumpbar sind, oder?
    Wahnsinn.
    An manchen Tagen denke ich, man sollte eine Lizenz brauchen, um einen Computer anfassen zu dürfen.

    • Viele Unternehmen haben keine festangestellten Entwickler.
      Sie beauftragen eine Agentur mit der Erstellung ihrer Website, und die Agentur tauscht die Entwickler immer wieder aus: Am Anfang setzt sie einen guten Entwickler ein, später wird der Auftrag an weniger erfahrene Entwickler weitergereicht, solange sich das Unternehmen nicht beschwert.
      Die E-Mail zur Schwachstelle wurde vermutlich als Spam ignoriert, weitergeleitet und dann liegen gelassen, oder sie landete in der Meeting-Warteschlange eines PM als Punkt, der dem Kunden möglichst umfangreich in Rechnung gestellt werden soll, während man ihn behebt.
      Auch in Bereichen mit verpflichtender Berufslizenz gibt es viele inkompetente Lizenzinhaber.
      Selbst bei Ärzten sind Ausbildung und Zulassungsanforderungen enorm, aber an Quacksalbern und lizenzierten Alternativmedizinern mangelt es nicht.
    • Traurig, aber wahr, und vermutlich sind es noch viel mehr.
      Ich habe mein Bestes getan und jeder Site individuell zugeschnittene E-Mails mit den betroffenen Inhalten, der Behebung und Kontaktmöglichkeiten geschickt.
    • Genau. Deshalb konnte ich die Liste der betroffenen Sites nicht veröffentlichen, damit böswillige Akteure sie nicht sofort ausnutzen können.
    • Solange ein Unternehmen nicht wegen eines Datenlecks zugrunde geht, ist das für sie ein Geschäftskostenpunkt, und diese Kosten werden an die Nutzer weitergegeben.

  • Das ist die zwangsläufige Folge davon, im Cheap-fast-good-Dreieck eines PM die billige und schnelle Wahl getroffen zu haben.
    Leider blieben die Bedenken einiger Kunden und Nutzer in der Diskussion außen vor, und ihre personenbezogenen Daten wurden zum Preis dafür.
    Bei den hier aufgeführten Unternehmen wäre ich vorsichtig, wenn sie solche Entscheidungen getroffen haben und sich trotzdem nichts an der Führung geändert hat.
    Es wurde mehrfach bewiesen, dass viele Unternehmen sich nicht genug darum kümmern, ihre Kunden zu schützen, und Geschichte wiederholt sich.

    • Ich stimme im Großen und Ganzen zu, aber es gab, wenn auch sehr wenige, auch positive Beispiele, die dankbar reagiert und schnell nachgebessert haben.

  • Ich habe eine sehr grundlegende Frage zu Firebase: Wurden die meisten Apps in diesem Artikel ohne eigenen Server-Code nur mit statisch gehostetem clientseitigem JavaScript umgesetzt?
    Ich frage mich, ob das Backend also zu 100 % eine von Google gehostete Firebase-Konfiguration ist.
    Falls ja, war mir nicht klar, dass eine solche Architektur bei Websites mit Millionen Nutzern so verbreitet geworden ist.

    • Genau. Entweder vollständig clientseitig oder, selbst wenn ein Server dazwischengeschaltet ist, nur naiv durchgereicht.
      Wenn eine API ein Sicherheitsmodell mit standardmäßig erlaubtem Zugriff hat, kommt es zwangsläufig dazu.
      Leider sind unsichere Defaults bei Libraries, die auf JavaScript-Entwickler abzielen, weit verbreitet, und GraphQL wirkt ebenfalls wie ein Bereich, in dem solche Probleme auftreten können.
    • Es kann auch eine Mischung sein.
      Firebase hat auch Firebase Functions, also in der Cloud aufrufbare Funktionen, deren Code nicht öffentlich ist.
      Aber sowohl Firestore als auch Firebase Realtime Database erfordern, dass Nutzer Sicherheitsregeln konfigurieren; andernfalls kann jeder alle Daten lesen.
    • Das wirkt wie ein ziemlich radikales Setup, kann aber funktionieren, wenn man im SQL-Schema des Backends passende Autorisierungsregeln codiert.
      Entscheidend ist, es einfach zu machen, im Backend passende Autorisierungsregeln zu schreiben.

  • Wenn ich so etwas sehe, bin ich froh, dass ich mich schon vor langer Zeit für einen Passwortmanager und virtuelle Karten entschieden habe.
    Trotzdem wird das Internet beängstigender.
    Die meisten haben überhaupt keine Ahnung, wie verwundbar das Web ist und wie stark sie selbst exponiert sind.

    • Ich glaube, es wird in Zukunft noch schlimmer.
      KI-Agenten werden Schwachstellen viel effizienter finden als Bots; es fühlt sich an, als stünde uns eine seltsame Zukunft bevor.
    • Mit der Zeit machen Dienste das Erstellen von Websites immer einfacher und abstrahieren immer mehr weg, sodass Entwickler nicht mehr wissen, was sie konfigurieren müssen.
    • Ein Passwortmanager allein reicht nicht.
      Man sollte für jeden Dienst, bei dem man sich registriert, eine eindeutige E-Mail-Adresse verwenden.
      So lässt sich der Schaden bei einem Vorfall begrenzen, und man verhindert auch, dass öffentlich verfügbare Informationen mit anderen Diensten abgeglichen und gesammelt werden.
      Manchmal kann man, wenn an diese eindeutige Adresse bösartige E-Mails kommen, sogar vor dem Website-Betreiber bemerken, dass etwas kompromittiert wurde.

  • Weiß jemand mehr über die Stelle, dass „ein Python-Programm mit etwa 500 Threads mit der Zeit anfängt, Speicher zu fressen“?
    Ich habe selbst einen Scraper mit mehreren Hundert Threads in Python, und der scheint ziemlich viel Speicher zu verbrauchen.
    Ich frage mich, ob es Workarounds gibt oder ob ein Rewrite in einer anderen Sprache die einzige Lösung ist.

    • Man kann es auch mit Python machen, aber dafür muss man sich damit beschäftigen, wie Pythons Referenzzählung mit Threads interagiert.
      Persönlich bevorzuge ich Prozesse statt Threads und nutze Worker-Pools und einen Message Bus statt Shared Memory.
      Auch diese Lösung hat Nachteile und etwas Overhead, aber man muss sich deutlich weniger Sorgen um Speicherprobleme machen.
      Bei einem Crawler scheint das Prozessmodell besser zu passen, weil die Zahl der Prozesse relativ konstant ist und die Arbeit jedes Prozesses unabhängig ist.
    • import multiprocessing as threading
    • Ich kenne das genaue Problem nicht, aber ehrlich gesagt ist Python nicht die passende Sprache für solche Aufgaben.
      Ein Rewrite ist praktisch die einzige echte Lösung.
    • Für diesen Einsatzzweck sollte man asyncio verwenden.
      Das ist ein sehr gut passender Use Case.

  • Gute Arbeit.
    Ich frage mich, wie ihr zu dem Schluss gekommen seid, dass die Zahl der betroffenen Nutzer tatsächlich wahrscheinlich höher ist.
    Auf den ersten Blick sieht es so aus, als könnten bei einigen Seiten, etwa Glücksspielseiten oder Lead Carrot, viele Fake-Account-Daten darunter sein.

    • Bei einer manuellen Prüfung mehrerer Websites stellte sich heraus, dass der automatische Scanner bekannte Datentypen wie Telefonnummern anhand von Variablennamen prüft und personenbezogene Daten in anderen Sprachen als Englisch daher schlecht erkennt.
      Das funktioniert nur bei englischsprachigen Websites gut.
    • Ich habe bestätigt, dass die Daten der Glücksspielseiten nicht fake sind, aber bei Lead weiß ich es nicht.
      Der Grund für die Annahme, dass es mehr sind, ist, dass wahrscheinlich auch andere Dienste verwundbar sind, die nicht auf der Scan-Liste standen.