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

41–50 of 287 posts

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

#41

Post by unethical_ban »

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?

Not all websites offer them.

Hell, no bank I use (several large and several regional) support generic totp. Some have sms, one has Symantec VIP, proprietary and not redundant.

Edit: since I'm posting too fast according to HN, even though I haven't posted in an hour, I'll say it here. Symantec is totp but You cannot back up your secrets and you cannot have backup codes.

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

#42

Post by gabereiser »

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.

There’s a lot of ways to get clips of recordings of someone’s voice. You can get that if they ever spoke at a conference or on a video. Numerous other ways I won’t list here.

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

#43

Post by themagician »

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.

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

#44

Post by captn3m0 »

pyrolistical wrote: post #4

Naming/training issue imo. We need a better name than MFA. Something like “personal password like token that should only be entered into secure computer on specific website/app/field and never needed to be shared”

I've been thinking along these lines for a while. The whole "factors of authentication", where higher=better is no longer a good summary of the underlying complexity in modern authn systems.

We need better terminology.

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

#46

Post by hn_throwaway_99 »

batmansmk wrote: post #36

Are the claims of deepfake and intimate knowledge of procedures based of the sole testimony of the employee who oopsed terribly? This is a novelisation of an events Retool needs to revise the basic security posture. There is no point in complicated technology if the warden just gives the key away.

> Retool needs to revise the basic security posture.

Couldn't agree more. TBH I thought this post was an exercise in blame shifting, trying to blame Google.

> We use OTPs extensively at Retool: it’s how we authenticate into Google and Okta, how we authenticate into our internal VPN, and how we authenticate into our own internal instances of Retool. The fact that access to a Google account immediately gave access to all MFA tokens held within that account is the major reason why the attacker was able to get into our internal systems.

Google Workspace makes it very easy to set up "Advanced Protection" on accounts, in which case it requires using a hardware key as a second factor, instead of a phishable security code. Given Retool's business of hosting admin apps for lots of other companies, they should have known they'd be a prime target for something like this, and not requiring hardware keys is pretty inexcusable here.

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

#47

Post by duderific »

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…

In my company, such a communication would never come via a text, so that would be a red flag immediately. All such communications come via email, and we have pretty sophisticated vetting in place to ensure that no such "sketchy" emails even arrive in our inboxes in the first place.

Additionally, we have a program in place which periodically "baits" us with fake phishing emails, so we're constantly on the lookout for anything out of the ordinary.

I'm not sure what the punishment is for clicking on one of these links in a fake phishing email, but it's likely that you have to take the security training again, so there's a strong disincentive in place.

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

#48

Post by adamckay »

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?

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

#49

Post by pushcx »

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…

The workaround I've seen is to issue a user two 2FAs keys, one for regular use and one to store securely as a backup. If they lose their primary key, they have the backup until a new backup can be sent to them. Using a backup may prompt partial or total restriction until a security check can be done. If they lose both, yes, there needs to be some kind of a reauth. In workplace context like this it's straightforward to design a high-quality reauth procedure.

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

#50

Post by hn_throwaway_99 »

brunojppb wrote: post #31

Fantastic write-up. Major props for disclosing the details of the attack in a very accessible way. It is great that this kind of security incident post-mortem is being shared. This will help the community to level-up in many ways, specially given that its content is super accessible and not heavily leaning on tech jargon.

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