
Google Docs Users Targeted by Phishing Scam - ulam2
http://www.symantec.com/connect/blogs/google-docs-users-targeted-sophisticated-phishing-scam
======
zaroth
What's to stop the attacker from going the next step and forwarding the
user/pass to Google, triggering the SMS for 2FA, and then prompting me to
enter it?

Now all you can hope is that Google notices the source IP or user-agent of the
attacker doesn't match up with the user's usual pattern.

~~~
johns
If they use CSRF tokens, this wouldn't be possible.

~~~
rabbidruster
I don't see how CSRF tokens apply here. They can login as you on another
machine.

~~~
hahainternet
You did not read the parent comment. They cannot (or should not) be able to
forward the login to Google's real form and trigger SMS 2FA because the real
form should be protected by CSRF tokens.

~~~
eli
No, CSRF isn't relevant. I'm an attacker and I have a server that's pretending
to be a Google login form. I also have a client computer with a scripted
browser pretending to be someone trying to login to Google. When you come to
my page and login, I steal your data and immediately have my client program
use it to login. If Google asks my client browser for a 2FA code, behind the
scenes I forward that request to you and then when you answer, I forward the
answer back to Google. From what Google can see, it just looks like someone
logging in from a new computer.

None of this has anything to do with cross-site scripting. It's a MITM attack.
CSRF doesn't come into play.

------
semenko
Surprised no one's used this opportunity to talk about Google's gnubby / FIDO
/ U2F plans.

Non-phishable two-factor auth token:
[http://fidoalliance.org/](http://fidoalliance.org/)

See presentation:
[https://docs.google.com/a/google.com/presentation/d/16mB3Npt...](https://docs.google.com/a/google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-
ozN6j3-fr7JL8XVyA/edit#slide=id.g19c09a112_2_0)

~~~
peterkelly
Sure, I'll just click on that google docs link to read about it...

~~~
aawc
The pathname "/a/google.com" means it does come from within Google.

~~~
RKearney
No, it doesn't. You can put any valid Google Apps domain there.

See:
[https://docs.google.com/a/google.com/document/d/1MBxYZ9C51t9...](https://docs.google.com/a/google.com/document/d/1MBxYZ9C51t9sqL83D3T5708eRk05WaYbE1Dw0qX-
iB8/)

If you're logged into a Google Apps domain it will change the google.com to
match your domain. If you're logged into a regular Google account it will
remain as google.com.

~~~
aawc
Thanks for correcting me. I never realized this.

------
juliann
This is why EVERYONE should have Two-Step Verification
([https://support.google.com/accounts/answer/180744?hl=en](https://support.google.com/accounts/answer/180744?hl=en))
enabled if you care a little bit about your Google Account and the data you
have stored there. This kind of attack will expose your password, but the
attackers wont get in your account anyway.

~~~
wtvanhest
I have it, but one thing to consider when you add Two-step is that you need a
plan when you travel overseas and may not have the same sim card. Not
difficult to consider, but you still need to. Being in Europe for a few weeks
with no email is no fun.

~~~
juliann
The two step app works even with no connection to the internet. I dont know
how but it does. I think you dont need to have the same sim card. only the
phone turned on.

~~~
tjohns
Google Authenticator uses TOTP (RFC 6238), which means the codes are a
function of time plus a secret key. As long as your phone's clock is
reasonably accurate, the app will work without any network access.

[http://tools.ietf.org/html/rfc6238](http://tools.ietf.org/html/rfc6238)

~~~
UnfalseDesign
You definitely don't need network access. I use Google Authenticator on my
Wifi only tablet. You need an internet connection to sync it to Google's key
but not after that. And, yes, when the tablet's clock is off by a few minutes,
the code doesn't work.

------
iancarroll
It's interesting how this is done - and there's no real workaround except to
force 2FA.

~~~
eli
How does 2FA solve this? You're interacting with an attacker who is prompting
you for information in real time.

~~~
TrainedMonkey
Right. This is MITM attack and they can defeat most of 2FA out there today.

One technique that might help is to make user choose a picture during account
registration. During login show that picture, if user does not see correct
picture he would suspect something.

It does not have to be picture, could be style or background of login
component.

~~~
eli
If the server just knows what picture is attached to my account, couldn't this
attacker simply request the picture on my behalf and then show it to me?

~~~
juliann
That information would obviusly not be accessible via ANY api. So that would
be something only Google private apps have access to.

~~~
georgemcbay
Doesn't really matter if there is an API for it or not, if Google were to
display it prior to you being authenticated (which they would have to for it
to have any impact in this sort of attack), it would be fairly trivial for the
attack code to (behind the scenes) present themselves as you to Google and
then scrape the correct image from Google's response to their request. There
are various things Google could do to make this more difficult, like some
fancy rendering via canvas or webgl instead of just using a bog standard img
tag, but to counter this the attack could just run a headless rendering
browser and pixel scrape the resulting image.

Such a verification image makes the MITM attack a bit harder to code, but not
really by much, and in the process might introduce an increased false sense of
security.

------
therealmarv
I think it is important that Symantec should mention how the URL looks like.
From reading this news I can only assume that this happens with hosted
websites from Google Drive which have an URL like
[https://googledrive.com/host/someidhere](https://googledrive.com/host/someidhere)
This warning could be better.

------
dhekir
Since we are talking about phishing in Google's domains, can someone explain
me why [http://www.blogspot.co.uk](http://www.blogspot.co.uk) (and .ie, and
.fr, etc.) leads to someone's specific blog, instead of doing like the
[http://www.blogspot.com](http://www.blogspot.com) site does, which leads to
Google's login?

What prevents this "www" Blogger user from mounting a phishing attack?

~~~
judk
Nice, www.neocities.com had a similar flaw.

------
brown9-2
_After pressing "Sign in", the user’s credentials are sent to a PHP script on
a compromised web server._

I might be missing something, but how does this part work?

Is it because the document in the Google Drive folder is actually a html
document that the browser is loading (and executing javascript of)?

~~~
eli
AFAIK, it's not a legitimate login form. It's a attacker-created form that
just _looks_ like the login form. The trick is that they used Google Docs to
host it on a .google.com server.

~~~
somerandomness
it wasn't actually hosted on a .google.com domain. It was googledrive.com,
which is also owned by Google, but you should never expect a login form on
that domain.

------
mikeash
And that's why you shouldn't serve user content on the same domain as your own
stuff.

~~~
timothya
Which they don't. Google Drive data is served from a different URL for
precisely this reason.

~~~
mikeash
They use a different subdomain, but both the official login page and user docs
are served from a *.google.com hostname. I'm not sure if that counts or not.

~~~
timothya
The _real_ login page is on a *.google.com domain, of course. But this
phishing scheme is on a different domain, namely
[https://googledrive.com/..](https://googledrive.com/..).

~~~
mikeash
Good! I tried loading a document of my own but only figured out how to get a
preview and a download. Shouldn't have extrapolated from there, I guess.

------
judk
> Symantec customers are protected against this threat.

How?

------
mathattack
I've seen an account hacked already.

