7 ms·

Thousands of Apps Leak Sensitive Data via Misconfigured Firebase Back Ends

93 points by kjhughes 8y ago

swrobel 8y ago
"The leaked information weighed more than 113 GBs" Love this turn of phrase
wnsire 8y ago
This is why I hate giving my personal info when "Signin Up" for online services of stuff made by startups. They usually know nothing about Back End security , and today's trend is to create product that "sale" and to ship as fast as possible regardless of compliance or security. One way or another it usually end up being stored in a completely unsecured manner. This is even more outrageous knowing how secure Firebase actually is. The documentation even contains a "Securing your Data Model" section .
- cremp 8y ago
  I don't think it is about compliance or security at all; just developers that aren't competent. > 2.6 million plaintext passwords Anyone who is actually competent knows hashing at a minimum; and it costs nothing to implement, both time and money wise. All of this, because Johnny over here read a tutorial on how to make your own app. The downside of development is that, you do get these people who 'stain' the title, because they just read it and followed blindly instead of actually learning.
  - jmtulloss 8y ago
    This is especially surprising because Firebase provides authentication APIs that do the right thing by default. This means devs are doing more work to get to a less secure solution.
    - cremp 8y ago
      Or treating it like any other database; and just using it because its 'popular.' Those 'developers' who do that (use popular just because,) are just the people who stain the title.
    - dunham 8y ago
      I think what firebase provides has changed over time. These problematic instances maybe be legacy. And the difficulty of setting up firebase's auth may also have changed over time. Did they always have hosted user/password auth or did they rely on third party pre-google?
  - duxup 8y ago
    I recently finished a boot camp. When I asked about security I was told "We really don't cover that." I have had to figure it out myself. It isn't hard, just took some extra effort to look into.
  - optimuspaul 8y ago
    For sure incompetence is at play here, but if these teams had compliance and security procedures in place then their incompetence would have been accounted for.
    - deleted 8y ago
      [deleted]
    - sbov 8y ago
      Realizing you need compliance and security procedures requires competence. The two of you are basically saying the same thing. There is no world where a company that can't get the most BASIC security practices right will realize they should have security procedures in place.
  - jordan801 8y ago
    I joined a company as a junior developer. Their senior developers did not see a problem with unsalted MD5 passwords. When I told them how unfathomable it was to think that was secure, they argued that there was a much larger problem if the database was breached. Not even a day later a company like ours was hacked in Canada and they went into bankruptcy because of it. I was called on a Saturday and asked how fast we could implement it. It took one hour to implement the new hashing and have a conversion strategy for the old MD5. The entire system is now upgraded to sha5 hashes with csprng salts. A few weeks ago I found out a newer hire (at senior level) decided to build his own auth system, because the current one, "doesnt work". It doesn't work because it doesn't allow our employees to handle customer passwords. Even with high turnover, some people don't understand why that is essential. When simplicity fights security in a corporate setting, simplicity nearly always wins. The exception is when an executive is security savvy and isn't a push over to their peers.
kjhughes 8y ago
A developer-level explanation would be helpful here. Was the mistake in the default Firebase configuration settings, or were common poor choices made by each of the app developers independently?
- ProblemFactory 8y ago
  Firebase Database default settings make the entire database world-readable and world-writable by all "authenticated users". But once you have enabled authentication, then that means anyone who signs into your app with a Google account. Restricting users to only access their own data requires understanding and writing "security rules". It's the most irresponsible default I have seen in practice.
  - z5h 8y ago
    I disagree. I bet if the default was no access, developers would simply enable all access (and not even realize they could restrict access to authenticated users). So the default is likely much safer than what would otherwise happen. Let's not forget that there is a security/permissions testing feature built right into Firebase. It would literally take 1 minute for a dev to ask and test: hey, can people read each other's data?
    - rhizome 8y ago
      developers would simply enable all access (and not even realize they could restrict access to authenticated users). So the default is likely much safer than what would otherwise happen. That's not what "safer" means. You cannot say that that's what would happen, either.
  - maxxxxx 8y ago
    We are using a system called Kinvey and there it's the same . By default everyone can read everybody's data. You can restrict it but I don't understand why they don't have a restricted model as default.
  - davideast 8y ago
