Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The closest I've ever come to falling for a Gmail phishing attack

twitter.com

Post reply on HN
Print view View original

91–100 of 289 posts

Re: The closest I've ever come to falling for a Gmail phishing attack

#91

Post by [deleted] »

willvarfar wrote: post #52
xja wrote: post #35

Earlier quoted context omitted.

That's a real shame. There are certainly things they could do to prevent images looking quite so similar to UI elements.

And stop people emailing screen shots? The best approach I can come up with after five seconds thought is disabling links on non-text elements. And then they go make an anchor that is whitespace over top of a background image... so we'd also need to disable links on large expanses of empty whitespace in text when its embedded in a mail. I should think that can likely be worked around too, however. Got any more ideas?

[deleted]

Re: The closest I've ever come to falling for a Gmail phishing attack

#92

Post by hayleox »

Jarwain wrote: post #73
colinbartlett wrote: post #64

Earlier quoted context omitted.

Requiring 2-factor auth would prevent this from being exploitable, right? Probably impossible in a school environment but in an enterprise situation, more palatable perhaps.

My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used…

Oh my god that's awful, what's the point of making it so counterintuitive?? I'll never understand the motivation of companies that roll their own 2FA instead of just using TOTP or Authy.

Re: The closest I've ever come to falling for a Gmail phishing attack

#93

Post by michaelt »

danielbarla wrote: post #77
IanCal wrote: post #68

Earlier quoted context omitted.

I don't think so, I'm not sure how it could. One of the tweets points out that something like lastpass would help with this as it wouldn't allow you to autofill your password (as it's not on the google the domain), but then you could get it manually from there anyway.

Well, when the attacker attempts to log in via the stolen credentials, they would get the 2FA check, and you would get an SMS. Normally this would alert you to the fact that someone is logging in to your account, and would stop the attacker since they lack the 2FA one time pass. In this case though, since you've already fallen for the "I'm trying to log in to Google again", the attacker will probably fake the 2FA scr…

1. You visit the attacker's page and give them your username and password.

2. The attacker immediately tries them, triggering an SMS to you and an 'enter SMS code' page for them.

3. The attacker shows the 'enter SMS code' page to you, and you enter the code from the SMS you just received, giving it to the attacker.

4. The attacker completes their login using the SMS code.

5. The attacker shows the user some believable error message (implying an error on Google's end, or a typo in the SMS code) then forwards the user to the legitimate Google login page.

Re: The closest I've ever come to falling for a Gmail phishing attack

#94

Post by jpalomaki »

midgetjones wrote: post #89
microtonal wrote: post #79

Earlier quoted context omitted.

Yes, but as per the standard TOTP codes are valid for a window of 1 minute. TOTP barely protects against phishing. What you want is an U2F key as the second factor. It's not like they are expensive anyway (usually 7-15 Euro) and quite some large services support U2F tokens already (Google, Dropbox, GitHub, Fastmail, etc.).

Thanks! Is the 1 minute window always the case? In the authenticator app, it seems like codes expire after ~30 seconds. If I wait till the last few seconds before using the code, does that make me any safer?

In some cases the server is configured to accept multiple codes (prev, current, next) to handle timesync issues between server and client (where the app is running).

Re: The closest I've ever come to falling for a Gmail phishing attack

#95

Post by danielbarla »

michaelt wrote: post #93
danielbarla wrote: post #77

Earlier quoted context omitted.

Well, when the attacker attempts to log in via the stolen credentials, they would get the 2FA check, and you would get an SMS. Normally this would alert you to the fact that someone is logging in to your account, and would stop the attacker since they lack the 2FA one time pass. In this case though, since you've already fallen for the "I'm trying to log in to Google again", the attacker will probably fake the 2FA scr…

1. You visit the attacker's page and give them your username and password. 2. The attacker immediately tries them, triggering an SMS to you and an 'enter SMS code' page for them. 3. The attacker shows the 'enter SMS code' page to you, and you enter the code from the SMS you just received, giving it to the attacker. 4. The attacker completes their login using the SMS code. 5. The attacker shows the user some believabl…

Yep, that's what I'm saying too. If you've fallen for providing 1FA, you'll fall for 2FA too, since you think it's legit.

Re: The closest I've ever come to falling for a Gmail phishing attack

#96

Post by IshKebab »

timruffles wrote: post #32

I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…

Ah the classic "ugh. we don't want to have to fix this, so here are some bullshit technical reasons why it's impossible and a bad idea".

Re: The closest I've ever come to falling for a Gmail phishing attack

#98

Post by jneal »

timruffles wrote: post #32

I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…

This is pretty scary. When you hear security professionals explain to laymen how to identify phishing attacks, it's almost always check the URL, make sure you're actually at google.com and not go0gle.com, or something like that.

I can't even imagine what legitimate use there is to placing an entire HTML document into the URL. Just seems like a hack someone came up with as a solution to a problem, not the right solution, but a solution nonetheless.

Re: The closest I've ever come to falling for a Gmail phishing attack

#99

Post by bad_user »

andygambles wrote: post #39

The aim of EV certificates is to reduce such risks and highlight to the user the legitimacy of such websites. HTTPS alone only provides encryption. Google doesn't use EV anywhere but I feel it should on login pages especially given it is a high phishing target.

EV certificates don't work. You're relying on the user to spot a change in the address bar, which is no different than relying on the user to notice that the domain is not "gmail.com".

HTTPS is meant for preventing MITM attacks, but it isn't meant to validate the identity of the entity you're speaking to; even though some people try doing that, it's just a game of pretend.

Re: The closest I've ever come to falling for a Gmail phishing attack

#100

Post by Latty »

Jarwain wrote: post #73
colinbartlett wrote: post #64

Earlier quoted context omitted.

Requiring 2-factor auth would prevent this from being exploitable, right? Probably impossible in a school environment but in an enterprise situation, more palatable perhaps.

My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used…

I assume some misguided soul got told that they needed to reduce the number of texts sent to save costs, but that's horrible.

SMS for 2fa is poor to begin with. I wish people would at least implement the standard TOTP/HOTP option as well if they are going to pull stuff like that.

Post reply on HN