900 Websites, 125 Millionen Konten, 1 Schwachstelle

Erster Versuch

• Ein einfacher, in Python geschriebener Scanner prüfte Firebase-Konfigurationsvariablen.
• Wegen Problemen beim Speicherverbrauch stellte er innerhalb einer Stunde den Betrieb ein.

Zweiter Versuch

• Der in Go neu geschriebene Scanner hatte kein Memory Leak.
• Das Scannen von mehr als 5 Millionen Domains dauerte länger als erwartet.

Alle Domains manuell prüfen

• Jeder Eintrag in einer Textdatei mit 550.000 Zeilen wurde manuell überprüft.
• 136 Websites und 6,2 Millionen Datensätze wurden bestätigt, doch es wurde klar, dass ein automatisierter Ansatz nötig war.

Katalysator

• Eine Liste potenziell betroffener Websites wurde mit einem Hilfsscanner namens Katalysator geprüft.
• Er überprüfte automatisch, ob auf der Website oder in .js-Bundles Lesezugriff auf gemeinsame Firebase-Collections möglich war.
• Um die Tragweite der Daten zu bewerten, wurden Stichproben von 100 Datensätzen gesammelt und die Art der Informationen geprüft.
• Zur Speicherung der Ergebnisse wurde Supabase ausgewählt, ein Open-Source-Konkurrent von Firebase.

Zahlen

• Datensätze insgesamt: 124.605.664
• Namen: 84.221.169
• E-Mail-Adressen: 106.260.766
• Telefonnummern: 33.559.863
• Passwörter: 20.185.831
• Zahlungsinformationen: 27.487.924
• Beachte, dass diese Zahlen höher als die tatsächlichen Werte sein können.

Liste betroffener Websites

1. Silid LMS

• Ein Lernmanagementsystem für Schüler und Lehrkräfte.
• Die meisten Nutzerdatensätze offengelegt, 27 Millionen Betroffene.

2. Online-Glücksspielnetzwerk

• Besteht aus 9 Websites, alle mit unterschiedlichem Design.
• Bei einigen Spielen war die Gewinnwahrscheinlichkeit manipuliert und lag bei 0 %.
• Als versucht wurde, das Problem zu melden, versuchte der Kundensupport zu ködern.
• Die meisten Bankkontoinformationen offengelegt, 8 Millionen.
• Die meisten Klartext-Passwörter offengelegt, 10 Millionen.

3. Lead Carrot

• Ein Online-Lead-Generator für Cold Calling.
• Eine der drei Websites mit den meisten offengelegten Nutzerdaten, 22 Millionen Betroffene.

4. MyChefTool

• Eine App zur Unternehmensverwaltung und Point-of-Service-Anwendung für Restaurants.
• Die meisten Namen und die zweitmeisten E-Mail-Adressen offengelegt, 14 Millionen bzw. 13 Millionen.

Ergebnisse

• 842 E-Mails in 13 Tagen versendet.
• 85 % der E-Mails zugestellt.
• 9 % der E-Mails zurückgewiesen.
• 24 % der Website-Betreiber behoben die Fehlkonfiguration.
• 1 % der Website-Betreiber antworteten.
• 0,2 % (2) der Website-Betreiber boten ein Bug Bounty an.

Meinung von GN⁺