z5h 8y ago
There is a permission testing tool built in to firebase. And excellent documentation. This is 100% the fault of developers.
- azinman2 8y ago
  Perhaps knowing that humans are fallable and that many of these app devs are educated solely in a 2 month boot camp, Firebase might do something to make this less likely.
  - master-litty 8y ago
    Immediate suggestions that come to mind?
    - azinman2 8y ago
      Not allowing unauthenticated requests? Look for things like plaintext passwords from one of many giant dictionaries of commonly used passwords and flag that behavior? Look for fields that match credit card numbers? Do better in documentation, especially around any schema creator? I don’t know enough about the exact security problem (I don’t use firebase) but I’m guessing tossing your hands in the air isn’t the only option.
- rhizome 8y ago
  But just to be clear, Firebase defaults to open permissions.
  - davideast 8y ago
    No it does not. By default it locks down your empty database to only authenticated users.
    - rhizome 8y ago
      You know what I mean: open to all authenticated users, authentication being cleared at the app level. Only having to create an account for full access to all data is indeed "open." Would that Facebook used this strategy, the implications would be clear.
yohann305 8y ago
The underlying issue here is that Firebase was sold as the answer to the not-so-techy people that wanted to create apps but couldn't necessarily handle the backend and here the issue is that Firebase should have thought that the majority of the audience thought Firebase would handle backend security for them as well. Yes, Firebase team messed up here, but technically speaking it's not too late to fix if done right now. I noticed Firebase already added big banners in Firebase dashboard to make people aware of this issue, or maybe it's a way for Firebase team to cover their asses by saying we told you so!! It's a good step towards fixing this issue but it's still not enough.
- sdhgaiojfsa 8y ago
  That is not a very good take. There have been dozens if not hundreds of similar leaks from people who thought they could handle the backend and used more traditional technologies. There's precious little evidence that I'm aware of that these apps are systemically less secure than apps that use bespoke backends.
- baybal2 8y ago
  >The underlying issue here is that Firebase was sold as the answer to the not-so-techy people Very explanatory
- filleduchaos 8y ago
  What on earth? Firebase has had the notice that your database is open to public access (if set that way) for ages. They've had IAM rules for years.
monksy 8y ago
This is what happens when: 1. You let inexperienced devs make big decisions. 2. "MVP" and ignore all of the other parts of the dev lifecycle.
- meritt 8y ago
  3. Everything critical to your company is a 3rd party SaaS accessible via public IPs. #1 and #2 have been symptomatic of the tech industry since at least the 90s. The difference back then was the surface area was generally limited to your private network only.
patwolf 8y ago
I always figured there were a lot of poorly-secured Firebase apps out there. My experience with Firebase Database is that it's great for apps with extremely simple models, or for PoCs where security and performance aren't a concern. If each user's data is independent and isolated, then it's not a problem. But for more complex cases, e.g. two particular users can see a piece of data because they belong to the same group, the complexity of trying to properly secure the database isn't worth whatever efficiencies you would gain over using a more traditional database. However, if your goal is to create an offline-capable app, then there aren't necessarily going to be any simple alternatives. CouchDB is good for offline but doesn't necessarily solve security.
pnwguy 8y ago
Could this be related to Typeform data breach? https://news.ycombinator.com/item?id=17425453 https://news.ycombinator.com/item?id=17425453
vlucas 8y ago
> 2.6 million plaintext passwords and user IDs This seems really odd to me. If you use Firebase Auth, you never see or get the users's password at all unless you are also copying it (on user login or registration) and storing it in another collection on your own, and then not hashing or securing that. The 2.6 million number could also conceivably be just a handful of really popular apps (or even just one!).

