Selon ice0.blog, une analyse de ~1 200 applications mobiles parmi les plus populaires a mis en évidence des règles de sécurité Firebase faibles (« test mode » et règles permissives) conduisant à plus de 150 services ouverts — Realtime Database, Storage, Firestore et Remote Config — avec exposition de données sensibles; l’auteur publie l’outil OpenFirebase pour automatiser la détection sur plusieurs services et formats.

• Constat principal: des centaines d’apps (souvent à 100K+, 1M+, 10M+, 50M+, 100M+ téléchargements) utilisent Firebase (≈80%) et une part significative présente des accès non authentifiés. Données exposées: paiements, données utilisateurs, messages privés, mots de passe en clair, prompts, tokens GitHub/AWS à privilèges élevés, etc. L’incident « Tea » a servi de déclencheur, mais le problème est bien plus large.

• Cause: règles Firebase faibles ou test mode et couverture limitée des outils existants. Les services vulnérables incluent Storage, Realtime Database, Firestore et Remote Config. Les formats/URLs varient (anciens/nouveaux domaines et régions), rendant les scans naïfs incomplets. OpenFirebase a été conçu pour extraire les éléments Firebase d’APKs et tester automatiquement les permissions de lecture/écriture sur plusieurs services et formats.

• Résultats chiffrés (échantillon):

  • Storage (937 projets): 44 seaux publics; 386 protégés; 507 non trouvés. Exemple marquant: un bucket d’une app 100M+ contenant des photos d’identités d’utilisateurs accessibles.
  • Realtime Database (937 projets): 35 bases publiques; 277 protégées; 158 verrouillées/désactivées; 467 non trouvées. Données vues: noms, emails, mots de passe (parfois en clair), chats, coordonnées de localisation, etc.
  • Remote Config: 383 configs publiques; 61 protégées; 1 sans contenu; 429 apps sans Remote Config. Environ 30 configs contenaient des secrets (ex: clés OpenAI, AWS, GitHub); d’autres cas possibles n’ont pas tous été vérifiés.
  • Firestore (929 projets): 50 projets accessibles publiquement; 24 collections ouvertes identifiées; 675 protégés; 122 en Datastore Mode (souvent vides/inutilisés). Dans 18 cas (dont des apps 10M+), 3 ou 4 services sur le même projet étaient publics avec des données clients.

• Points techniques notables: nouvelles/anciennes formes d’URL pour Realtime DB (firebaseio.com, firebasedatabase.app, avec gestion des régions) et Storage (appspot.com et firebasestorage.app via l’API firebasestorage.googleapis.com). Remote Config nécessite le google_api_key et le google_app_id (extraits de strings.xml dans l’APK). Firestore est distinct de Realtime DB; les noms de collections (souvent repérés via décompilation JADX) permettent de tester l’accès; le fuzz de collections communes est intégré. Les vérifications d’écriture confirment souvent le test mode (p. ex. création/écriture de documents). Certaines règles v1 empêchent la « list » mais n’empêchent pas l’accès direct aux objets si le nom est connu.

• Outil: OpenFirebase automatise l’extraction (APKs ou Project IDs), teste lecture/écriture sur multiples services et formats, gère le multi-URL/format, le scan en masse et, en « Part II » annoncée, un scan authentifié avec contournement de restrictions de clés API Google. Des limites sont notées (ex: un check géré par un autre outil non-CLI), et l’auteur envisage d’examiner Cloud Functions.

Indicatifs techniques et TTPs:

  • Endpoints/artefacts clés (exemples de formats) 🔎:
  • TTPs 🛠️:
    • Extraction de Project IDs/artefacts Firebase depuis APKs (strings.xml, google-services.json, décompilation JADX)
    • Détection d’accès anonymes par variantes d’URL/format et gestion des régions
    • Vérifications lecture/écriture sur Storage/Realtime DB/Firestore
    • Fuzz de noms de collections Firestore; tests document/collection
    • Récupération de Remote Config avec google_api_key et google_app_id
    • Annonce d’un bypass des restrictions de Google API key (Part II)
    • Outils tiers mentionnés: Trufflehog, Gitleaks, Burp pour l’analyse de secrets

Conclusion: il s’agit d’une publication de recherche présentant des résultats de scan à grande échelle sur des mauvaises configurations Firebase et l’outil OpenFirebase pour auditer de multiples services et formats.

🧠 TTPs et IOCs détectés

TTP

Extraction de Project IDs/artefacts Firebase depuis APKs, Détection d’accès anonymes par variantes d’URL/format et gestion des régions, Vérifications lecture/écriture sur Storage/Realtime DB/Firestore, Fuzz de noms de collections Firestore, Récupération de Remote Config avec google_api_key et google_app_id, Annonce d’un bypass des restrictions de Google API key

IOC

<PROJECT_ID>.appspot.com, <PROJECT_ID>.firebasestorage.app, <PROJECT_ID>.firebaseio.com, <PROJECT_ID>-default-rtdb.firebaseio.com, <PROJECT_ID>.REGION.firebasedatabase.app, firestore.googleapis.com, content-firestore.googleapis.com, firebaseremoteconfig.googleapis.com

🔗 Source originale : https://ice0.blog/docs/openfirebase