Hacker News new | ask | show | jobs
Be warned, there's a nasty Google 2 factor auth attack going around (twitter.com)
142 points by maccman 3667 days ago
10 comments

So the scam is, attacker knows your gmail address and your phone number. They send you the text message about suspicous activity on your account. Then they attempt to reset the password on your gmail account. That triggers Google to send you the code. You reply to the attacker's message with the code as instructed, and they own your account.
Again, this is a social engineering attack. 2-factor remains mathematically secure.
Sure, but implementation matters. I've long thought that 2 factor via SMS is a sub-optimal solution because it trains you to expect secure login info from a random shortcode SMS number.
It doesn't sound like "2-factor" if all they need is the single code on your phone.
Account recovery is always a nagging weak spot. At some point, a user will forgot their password or lose their TFA device, and now you need them to be able to prove their identity outside of the usual flow. And if you have enough users, this has to be automated, leaving even more room for exploitation.
> And if you have enough users, this has to be automated

Not really, they could just charge people $100 to retrieve a lost password and then do it manually.

I would love for services that I REALLY care about never ever ever being broken into (email, web hosting) there was ONLY the $100-and-speak-to-a-human option to change the password

I would even make it $100 + skype and show live on skype your passport.

Charging $100 is pretty punitive, but I've often wondered why more online services sensitive to attack don't use token credit card charges as a way to limit account duplication, increase complexity in a malicious operation, etc.

Stealing credit cards is cheap, yes, but the additional cost to using such a card on a password reset would still be a deterrent.

And in the real world, no one would use that service. You aren't wrong though, that would be the way to do it if you wanted it to be secure.
That is a PR nightmare...
I'd say it is two factor (googles implementation, the attack is classical social engineering): something you know (the password) and something you have (access to your phone).
In Google's implementation, only the "something you have" is really necessary for access. If you have the phone but not the password, you can just issue a password reset, which is confirmed via the phone, so the password doesn't function as a second factor independent of the phone.
I wonder if anyone implements the restriction that a password reset can only be ordered after a certain time (a week, say) since the last successful password entry, for long-established accounts. Most real password resets are likely either in long-dormant or recently-created accounts, and this would add just another layer of partial protection against these kinds of attacks.
Whoa. I hadn't realized this. So someone that knows my email address and has my phone has access to my entire life, because all password resets use my email address.

If it's come to this, to using "something you have", then we can all go back to using paper password notebooks. They offer the same security, surprisingly.

Mathematically secure is totally meaningless. OTPs can be phished, and this attack is a great example of that.

U2F is the fix for this.

Was anyone claiming otherwise?
This sounds like an ancient Agora protocol interaction attack back in the beginning of e-commerce :-D
This isn't a 2 factor attack. It's a social engineering Google account password reset attack. The attacking party is resetting your Google password and asking you to provide the code Google sends your registered mobile number via text to them.
It is a 2 factor attack in the sense that it reduces the two factors down to one.
2 factor auth is not a defence against phishing. This is such a common misconception. All two-factor means is that someone with only your password cannot log in, or only your device.

What's happening here is that Google accounts without 2-factor but with a phone recovery path set up are being "account recovered" by a bad guy. It's just plain old phishing.

I don't think there were ever 2 steps in this account recovery flow. There seems to be only 1 step when initiating a account recovery: provide the code sent to your phone.

A 2 factor recovery flow would be 1) verify an email that was sent to your recovery email address that triggers 2) this account recovery code sent to your phone.

It does not reduce the two factors down to one. You still need two factors (password and SMS code) to login. It's just that you're giving both of them to the attacker.
I wonder if this is at all related to a phishing attempt that just got my mom and all her friends. It came in as a "docusign" email that looked reasonably legit (to an ordinary person) that just had one button to sign and review a document. Apparently they asked for email, email password, and phone number. I was surprised to learn about the phone number bit and how they'd use it. Something like this is probably how.

While I'd have thought entering your email password would have been red flag galore, my mom and her friends were all exploited by the social trust aspect "I figured if it was coming from you it would be real."

> "I figured if it was coming from you it would be real."

You should set up a strict DMARC policy (p=reject) to prevent people from spoofing your email address. It appears that you have not[1].

Additionally, you should harden your SPF record: change ~all to -all.

[1]: https://dmarcian.com/record-tools/azinman.com

It's not a spoof when you're phished and hand over your credentials.

It also was my mom that was phished, not me.

Sorry, I don't think you understand.

I'm saying that people cannot send emails to your mother pretending to be you if you were to implement the changes I have suggested.

I didn't say you were phished, I said you were spoofed. Judging by your first comment, your email address being spoofed is how your mother was phished.

I do understand :) Perhaps my first comment was not clear. She never received anything from me. I'm not involved at all. It was her friend that got originally phished, which then sent a legitimate email (from an SPF record perspective) to her, which then phished her credentials, and so forth.
I just saw one of those. It's especially convincing when they target realtors' address books, because everyone in a real estate transaction is expecting a bunch of docusign links to be flying around from their realtor and their title company. So if something doesn't look kosher, they attribute it to a clunky process and hand over their login.
This is exactly how my parents were phished. Interesting to hear it likely wasn't a coincidence that it came from their realtor.

I subsequently set them up with two factor almost everywhere, but I'd give at least even odds they'd fall for this, too. Sigh.

Clever. If you've never actually had 2FA trigger before to know how it works, you could fall for this.
This is one of nice things about using a hardware security key (FIDO U2F), like Yubikey.

Since the security key works with the browser to ensure its communicating directly with a specific site, you can't MITM them like you can mobile app (TOTP) or SMS-based two-factor codes.

I wish more browsers would add support for them.

This "attack" could be semi-mitigated by using Authy or Google Authenticator instead of SMS. If users knew to never ever paste the generated codes anywhere but the site, this attack wouldn't exist at all.
A friend is currently receiving spear phishing attempts via text. Claims their lost iPhone has been found and that they need to log into icloud10 . com
While you're add it, verify that your password has not been hacked by entering it here: hxxp://evil.example.com/password-checker
hunter2
password123
How can this possibly work?

Even if an attacker gets the phone code, they should still need your password to sign in. How do they get past that?

As ams6110 noted, it's likely not a 2-factor auth attack but rather a password reset attack.
I guess I'm going to go set all my security question answers to random 64-byte strings that are base-64 encoded.
Don't forget to apply a ROT-13 encoding afterwards, that should make it super secure.
I'm doubly secure with ROT-13 applied twice! ROT-26 (Patent Pending). Don't leave home without it.
The nice thing about applying ROT-13 twice is that it greatly reduces decoding time.