• Diese Untersuchung zeigt, wie leicht Fehlkonfigurationen bei den Sicherheitseinstellungen von Firebase entstehen können. Sie ist ein wichtiges Beispiel dafür, Entwickler für Sicherheitseinstellungen zu sensibilisieren.
• Sie macht deutlich, dass die Reaktionen der Website-Betreiber auf entdeckte Sicherheitsprobleme unterschiedlich ausfielen. Die meisten behoben das Problem, einige ignorierten es jedoch oder boten keine angemessene Belohnung an.
• Die zur Suche nach diesen Sicherheitslücken eingesetzten Automatisierungstools können auch für andere Sicherheitsforscher nützlich sein. Werkzeuge mit ähnlichen Funktionen sind etwa OWASP ZAP und Burp Suite.
• Beim Einsatz von Cloud-Diensten wie Firebase ist es wichtig, die Sicherheitseinstellungen korrekt zu verstehen und anzuwenden. Fehlkonfigurationen können zu Datenlecks in großem Maßstab führen.
• Dieser Fall kann dabei helfen, beim Blick auf andere Dienste, einschließlich der Open-Source-Alternative Supabase, Sicherheitsfunktionen und Benutzerfreundlichkeit zu vergleichen. Supabase basiert auf PostgreSQL, bietet ähnliche Funktionen wie Firebase und ist Open Source.

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer, der lange bei Firebase gearbeitet hat, erwähnt, dass Probleme im Zusammenhang mit den Sicherheitsregeln das Produkt schon immer geplagt haben. Es wurden verschiedene Ansätze ausprobiert, dennoch stellte sich heraus, dass viele Datenbanken weiterhin sicherheitsanfällig sind. Das liegt daran, dass die Sicherheitsregeln von Firebase ein neues und komplexes Konzept sind und Entwickler dazu neigen, die Sicherheitsregeln nicht anzupassen, wenn sie zu bestehenden Daten neue Daten hinzufügen. Außerdem gibt es keine maßgeschneiderte Backend-Implementierung, was Massenscans erleichtert, und die Sicherheitsregeln der Realtime Database sind schwer zu schreiben und schlecht skalierbar. Da automatisierte Scans jedoch oft nur offen zugängliche Daten finden, tritt dieses Problem nicht so häufig auf, wie man denken könnte. Mit dem Firebase-Ansatz selbst gibt es technisch kein Problem, aber weil es eines der wenigen Backends ist, das auf gespeicherten Daten und Sicherheitsregeln basiert, ist es anfällig für Missverständnisse, unsachgemäße Nutzung und solche Probleme.
• Ein Nutzer erwähnt, dass ihn diese Situation an Fälle erinnert, in denen US-amerikanische Fast-Food-Ketten gehackt wurden.
• Ein anderer Nutzer weist darauf hin, dass laut dem letzten Teil dieses Beitrags 75 % der Sites mit solchen Schwachstellen immer noch auf einen Daten-Dump warten, und bewertet das als verrückt. Er fügt hinzu, dass er manchmal denkt, man brauche einen Führerschein, um mit Computern umzugehen.
• Ein Nutzer weist darauf hin, dass die Wahl von billig und schnell ein unvermeidliches Ergebnis sei, und erwähnt, dass die Sorgen einiger Kunden/Nutzer in der Diskussion fehlten und ihre persönlichen Daten den Preis dafür bezahlt hätten. Er warnt davor, bei den hier aufgelisteten Unternehmen vorsichtig zu sein, wenn sich deren Führung nicht geändert hat. Es sei wiederholt bewiesen worden, dass viele Unternehmen sich nicht genug darum kümmern, ihre Kunden zu schützen.
• Ein anderer Nutzer stellt die grundsätzliche Frage, ob die meisten in diesem Beitrag erwähnten Apps vollständig als statisch gehostetes clientseitiges JavaScript umgesetzt wurden und ob das Backend zu 100 % eine von Google gehostete Firebase-Konfiguration ist. Falls ja, erwähnt er, dass ihm nicht klar gewesen sei, wie verbreitet eine solche Architektur bei Sites mit Millionen von Nutzern ist.
• Ein Nutzer macht den Witz: 900 Sites, 125 Millionen Accounts, 1 Schwachstelle, 0 Freundinnen.
• Ein anderer Nutzer sagt, dass er in dieser Situation dankbar sei, sich schon vor langer Zeit für einen Passwort-Manager und virtuelle Karten entschieden zu haben. Er merkt an, dass die meisten Menschen nicht wüssten, wie fragil das Web ist und wie verletzlich sie selbst sind, und dass sich das Internet dadurch beängstigender anfühlt.
• Ein Nutzer berichtet, dass er festgestellt habe, dass ein Python-Programm mit etwa 500 Threads im Lauf der Zeit immer mehr Speicher verbraucht, und fragt, ob es dazu weitere Informationen oder Lösungen gibt. Er erwähnt, dass auch sein Python-Scraper Hunderte von Threads habe und offenbar viel Speicher nutze.
• Ein Nutzer lobt die gute Arbeit und möchte wissen, wie man zu der Schlussfolgerung gekommen ist, dass die Zahl der betroffenen Nutzer wahrscheinlich höher ist. Einige der erwähnten Sites (Glücksspiel, Lead Carrot) seien seiner Vermutung nach voller Fake-Account-Daten.
• Zum Schluss bedankt sich ein Nutzer dafür, dass der Kundensupport ihm einen Lacher beschert habe.