93 points by kjhughes 8y ago

"The leaked information weighed more than 113 GBs" Love this turn of phrase

This is why I hate giving my personal info when "Signin Up" for online services of stuff made by startups. They usually know nothing about Back End security , and today's trend is to create product that "sale" and to ship as fast as possible regardless of compliance or security. One way or another it usually end up being stored in a completely unsecured manner. This is even more outrageous knowing how secure Firebase actually is. The documentation even contains a "Securing your Data Model" section .

cremp 8y ago
I don't think it is about compliance or security at all; just developers that aren't competent. > 2.6 million plaintext passwords Anyone who is actually competent knows hashing at a minimum; and it costs nothing to implement, both time and money wise. All of this, because Johnny over here read a tutorial on how to make your own app. The downside of development is that, you do get these people who 'stain' the title, because they just read it and followed blindly instead of actually learning.
- jmtulloss 8y ago
  This is especially surprising because Firebase provides authentication APIs that do the right thing by default. This means devs are doing more work to get to a less secure solution.
  - cremp 8y ago
    Or treating it like any other database; and just using it because its 'popular.' Those 'developers' who do that (use popular just because,) are just the people who stain the title.
  - dunham 8y ago
    I think what firebase provides has changed over time. These problematic instances maybe be legacy. And the difficulty of setting up firebase's auth may also have changed over time. Did they always have hosted user/password auth or did they rely on third party pre-google?
- duxup 8y ago
  I recently finished a boot camp. When I asked about security I was told "We really don't cover that." I have had to figure it out myself. It isn't hard, just took some extra effort to look into.
- optimuspaul 8y ago
  For sure incompetence is at play here, but if these teams had compliance and security procedures in place then their incompetence would have been accounted for.
  - deleted 8y ago
    [deleted]
  - sbov 8y ago
    Realizing you need compliance and security procedures requires competence. The two of you are basically saying the same thing. There is no world where a company that can't get the most BASIC security practices right will realize they should have security procedures in place.
- jordan801 8y ago
  I joined a company as a junior developer. Their senior developers did not see a problem with unsalted MD5 passwords. When I told them how unfathomable it was to think that was secure, they argued that there was a much larger problem if the database was breached. Not even a day later a company like ours was hacked in Canada and they went into bankruptcy because of it. I was called on a Saturday and asked how fast we could implement it. It took one hour to implement the new hashing and have a conversion strategy for the old MD5. The entire system is now upgraded to sha5 hashes with csprng salts. A few weeks ago I found out a newer hire (at senior level) decided to build his own auth system, because the current one, "doesnt work". It doesn't work because it doesn't allow our employees to handle customer passwords. Even with high turnover, some people don't understand why that is essential. When simplicity fights security in a corporate setting, simplicity nearly always wins. The exception is when an executive is security savvy and isn't a push over to their peers.

kjhughes 8y ago

A developer-level explanation would be helpful here. Was the mistake in the default Firebase configuration settings, or were common poor choices made by each of the app developers independently?

ProblemFactory 8y ago
Firebase Database default settings make the entire database world-readable and world-writable by all "authenticated users". But once you have enabled authentication, then that means anyone who signs into your app with a Google account. Restricting users to only access their own data requires understanding and writing "security rules". It's the most irresponsible default I have seen in practice.
- z5h 8y ago
  I disagree. I bet if the default was no access, developers would simply enable all access (and not even realize they could restrict access to authenticated users). So the default is likely much safer than what would otherwise happen. Let's not forget that there is a security/permissions testing feature built right into Firebase. It would literally take 1 minute for a dev to ask and test: hey, can people read each other's data?
  - rhizome 8y ago
    developers would simply enable all access (and not even realize they could restrict access to authenticated users). So the default is likely much safer than what would otherwise happen. That's not what "safer" means. You cannot say that that's what would happen, either.
