Last month, I gave a talk on the exploitation of insecure Firebase applications with my Baserunner tool at BSides Joburg.

I first developed this tool while pentesting a Firebase app in 2021, and have used it in many similar assessments since. It’s essentially a database query tool. Given a Firebase configuration and user credentials, it can run the same Firestore, Realtime Database, and Storage Bucket queries as the legitimate application, without the artificial constraints of the front-end.

If you found this interesting, you may enjoy this list of further reading:

Introducing Baserunner: a tool for exploring and exploiting Firebase datastores

The release blogpost for Baserunner, which covers some of the same ground as the talk above.

Firebase: Google Cloud’s Evil Twin

A 2020 whitepaper from Brandon Evans at SANS on these kinds of attacks.

Firebase: Insecure by Default

A write-up by Aditya Saligrama on compromising a college social media app with Baserunner.

Dodging OAuth origin restrictions for Firebase spelunking

A blogpost about implementing Google OAuth login in Baserunner, also from Aditya Saligrama.

gaining access to anyones browser without them even visiting a website

A blogpost by xyzeva about a remote JavaScript code execution vulnerability in the Arc browser (CVE-2024-45489), caused by an insecure Firebase datastore. The researcher didn’t use Baserunner, but this is one of most interesting vulnerabilities caused by insecure Firebase storage.

As I mentioned towards the end of the talk, a social media application named Tea suffered a massive data breach the day before I presented. It was built on Firebase and used an insecure Storage Bucket to host users’ ID verification images and documents – Storage Buckets use the same rule engine as Cloud Firestore. This is grimly portentous in light of recent pushes for legislation in various countries aimed at compelling websites to verify user identities.