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

141–150 of 287 posts

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

#141

Post by hn_throwaway_99 »

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…

Amen, amen, amen. IMO "Hang up, look up, call back" should basically be the only thing that security training focuses on, and it should be culturally ingrained: https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo...

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

#142

Post by deepspace »

dvdhsu wrote: post #99
hn_throwaway_99 wrote: post #50

Earlier quoted context omitted.

I disagree. I appreciate the level of detail, but I don't appreciate Retool trying to shift the blame to Google, and only putting a blurb in the end about using FIDO2. They should have been using hardware keys years ago.

Hi, I'm sorry you felt that way. "Shifting blame to Google" is absolutely not our intention, and if you have any recommendations on how to make the blog post more clear, please do let me know. (We're happy to change it so it reads less like that.) I do agree that we should start using hardware keys (which we started last week). The goal of this blog post was to make clear to others that Google Authenticator (through…

There is also the bit about the phishers deep-faking an employee's voice. Yeah, right. That happened. /sarcasm

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

#143

Post by deepspace »

themagician wrote: post #43
AYBABTME wrote: post #29

To deepfake the voice of an actual employee, they would need enough recorded content of that employee's voice... and I would think someone doing admin things on their platform isn't also in DevRel with a lot of their voice uploaded online for anyone to use. So it smells like someone with close physical proximity to the company would be involved.

Probably wasn't a "deepfake" just someone decent with impressions and a $99 mixer. After compression this will be more than good enough to fool just about anyone. No deepfake is needed. Just call the person once and record a 30 second phone call. Tell them you are delivering some package and need them to confirm their address.

That is more plausible. But the embellishment about the phisher knowing the layout of the office etc makes me think it was just straight up an inside job, with the employee willingly handing over the OTP and trying to cover their tracks.

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

#144

Post by bawolff »

tomatocracy wrote: post #139
bawolff wrote: post #64

Earlier quoted context omitted.

> I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. Depends on what you think the purpose is. People talk about TOTP solving all sorts of problems, but in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking. While i also think th…

It's also a reasonable defence against naive keylogging techniques - including shoulder-surfing either directly or eg via security cameras. In some places this can be a pretty big threat.

I think its reasonable against spur of the moment shoulder surfing. I'm a little doubtful about how common that attack vector is - i think showing passwords as ** is a reasonable deterrant against literal shoulder surfing as well. Once you get security cameras involved things get more sophisticated and people can watch the feed live or do other things with physical access to the device.

Ultimately, i think for the average user the attacker is mostly not in physical proximity (although there certainly are exceptions), and if you are being targeted explicitly then you are screwed if they are installing cameras and modifying your hardware.

Maybe the big exception would be a camera in a coffee shop place looking for people (not live) logging into their bank accounts. I could inagine this being a helpful defense.

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

#145

Post by dataflow »

macNchz wrote: post #126
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…

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…

I'm sure a lot of people are like what you describe (this doesn't occur to them), but I think it does affect those who are a bit suspicious/on the fence, potentially like the person in the article. ("Throughout the conversation, the employee grew more and more suspicious, but unfortunately did provide [the MFA code].")

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

#146

Post by hn_throwaway_99 »

deepspace wrote: post #142
dvdhsu wrote: post #99

Earlier quoted context omitted.

Hi, I'm sorry you felt that way. "Shifting blame to Google" is absolutely not our intention, and if you have any recommendations on how to make the blog post more clear, please do let me know. (We're happy to change it so it reads less like that.) I do agree that we should start using hardware keys (which we started last week). The goal of this blog post was to make clear to others that Google Authenticator (through…

There is also the bit about the phishers deep-faking an employee's voice. Yeah, right. That happened. /sarcasm

In fairness dvdhsu responded about that point elsewhere: https://news.ycombinator.com/item?id=37502239

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

#147

Post by dvdhsu »

hnburnsy wrote: post #135
dvdhsu wrote: post #89

Earlier quoted context omitted.

Hi, David, founder @ Retool here. We are currently working with law enforcement, and we believe they have corroborating evidence through audio that suggests a deepfake is likely. (Put another way, law enforcement has more evidence than just the employee's testimony.) (I wish we could blog about this one day... maybe in a few decades, hah. Learning more about the government's surveillance capabilities has been interes…

Thanks for all this insight, this is why HN rules. What is your impression of law enforcement, everyone claims to reach out after an attack, but I've never seen follow up of sucessful law enforcement activity resulting in arrests or prosecution. Thanks again.

(May also have to delete this later, but...)

Law enforcement is currently attempting to ascertain whether or not the actor is within the US. If it's within the US, I (personally) believe there's a good chance they'll take the case on and presumably with enough digging, will find the attacker. (The people involved seem to be... pretty good.)

But if they're outside US (which is actually reasonably high probability, given the brazenness of the attack, and the fact that they're leaving a lot of exhaust [e.g. IP address, phone number, browser fingerprints, etc.]), then my understanding is that law enforcement is far less interested, since it's unlikely that even an identification of the hacker would lead to any concrete results (e.g. if they were in North Korea). (FWIW, the attack was not conducted via Tor, which to me implies that the actor isn't too worried about law enforcement.)

To give you a sense, we are in an active dialogue with "professionals". This isn't a "report this to your local police station" kind of situation.

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

#148

Post by Zarathustra30 »

itake wrote: post #24
unethical_ban wrote: post #10

Earlier quoted context omitted.

Syncing of "MFA codes" is really syncing of the secret component of TOTP (time based one time password). And it's a good thing, and damn any 2fa solution that blocks it. I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone. So I use authy personally, while a friend backs his up locally.

> I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone Why don't you use the printed recovery tokens?

The toddler got there first.

Seriously, though, it's hard to keep track of something that gets used once every five years.

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

#149

Post by couchand »

dataflow wrote: post #145
macNchz wrote: post #126

Earlier quoted context omitted.

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…

I'm sure a lot of people are like what you describe (this doesn't occur to them), but I think it does affect those who are a bit suspicious/on the fence, potentially like the person in the article. ("Throughout the conversation, the employee grew more and more suspicious, but unfortunately did provide [the MFA code].")

The old adage is that a con artist makes the best mark.

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

#150

Post by andersa »

Guvante wrote: post #32
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…

On the otherhand having your device die means without cloud backup you either lose access or whoever was relying on that 2FA needs to fall back on something else to authenticate you. After all if I can bypass 2FA with my email whether 2FA is backed up to the cloud doesn't matter from a security standpoint. Certainly I would agree with the assertion that opting out for providers of codes would be nice. Even if it is a…

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.
Post reply on HN