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

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

retool.com

Post reply on HN
Print view View original

121–130 of 287 posts

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

#121

Post by supertrope »

miki123211 wrote: post #53
softfalcon wrote: post #26

Earlier quoted context omitted.

>FIDO2 can also detect the domain making the request, and will not provide the correct code even it the page looks correct to a human. I could not agree more with this sentiment! We need more of this kind of automated checking going on for users. I'm tired of seeing "just check for typo's in the URL" or "make sure it's the real site!" advice given to the average user. People are not able to do this even when they kno…

The problem with Fido (and other such solutions, including smartphone-based passkeys) is that they make things extremely hard if you're poor / homeless / in an unsafe / violent family situation and therefore change devices often. It's mostly a non-issue for Silicon Valley tech employees working solely on their corporate laptops, and U2F is perfect for that use-case, but these concerns make MFA a non-starter for the w…

Stronger security can also help the marginalized. If your abusive SO has the phone plan in their name they can order up a new SIM card and reset passwords on websites that way too often fallback from “two factor” to SMS as a root password.

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

#122

Post by Master_Odin »

adamckay wrote: post #48
rolobio wrote: 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…

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

A number of sites I've signed up for recently have required TOTP to be setup, but did not provide back up codes at the same time. There's a lot of iffy implementations out there.

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

#123

Post by tyingq »

macNchz wrote: post #100

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…

>This also applies to non-work related calls: someone from your credit card company is calling and asking for something? Call back on the number on the back of your card.

There's a number of situations, not just credit card ones, where it's impossible or remarkably difficult to get back to the person that had the context of why they were calling.

Your advice holds, of course, because it's better to not be phished. But sometimes it means losing that conversation.

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

#124

Post by dataflow »

josho wrote: post #120
dataflow wrote: post #116

Earlier quoted context omitted.

> 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. The trouble is, calling the number on the back of your card requires actually taking out your card, dialing it, wading through a million menus, and waiting who-knows-how-long for s…

Great point. But it could be easily solved with something like: “Call the number on the back of your credit card. Push *5 and when prompted enter your credit card number and you will be immediately connected back to my line”

Or just connect you directly if you call back within a few minutes from the same number they called, no need to press anything. But I guess that's too advanced for 2023 technology

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

#125

Post by deathanatos »

j-bos wrote: post #102

Where can one find a breakdown of how to build implement a TOTP generator? For curiosity's sake

The basic premise is in https://datatracker.ietf.org/doc/html/rfc6238, although today I'd use SHA-256, not SHA-1, if possible.

But I'd disfavor TOTP over hardware tokens that can sign explicit requests.

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

#126

Post by macNchz »

dataflow wrote: post #116
macNchz wrote: post #100

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…

> 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. The trouble is, calling the number on the back of your card requires actually taking out your card, dialing it, wading through a million menus, and waiting who-knows-how-long for s…

I don't think most people who get scammed this way pause to say "oh, this might be someone stealing my credit card number", then disregard that thought because it's too much of a pain to call back on an official line. Instead I think they don't question the situation at all, or the scammer has enough information to sound sufficiently authoritative. Most non-technical people I've talked to about this are pretty scared of getting scammed, but tell me the thought never crossed their mind they could call back on a trusted number.

I like the "hang up, call back" approach because it takes individual judgment out of the equation: you're not trying to evaluate in real time whether the call is legit, or whether whatever you're being asked to share is actually sensitive. That's the vulnerable area in our brains that scammers exploit.

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

#127

Post by bawolff »

timando wrote: post #119
bawolff wrote: post #86

Earlier quoted context omitted.

No it can't. The rouge javascript or keylogger would just steal the totp code, prevent the form submission, and submit its own form on the malicious person's server. Not to mention if your threat model includes attacker has hacked the server and added javascript, why doesn't the attacker just take over the server directly? If the attacker installed a keylogger why dont they just install software to steal your session…

> Not to mention if your threat model includes attacker has hacked the server and added javascript, why doesn't the attacker just take over the server directly? If the attacker can only hack the server that hosts your SPA, but not your API server, they can inject javascript to it, but can't do a lot beyond that

So assuming server side compromise not xss - in theory the servers can be isolated, in practise its rare for people to do a good job with this except at really big companies.

Regardless if they got your spa, they can replace the html, steal credentials, act as users, etc. Sure the attacker might want something more, but this is often more than enough to do anything the attacker might want if they are patient enough. Certainly its more than enough to do anything TOTP would protect against.

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

#128

Post by dmazzoni »

tough wrote: post #3
rahidz wrote: post #2

>The caller claimed to be one of the members of the IT team, and deepfaked our employee’s actual voice. The voice was familiar with the floor plan of the office, coworkers, and internal processes of the company. Wow that is quite sophisticated.

inside job?

Anything's possible, but the simplest explanation (per Occam's razor) is just that the employee was fooled.

Is it plausible that if a good social engineer cold-called a bunch of employees, they'd eventually get one to reveal some info? Yes, it happens quite frequently.

So any suggestion that it was an inside job, or used deep fakes, or something like that would require additional evidence.

Kevin Mitnick's "The Art of Deception" covers this extensively. The first few calls to employees wouldn't be attempts to actually get the secret info, it'd be to get inside lingo so that future calls would sound like they were from the inside.

For example, the article says the caller was familiar with the floor plan of the office.

The first call might be something like "Hey, I'm a new employee. Where are the IT staff, are they on our floor?" - they might learn "What do you mean, everyone's on the 2nd floor, we don't have any other floors. IT are on the other side of the elevators from us."

They hang up, and now with their next call they can pretend to be someone from IT and say something about the floor plan to sound more convincing.

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

#129

Post by skeaker »

rahidz wrote: post #2

>The caller claimed to be one of the members of the IT team, and deepfaked our employee’s actual voice. The voice was familiar with the floor plan of the office, coworkers, and internal processes of the company. Wow that is quite sophisticated.

Highly reminiscent of the sort of social engineering hacks Mitnick would run. In his autobiography he would pull this sort of thing by starting small and simply asking lower ranking employees over the phone for low risk info like their name and things like that so when it came time to call higher ranking ones he could have trustworthy-sounding info to call back to. The attack is clever for sure, but not necessarily any more sophisticated than multiple well-placed calls.

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

#130

Post by tamimio »

You know how I never get phished? I never answer any call or sms asking anything, and a link in a text message is ALWAYS a major red flag. I know everyone is talking about the MFA, but the entry point was the employees phone numbers, how they got that in the first place? Especially from the article the attacker knew the internals of this company..

As for the MFA, google should have the on demand peer-peer sync rather than cloud save, for example, a new device is added, then your Google account is used to link between these new device and existing device, click sync and you will be asked on your old device that a new device is requesting bla bla would you allow it? And obviously nothing saved in the cloud, just a peer-peer sync and google is a connection broker.

Post reply on HN