Google Docs Users Targeted by Phishing Scam

http://www.symantec.com/connect/blogs/google-docs-users-targeted-sophisticated-phishing-scam

by ulam2 • 12 years ago

117 76 12 years ago

juliann4• 12 years ago

This is why EVERYONE should have Two-Step Verification (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• 12 years ago

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.

juliann4• 12 years ago

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.

teraflop• 12 years ago

That's not a problem if you use the Authenticator app (or a compatible alternative) instead of getting codes over SMS.

greyskull• 12 years ago

In that case, use the one-time backup codes and make sure to refresh them every few logins while you're away. I think they give you eight at a time.

anon1385• 12 years ago

Serious question: what if you don't have a mobile phone?

axyjo• 12 years ago

Google provides you access to one-time codes, if you wish.

eli7• 12 years ago

There's a compatible OTP app for nearly every OS. Ideally you'd be running it on a device that isn't the same as the one running your web browser, but you could just install e.g. a Windows OTP app and use that. Better than nothing.

shirKahn• 12 years ago

Personally I use a phone, but I also own a TI Chronos programmable watch that has Google OTP support.

The algorithm is fairly straightforward and does not require internet connectivity (through mathematical magic).

skj• 12 years ago

I don't understand how 2FA completely counters this scam.

Consider if you called someone up and told them your password, and then gave them an up-to-date number from your OTP generator.

Except instead of calling them up, you're entering it into a fake web page. Certainly the login you just made would not work when you opened up gmail in another window, but all necessary information would have been given to the attacker.

juliann4• 12 years ago

First, the scam would be randomly asking for the code or not. Cause it can't know whether the user has 2FA activated or not. So that is one way of noticing that its a scam. 2nd the code only works for 30 seconds or so.

I don't know if there's some way of login in through google api's as soon as the user enters the user and password. Also im almost sure that google requires you to enter the code via a form that is provided by them (as a google url). So im thinking something like loggin in to google using server side code and somehow using the code that the user provides to enter into google form (that will be displayed on the server side).

Im still not sure if there's any way of doing this using code. If there's no way of doing it using code then the attacker should be fast enough to use your logins and token in less than 30 seconds (or even less when the code is entered later). So it reduces the chances to get attacked a lot.

ikarandeep• 12 years ago

Agreed 100% However, hopefully you aren't using the same password on other sites. And hopefully you don't plan to use the same password on other sites in the future.

iancarroll• 12 years ago

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

eli7• 12 years ago

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

TrainedMonkey3• 12 years ago

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.

zaroth4• 12 years ago

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• 12 years ago

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

rabbidruster• 12 years ago

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

ianhawes• 12 years ago

I think the parent is theorizing that they could emulate someone logging in through their own headless browser to see if the credentials are valid, then if they are and the account has 2FA, they could trigger the SMS.

clamprecht• 12 years ago

Practically speaking, I think the attackers just focus on the 95% (or whatever percent it is) that don't have 2FA enabled. No reason to worry about the 5% who do.

This all changes if they are targeting a specific individual, or if one day everyone has 2FA enabled.

eam2• 12 years ago

Can't they just disable forms that have the action attribute in forms pointed at anything other than google domain? i.e. a form with action="badbadsite.com/customfile.php" would be disabled.

brown9-22• 12 years ago

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)?

C1D• 12 years ago

It's probably using a form tag in the html. The data entered would be sent as a POST request to the external site.

Or it could be trough JavaScript which would Ajax the data to the external site.

jontas• 12 years ago

The latter would require a cross domain ajax request, I'm sure it is just a regular form POST.

eam2• 12 years ago

My guess would be:

Using something like:<form action="somebadsite.com/script.php">

So the credentials entered get submitted to the form which is sent via POST request to an external server. From there they can do whatever they want with the credentials (perhaps save them to a db) then redirect back to google docs.

eli7• 12 years ago

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.

brown9-22• 12 years ago

Thanks, the article was not very clear about that part.

somerandomness• 12 years ago

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.

semenko• 12 years ago

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/

See presentation: https://docs.google.com/a/google.com/presentation/d/16mB3Npt...

peterkelly3• 12 years ago

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

aawc2• 12 years ago

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

zaroth4• 12 years ago

Here's what FIDO says about the Login process;

1) Online service challenges the user to login with a previously registered device that matches the service's acceptance policy.

2) User unlocks the FIDO authenticator using the same method as at Registration time.

3) Device uses the user's account identifier provided by the service to select the correct key and sign the service's challenge.

4) Client device sends the signed challenge back to the service, which verifies it with the stored public key and logs in the user.

What's to stop an attacker from putting up a phishing page like this, MITM the username/password, forwarding the service's challenge back to the end-user?

I'm going to guess the trick is that the end-user browser has some way to know where the signed challenge should be POSTed for a given service, e.g. by baking that into the "account identifier" used in Step 3. So an attacker can try to MITM the account identifier, but the signed challenge would always be sent directly to the service bypassing the attacker. I'll have to check out the spec...

zaroth4• 12 years ago

OK, just following up on my own curiosity here. Sorry if this is getting OT...

Every FIDO request has an AppID which is the service you are registering for, and it's an HTTPS URI.

When you resolve (HTTPS GET) the AppID, it returns a list of "FacetIDs" which are basically the different channels/endpoints which you can trust sending an authentication response. No more than one of those channels may be a 'Web Origin' facet. "In the Web case, the facetID is the Web Origin [RFC6454] of the web page triggering the FIDO operation". Examples of a non-web facets are "android:apk-key-hash:2jmj..." or "ios:bundle-id:com.acme.app"

While processing an authentication request, the FIDO client must;

o Obtain FacetID of the requesting Application. Resolve AppID URI and make sure that this FacetID is listed in TrustedApps.

- If FacetID is not in TrustedApps – reject the operation

The FIDO client will embed the FacetID it used as part of the signed response it sends back to the server.

The authentication response can optionally contain TLS channel binding information, which the server can use to try to detect MITM (although there can be false positives depending on your network). It also looks like a MITM may be able to use a specially crafted certificate to ensure channel binding information is not usable by the FIDO client.

The final step on the FIDO client in the spec is simply: "Send [xyz]Response message to FIDO Server".

So in summary, it looks like the response channel can be DYNAMIC -- I can ask your FIDO Client to send an authentication response from a different URL than the one you used when you enrolled, but the domain I ask from has to be listed in the response provided by HTTPS GET of the AppID.

The haven't found where spec says exactly how the facet ID should be matched up against the string array returned by resolving the AppID. It appears the full path is undefined and left to the control of the attacker. So a FacetID of https://www.google.com would allow an authentication response to be sent to https://www.google.com/a/domain.com/...

dhekir• 12 years ago

Since we are talking about phishing in Google's domains, can someone explain me why 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 site does, which leads to Google's login?

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

judk5• 12 years ago

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

mikeash3• 12 years ago

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

timothya2• 12 years ago

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

mikeash3• 12 years ago

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.

therealmarv• 12 years ago

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 This warning could be better.

mathattack• 12 years ago

I've seen an account hacked already.

judk5• 12 years ago

Symantec customers are protected against this threat.

How?

Google Docs Users Targeted by Phishing Scam

Related Stories