- Une seule règle de sécurité Firebase mal configurée a entraîné l’exposition des données utilisateur de plusieurs centaines de sites, pour un volume confirmé d’environ 124,6 millions d’enregistrements
- L’enquête a commencé en recherchant des variables de configuration Firebase dans les sites web et les bundles JavaScript chargés, puis a été réécrite en Go à cause de problèmes mémoire du scanner Python
- Le scanner auxiliaire Catalyst vérifie automatiquement si les collections Firebase sont accessibles en lecture et estime le type ainsi que le volume des données exposées à partir d’échantillons
- Les éléments exposés recensés comprennent 84 221 169 noms, 106 266 766 adresses e-mail, 33 559 863 numéros de téléphone, 20 185 831 mots de passe en clair et 27 487 924 éléments d’information de paiement
- Les chercheurs ont envoyé 842 e-mails de signalement en 13 jours, mais seuls 24 % des propriétaires de sites ont corrigé la configuration, 1 % ont répondu, et 2 sites seulement ont proposé une bug bounty
Scan à l’échelle d’Internet des expositions Firebase
- Après le cas de compromission de Chattr.ai, un scan de l’ensemble d’Internet a été lancé pour identifier les PII exposées via des instances Firebase mal configurées
- Le premier scanner en Python vérifiait les variables de configuration Firebase dans les sites web ou les bundles
.jschargés, mais en fonctionnant avec environ 500 threads, l’usage mémoire augmentait jusqu’à provoquer un OOM en moins d’une heure - Le scanner, ensuite réécrit en Go, a été exécuté sur 5,5 millions de domaines et a pris 2 à 3 semaines, soit plus que les quelque 11 jours initialement prévus
- La revue manuelle initiale avait déjà permis d’identifier 136 sites et 6,2 millions d’enregistrements, mais l’ampleur de la liste de candidats a rendu une automatisation complète nécessaire
Catalyst et estimation de l’ampleur de l’exposition
- Catalyst prend en entrée des sites candidats ou des bundles JavaScript, puis vérifie automatiquement l’accessibilité en lecture des collections Firebase courantes ainsi que de celles mentionnées directement dans le JavaScript
- Lorsqu’une collection accessible en lecture est trouvée, 100 enregistrements d’échantillon sont collectés pour identifier les types d’informations incluses, puis ce résultat est multiplié par la taille totale de la collection pour estimer l’impact
- Comme dépôt de résultats, le choix s’est porté sur Supabase, un concurrent open source de Firebase basé sur PostgreSQL, et les données nettoyées ont été envoyées dans une table de base de données privée
- Les chiffres agrégés sont les suivants, et l’ampleur réelle de l’exposition pourrait être supérieure aux valeurs affichées
- Enregistrements totaux : 124 605 664
- Noms : 84 221 169
- E-mails : 106 266 766
- Numéros de téléphone : 33 559 863
- Mots de passe : 20 185 831
- Informations de paiement : 27 487 924, dont informations bancaires et factures
Sites les plus touchés
-
Silid LMS
- Système de gestion de l’apprentissage pour étudiants et enseignants
- Avec 27 millions d’enregistrements utilisateur exposés, dont noms, e-mails et numéros de téléphone, c’est le cas le plus important
-
Réseau de jeux d’argent en ligne
- Composé de 9 sites redéclinés les uns des autres
- Certains spins étaient truqués pour ramener la probabilité de gain à 0 %
- Les informations de connexion détaillées de comptes bancaires étaient les plus exposées, avec 8 millions d’entrées
- Les mots de passe en clair ont également atteint 10 millions, le plus grand volume parmi les sites affectés
- Lors de la tentative de signalement du problème, le support client s’est mis à flirter pendant l’échange
-
Lead Carrot
- Service en ligne de génération de leads pour le cold calling
- Troisième plus gros volume de données utilisateur exposées, avec 22 millions de personnes affectées
-
MyChefTool
- Application de gestion d’activité et application POS pour restaurants
- Numéro 1 pour les noms exposés et numéro 2 pour les e-mails, avec respectivement 14 millions et 13 millions d’éléments exposés
Réactions après les signalements
- Les chercheurs ont envoyé 842 e-mails sur 13 jours
- 85 % ont été distribués et 9 % ont rebondi
- 24 % des propriétaires de sites ont corrigé la mauvaise configuration
- Seuls 1 % des propriétaires de sites ont répondu
- 2 propriétaires de sites, soit 0,2 %, ont proposé une bug bounty
1 commentaires
Avis de Hacker News
J’ai travaillé longtemps chez Firebase, et le problème des règles de sécurité a toujours continué à hanter le produit
On a essayé plusieurs approches, comme des règles par défaut qui expirent automatiquement ou un meilleur accompagnement, mais au final on voit encore beaucoup de bases de données non sécurisées
Les raisons sont complexes : les règles de sécurité à la Firebase restent un concept peu familier, et quand un nouveau développeur ajoute des données à un emplacement existant, il ne pense souvent pas à modifier aussi les règles en fonction de l’évolution des exigences de confidentialité de ces données
En plus, la « sécurité par l’obscurité » qu’apportait un backend maison disparaît, ce qui facilite les scans à grande échelle
En particulier, les règles de Realtime Database sont difficiles à écrire et passent mal à l’échelle, mais comme les scans automatiques cherchent généralement seulement les données ouvertes, il suffisait souvent d’être un peu meilleur que
read write truepour s’en prémunirTechniquement, l’approche de Firebase n’est pas mauvaise en soi, mais comme c’est presque le seul backend à utiliser un modèle centré sur les données stockées et les règles de sécurité, il est particulièrement exposé aux malentendus, aux mauvais usages et à ce type d’incidents
Dans un backend classique, validation et règles de sécurité font partie de la spécification, alors que les règles de sécurité de Firebase sont une étape séparée qu’on oublie facilement et qu’il faut réévaluer à chaque nouvelle fonctionnalité
Pour attirer l’attention de quelqu’un capable de prévenir les propriétaires de projet, il aurait probablement fallu faire remonter l’affaire à un niveau assez élevé en interne chez Firebase
Par exemple, est-ce que des modèles comme « seul le propriétaire du contenu peut y accéder » ou « accès basé sur les attributs / les rôles » couvriraient les schémas de la plupart des applications, ou bien faut-il réellement beaucoup de règles sur mesure ?
Le gros problème de l’écriture des règles de sécurité, c’est que presque toute erreur devient un problème de sécurité, donc on préfère ne pas y toucher si ce n’est pas nécessaire
Si les règles sont trop verrouillées, l’application cesse de fonctionner et ça se voit tout de suite, mais si elles sont trop ouvertes, l’excès d’accès reste souvent invisible tant qu’on ne va pas le tester soi-même
À ce sujet, on pourrait aussi envisager d’obliger les développeurs à écrire, pour chaque règle de sécurité, des cas de test d’exemple où l’accès doit être refusé
fireplanajoutait une règle"$other": {".read": false, ".write": false}par défaut à toutes les propriétésGrâce à ça, les nouveaux champs devaient être ajoutés explicitement, ce qui rendait presque impossible qu’une nouvelle valeur « hérite » sans qu’on s’en rende compte de règles existantes
J’utilise Firebase depuis plus de 10 ans, donc je ne sais pas si les outils de règles les plus récents fonctionnent toujours ainsi
Ce qui aiderait vraiment, ce serait un support natif pour renommer des champs ou faire évoluer la structure des données quand on doit gérer plusieurs versions de clients difficiles à contrôler, un moyen léger de tester les règles sans lancer la base de données, et de meilleures informations de débogage quand une règle échoue en production
À chaque échec, il faudrait enregistrer aussi toutes les valeurs auxquelles la règle a accédé, afin de pouvoir déboguer les échecs temporaires causés par des données qui changent
C’est un modèle conceptuel insuffisamment expliqué
Sur nos projets, on dit que chaque collection doit avoir un profil de sécurité — public, données utilisateur, visible uniquement aux utilisateurs authentifiés, réservé aux administrateurs, etc. — et on essaie d’imposer ces catégories via des fonctions de règles de sécurité plutôt qu’en écrivant des conditions sur mesure pour chaque collection
Penser la sécurité au niveau de la collection plutôt qu’au niveau du champ réduit les cas où différentes intentions de sécurité se retrouvent mélangées dans un même document
Si une collection est publique, elle ne doit pas contenir de champs non publics ; si nécessaire, on peut utiliser un trigger Firestore pour recopier des données d’un contexte sensible vers un contexte public, mais pas dans l’autre sens
Le problème, c’est qu’il faut documenter l’intention des règles en dehors des règles elles-mêmes, ce qui rend les erreurs d’application faciles ; écrire les tests était autrefois pénible, mais ça s’est beaucoup amélioré
Ça me fait penser à « How I pwned half of America’s fast food chains, simultaneously. » : https://mrbruh.com/chattr/
HN : https://news.ycombinator.com/item?id=38933999
After the initial buzz of [pwning Chattr.ai] had settled down, […]Sauf erreur de ma part, ça veut dire qu’au moment où l’article se termine, 75 % des sites concernés par cette vulnérabilité sont encore ouverts et exploitables, non ?
C’est dingue
Certains jours, je me dis qu’il devrait falloir un permis pour toucher à un ordinateur
Elles sous-traitent leur site web à une agence, qui fait tourner les développeurs, met de bons profils au début puis confie ensuite le contrat à des développeurs moins expérimentés tant que l’entreprise ne se plaint pas
L’e-mail sur la vulnérabilité a probablement été ignoré comme du spam, ou transféré puis abandonné, ou mis dans la file d’attente des réunions d’un chef de projet comme un élément à corriger en facturant au maximum le client
Même dans les domaines où un permis professionnel est obligatoire, on trouve beaucoup de titulaires incompétents
Les médecins ont pourtant une formation et des exigences de licence énormes, mais il ne manque ni charlatans ni praticiens de médecines alternatives dûment autorisés
J’ai fait de mon mieux en envoyant à chaque site un e-mail personnalisé expliquant ce qui était touché, comment corriger le problème et comment me contacter
C’est le résultat inévitable du choix bon marché et rapide dans le triangle cheap-fast-good du PM
Malheureusement, les inquiétudes de certains clients et utilisateurs ont été écartées de la discussion, et leurs données personnelles en ont payé le prix
Parmi les entreprises listées ici, je me méfierais de celles qui ont pris ce genre de décision sans que leur direction ne change
Il a été prouvé à de nombreuses reprises que beaucoup d’entreprises ne se soucient pas assez de protéger leurs clients, et l’histoire se répète
J’ai une question très basique sur Firebase : la plupart des applis mentionnées dans cet article étaient-elles construites sans code serveur personnalisé, uniquement avec du JavaScript côté client hébergé en statique ?
Je me demande si cela signifie que le backend était une configuration Firebase hébergée à 100 % par Google
Si oui, je ne réalisais pas que ce type d’architecture était devenu si courant pour des sites comptant des millions d’utilisateurs
C’est le résultat inévitable d’un modèle de sécurité allow by default au niveau de l’API
Malheureusement, les bibliothèques visant les développeurs JavaScript ont souvent des valeurs par défaut peu sûres, et GraphQL semble aussi être un domaine propice à ce genre de problème
Firebase propose aussi des Firebase Functions, des fonctions appelables dans le cloud, et ce code n’est pas public
Mais pour Firestore ou Firebase Realtime Database, c’est à l’utilisateur de définir les règles de sécurité ; sinon, n’importe qui peut lire toutes les données
L’important, c’est de rendre l’écriture de règles d’autorisation correctes facile côté backend
Quand je vois ce genre de choses, je suis bien content d’avoir adopté depuis longtemps un gestionnaire de mots de passe et des cartes virtuelles
Malgré tout, Internet fait de plus en plus peur
La plupart des gens n’ont absolument aucune idée de la fragilité du web ni de leur niveau d’exposition
Les agents IA vont trouver les vulnérabilités bien plus efficacement que les bots, donc on se dirige vers un futur assez étrange
Il faut utiliser une adresse e-mail unique pour chaque service auquel on s’inscrit
Cela permet de limiter les dégâts en cas d’incident et d’éviter que des informations publiques soient recoupées avec celles d’autres services
Il arrive même qu’en recevant un e-mail malveillant sur cette adresse unique, on découvre la compromission avant l’exploitant du site
Quelqu’un en sait plus sur le passage disant qu’« un programme Python avec environ 500 threads commence à consommer de la mémoire avec le temps » ?
J’ai moi aussi un scraper en Python avec plusieurs centaines de threads, et j’ai l’impression qu’il consomme beaucoup de mémoire
Je me demande s’il existe un contournement, ou si la seule vraie solution est de le réécrire dans un autre langage
Personnellement, je préfère les processus aux threads, et les pools de workers avec un bus de messages plutôt que la mémoire partagée
Cette solution a aussi ses inconvénients et un léger surcoût, mais on se soucie beaucoup moins des problèmes de mémoire
Pour un crawler, le modèle par processus semble mieux adapté, car le nombre de processus reste relativement stable et le travail de chacun est indépendant
import multiprocessing as threadingRéécrire est à peu près la seule solution réellement pratique
C’est un cas d’usage qui lui correspond très bien
Bien joué
Je me demande comment vous êtes arrivés à la conclusion que le nombre réel d’utilisateurs affectés est probablement plus élevé
À vue d’œil, certains sites, comme les sites de paris ou Lead Carrot, pourraient contenir beaucoup de fausses données de comptes
C’est une méthode qui fonctionne surtout sur les sites en anglais
Si nous avons dit qu’il y en avait probablement davantage, c’est aussi parce que d’autres services non présents dans la liste scannée pourraient être vulnérables