Introduction
Présentation de Firebase
Firebase Realtime est une base de données NoSQL, rachetée par Google en 2014, bénéficiant d’un hébergement Cloud permettant de stocker et de synchroniser les données entre les utilisateurs en temps réel. Ces données peuvent inclure des flux en direct, des journaux d’ouverture de session, des discussions avec les clients, des journaux d’application, des détails sur les utilisateurs, et bien plus encore.
Ses fonctionnalités ainsi que sa facilité d’utilisation permettent aux développeurs (notamment mobiles) d’utiliser pleinement Firebase. En effet, grâce à la synchronisation en temps réel, les utilisateurs de l’application peuvent consulter leurs données depuis n’importe quel terminal sans distinction.
De plus, lors d’un passage en mode hors ligne, le cache permet d’enregistrer les modifications qui seront automatiquement synchronisées lorsque l’appareil sera en ligne.
Pourquoi s’en prendre à Firebase ?
Depuis plusieurs années, l’utilisation de Firebase devient monnaie courante dans la plupart des développements en utilisant principalement les bases de données en temps réel.
Dans sa configuration par défaut, les paramètres de la base de données sont privés. Néanmoins, pour utiliser une base de données en temps réel, il est nécessaire de définir les accès en lecture (read) ainsi que ceux en écriture (write).
Afin de stocker des informations dans la base de données, il est primordial d’activer l’écriture (write:true). Pour les lire, la lecture (read:true) devra être activée dans les règles d’accès.
Accès et vérification de la configuration
L’accès à la « configuration » de Firebase est relativement simple. En effet, pour l’URL suivante https://bssi.firebase.com/, il est possible de vérifier la configuration grâce à l’URL https://bssi.firebaseio.com/.json
La réception d’un « Permission denied » confirme la bonne configuration de la base (à minima, le read est à false) :
Tout espoir n’est pas perdu dans ce cas de figure. En effet, il est également possible que des enfants aient une configuration différente :
Dans le meilleur des cas, l’accès aux données peut également se faire de manière directe :
À la recherche de la base cachée
La manière douce
Dans une partie de cache-cache, il y a toujours plusieurs stratégies pour arriver à nos fins. La première consiste à chercher des indices pouvant nous mettre sur la piste des personnes que nous essayons de trouver. Un pied qui dépasse de derrière les rideaux, une porte anormalement fermée sont tout autant d’indices qui peuvent trahir celles et ceux qui tentent de se cacher. Sur Internet, c’est sensiblement la même chose !
Pour ce faire, la méthode la plus simple est de demander à notre moteur de recherche favori qu’il nous transmette ces informations grâce à une simple Dorks telle que « site:.firebaseio.com » :
Les indices ne semblent pas vraiment être légion à la suite de notre recherche. Néanmoins, comme indiqué en introduction, Firebase appartenant à la maison mère de Google, il y a donc fort à parier que ce moteur de recherche ne dévoile pas tout. Essayons donc avec Bing :
Cette différence de capture met en avant que Google a connaissance de la vulnérabilité, mais préfère la cacher. C’est ce qu’on appelle « la sécurité par l’obscurité ». Vivons heureux vivons cachés comme dirait Jean-Pierre !
De plus, il n’est pas nécessaire de réaliser une recherche avancée avant de trouver des informations potentiellement intéressantes pour un attaquant :
La manière moins douce
Comme spécifié en introduction, les bases de données Firebase sont toujours « conçues » de la même manière avec une URL ressemblant à https://NAME.firebaseio.com/.json. Dès lors, il est possible d’utiliser n’importe quel outil de bruteforce d’URL pour tenter d’identifier des bases Firebase qui ne seraient pas divulguées par Google. Ainsi, grâce à ffuf et ses 5290 requêtes par seconde, il est possible de venir à bout de la base d’Alexa (environ 600 000 entrées) en un peu moins d’une minute permettant de trouver quelques résultats intéressants :
Des identifiants, des mots de passe, des données personnelles le tout en libre accès ? Firebase is the new SQL Injection !
Une étude sur près de 4000 applications Android a permis de révéler l’exposition de 7 millions d’adresses mail, 5,3 millions de numéros de téléphone, 4,4 millions de noms d’utilisateur, 1 million de mots de passe, etc. Plutôt que prendre en compte ces importantes fuites d’informations, Google a préféré rejeter la faute sur les développeurs.
Post-exploitation sous Firebase ? Qu’ouis-je, qu’entends-je, qu’acoustiquais-je ?
La post-exploitation à la suite de la divulgation de 4,4 millions de noms d’utilisateurs et 1 million de mots de passe semble couler de source. Néanmoins, la configuration de la base de données peut également avoir des effets de bords sur les utilisateurs.
En effet, si les deux attributs (read et write) sont à true, il est possible pour un attaquant de réécrire les informations présentes en base :
Bien que les données injectées soient au format JSON, il est impossible de prévoir comment ces dernières seront interprétées au sein de l’application cible et il n’est pas impossible d’y exploiter une injection de code (XSS, SQL, RCE, etc.).
Conclusion
Pour contrer les attaquants, il est nécessaire d’utiliser leurs techniques (ou de le faire via des sociétés spécialisées) en avance de phase. Certains outils publiquement disponibles tels que firebase.py ou encore firebaseWritableCheck permettent d’exploiter les mauvaises configurations des bases Firebase.
Il est important de garder à l’esprit que la sécurité par l’obscurantisme ne dure qu’un temps et c’est pourquoi il est nécessaire de lire la documentation officielle, afin d’adopter les meilleures pratiques de sécurité.
Article originellement publié sur blog.bssi.fr