Hundreds of iOS apps leaking data due to misconfigured Firebase backends, report says

13»

Comments

  • Reply 41 of 54
    avon b7avon b7 Posts: 7,625member
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.

    Wouldn't great product design force them to set a passcode 'for their own good'?
    muthuk_vanalingamcornchip
  • Reply 42 of 54
    ericthehalfbeeericthehalfbee Posts: 4,485member
    avon b7 said:
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.

    Wouldn't great product design force them to set a passcode 'for their own good'?

    There are very good reasons people might not use passcodes. Like a device that never leaves your home. I can’t think of any valid reasons to turn this off in Firebase or Apps should be allowed to go “live” with it still off.
    tmaywatto_cobracornchip
  • Reply 43 of 54
    lowededwookielowededwookie Posts: 1,143member
    I thought Apple bought Firebase or is it some other database they bought? Or is it that Apple bought it but Google incorrectly setup their servers to make Firebase seem like a bad server?
    watto_cobra
  • Reply 44 of 54
    lowededwookielowededwookie Posts: 1,143member
    foggyhill said:
    maestro64 said:
    HeliBum said:

    Yep, leaking private information and Google are synonymous.


    Anybody know where to find the list of affected apps?

    It would be nice to know which apps have this issue.
    Report is pay to view but

    Enterprises are at significant risk from the Firebase vulnerability because 62% of enterprises have at least one vulnerable app in their mobile environment. The vulnerable apps are in multiple categories, including tools, productivity, health and fitness, communication, finance and business apps.

    Worse, the data being leaked is highly sensitive including PII, PHI, plaintext passwords, social media account and cryptocurrency exchange private access tokens, financial transactions, vehicle license plate and geolocation information, and more. 

    Our Mobile Threat Team discovered over 2,300 unsecured Firebase databases and 3,000 unique iOS and Android apps with this vulnerability. The Android versions of these apps alone have been downloaded over 620 million times. 

    More than 100 million records are exposed, including: 

    • 2.6 million plain text passwords and user IDs
    • 4 million+ PHI (Protected Health Information) records (chat messages and prescription details)
    • 25 million GPS location records
    • 50 thousand financial records including banking, payment and Bitcoin transactions
    • 4.5 million+ Facebook, LinkedIn, Firebase, and corporate data store user tokens

    Why on god's green earth are plain text passwords even stored..., why not store salted hashes, who the hell does that... It wasn't even good security practice in 1993, let alone 25 years later!!.
    I just don't get it.
    Seems it's not just Google that were idiotic here; most IT and devs are lazy ass that wouldn't know security if it bit them in the ass.
    Welcome to what used to be my past eighteen years. I’m so glad I’m a motorcycle postie now because I was tired of incorrectly setup systems that made my life a living hell.
    watto_cobra
  • Reply 45 of 54
    avon b7avon b7 Posts: 7,625member
    avon b7 said:
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.

    Wouldn't great product design force them to set a passcode 'for their own good'?

    There are very good reasons people might not use passcodes. Like a device that never leaves your home. I can’t think of any valid reasons to turn this off in Firebase or Apps should be allowed to go “live” with it still off.
    That is irrelevant and burglaries are not uncommon. The point was if the option to turn off security should even exist and if allowing users to do so constituted good or great design (as per the OPs comment).

    Should helmets for cyclists be mandatory? That's happening in some places but historically it has been a requirement as people didn't see them as necessary.

    When it comes to security or safety sometimes the decisions aren't ours to take.

    My bank eliminated the signature plus ID option on my EMV card, forcing me to use a PIN which is far easier to defeat due to unprotected keypunching issues on many terminals.

    Now, personally I'm in favour of the option of not having a passcode on a phone but the OP was implying that Google didn't go far enough as it allowed developers to turn off a feature the exact same feature as iOS has.
    muthuk_vanalingam
  • Reply 46 of 54
    avon b7 said:
    avon b7 said:
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.

    Wouldn't great product design force them to set a passcode 'for their own good'?

    There are very good reasons people might not use passcodes. Like a device that never leaves your home. I can’t think of any valid reasons to turn this off in Firebase or Apps should be allowed to go “live” with it still off.
    That is irrelevant and burglaries are not uncommon. The point was if the option to turn off security should even exist and if allowing users to do so constituted good or great design (as per the OPs comment).

    Should helmets for cyclists be mandatory? That's happening in some places but historically it has been a requirement as people didn't see them as necessary.

    When it comes to security or safety sometimes the decisions aren't ours to take.

    My bank eliminated the signature plus ID option on my EMV card, forcing me to use a PIN which is far easier to defeat due to unprotected keypunching issues on many terminals.

    Now, personally I'm in favour of the option of not having a passcode on a phone but the OP was implying that Google didn't go far enough as it allowed developers to turn off a feature the exact same feature as iOS has.


    More bulshit and deflection. Just your usual trolling trying to find a way to complain about Apple in an article about a Google problem.

    If a user decides against a PIN and their device is stolen, they’re the only “victim”. Turning off authentication for an App affects potentially millions of users. See the difference? Both are a single decision with wildly varying consequences. Google needs to add additional protections beyond a simple warning because of the fact it can affect so many users.

    Google Drive encrypts all your stored files. There’s no way to store files in an unencrypted state readable by others. Yet this is possible in Firebase. The real question is why Google even allows this option in Firebase and doesn’t enforce use of authentication.


    BTW, your bank example is stupid. If your card gets stolen or used for an unauthorized transaction, who pays? Oh right, the bank. They assume liability if your card is used by a criminal if you’re using it in the manner intended by the bank. Do these developers and/or Firebase make any guarantees regarding unauthorized use of your data? Didn’t think so.
    fastasleepwatto_cobra
  • Reply 47 of 54
    avon b7avon b7 Posts: 7,625member
    avon b7 said:
    avon b7 said:
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.

    Wouldn't great product design force them to set a passcode 'for their own good'?

    There are very good reasons people might not use passcodes. Like a device that never leaves your home. I can’t think of any valid reasons to turn this off in Firebase or Apps should be allowed to go “live” with it still off.
    That is irrelevant and burglaries are not uncommon. The point was if the option to turn off security should even exist and if allowing users to do so constituted good or great design (as per the OPs comment).

    Should helmets for cyclists be mandatory? That's happening in some places but historically it has been a requirement as people didn't see them as necessary.

    When it comes to security or safety sometimes the decisions aren't ours to take.

    My bank eliminated the signature plus ID option on my EMV card, forcing me to use a PIN which is far easier to defeat due to unprotected keypunching issues on many terminals.

    Now, personally I'm in favour of the option of not having a passcode on a phone but the OP was implying that Google didn't go far enough as it allowed developers to turn off a feature the exact same feature as iOS has.


    More bulshit and deflection. Just your usual trolling trying to find a way to complain about Apple in an article about a Google problem.

    If a user decides against a PIN and their device is stolen, they’re the only “victim”. Turning off authentication for an App affects potentially millions of users. See the difference? Both are a single decision with wildly varying consequences. Google needs to add additional protections beyond a simple warning because of the fact it can affect so many users.

    Google Drive encrypts all your stored files. There’s no way to store files in an unencrypted state readable by others. Yet this is possible in Firebase. The real question is why Google even allows this option in Firebase and doesn’t enforce use of authentication.


    BTW, your bank example is stupid. If your card gets stolen or used for an unauthorized transaction, who pays? Oh right, the bank. They assume liability if your card is used by a criminal if you’re using it in the manner intended by the bank. Do these developers and/or Firebase make any guarantees regarding unauthorized use of your data? Didn’t think so.
    Irrevelant again. This is about a 'decision' (having or not having the option to turn something on or off) not  'who is impacted' by actions resulting from it. Re-read the thread and the 'good' vs 'great' comments. There is a major difference between the two.

    As for banks I can assure you you are making blanket statements without knowing the facts.

    When the option to use my EMV card with signature and ID was forcibly removed I kicked up an almighty stink but the bank put up a wall of silence and started passing the buck at lower levels. 

    A signature plus ID is far more secure than a PIN but it slows down transactions. The upshot is that if your card is used in person without your permission, the bank will claim that you revealed your PIN. That is a given. It will not cover any liability without a fight. If you read the fine print of your contract, this aspect might be spelt out in very clear terms. This is the Spanish case.

    Something different is if you report the card as stolen, lost etc and a transaction slips through before it is suspended/cancelled. 


    muthuk_vanalingam
  • Reply 48 of 54
    mcdavemcdave Posts: 1,927member
    So iOS devices aren’t leaking the data at all, the backend is.
    fastasleepwatto_cobra
  • Reply 49 of 54
    fastasleepfastasleep Posts: 6,408member
    ...is the simplest way to avoid such issues to never left 'Elvis leave the building' as they say... ? Is there a reason all Apple roads seem to lead to iCloud? Why so many entrust data to any cloud (gmail/hotmail/apple servers included) especially stateside given the Patriot Act is beyond my comprehension... I have a tough time convincing anyone to integrate the seemingly ubiquitous S/MIME encryption despite free certificate availability for personal use (numerous finer points debatable) and yet... ...will we all get what we deserve in the end...?
    Having to go home to check my email kinda defeats the "e" part of it, no?
    Not sure I understand - I found S/MIME easier to set up in iOS than macOS,
    and it seems to work seamlessly with windoze types if they are interested...?
    https://arstechnica.com/gadgets/2011/10/secure-your-e-mail-under-mac-os-x-and-ios-5-with-smime/
    ...of course nothing is perfect, well except maybe the Kremlin strategy of using typewriters, ha ha...
    https://www.huffingtonpost.com/2013/07/11/kremlin-typewriters_n_3579184.html  :)
    End to end encryption means fuck all if the data resides insecure on a server somewhere, which was the crux of your argument.
    edited July 2018 watto_cobra
  • Reply 50 of 54
    fastasleepfastasleep Posts: 6,408member
    So, how long before we are told of the companies out there brokering the data syphoned from Google Firebase? Google are masters of data extraction and manipulation for which we know third-parties pay handsomely.


    NSA: "Hey, Sundar — Can you roll out a database vulnerability in Firebase for us? We've got another quota deadline coming up for unencrypted domestic data collection. I've got some no-bid contracts on the new Hunter-Killer drone AI project to send your way if so, LMK ASAP plz kthanx."
    edited July 2018 watto_cobra
  • Reply 51 of 54
    fastasleepfastasleep Posts: 6,408member
    mcdave said:
    So iOS devices aren’t leaking the data at all, the backend is.
    Yeah, the headline on this made parsing the article more difficult for me. It really has nothing to do with the actual app, just the Google backend service that serves the database. Nothing leaks from the app itself.
    watto_cobra
  • Reply 52 of 54
    anton zuykovanton zuykov Posts: 1,056member
    avon b7 said:
    gatorguy said:
    evilution said:
    I’m sure it’ll be all Apple’s fault somehow. News sites will post about iOS apps sending out data, totally missing the fact it happens on Android and is Google’s product at fault.
    Totally missing the fact that it’s not anything to do with the apps, per se, but with the underlying developers’ choice to use that server database.  No change to the apps could be made to close that leak, so why it’s presented by the press as an app issue is a bit odd.  
    Late to the party this morning. From what I'm reading going to a couple of Reddit sites is that this a failure by the affected developers and not something on Google's end.
    Yes and no. Good product is a product that lets you do what it claims on a tin without problems, while a great product is designed in such a way that minimizes mishaps mentioned in the article, instead of simple pushing that as a sole responsibility of an end user.
    If the default setting is 'on' and developers have to manually turn it 'off' and pass through a modal dialog that warns of the consequences, how is that any different to iOS allowing users to turn off iDevice passcodes or set simply set very weak passcodes.
    1. Was it ON by default, though? 
    2. The difference is that the user does not service other people with that setup, unlike those developers. Different tiers of the product, imho.

    Android and iOS users are fundamentally the same, but Apple sets everything up as if the users don't know anything (and locks everything up that poses a risk, if a user is not knowledgable), while Android is too reluctant with their "locking" and "wall-gardening", which makes products more customizable and much less secure...
     Yes, the responsibility to use the available tools is on the end user, but statistics clearly demonstrated that trusting your customer with that is a bad idea, if he doesn't not know the tech AND/OR how to use it correctly. 

    As I said, Android and iOS users are fundamentally the same, but where they differ is that one side is a lot more arrogant about how much tech they think they know well. The point being - Google played its standard game - they pushed everything to the end user...and users and Google will pay a little more price for that. And Apple will probably start banning some tech from being used, if it's fundamentally a flawed approach that damages their customers. After that everyone else will start to freak out about Apple being restrictive again. And then the cycle will repeat.
    tmaywatto_cobra
  • Reply 53 of 54
    cornchipcornchip Posts: 1,945member
     or Apps should be allowed to go “live” with it still off.

    Exactly what I was gonna say. Wouldn’t this be a red flag before going live on an App Store? 





  • Reply 54 of 54
    fastasleepfastasleep Posts: 6,408member
    cornchip said:
     or Apps should be allowed to go “live” with it still off.

    Exactly what I was gonna say. Wouldn’t this be a red flag before going live on an App Store? 

    It should be for the developer, somehow. Not sure Apple has any way to test back end services that apps use though in the approval process, not like they go do penetration testing on all the AWS instances that run various app backend services.
Sign In or Register to comment.