MrBruh's Epic Blog

1.4 Billion user records exposed by insecure firebase instances in top android apps

TLDR: Out of the top 1.5 Million android apps on the Play Store, 11,305 were insecure and exposed users PII. In total these 11 Thousand apps exposed 1.43 Billion user records.

Two years ago, along with a few friends, we looked into scanning the internet for insecure Firebase instances. I wanted to take another look, scanning mobile apps instead of websites.

Part One: Downloading & Parsing

To do this, I reached out to the University of Luxembourg who provided me with access to their AndroZoo dataset. In total we were provided with 1.5 Million API credits to make use of.

To calculate the list of apps and file ids, I downloaded their Google Play Metadata dataset, and used some SQL to generate a list of the top 1.5 million most popular apps based on their download count, and also output the SHA256 hash of the latest version for each app.

Unfortunately, there was one small issue with this. The size of all of the APKs combined, totalled to around 42 terabytes of data, and on my VDSL connection, it would’ve taken over 4 and a half months to finish downloading. Not to mention, who has 42 terabytes of free storage lying about.

The solution to this came in two parts. First, I decided to split the workload into multiple chunks, and spreading the work across across multiple machines. I asked a few friends of mine for help with this.

Secondly, I made the decision to avoid storing all of the downloaded APK’s, and instead opted to parse them on the fly & only save the relevant information to our research. For this, I ported a tool by Google called ArscBlamer. This program allowed for the parsing of a key:value store in APK’s called resource.arsc, and let us extract the Firebase project-id and Google API Key from the app.

All up, the development of this program took about a month of on-and-off work to write, test and polish to point where I was confident that it could autonomously download and parse all 1.5 Million apps without crashing or failing in any way.

At this point, it was time to let it loose and see how well it could do when deployed for real.

…

A week later, we had results. Out of the 1.5 million apps downloaded, 800,000 apps had valid Firebase configurations that were able to be extracted.

It’s important to note that a large portion of these apps only used Firebase for analytics, rather than for storing data.

Part Two: Scanning for misconfigured instances

I wanted to be as ethical as possible when scanning for misconfigured Firebase instances. To achieve this, I wanted to avoid requesting any samples of user data and instead just request the number of rows in the vulnerable collection.

This would make it more difficult to understand the exact type of data that was being exposed, however I was confident that it’s composition would likely be similar to my previous internet-wide Firebase scan, for which I had statistics for the type of information that was being exposed.

I have published an open source version of the Firebase checker/scanner on Github for those who want to more deeply understand how it works.

Website: https://firewreck.github.io/

Source Code: https://github.com/firewreck/firewreck.github.io/blob/main/index.html

In short it attempts to register a dummy account and request an authentication token for it, then it requests a structuredAggregationQuery for the total entries in the “users” collection using said Bearer token. If sign-ups are disabled, it will fall back and attempt the structuredAggregationQuery unauthenticated.

To test all 800 thousand Firebase instances, it took about 5 hours, however in reality this took course over the span of a couple days due to me finding and fixing multiple bugs during earlier test runs.

Part Three: The results

The results of the scan are as follows:

Total Vulnerable Firebase Instances: 11,305

Total Exposed user records: 1,436,747,729 (1.43 Billion)

Total Vulnerable app downloads: 2,605,162,019 (2.6 Billion)

If I take the ratio’s of the type of information found exposed by Firewreck I, and apply them to the user record count of Firewreck II it gives the following estimated results:

For reference, here’s a list of the biggest breaches from Have I Been Pwned.

HIBP.avif

Here is a graph showing the distribution of vulnerable android apps based on their total downloads according to the Google Play Store.

Here is a table showing the same data:

App Count
100M Downloads 5
50M Downloads 10
10M Downloads 65
5M Downloads 62
1M Downloads 338
500K Downloads 258
100K Downloads 1080
50K Downloads 728
10K Downloads 2345
5K Downloads 1325
1K Downloads 3050
500 Downloads 1173
100 Downloads 457
50 Downloads 53
10 Downloads 173
5 Downloads 64
1 Downloads 119

Graph of the distribution of number of exposed user records: ![[graph_inverted_engineer 1.png]]

The most common bucket was log(8) aka ~3,000 users per Firebase instance, however it went as high as ~35 Million exposed users for three different popular android apps.

Exponent (n) Decimal Value
log(2) 7
log(3) 20
log(4) 55
log(5) 148
log(6) 403
log(7) 1,097
log(8) 2,981
log(9) 8,103
log(10) 22,026
log(11) 59,874
log(12) 162,755
log(13) 442,413
log(14) 1,202,604
log(15) 3,269,017
log(16) 8,886,111
log(17) 24,154,953
log(18) 65,659,969

Part Four: Reporting

For reporting, I decided to use the developer contact emails which were included in the Androzoo Google Play Metadata dataset, combined with an email template I made that would automatically be filled out with the relevant details.

For sending these emails out, I settled on using resend as it would only cost me $20 to send out 20 thousand emails and the documentation for it seemed very mature. After filtering out Firebase instances with less than 10 users and letting my computer run for a couple of hours, it ended up sending out a total of 9,905 emails with 16% of them bouncing.

Statistics:

Part Five: Google’s Response

I also reported this issue, and the list of vulnerable Firebase project-ids to Google’s through their Firebase support form and their Bug Hunters portal.

Firebase support

I received a response back from their Firebase support in two days, here it what it said:

Hello MrBruh, 

Thank you for reaching out to Firebase Support, this is <Support Agent> and I will be happy to help you out.

I understand you are reporting a large number of Firestore instances with potentially insecure rules. While we cannot process external lists to send manual notifications to project owners, I want to assure you that we have systems in place to address this.

Firebase actively monitors for insecure Security Rules (such as allow read, write: if true;). When we detect these configurations, we automatically send Insecure Rules Alerts via email to the project owners and display warnings directly in the Firebase Console. These automated systems are designed to notify developers so they can take corrective action.

At the same time, if you believe that you have identified a vulnerability in the Firebase platform itself, or a way to bypass our security checks, I would encourage you to file a report through the Google Vulnerability Reward Program (VRP) at [bughunters.google.com](https://bughunters.google.com/). This will ensure that your findings are triaged by our dedicated security engineering teams.

I hope this gives you a sense of direction regarding your findings. If you have any questions or concerns, please feel free to contact me. 

Cheers, 

<Support Agent>

While it was good to hear that Google automatically alerts owners who have insecure Firebase rules, I wanted to test this for myself.

open_security_rule.avif

Firebase automatically warns if you allow unrestricted read/write access…

authed_security_rule.avif

… But gives no such warning when giving unrestricted read/write access to any authenticated user.

insecure_rules_docs.avif

Despite this exact configuration being warned against in Google’s documentation for insecure Firebase rules!

Google’s Vulnerability Reward Program

…

Part Six: The Aftermath

…

Timeline

Credits