Google Was Warned About This Week's Mass Phishing Email Attack Six Years Ago (vice.com) 45
An anonymous reader quotes a report from Motherboard: For almost six years, Google knew about the exact technique that someone used to trick around one million people into giving away access to their Google accounts to hackers on Wednesday. Even more worrisome: other hackers might have known about this technique as well. On October 4, 2011, a researcher speculated in a mailing list that hackers could trick users into giving them access to their accounts by simply posing as a trustworthy app. This attack, the researcher argued in the message, hinges on creating a malicious application and registering it on the OAuth service under a name like "Google," exploiting the trust that users have in the OAuth authorization process. OAuth is a standard that allows users to grant websites or applications access to their online email and social networking accounts, or parts of their accounts, without giving up their passwords. "Imagine someone registers a client application with an OAuth service, let's call it Foobar, and he names his client app 'Google, Inc.'. The Foobar authorization server will engage the user with 'Google, Inc. is requesting permission to do the following,'" Andre DeMarre wrote in the message sent to the Internet Engineering Task Force (IETF), the independent organization responsible for many of the internet's operating standards. "The resource owner might reason, 'I see that I'm legitimately on the https://www.foobar.com/ site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow,'" DeMarre concluded. As it turns out, DeMarre claims he warned Google directly about this vulnerability in 2012, and suggested that Google address it by checking to see ensure the name of any given app matched the URL of the company behind it. In a Hacker News post, DeMarre said he reported this attack vector back then, and got a "modest bounty" for it.
Re: (Score:2)
The only thing under Trump's watch is maybe a mole and tiny hands.
yay the cloud (Score:1)
OAuth is a standard that allows users to grant websites or applications access to their online email and social networking accounts, or parts of their accounts
Lesson #1 of computer security: don't aggregate all your data on somebody else's computer.
Lesson #2 of computer security: don't aggregate all your data with all of everybody else's data, especially when also in violation of Lesson #1.
Lesson #3 of computer security: they aren't on your side. (For any arbitrary value of "they", but most especially including companies inducing you to violate Lessons #1 and #2).
Re:That should make you feel good (Score:5, Insightful)
It's a web app, not a mobile app, and this is a social engineering attack, not a hack, so the device doesn't matter. As such, you can fall prey to this exact scam while using a Mac, a Surface tablet running Windows, or an Android phone with the latest security updates.
Re: (Score:2)
I wasn't talking about Gmail. I was talking about the rogue app.
Re: (Score:2)
Are you surprised an ifanboy wouldn't understand the issue?
Re: (Score:2)
Are you surprised an ifanboy wouldn't understand the issue?
Why does it matter what platform he prefers? Does his choice offend you? Harm you? Threaten you?
Stick to the facts, correct his misconceptions, and move along. You'll find that the quality of your life improves significantly when you stop getting worked up about the preferences of others.
"Allow?" Well, if you have to ask... (Score:2)
Negligence and Liability (Score:1)
While I agree that there are risks for users storing their data in the cloud, it seems like Google should be liable for damage done by this attack. Google clearly was notified and was aware of the vulnerability, hence the bug bounty paid out. I understand that it's not possible to deliver patches immediately, but there are reasonable standards depending on the scope of the vulnerability. Several years is beyond the length of a reasonable length to fix a security issue that could compromise a user's accou
Re: (Score:3, Insightful)
While I agree that there are risks for users storing their data in the cloud, it seems like Google should be liable for damage done by this attack. Google clearly was notified and was aware of the vulnerability, hence the bug bounty paid out.
Even worse, Google allowed a random person to create and distribute an app called "Google Doc". What the fucking fuck?
Re:Negligence and Liability (Score:4, Insightful)
Correct me if I'm wrong here, but Google doesn't have to be involved AT ALL.
These folk are fishing for credentials, they're pretending to be a trustworthy web site, and pretend they're asking for Google credentials. This whole OAuth request is (can be) faked just as well. Just reject whatever the user inputs, after a few attempts they're likely to give up.
They could of course involve Google and actually use the given credentials behind the scenes to genuinely log in the user (doesn't look as suspect), all the while storing the credentials for later use. That would potentially make the attack work longer; the moment Google catches up it's on to plan B which is just storing the credentials (usually entered correctly anyway) and then telling the user the authentication failed.
The apps themselves may be distributed through the Google Play store - greater audience but high risk of being caught out - or through one of a myriad of alternative stores Google has no control over.
Re: (Score:3)
While I agree that there are risks for users storing their data in the cloud, it seems like Google should be liable for damage done by this attack. Google clearly was notified and was aware of the vulnerability, hence the bug bounty paid out. I understand that it's not possible to deliver patches immediately, but there are reasonable standards depending on the scope of the vulnerability. Several years is beyond the length of a reasonable length to fix a security issue that could compromise a user's account that might contain sensitive and confidential data. It sure seems like Google was negligent in their security, and ought to be held responsible for damages caused in the attack. There needs to be a lot more liability when businesses are negligent in implementing reasonable security practices and when they fail to respond to reports of security issues within a reasonable amount of time. The only way for security to become a priority is when failing to practice it causes real financial penalties.
Came here to say this, but also to add that perhaps the responsibilities and liabilities are less clear in a legal sense when no money has changed hands, and therefore there may be no express or implied contract between Google and the average user. Some will say the TOS is that contract, and I'd be interested to see how that angle would play out in court, given the spotty history of court cases involving TOS.
It might be better for someone seeking damages in a case like this to also argue that the informatio
How is this Google's fault again? (Score:2)
'I see that I'm legitimately on the https://www.foobar.com/ [foobar.com] site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow,'"
Let's see. You're on the attacker's website and you trust it (apparently because it has https in the URL), and you trust Google, so you allow the attacker free access to your google account. How is this Google's fault again? I mean, you give access to your account to people you shouldn't and it's someone else's fault?
Re: (Score:2)
Would this require me to be logged in to google for this to work?
Re:How is this Google's fault again? (Score:5, Informative)
That's not exactly what happened in the latest attack. The email contained a link to a real OAuth page hosted on the real, properly secured, accounts.google.com, and requested permissions for a malicious app called "Google Docs". If given permission, the app would have full access to much of the contents of the google account including emails (not login credentials, though).
Google's main fault in this situation is that they should never allow app names to impersonate real Google features, like Docs. The OAuth page should also make it clear when it's an untrusted third party requesting the access.
Re: (Score:1)
The OAuth page should also make it clear when it's an untrusted third party requesting the access.
So how is Google going to know which parties you are trusting, and which parties you are not trusting? Their magic 8 ball?
There are basically only two options:
- YOU Decide who to trust or not to trust
- Google deciding it FOR you.
In my opinion, Option one is the lesser of two evils.
Re: (Score:2)
'I see that I'm legitimately on the https://www.foobar.com/ [foobar.com] site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow,'"
Let's see. You're on the attacker's website and you trust it (apparently because it has https in the URL), and you trust Google, so you allow the attacker free access to your google account. How is this Google's fault again? I mean, you give access to your account to people you shouldn't and it's someone else's fault?
The mistake here is Google wants permission. That's not what's happening. It's Foobar asking for permission by pretending to be google. So while you would trust Google to give you access to foobar without giving Foobar too much info. You don't trust Foobar directly. So youclick Allow on Google but you're actually clicking on Foobar.
"Google, Inc." (Score:2)
Up next, new app scam named "Goggle, Inc.". Another 1 million people clicked on it.
Re: (Score:2)
Up next, new app scam named "Goggle, Inc.". Another 1 million people clicked on it.
Don't for get the other common scam trick, calling it "Google, lnc" (pronouced like "link")
How is this not incredibly obvious? (Score:2)
Honestly, it's the first thought that popped into my head when they changed the way the permissions interface for Oauth worked about 8ish years ago. Don't know if there's much, if anything you can do about it though, other than ban the app on a case by case basis, or put some kind of filter in place that remembers the name of every trademark holder. But even then, there'll still be bad guys that manage to get through it.
Another reason to avoid any such generic login (Score:3)
The attack sounds quite obvious, thinking about it. Just fake the whole thing, and store the credentials in the process.
It's for me just another reason to avoid Google, Facebook, LinkedIn, or whatever login you can find on various web sites. I'd rather create a new account with unique password. Without direct link to any other web site, without giving them a chance to access to any of my info on the other web sites, without allowing Google and Facebook yet another vector of tracking me (why else are they offering that service?).
Someone using their Google credentials to log in to just about anything, has a big problem were there Google account to be compromised. All those sites suddenly become accessible. It maybe takes a bit of guesswork and luck from the attacker, but they already have the credentials. That's just no fun.
Admittedly the same could happen if my LastPass master password is compromised, but the chance of that is less as I know when to expect to have to enter it. It's a whole lot harder for any software to fake this. I bet it's not impossible, just much harder than setting up a genuine looking web site or app and asking me for it.
Re: (Score:2)
That's not true. You authenticate via Google, Facebook, LinkedIn, or whatever, and possibly give access to data in that account to the website you log in to. But that website has no access to any other site you logging in to with that Google, Facebook, LinkedIn, or whatever account. You only (partially) compromise your Google, Facebook, LinkedIn, or whatever account. The sites you log in to also have zero knowledge about your credentials,
The big reason why you do not want to use Google, Facebook, LinkedIn,
Re: (Score:2)
That's not true. You authenticate via Google, Facebook, LinkedIn, or whatever, and possibly give access to data in that account to the website you log in to. But that website has no access to any other site you logging in to with that Google, Facebook, LinkedIn, or whatever account. You only (partially) compromise your Google, Facebook, LinkedIn, or whatever account. The sites you log in to also have zero knowledge about your credentials,
That's what I'd hope for. But how can you be sure that this login page where you enter your credentials is actually served by Google/Facebook/etc? It's easy enough to fake this part, and for the web site to perform a MiM attack on your credentials. That's what these apps are apparently doing.
But you also need to use uBlock and Ghostery to block all those webbugs placed everywhere for Google, Facebook, LinkedIn, or whatever.
I haven't gone that far. I got a cookie self-destruct extension and ABP. Should help a lot - at least no more stray Facebook cookies they may track when I logged off (even though they claim they don't, rather make sure
Re: Another reason to avoid any such generic login (Score:1)
Re: Another reason to avoid any such generic logi (Score:2)
What stops this would be attacker from obtaining a certificate for whatever phishing domain they register?
This green lock is no guarantee you are on the site you think you are. You'll have to open it and check the certificate details. Too much work for what I'd estimate at about 99.99% of the average computer users.
Re: (Score:2)
You don't want to, but everyone else does. People want to spend time doing work, not putting in 60 different usernames and passwords for each of the 60 websites they visit.
Ideally, people could run password managers on their PC's (optionally mirrored and encrypted in "the Cloud") that use a standardized web interface to talk to websites so you only remember your one manager password. But that requires a lot of different people working together to make that "the standard."
Re: (Score:2)
Ideally, people could run password managers on their PC's (optionally mirrored and encrypted in "the Cloud") that use a standardized web interface to talk to websites so you only remember your one manager password. But that requires a lot of different people working together to make that "the standard."
Ever heard of LastPass? That is doing exactly as you describe. Encrypted, mirrored in "the cloud", available from any device, autofill passwords, autologin most sites (so even easier than using a Facebook or Google login - especially as I'm not always logged in to those sites), can create and autofill random passwords for you, etc. There are more such password managers; no need for a worldwide standard to be able to use them conveniently. Having fields called "username" and "password" or so will do the job
The problem is the people that clicked on it (Score:1)
This "attack" was so obvious I didn't even consider it a serious attempt until multiple people started getting it.
The mail was sent with the From as one of your contacts' plain e-mail addresses (it didn't even have the full name of the user which Gmail contacts usually have) and To as hhhhhh@mailinator.com
The thing then said this person shared a document, not even an official Google logo, image or disclosure with a link to "Open in Docs". If then took you to a site that asked whether you wanted to give a "G
Re: never (Score:1)
PBKAC error (Score:1)
Ya right (Score:2)
Re: Ya right (Score:1)