Why you should choo-choo-choose to have a vulnerability disclosure policy (2M+ Accounts exposed)

Published in

dvuln

5 min readJan 8, 2020

BACKGROUND

In November 2019 (Dvuln) launched www.Securityat.me, a free app/service that was created with two key goals in mind.

Help as many organisations as possible create their own vulnerability disclosure policies that detail how external parties can report security issues in an efficient manner
Assist finders/researchers who are having difficulties communicating with the affected organisations and prevent avoidable, pre-mature disclosures and/or legal issues for both sides

SUMMARY

On November 29th (just a few days post-launch) we received our first disclosure assistance request. The request was from a security researcher who had identified a misconfigured Google Firebase Database that was exposing over 2-Million emails, usernames and plain-text passwords.

The researcher was genuinely concerned as they had attempted to contact the affected party through all available channels to no avail.

Furthermore, the researcher even requested external assistance from journalists who were also not able to make any contact with the affected parties.

Dvuln was able to make direct contact (on behalf of the security researcher) with the necessary stakeholders within 24 hours and deliver the details of the security issue to successfully remediate the issue.

WHAT IS GOOGLE FIREBASE?

Firebase is a fully managed platform for building iOS, Android, and web apps that provides automatic data synchronisation, authentication services, messaging, file storage, analytics, and more.
The service is popular with mobile developers as they can easily integrate with their projects and benefit from Google’s large-scale and high-performance systems within their apps.

WHAT IS THE IMPACT?

2,357,684 email addresses, usernames and plain-text passwords. (247MB of data)
The affected application is purported to be downloaded by over 10,000,000 users
The affected application is ranked as #27 globally for Travel apps (according to Apple AppStore)
The domain related to the application dates back to at least 2015/10/08. Additionally, according to the iOS AppStore version history, the current version is (5.4.2) and the furthest recorded version (5.1.5) predates this back to 14 Aug 2018.

This raises a couple of important questions

How long has the Firebase Database been openly exposed and have any attackers stolen the data within this timeframe?
Have any other researchers attempted to contact this organisation in the past and failed?

Exposed Firebase Database (hybrid-elixir-108806)

THE ‘TECHNICAL’ PROBLEM

This issue stems from the specific configuration of Cloud Firestore Security Rules which would have been set by someone within the affected organisation’s application development or ops team.

To secure data properly, developers need to implement user authentication on all database tables and rows, which should not be hard since the rules are set to DENY ALL by default.

Subsequently, Google defines security guidelines that warn against this exact issue:

https://firebase.google.com/docs/firestore/security/insecure-rules
Cloud Firestore Security Rules protect your data from malicious users. The default rules for any Cloud Firestore instance created in the Firebase console deny access to all users. To develop your app and access your database, you’ll need to modify those rules and might consider granting blanket access to all users in a development environment. Before deploying your app to a production environment, however, take the time to properly configure your rules and secure your data.

Example of Firebase Rules that allow public read/write access

After downloading the application from the AppStore, an attacker could perform static analysis on the application files to identify the database configuration file as shown below.

Whether an attacker identifies a Firebase instance by fuzzing using HTTP reconnaissance %targetcompany%.firebaseio.com or by identifying a valid Firebase database instance within a mobile application, it takes little effort for attackers to test for misconfigurations which can result in gaining access to millions of private records as witnessed.

THE ‘OTHER’ PROBLEM

After almost 1 month of attempted disclosure by the security researcher and journalist(s) the company was still unresponsive. This is most probably because there was no defined process to report such issues.

There is no doubt that organisations who lack a defined process to report security issues put themselves and they’re consumers at significant risk.

The increasing trend of responsible vulnerability disclosures combined with a growing number of organisations with no defined way to disclose these issues points to a clear need for more adoption by businesses who own or manage digital assets online.

WHAT IS A VULNERABILITY DISCLOSURE POLICY?

TLDR:

People are going to find vulnerabilities within your digital assets whether you give them permission or not.
You should atleast have a clear policy that defines what you would consider helpful vs what you would call the lawyers over to avoid unnecessary, time and resource consuming vulnerability disclosures.

Backed by policy standards:

ISO29147: Information technology — Security techniques — Vulnerability disclosure
Vulnerability disclosure policies are not bug-bounty programs

A vulnerability disclosure policy or responsible disclosure policy is a policy which encourages individuals who become aware of vulnerabilities in a company’s digital product or service to report them privately to the affected company.

The policy encourages reporting this by providing clear guidance on how a company will respond when a vulnerability is reported to it.

This may include, for instance, a guarantee that it won’t take legal action against the person who submitted the report, so long as the person reporting is acting in good faith and has followed any terms and conditions listed in the policy.

The policy may also outline the steps the agency will take to resolve any vulnerability reported to it.

If you would like to learn more about how to create a vulnerability disclosure policy for your organisation, head over to Security@me and create your own free vulnerability disclosure policy that is based on tried and tested policies used by some of the most risk-averse organisations around the world.

Additional info on vulnerability disclosure policies:

TIMELINE

28/10/2019: Journalist begin to attempt contact (no success)
29/11/2019: Initial triage by www.Securityat.me
30/11/2019: Successful contact with application developer
07/01/2020: Remediation of exposed Firebase Database