- maxxxxx 8y ago
  We are using a system called Kinvey and there it's the same . By default everyone can read everybody's data. You can restrict it but I don't understand why they don't have a restricted model as default.
- davideast 8y ago

z5h 8y ago

There is a permission testing tool built in to firebase. And excellent documentation. This is 100% the fault of developers.

azinman2 8y ago
Perhaps knowing that humans are fallable and that many of these app devs are educated solely in a 2 month boot camp, Firebase might do something to make this less likely.
- master-litty 8y ago
  Immediate suggestions that come to mind?
  - azinman2 8y ago
    Not allowing unauthenticated requests? Look for things like plaintext passwords from one of many giant dictionaries of commonly used passwords and flag that behavior? Look for fields that match credit card numbers? Do better in documentation, especially around any schema creator? I don’t know enough about the exact security problem (I don’t use firebase) but I’m guessing tossing your hands in the air isn’t the only option.
rhizome 8y ago
But just to be clear, Firebase defaults to open permissions.
- davideast 8y ago
  No it does not. By default it locks down your empty database to only authenticated users.
  - rhizome 8y ago
    You know what I mean: open to all authenticated users, authentication being cleared at the app level. Only having to create an account for full access to all data is indeed "open." Would that Facebook used this strategy, the implications would be clear.

yohann305 8y ago

The underlying issue here is that Firebase was sold as the answer to the not-so-techy people that wanted to create apps but couldn't necessarily handle the backend and here the issue is that Firebase should have thought that the majority of the audience thought Firebase would handle backend security for them as well. Yes, Firebase team messed up here, but technically speaking it's not too late to fix if done right now. I noticed Firebase already added big banners in Firebase dashboard to make people aware of this issue, or maybe it's a way for Firebase team to cover their asses by saying we told you so!! It's a good step towards fixing this issue but it's still not enough.

sdhgaiojfsa 8y ago
That is not a very good take. There have been dozens if not hundreds of similar leaks from people who thought they could handle the backend and used more traditional technologies. There's precious little evidence that I'm aware of that these apps are systemically less secure than apps that use bespoke backends.
baybal2 8y ago
>The underlying issue here is that Firebase was sold as the answer to the not-so-techy people Very explanatory
filleduchaos 8y ago
What on earth? Firebase has had the notice that your database is open to public access (if set that way) for ages. They've had IAM rules for years.

monksy 8y ago

This is what happens when: 1. You let inexperienced devs make big decisions. 2. "MVP" and ignore all of the other parts of the dev lifecycle.

meritt 8y ago
3. Everything critical to your company is a 3rd party SaaS accessible via public IPs. #1 and #2 have been symptomatic of the tech industry since at least the 90s. The difference back then was the surface area was generally limited to your private network only.

patwolf 8y ago

I always figured there were a lot of poorly-secured Firebase apps out there. My experience with Firebase Database is that it's great for apps with extremely simple models, or for PoCs where security and performance aren't a concern. If each user's data is independent and isolated, then it's not a problem. But for more complex cases, e.g. two particular users can see a piece of data because they belong to the same group, the complexity of trying to properly secure the database isn't worth whatever efficiencies you would gain over using a more traditional database. However, if your goal is to create an offline-capable app, then there aren't necessarily going to be any simple alternatives. CouchDB is good for offline but doesn't necessarily solve security.

pnwguy 8y ago

Could this be related to Typeform data breach? https://news.ycombinator.com/item?id=17425453 https://news.ycombinator.com/item?id=17425453

vlucas 8y ago

> 2.6 million plaintext passwords and user IDs This seems really odd to me. If you use Firebase Auth, you never see or get the users's password at all unless you are also copying it (on user login or registration) and storing it in another collection on your own, and then not hashing or securing that. The 2.6 million number could also conceivably be just a handful of really popular apps (or even just one!).