Analysing Misconfigured Firebase Apps: A Tale of Unearthing Data Breaches (Wave 10)
Introduction
In the last few years, Data breaches have been on the rise. Apart from the web servers, mobile applications and other assets that are generally targeted, a popular mobile and web application development platform named “Firebase” have become a hot target for hackers.
It offers a product named “Firebase Realtime Database”, which is a cloud-hosted database. The data is stored as JSON and synchronised in real-time to every connected client using a NoSQL cloud database. This product is vulnerable to information leakage if not configured correctly.
We at RedHunt Labs conducted a mass scan on a sample of ~40000 Firebase subdomains to understand their state of security. This wave details the common misconfiguration found in Firebase applications and our findings from the scan regarding data breaches.
Understanding the Vulnerability
The actual vulnerability lies in the (mis)configuration of these databases. Go to the “Rules” tab of the database section in your Firebase dashboard, and you’ll observe that these real-time databases are set to be protected by default, meaning that no one can write or read data of the database using the firebase reference URL.
As we can see in the above image, the “.read” and “.write” flags are set to false. Developers must set the “.write” flag to true if they want to store anything in the database. But sometimes, while testing the database, the developers tend to make the “.read” flag true as well, which lets anyone with the firebase reference URL read the database’s content without any authentication mechanism in place.
As we can see in the image above, the “.read” flag is set to true, due to which anyone with a firebase reference URL can easily access all the data in a database. Despite a very clear warning, as can be seen in the image, users tend to miss out and (un)intentionally end up leaving these instances out there for attackers.
A malicious actor can exploit this misconfiguration by using that specific database’s firebase URL. The general format of these URLs is “https://some-name-here.firebaseio.com/”. We can find this URL pattern from various mobile applications, web pages etc., and it is generally used to store/retrieve their data.
If we append “.json” to the URL, i.e., “https://some-name-here.firebaseio.com/.json”, and make a request to the URL, it should return with a JSON output. If the database has been appropriately configured, it should return with output as shown below.
However, in case the database is misconfigured, the result would include the contents of the database in JSON format, as we can see in the below image.
Our Approach
Initially, we started with a sample of a decent number of the firebase subdomains we would like to check out in this scan. Apart from the 14,000 URLs, we picked a few from our last wave when we scanned mobile applications; we also referred to Github and some other platforms to fetch such subdomains present on them.
We then passed it to our internal tools (a subset of our ASM platform) to check the response they returned after appending “.json” to the end of the URL. We then filtered out any URLs returning errors in the JSON, indicating that the specific Firebase Realtime Database is having some issue or has been appropriately configured.
After this step, we reviewed all the data through Regular Expression patterns to log the count of all the leaked data across these databases before finally disposing of all the data securely.
Below is an architectural overview of our scan.
Our Findings
Hopping on to the findings from the research, after scanning 43,169 firebase URLs, we discovered that 7,916 of them were vulnerable, indicating that 1 out of every five Firebase databases is vulnerable to misconfigurations.
We found several interesting items from the data. This includes (not limited to) emails, usernames, passwords, addresses, phone numbers etc.
In the above infographic, we can see the count of various exposures discovered in these databases.
We discovered that the emails found in the breach also contained accounts belonging to large organizations such as Google, Facebook, Amazon, and a few government agencies.
We also found a total of 1,43,894 private messages of users to whom these databases served to.
Apart from these things, we even discovered exposures which could help identify an individual’s blood group, religion, age, interests, income and hobbies, to name a few.
We also discovered two browser applications from our last wave, which turned out to be logging the browsing history of their users in their misconfigured firebase databases. The package names of these applications are browser4g.fast.internetwebexplorer and webexplorer.amazing.speed, and collectively they had a userbase of more than 15 million.
One interesting thing we noted here is that, although both of these applications share different names, the developer contact email of webexplorer.amazing.speed matches the one mentioned in the privacy policy of browser4g.fast.internetwebexplorer. The email is contact@zoomob.com.
Interestingly, although the first developer claims to be from Hong Kong, the second one claims to be from San Francisco.
Although both of these browsers have now securely configured their databases after potentially noticing our traffic across the URLs, we were able to log the data when they were misconfigured successfully.
Below is an infographic showing the data present in their respective database endpoints. RedHunt Labs is currently in the process of reporting the applications to Google Playstore as well as Firebase.
Mitigation
Developers are advised to make sure that they don’t set the “.read” flag in Firebase to true since that becomes the primary cause for unauthorised access to the contents of the database with the help of a database’s URL.
They are also advised to encrypt all the data before storing anything in the database to prevent a malicious actor from having direct access to any sensitive information.
Conclusion
Such misconfigurations are here to stay; developers need to take preventive measures to deal with them and prevent malicious actors from accessing sensitive information they might store in such databases. Our study shows that even developers of applications with large user bases fall prey to such mistakes and end up leaving millions of their users prone to data breaches.
The browser applications we discovered during the research are yet another warning for the users of such applications to make sure that they only use reliable browsers, considering how much sensitive information could be found through the browser history.
Taking the sensitivity of data into consideration, we at RedHunt Labs are already in the process of reporting these misconfigured Firebase databases and have securely disposed of all the scan data.
How can we help?
Our SaaS-based Attack Surface Management solution, NVADR, continuously keeps track of your organization’s external digital footprint by identifying and profiling the assets as they surface on the internet. The assets we identify are way beyond IP Addresses and Subdomains, and we cover a wide variety, including Docker Containers, Mobile Applications, Code Repositories, and much more. Once these assets are identified, we find security misconfigurations across all asset classes (including secret exposures and misconfigured cloud storage buckets).
To understand how NVADR can help your organization improve its external digital footprint and security posture, Request a Demo.
