900 sites, 125 millions de comptes, 1 seule vulnérabilité

Première tentative

• Un scanner basique écrit en Python vérifiait les variables de configuration Firebase.
• Il s'est arrêté de fonctionner en moins d'une heure à cause de problèmes de consommation mémoire.

Deuxième tentative

• Le scanner réécrit en Go ne présentait pas de fuite mémoire.
• L'analyse de plus de 5 millions de domaines a pris plus de temps que prévu.

Vérification manuelle de tous les domaines

• Chaque entrée d'un fichier texte de 550 000 lignes a été inspectée manuellement.
• 136 sites et 6,2 millions d'enregistrements ont été confirmés, mais il est devenu évident qu'une méthode automatisée était nécessaire.

Catalyst

• La liste des sites potentiellement affectés a été examinée avec un scanner auxiliaire appelé Catalyst.
• Il vérifiait automatiquement l'accès en lecture à des collections Firebase communes sur les sites ou dans les bundles .js.
• Un échantillon de 100 enregistrements a été collecté afin d'évaluer l'impact des données et d'identifier les types d'informations exposées.
• Supabase (un concurrent open source de Firebase) a été choisi pour stocker les résultats.

Les chiffres

• Enregistrements totaux : 124 605 664
• Noms : 84 221 169
• E-mails : 106 260 766
• Numéros de téléphone : 33 559 863
• Mots de passe : 20 185 831
• Informations de paiement : 27 487 924
• À noter que ces chiffres peuvent être supérieurs à la réalité.

Liste des sites affectés

1. Silid LMS

• Système de gestion de l'apprentissage pour les élèves et les enseignants.
• Le plus grand nombre d'enregistrements d'utilisateurs exposés, avec 27 millions de personnes affectées.

2. Réseau de jeux d'argent en ligne

• Composé de 9 sites, tous avec des designs différents.
• Certains jeux étaient truqués avec une probabilité de gain de 0 %.
• Lors d'une tentative de signalement du problème, le service client a cherché à amadouer le chercheur.
• Le plus grand nombre d'informations de comptes bancaires exposées : 8 millions.
• Le plus grand nombre de mots de passe en clair exposés : 10 millions.

3. Lead Carrot

• Générateur de leads en ligne pour le cold calling.
• L'un des 3 sites ayant exposé le plus d'informations utilisateurs, avec 22 millions de personnes affectées.

4. MyChefTool

• Application de gestion d'activité et point de vente pour les restaurants.
• Le plus grand nombre de noms exposés et le deuxième plus grand nombre d'e-mails exposés, avec respectivement 14 millions et 13 millions.

Résultats

• 842 e-mails envoyés en 13 jours.
• 85 % des e-mails ont été délivrés.
• 9 % des e-mails ont rebondi.
• 24 % des propriétaires de sites ont corrigé l'erreur de configuration.
• 1 % des propriétaires de sites ont répondu.
• 0,2 % (2) des propriétaires de sites ont proposé une bug bounty.

L'avis de GN⁺

• Cette étude montre à quel point une mauvaise configuration de sécurité Firebase peut se produire facilement. C'est un cas important qui rappelle aux développeurs la nécessité de prêter attention aux paramètres de sécurité.
• On constate que les réactions des propriétaires de sites variaient lorsqu'un problème de sécurité était découvert. La plupart ont corrigé le problème, mais certains l'ont ignoré ou n'ont pas proposé de compensation appropriée.
• Les outils d'automatisation utilisés pour trouver ces vulnérabilités peuvent aussi être utiles à d'autres chercheurs en sécurité. Parmi les outils offrant des fonctionnalités similaires, on peut citer OWASP ZAP et Burp Suite.
• Lorsqu'on utilise des services cloud comme Firebase, il est important de bien comprendre et appliquer les paramètres de sécurité. Une mauvaise configuration peut conduire à des fuites de données à grande échelle.
• Ce cas peut aussi aider à comparer les fonctions de sécurité et la facilité d'utilisation d'autres services, y compris l'alternative open source Supabase. Supabase repose sur PostgreSQL et offre des fonctionnalités similaires à Firebase tout en étant open source.

[GN⁺]

Avis Hacker News

• Un utilisateur ayant longtemps travaillé chez Firebase mentionne que les problèmes liés aux règles de sécurité ont toujours été un point faible du produit. Plusieurs approches ont été essayées, mais il a tout de même constaté que de nombreuses bases de données restaient vulnérables. Cela s’explique par le fait que les règles de sécurité de Firebase constituent un concept nouveau et complexe, et que les développeurs ont tendance à ne pas les mettre à jour lorsqu’ils ajoutent de nouvelles données à des données existantes. En outre, l’absence d’implémentation de backend personnalisé facilite les scans à grande échelle, et l’écriture de règles de sécurité pour la base de données temps réel est difficile et peu scalable. Cependant, comme les scans automatisés ne trouvent souvent que les données laissées ouvertes, ce problème ne se produit pas aussi souvent qu’on pourrait le penser. L’approche de Firebase elle-même ne présente pas de problème technique, mais comme c’est l’un des rares backends reposant uniquement sur les données stockées et les règles de sécurité, cela le rend sujet aux malentendus, aux mauvaises utilisations et à ce type de problèmes.
• Un utilisateur dit que cette situation lui rappelle des cas de piratage de chaînes de fast-food américaines.
• Un autre utilisateur souligne que, d’après la dernière partie de ce post, 75 % des sites présentant ce type de vulnérabilité attendent toujours un dump de données, ce qu’il qualifie de complètement fou. Il ajoute qu’il lui arrive de penser qu’il faudrait un permis pour utiliser un ordinateur.
• Un utilisateur fait remarquer que choisir le moins cher et le plus rapide mène inévitablement à ce résultat, et que certaines inquiétudes des clients/utilisateurs étaient absentes de la conversation, tandis que leurs données personnelles en ont payé le prix. Il avertit qu’il faut se méfier des entreprises listées ici dont la direction n’a pas changé, car il a été démontré à maintes reprises que beaucoup d’entreprises ne se soucient pas assez de la protection de leurs clients.
• Un autre utilisateur pose une question de base : la plupart des apps mentionnées dans ce post sont-elles entièrement implémentées en JavaScript côté client hébergé statiquement, avec pour seul backend une configuration Firebase hébergée à 100 % par Google ? Si c’est bien le cas, il dit qu’il ne réalisait pas à quel point cette architecture est courante pour des sites comptant des millions d’utilisateurs.
• Un utilisateur plaisante : 900 sites, 125 millions de comptes, 1 vulnérabilité, 0 petite amie.
• Un autre utilisateur dit que cette situation lui fait apprécier d’avoir adopté depuis longtemps un gestionnaire de mots de passe et des cartes virtuelles. Il ajoute que la plupart des gens ne savent pas à quel point le web est vulnérable, ni à quel point eux-mêmes le sont, et qu’Internet lui paraît encore plus effrayant.
• Un utilisateur explique avoir constaté qu’un programme Python avec environ 500 threads utilise de plus en plus de mémoire au fil du temps, et demande s’il existe plus d’informations ou une solution à ce problème. Il ajoute que son scraper Python possède lui aussi des centaines de threads et semble consommer beaucoup de mémoire.
• Un utilisateur félicite l’auteur pour ce bon travail et aimerait savoir comment il est arrivé à la conclusion que le nombre d’utilisateurs touchés serait encore plus élevé. Il soupçonne que certaines des données de comptes sur quelques sites mentionnés (jeux d’argent, lead carrot) sont remplies de faux comptes.
• Enfin, un utilisateur remercie l’auteur en disant que le support client l’a bien fait rire.