[BreachExchange] How was Google Firebase security bypassed?
destry at riskbasedsecurity.com
Tue Oct 9 20:57:21 EDT 2018
Google Firebase's inadequate back-end development led to data leaks
and vulnerabilities, including HospitalGown. Learn more about this
security flaw from expert Michael Cobb.
Appthority Inc. discovered thousands of mobile apps were leaking data
from insecure Google Firebase databases. According to the vendor's
research team, these cloud databases do not secure data by default,
and the app developers didn't configure the settings to protect the
data. Should Google have default security settings for Firebase or are
the developers more to blame for not configuring their Firebase
Most software applications use a back-end database to store
information like user credentials, logs and data used by the
application, and those that live on the internet often use a
cloud-based database to ensure scalability and high availability. The
main options include Amazon Relational Database Service, Oracle
Database Cloud Service and Microsoft Azure.
For developers concentrating on mobile apps, there is also the option
of using Google Firebase, a mobile and web application development
platform that provides a real-time database that continuously syncs
data between the cloud and the users' mobile devices. The competition
between these services to attract developers and their projects is
intense, with marketing material promoting how quick and easy a
particular service is to use.
While researching insecure back-end servers connecting to mobile apps,
the Appthority Mobile Threat Team (MTT) found that Google Firebase was
one of the 10 most popular data stores for mobile apps in 2017. They
also discovered that Firebase databases are accessible via an API and
that if developers haven't correctly secured their Firebase database,
a simple web request can retrieve its entire contents.
MTT tested this attack vector on over 2.7 million iOS and Android apps
and found over 113 GB of data was exposed through 3,000 apps,
including at least 4 million records with protected health
information; 25 million GPS location records; 50,000 financial
records; and at least 4.5 million Facebook, LinkedIn, Google Firebase
and corporate data store user tokens, with health and fitness apps
leaking the most data.
MTT has named this type of vulnerability, in which data is exposed not
by flaws in an application's code but by the development team's
failure to properly secure the back end, HospitalGown. The reason that
it's so prevalent among apps using Google Firebase is that there is no
database security turned on by default.
While most applications tend to have security and privacy settings
turned on by default, a development platform can be difficult to learn
and awkward to use if the security settings are turned on at the
beginning of the development cycle, slowing down the initial
development phases while the code and functionality are being tested.
Anything that slows down development is likely to put developers off
using a particular platform.
As a default Firebase database has no security, it's the development
team's responsibility to correctly secure the database prior to it
storing real data. In Google Firebase, this is done by requiring
authentication and implementing rule-based authorization for each
database table. The configuration and security controls for any
sensitive data also need to be checked using vulnerability scanners
and pen test tools to verify that they have been implemented
effectively. Clearly, there are plenty of projects that fail to
implement these critical stages before releasing their applications.
While the fault lies with developers and their lack of awareness about
secure coding practices, the fact that so many apps connect to
unsecured Firebase databases suggests that the Firebase documentation
is not clear enough about the dangers of not securing the back-end
However, some of the records stolen included 2.6 million plaintext
passwords and user IDs. Even those that may argue that Firebase should
be more secure by default cannot disagree that not encrypting
passwords is gross negligence on the part of the developers
More information about the BreachExchange