THIS IS AN EXCERPT FROM BRANDON EVANS'S NEW WHITEPAPER.
Firebase allows a frontend application to connect directly to a backend database. Security wonks might think the previous sentence describes a vulnerability, but this is by design. Released in 2012, Firebase was a revolutionary cloud product that set out to “Make Servers Optional”. This should raise countless red flags for all security professionals as the application server traditionally serves as the intermediary between the frontend and backend, handling authentication and authorization. Without it, all users could obtain full access to the database. Firebase attempts to solve this by moving authentication and authorization into the database engine itself. Unfortunately, this approach has several flaws.
Firebase is extremely popular. In 2014, two years after launching, it was acquired by Google after obtaining 100,000 developers on their platform. By then, Firebase had expanded their service offering to include static website hosting and authentication. Initially, it appeared that Google was trying to incorporate all of these novel services into their own cloud platform, the Google Cloud Platform (GCP). However, six years later, not only have Firebase’s original three services remained distinct, but Firebase has added 15 services.
Firebase’s current service offerings.
If you think your company does not use Firebase, think again. This platform is lurking in a shadow cloud account somewhere outside of your security organization's purview. Even enabling Firebase in a GCP project can expose your organization to risk. By accepting these realities and learning about Firebase, we can guide lean development teams to move both quickly and safely with security guardrails. This paper is a starting point for your journey towards Firebase security and risk management.
This paper will reference a real-time customer service chat ReactJS component that we have open-sourced. This is an ideal use-case for Firebase. Readers are encouraged to connect the component to their own Firebase project and follow along to gain hands-on experience with the technology. The exercises detailed here were originally featured in a SANS Tech Tuesday Workshop.
In 2018, security researchers reported a new variant of a vulnerability they dubbed “HospitalGown”. To call it a “vulnerability” is slightly misleading as the issue was caused by Firebase operating properly according to its design. HospitalGown describes a frontend application that otherwise might be secure, but it leverages a wide-open backend database that has not been configured to require proper authentication or authorization. The report provided alarming numbers regarding the widespread nature of this misconfiguration of the Firebase Realtime Database:
- 3,000 iOS and Android apps were leaking data from 2,300 unsecured Firebase databases.
- 620 million downloads occurred of vulnerable Android applications alone.
- Multiple app categories were affected: “tools, productivity, health and fitness, communication, finance, and business apps.”
- 62% of enterprises were claimed to be affected, although the report did not make clear how this was determined.
- 2.6 million plaintext user IDs and passwords, over 4 million “Protected Health Information” records, 25 million GPS location records, and 50,000 financial records were leaked.
Of the applications compromised, perhaps the most notable was Periscope, a mobile app owned by Twitter. The vulnerability was responsibly disclosed by Deeptiman Pattnaik. The disclosure is now public on HackerOne.
We can reproduce the HospitalGown misconfiguration using the real-time customer service chat mentioned above. After following the steps for Testing Locally, we must provide our Realtime Database with security rules that make the database world-readable and writable. There are several options that meet this qualification. For example, when a user creates a Firebase database with either engine, they can either start with Locked mode (no one can read from or write to the database) or Test mode (world-readable and writable for 30 days). Using Test mode results in the following HospitalGown misconfiguration:
Allow reads and writes as long as the current time is prior to 30 days from the instantiation of the Realtime Database (as measured by a 13-digit Unix Timestamp containing milliseconds).
Prior to the addition of Test mode, several development guides recommended making the database world-readable and writable indefinitely:
Allow reads and writes. No stipulations.
Three seconds after loading the chat application, we will receive a message from a fictional Customer Service agent:
Every time we send a message to the agent, we will automatically receive a reply stating, “One moment please.”:
If the frontend application can connect directly to the database, so can the attacker. First, they would need to locate the database’s endpoint. This can be done trivially in both Firefox and Chrome by right-clicking the page and selecting View page source. The result will look something like this:
Clicking the link to /static/js/main.chunk.js will open the minified JavaScript file. In it, we will be able to find the database config by searching for firebaseio.com:
This code is ugly (the technical term is uglified), but we can clearly make out the URL: https://<Database name>.firebaseio.com
With the endpoint URL for a wide-open Realtime Database, the attacker merely has to append .json to it and load it. After loading https://<Database name>.firebaseio.com/.json, they will see something like the following:
The private conversation between the customer and the agent is made public via the insecure backend Firebase database.
Because this database is also world-writable, the attacker could also hijack the session by adding a message that looks like it came from the agent. This too can be accomplished with a simple HTTP request, this time using the POST method:
Session ID refers to the top-level key nested within the “chats” object (in the previous example, this would be ZJeBoN7bg6PGyOrjG0wcBShw3j22). If the attacker does not have access to curl, they could alternatively make the request with a web application such as Hoppscotch.
This request would instantly result in a message being sent to the customer prompting for highly sensitive information:
READ BRANDON'S COMPLETE WHITEPAPER HERE.
About the Author: Brandon Evans is the lead author of SEC510: Multicloud Security Assessment and Defense and an instructor for SEC540: Cloud Security and DevOps Automation. His full-time role is as a Senior Application Security Engineer at Asurion, where he provides security services for thousands of his coworkers in product development across several global sites responsible for hundreds of web applications. This includes performing secure code reviews, conducting penetration tests, developing secure coding patterns, and evangelizing the importance of creating secure products. Read his full bio here.
Thanks to Kat Traxler (@NightmareJS) for her contributions regarding Firebase’s GCP integration and to Tarl Smith for providing details on Firebase data sovereignty and compliance.
