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

81–90 of 287 posts

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

#81

Post by charcircuit »

unethical_ban wrote: post #10
kerblang wrote: post #6

I don't understand: Why on earth does google want to sync MFA tokens? They're one-time use, aren't they? Or... feh, I can't even fathom

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.

If you can backup a key it is not MFA. It just a second password and not another factor. The solution to having your phone smashed is to have multiple "something you have", so you have a backup.

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

#82

Post by luma »

oldtownroad wrote: post #75
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.

And obviously untrue. If you’re an employee who just caused a security incident of course you’re going to make it seem as sophisticated as possible but considering Retool has hundreds of employees from all over the world, the range of accents is going to be such that any voice will sound like that of at least one employee. Are you close enough to members of your IT team to recognise their voices but not be close enou…

Fully agreed, saying a deepfaked voice was involved without hard proof is deflecting blame by way of claiming magic was involved.

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

#83

Post by alsodumb »

Maybe it’s just me, but I am really skeptical about the DeepFake part - it’s a theoretically possible attack vector, but the only evidence they possibly could have to support this statement would be the employees testimony. Targeting a particular employee with the voice of a specific person this employee knows requires a lot of information and insider info.

Also, I think the article spends a lot of effort trying to blame Google Authenticator and make it seems like they had the best possible defense and yet attackers managed to get through because of Googles error. Nope, not even close. They would have had hardware 2FA if they were really concerned about security. Come on guys, it’s 2023 and hardware tokens are cheap. It’s not even a consumer product where one can say that hardware tokens hinder usability. It’s a finite set of employees, who need to do MFA certain times for certain services mostly using one device. Just start using hardware keys.

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

#84

Post by aberoham »

hn_throwaway_99 wrote: post #60

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…

Teleport has two person rule + hardware token enforcement, https://goteleport.com/resources/videos/hardened-teleport-ac...

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

#85

Post by hn_throwaway_99 »

dotty- wrote: post #62
hn_throwaway_99 wrote: post #46

Earlier quoted context omitted.

> 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 a…

> 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. This isn't immediately actionable for every company. I agree Retool should have hardware keys given their business, but at my company with 170 users we just haven't gotten around to figuring out the distribution and adoption of hard…

> What is a company like mine meant to do here to counter this problem?

What is hard about mailing everyone a hardware key? I honestly don't see the problem. It's not like you need to track it or anything, people can even use their own hardware keys.

1. Mail everyone a hardware key, or tell them if they already have one of their own they can just use that.

2. Tell them to enroll at https://landing.google.com/advancedprotection/

> Google Workspace actually lacks a lot of granular security features, something I wish they did better.

Totally agree with that one. Last time I checked you couldn't enforce that all employees use Advanced Protection in a Google Workspace account. However, you can still get this info (enabled or disabled) as a column in the Workspace Admin console so you can report on people who don't have it enabled. I'm guessing there is also probably a way to alert if it is disabled.

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

#86

Post by bawolff »

luma wrote: post #76
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…

TOTP is helpful when you don’t fully trust the input process. If rogue javascript is grabbing creds from your page, or the client has a keylogger they don’t know about, TOTP can help.

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

This threat model doesn't make sense. It assumes a powerful attacker doing the hard attack and totally ignoring the trivially easy one.

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

#87

Post by johngalt »

hn_throwaway_99 wrote: post #60

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…

Mechanisms like this exist, but they probably aren't integrated into whatever system you are using, and delays which involve an approval workflow add a lot of overhead.

In most cases the engineering time is better spent pursuing phishing resistant MFA like FIDO2. Admin/Operations time is better spent ensuring that RBAC is as tight as possible along with separate admin vs user accounts.

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

#88

Post by hn_throwaway_99 »

aberoham wrote: post #84
hn_throwaway_99 wrote: post #60

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…

Teleport has two person rule + hardware token enforcement, https://goteleport.com/resources/videos/hardened-teleport-ac...

Really, really appreciate you sending this! I will dig in but this seems to be exactly what I was asking about/looking for. I'm always really curious why the big native cloud platforms don't support this kind of authentication natively.

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

#89

Post by dvdhsu »

alsodumb wrote: post #83

Maybe it’s just me, but I am really skeptical about the DeepFake part - it’s a theoretically possible attack vector, but the only evidence they possibly could have to support this statement would be the employees testimony. Targeting a particular employee with the voice of a specific person this employee knows requires a lot of information and insider info. Also, I think the article spends a lot of effort trying to b…

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 interesting.)

I agree with you on hardware 2FA tokens. We've since ordered them and will start mandating them. The purpose of this blog post is to communicate that what is traditionally considered 2FA isn't actually 2FA if you follow the default Google flow. We're certainly not making any claims that "we are the world's most secure company"; we are just making the claim that "what appears to be MFA isn't always MFA".

(I may have to delete this comment in a bit...)

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

#90

Post by landemva »

hn_throwaway_99 wrote: post #60

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…

Transactions (messages) can be required to have multi-sig, if that is desired.

There are smartphone apps and various tools to send a multi-sig message:

https://pypi.org/project/pybtctools

Post reply on HN