Live data from Hacker News

When MFA isn't MFA, or how we got phished

retool.com

201–210 of 287 posts

Re: When MFA isn't MFA, or how we got phished

#201
post #22

Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…

They could’ve just had employees use Okta Verify as opposed to Google Authenticator

Re: When MFA isn't MFA, or how we got phished

#202

Earlier quoted context omitted.

> None, to date, have worked for a company that has a process established for safely establishing identity of the person they're calling What's fun here is, the moment they ask you for anything, flip the script and start to try to establish a trust identity for the caller. Tell them you need to verify them, and then ask how they propose you do that. Choose your own adventure from there.

Credit card fraud departments are generally good about this.

I can't remember which company it was, but I got a call a few years ago about some issue with an account, and they wanted some information to "verify my identity"

I said wait a minute, you called me. Shouldn't I be verifying who you are?

The guy kind of laughed and said yeah, but this is the process I've been given to follow. I said I would call back on public customer service number and he said that would be fine.

It turned out it was a legit call, but just weird that they would operate that way.

I wish I could remember who it was. A credit card, I think.

Re: When MFA isn't MFA, or how we got phished

#203
post #172

Earlier quoted context omitted.

You can't understand at all how someone with your coworker's voice might lull you into a false sense of urgency and safety? Security is a weak-link problem, not a strong-link one. You have to plan for the least security-minded people, the tired and stressed employee.

I can understand how someone with my coworker's voice might lull myself into a false sense of urgency and safety. To the point of sharing an OTP code over the phone from a strange number? I'm sorry, no.

You could give them a false number and see what happens. That might trip up their script enough to reveal they aren't who they seem to be. Just play dumb -- "I can't understand why it's not working, that's the number on my phone...."

Re: When MFA isn't MFA, or how we got phished

#204
post #200

Earlier quoted context omitted.

> I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose Probably so when you upgrade/lose your phone you don't otherwise lose your MFA tokens. Yes, you're meant to note down some recovery MFA codes when you first set it up, but how many "normal people" do that?

With Google Authenticator some years ago it wasn't even possible to restore your codes even if you had a local backup of the device. I'm not sure if that still is the case today but it was a common issue which we saw at our service desk before we switched to a different solution.

Yeah I had to re-enroll my phone when I got a new one a few years ago.

I never did get around to doing all of them so I still have the old phone in a drawer for those rare times I need it.

Re: When MFA isn't MFA, or how we got phished

#205

Beyond having hardware keys, this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. It's always okay to say, "actually, let me get back to you in a minute" and hang up, calling back on a known phone number from the employee directory, or…

I've had a wide range of responses from people calling me when I tell them I won't give personal details out based on a cold call. A few understand immediately and are good about it. Most have absolutely no idea why I would even be bothered about an unexpected caller asking me for personal information. A few are practically hostile about it. None, to date, have worked for a company that has a process established for…

Anecdotally, I seem to have had the opposite experience. I've been doing this for at least 15 years, and never had a negative reaction. With bank, credit card, or finance-related companies, they seem to understand immediately. With other callers I've gotten awkward pauses, but ultimately they were politely accommodating or at least understanding that some issue would have to be processed through other channels or postponed.

However, I don't have strict requirements. When a simple callback to the support line on the card, bill, or invoice doesn't suffice--and more often than not it does, where any support agent can field the return call by pulling up the account notes--all I ask for at most is an extension or name that I can use when calling through a published number. I'll do all the leg work, and am actually a little more suspicious when given a specific number over the phone to then verify. Only in a few cases did I have to really dig deep into a website for a published number through which I could easily reach them. In most cases it suffices to call through a relatively well attested support number found in multiple pages or places[1].

I'm relatively confident that every American's Social Security number (not to mention DoB, home address, etc) exists in at least one black market database, so my only real practical concern is avoiding scammers who can't purchase the data at [black] market price, which means they're not very sophisticated. A callback to a published phone number for an otherwise trusted entity that I already do business with suffices, IMO. And if I'm not already doing business with them, or if they have no legitimate reason to know something, they're not getting anything, period.

[1] I may have even once used archive.org to verify I wasn't pulling the number off a recently hacked page, as it was particularly off the beaten path and a direct line to the department--two qualities that deserve heightened scrutiny by my estimation.

Re: When MFA isn't MFA, or how we got phished

#206

Earlier quoted context omitted.

> Very sophisticated attack, I would bet most people would fall for this. No. If you think people at your company would fall for this, then IMO you have bad security training. The simple mantra of "Hang up, lookup, call back" ( https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo... ) would have prevented this. Literally like 99% of social engineering attacks would be prevented this way. Seriously, make a lit…

This fails to satisfy one of the core lessons here: trust nothing, not even your own training and culture.

Reminds me of a situation early in my career where I was talking with the CTO about some security concern and I said "well it's all on the internal company network" and he immediately said "why on earth do you think you can trust our internal network?"

Re: When MFA isn't MFA, or how we got phished

#207

Question for security folks out there: So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system. Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive…

I've worked in places where to get access to production or other sensitive stuff, an employee would need to submit a request which had to be approved by whoever was designated to approve such things. Then the employee got a short-lived credential that could be used to log in. Everything they did was logged. Once used, the credential could not be used for subsequent logins. Their session was time-limited. If they needed more time, they needed to submit another request.

Re: When MFA isn't MFA, or how we got phished

#208

Beyond having hardware keys, this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. It's always okay to say, "actually, let me get back to you in a minute" and hang up, calling back on a known phone number from the employee directory, or…

> any situation where you receive a phone call (or other message) and someone starts asking for information.

I had AWS of all places do this to me a year or two ago. The rep needed me to confirm some piece of information in order to talk to me about an ongoing issue with the account. If I recall correctly, the rep wanted a nonce that had been emailed to me.

"I'm terribly sorry but I won't do that. You called me."

Ultimately turned out to be legit, but I admit I was floored.

Re: When MFA isn't MFA, or how we got phished

#209
post #186

Am I the only one questioning the deep fake of the voice?

If they have an audio recording of the person, there's a bunch of sites where you can create them on the fly for free. Don't know about the quality, though I imagine distortion can be dismissed as being from the phone rather than the fake.

Yeah, just add some twangy dropouts like a poor cell connection has.

Re: When MFA isn't MFA, or how we got phished

#210
post #195

Earlier quoted context omitted.

They could do what Authy does. Codes are backed up to the cloud, so you're not completely fucked if the phone is stolen. But the backup is encrypted, and to access it on a replacement device you must enter the backup password.

That relies on someone remembering their backup password that they probably don't use often.

I suspect that this sort of issue is the real reason for making it difficult to not back up secrets to the cloud. On the one hand, you will have some number of people pissed off because they were taken advantage of and they realize that it was enabled by having backups in the cloud. On the other, you have people pissed off because they couldn't manage the final step in keeping their shit secure and are now locked out of something. The number in the latter category is vastly larger than the number in the former.
Post reply on HN