HospitalGown: Are Firebase Apps Still Vulnerable in 2020?

In 2017, Appthority — which was acquired by Symantec — which was acquired by Broadcom, uncovered a very nasty threat to Firebase apps. This wasn’t caused by a loophole in Firebase itself, but by the classic human negligence. In 2018, over 3000 apps were discovered to be leaking over 100 million exposed records from misconfigured Firebase backend databases. Their Mobile Threat Team (MTT) aptly named this type of backend exposure HospitalGown.

By default, security rules on Firebase databases are open for all.

It’s left to the developer to properly configure rules for every table. Follow me as I dive deep into what happened, why it happened, what could still happen and what we can do about it.

So what happened?

Over 100 million records were breached, but what were they? This matters because it helps us understand the severity of the incident. If they were just a list of scraped IMDB records, that would’ve been nice. No, it was worse. Some regulated data including medical information, sensitive personal data, vehicle license plate numbers and credit card information were exposed. Other leaked records include personal data, GPS LOCATION RECORDS and enterprise data (private keys, access credentials, sales info and private conversations). What else? Passwords. User passwords stored in PLAIN TEXT.

These were not just side projects or amateur apps. These were real, live apps from serious players, including the Twitter-owned Periscope, the Donald Daters App and WorkHive: team chat app. Appthority’s MTT reported that 62% of all enterprises had at least one vulnerable app.

How could this be exploited?

The primary vector is the fact that misconfigured apps expose the entire database via a single endpoint — https://[xxx].firebaseio.com/.json (where xxx is the app name). For a misconfigured app, all data will be dumped beautifully in JSON format.

Yet, a vulnerable app could still be compromised without an attacker knowing the firebase app url. Android apps have been decompiled to reveal the app url from the string resources. Multiple cases of successful takeover of Firebase databases have been reported, including an attack on the Periscope app by a bug bounty hunter. This person was able to read, write, update and delete data without breaking a sweat.

Easy peasy, wake up Chris Breazy

Where an attacker does not have a specific target, a DNS enumeration scan is performed on the firebaseio.com domain using tools like dnsdumpster to find subdomains. However, this vector appears to have been blocked as the domain no longer exposes app URLs in A-records. It appears that Firebase is using a wildcard to capture all app subdomains. Several apps could also be found using search engines. Most of these might be cached records from removed indexes. Why they were indexed in the first place? Beats me.

Isn’t that beautiful?

Bing does you a solid and appends the .json for you

How did this happen?

At this point, it’s obvious that the exposure was caused by developers leaving the default security rules (meaning, none) in production apps, or configuring them wrongly. But I believe other factors contributed to this.

1. The fact that the database can be configured with “open to all” rules.
2. Developers can be lazy. It’s either the configuration was procrastinated (and then forgotten) or not even considered in the first place. We need to do better.

Is this still a risk?

Of course, and it’ll continue to to be a risk for as long as Firebase allows developers to leave databases open and developers refuse or forget to configure them properly. Granted, they’ve taken steps to curb this, including a red security warning. But things like that eventually get filtered out by the mind.

What can we do about it?

1. Make sure your databases are correctly configured. Here’s the official guide
2. We need to increase awareness of threats like this. Developers need to be more conscious of security in general, beyond Firebase.
3. Management should invest more in employee security awareness, policies and tests.
4. We should include configuration checks as part of code review processes.
5. All cloud assets should be regularly checked for known and emerging vulnerabilities.
6. Can Google scan apps for misconfigured databases before deployment to Play Store?

This vulnerability is pretty severe. It’s easy to exploit, but also easy to detect and fix. The most tightly secured systems are still vulnerable, not to talk of the ones that are poorly secured. Bad things happen, and thinking they won’t happen to you is a mistake. All it takes is a threat actor’s motivation and creativity. Thanks for reading.

Update: Google has updated their Firebase policies. There’s a locked mode which blocks everything and test mode which allows all reads and writes. All access is denied for the test mode after 30 days if security rules are not updated (it’s still the responsibility of the developer to ensure that the rules are correct).

Also, they send periodic reminder emails if it’s detected that a database has insecure rules. That’s good progress if you ask me.

Links!

How Elliot Alderson shanked the Donald Daters app with relative ease: https://medium.com/@fs0c131y/how-i-found-the-database-of-the-donald-daters-app-af88b06e39ad

Firebase Database takeover: https://medium.com/@danangtriatmaja/firebase-database-takover-b7929bbb62e1

Firebase Database security documentation: https://firebase.google.com/docs/database/security/

Appthority’s official report: https://cdn2.hubspot.net/hubfs/436053/Appthority%20Q2-2018%20MTR%20Unsecured%20Firebase%20Databases.pdf

Periscope bug bounty report: https://hackerone.com/reports/684099