Thousands of misconfigured Android apps are leaving sensitive data exposed, researchers find
SOPA Images/LightRocket via Getty Images
Acquired by Google in 2014, Firebase is a mobile platform that helps users to develop apps quickly and securely. Think of it as the app production platform of choice for vast numbers of developers, taking advantage of the cloud-hosted real-time database that enables easy storage and syncing of data between users. It makes cross-platform collaboration a breeze, brings serverless app development to the masses, and is strong on user-based security.
If that is, developers configure everything securely in the first place. New research from Comparitech suggests that common misconfigurations of Google Firebase databases are exposing sensitive information, including passwords, telephone numbers, and chat messages, to anyone who wants to look. Here’s what you need to know.
The Android app configuration error problem, by the numbers
A Comparitech security research team led by Bob Diachenko analyzed a sample of 515,735 Android apps from the Google Play store. Of these, 155,066 were using Firebase. I spoke to Diachenko, who confirmed that from the sample that was using Firebase, some 11,730 of those apps were exposing that Firebase database publicly.
Drilling down even further, 9,014 included the necessary write permissions to enable a potential attacker to modify data, including adding or deleting it, as well as merely viewing or downloading it. And talking of which, the Comparitech analysis revealed that 4,282 of the apps were leaking sensitive information.
According to the report, that exposed data included more than 7 million email addresses, and almost the same number of chat messages. Then there’s the 4.4 million usernames and 1 million passwords to consider, along with 5 million telephone numbers.
All of which are concerning enough as these are big numbers, but they must be put into some perspective. It has been estimated that more than 1.5 million apps were using the Firebase platform, across Android and iOS, in March 2020. Even if you extrapolate from the analysis numbers, as Comparitech has done to reach a total of 24,000 Android apps potentially leaking sensitive data by way of such configuration errors, that’s only 1.6% of all apps using Firebase and 0.94% of all apps available to download from Google Play itself.
Hunting down those exposed Firebase database apps
The Comparitech researchers were able to discover the apps which had publicly exposed databases by first searching app resources for text strings indicative of Firebase usage. From there, appending a request to the database URL with .json enabled public databases to be accessed via the Firebase REST API for stored data. An access denied response is what the researchers wanted to get as this would indicate non-public exposure, but as the report shows, they ended up with the full database content returned way too often. The researchers then looked for sensitive information that was manually checked for false positives.
“All the accessed data was destroyed,” the researchers said, ensuring that the research was “fully compliant with white hat standards and procedures.” To reveal any write access to the databases, a PUT request was used to create a new node and then delete it.
Mitigating the configuration error risk
As with all leaky database issues that can be traced back to a configuration error, the mitigation advice sounds pretty simple: get the database configuration right the first time. Unfortunately, things are rarely as simple as they first appear.
So, sure, the mitigation advice offered up the researchers in this case of implementing the proper database rules and preventing unauthorized access from accessing sensitive data is correct. Recommending that app developers follow the “Security & Rules” guidelines as set out in Google’s Firebase documentation should be a no-brainer, but it’s not.
This has been demonstrated time and time again, with online databases of all sorts being misconfigured and leading to reports of data being leaked publicly. Indeed, earlier this year, it was reported that an astonishing 82% of security “vulnerabilities” were due to misconfiguration errors of one sort or another.
OK then, this is not a Google Firebase problem, it’s a developer problem, right?
Quite apart from the fact that playing the blame game here isn’t particularly helpful, it’s not as black and white as that either. “Anyone that does not think IT and software development isn’t an iterative process just doesn’t understand how it all works,” Ian Thornton-Trump, CISO at Cyjax says, “it’s not about the mistake it’s about how you recover from the mistake and do better.”
Security expert John Opdenakker agrees and says that what is helpful is “a secure software development lifecycle, as it embeds security in the process, and as such the much needed time for security can be planned.”
If we are to blame anyone, or rather anything, then time has to be front and center. Application security trainer and co-leader of the Open Web Application Security Project (OWASP) Scotland chapter, Sean Wright, is sure of that. “One thing I’ve seen so many times is that many developers are under constant pressure to deliver,” Wright explains, “This ultimately means they will take the shortest path to deliver.”
This means it’s not that uncommon for app developers to refer to existing examples of a technology implementation rather than the original documentation itself. “This is not an issue if the example is a correct and secure one,” Wright says, “but in many cases, this isn’t the case. Developers need to understand what it is they are doing, but given the time pressures that they are under, this is often not achievable.”
What does Google say about the Firebase misconfiguration data risk?
The Comparitech researchers made Google aware of the report findings on April 22 and received the following statement in response:
“Firebase provides a number of features that help our developers configure their deployments securely. We provide notifications to developers about potential misconfigurations in their deployments and offer recommendations for correcting them. We are reaching out to affected developers to help them address these issues.”
I have also reached out to Google, and if any further comment is forthcoming, I will update this article accordingly.