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

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 <i>receive</i> a phone call (or other message) and someone starts asking for information. It&#x27;s always okay to say, &quot;actually, let me get back to you in a minute&quot; and hang up, calling back on a known phone number from the employee directory, or communicate on different channel altogether.<p>Organizationally, everyone should be prepared for and encourage that kind of response as well, such that employees are never scared to say it because they&#x27;re worried about a snarky&#x2F;angry&#x2F;aggressive response.<p>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.

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.<p>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.

Very sophisticated attack, I would bet most people would fall for this.<p>I&#x27;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.<p>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 the request, and will not provide the correct code even it the page looks correct to a human.

<i>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</i><p>They should stop using OTPs. OTPs are obsolete. For the past decade, the industry has been migrating from OTPs to phishing-proof authenticators: U2F, then WebAuthn, and now Passkeys†. The entire motivation for these new 2FA schemes is that OTPs are susceptible to phishing, and it is practically impossible to prevent phishing attacks with real user populations, even (as Google discovered with internal studies) with ultra-technical user bases.<p>TOTP is dead. SMS is whatever &quot;past dead&quot; is. Whatever your system of record is for authentication (Okta, Google, what have you), it needs to require phishing-resistant authentication.<p>I&#x27;m not high-horsing this; until recently, it would have been complicated to do something other than TOTP with our service as well (though not internally). My only concern is the present tense in this post about OTPs, and the diagnosis of the problem this post reached. The problem here isn&#x27;t software custody of secrets. It&#x27;s authenticators that only authenticate one way, from the user to the service. That&#x27;s the problem hardware keys fixed, and you can fix that same problem in software.<p>† <i>(All three are closely related, and an investment you made in U2F in 2014 would still be paying off today.)</i>

&gt;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.<p>Wow that is quite sophisticated.

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<p>Retool needs to revise the basic security posture. There is no point in complicated technology if the warden just gives the key away.

Fantastic write-up. Major props for disclosing the details of the attack in a very accessible way.<p>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.

To deepfake the voice of an actual employee, they would need enough recorded content of that employee&#x27;s voice... and I would think someone doing admin things on their platform isn&#x27;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.

While the google cloud thing is a weird design, that seems like the wrong place to blame.<p>TOTP and SMS based 2FA are NOT designed to prevent phishing. If you care about phishing use yubikeys.

&gt; <i>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.</i><p>huh.. this raises way more questions than it answers; my first two are: - how did the voice of some random employee (in IT for that matter) get learned by outside the company (enough to be deepfaked (and i presume on the fly) for that matter)? Maybe we should record less conversations (looks at Teams, Discord, Zoom) - where there already leaks of &#x27;internal processes&#x27;?

MFA is a scam resulting from Google first, and then others wanting to get users&#x27; phone numbers associated with more data they collect on them. It provides no tangible security benefits, creates a lot of headache for IT department, creates big gaps in developer&#x27;s productivity (if used in a programming company) and, actually, creates a new attack vector (phones are lost or stolen a lot more often than any other means of authentication).<p>Since Github now requires MFA, I&#x27;m throwing away my account: I&#x27;ll never give them any physical evidence to connect me to other data they have on me.<p>In the company I work today (20-something thousands employees) the latest security breach was through MFA. Data was stolen. Perpetrators made jokes in company&#x27;s Slack etc.<p>Last time I had to upgrade my phone (while working for the same company), it took IT about two weeks to give me all the necessary access again, which required a lot of phone calls, video conferences, including my boss and my boss&#x27; boss.<p>It&#x27;s mind-boggling that this practice became the norm and is recommended by IT departments even of companies who have nothing to gain from collecting such data.

Unfortunately, MFA has become synonymous with SMS, email, and OTP. All of these methods require sharing a secret between two parties without any way to verify the authenticity of either party.<p>Key based authentication where both parties have private keys that are not shared is a much better alternative. Unfortunately, client side TLS certificates, which are application level protocol agnostic, never really caught on.

Why did they need to call? They could’ve phished the password and MFA by simply MITMing?<p>Perhaps we need a distinction from phishable MFA and unphishable U2F&#x2F;WebAuthn style

Question for security folks out there:<p>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.<p>Is anyone aware of systems that essentially require <i>multiple</i> logins from different users when accessing sensitive systems like internal admin tools? I&#x27;m thinking like the &quot;turn the two keys simultaneously to launch the missile&quot; systems. I&#x27;m thinking it would work like the following:<p>1. If a system detects a user is logging into a particularly sensitive area (e.g. a secrets store), and the user is from a new device, the user first needs to log in using their creds (including any appropriate MFA).<p>2. In addition, <i>another</i> user like an admin would need to log in simultaneously and approve this access from a new device. Otherwise, the access would be denied.<p>I&#x27;ve never seen a system like this in production, and I&#x27;m curious why it isn&#x27;t more prevalent when I think it should be the default for accessing highly sensitive apps in a corporate environment.

Some startup, please make a product that uses AI to identify these obviously fake emails.<p>Hello A, This is B. I was trying to reach out in regards to your [payroll system] being out of sync, which we need synced for Open Enrollment, but i wasn’t able to get ahold of you. Please let me know if you have a minute. Thanks<p>You can also just visit <a href="https:&#x2F;&#x2F;retool.okta.com.[oauthv2.app]&#x2F;authorize-client&#x2F;xxx" rel="nofollow noreferrer">https:&#x2F;&#x2F;retool.okta.com.[oauthv2.app]&#x2F;authorize-client&#x2F;xxx</a> and I can double check on my end if it went through. Thanks in advance and have a good night A.

does iOS have a &quot;is there a call in progress&quot; API?<p>If so, it would be a good idea for OTP apps to use it and display a prominent warning banner when opened during a call.

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..<p>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.

I was thinking about this the other night. Is there really a solution to this? Best case scenario lets say you have a hardware key and everything is sealed up really well. You get your phishing call but instead of asking for a MFA code they have a real time IA enhanced video call from your daughter or mom with a gun to her head and they just walk you through a set of steps that will expose your IT systems. Do you do as they demand with a loved one’s life at stake? Or maybe it’s a scam? What do you do? You have 5 seconds to decide. Me? I go John Wick on them but I’ve had more than 5 seconds so that doesn’t count.

This is the biggest reason why MFA codes shouldn&#x27;t be in the cloud. Use SMS-based MFA which is much more fool-proof though a pain in the ass. I have stopped using software based MFAs for this particular reason.

I don&#x27;t think it&#x27;s really accurate to describe it as not MFA. The attacker phished a password and 2 TOTP codes. So the attacker phished 3FA.<p>So yes, Google Authenticator sync made the security worse, but it didn&#x27;t downgrade the security from MFA to non-MFA. And even if the sync was off, the TOTP codes in Google Authenticator could have been phished as well, so Google Authenticator can&#x27;t be blamed so heavily, because the attack could have been done without it.<p>Disclosure: I work at Google but not on Google Authenticator.

TOTP: better than nothing, but not a lot better. It depends on the human being infallible. U2F doesn&#x27;t, and would have worked here to prevent the takeover and the need for blaming the employee for not being infallible, but hey, at least less than $50 of hardware costs was saved by the employer!

One thing that is left out it to use unphishable MFA like hardware security keys (Yubikey, etc).

The only takeaways you need from this:<p>- Your on-premise customers are the smart ones. Networks containing sensitive information should be isolated, not all pooled together.<p>- Google still has actually no understanding of practical security. Literally ban their products from your networks.

After reading all of the hype in the comments, I was disappointed by the actual article. There&#x27;s about one paragraph of actual material about the (&quot;spear&quot;) phishing attack.<p>There are not any details about the progress of the attackers or the speed of the attack, which would have been interesting to me. There are no details about any losses from the attack (or profits to the attacker).<p>Once the employee provided a TOTP code to the attacker, the only surprise is that they get control of the other codes by cloud sync (as extensively commented on here).<p>Regardless of the hate, this could happen to anyone. But... big L for reading out your TOTP code to somebody. (If more details about the deepfake come out, then it might be more exciting.)

1. install pass otp<p>2. pass otp add whatever&#x2F;otp&#x2F;me<p>3. paste in &quot;otpauth:&#x2F;&#x2F;totp&#x2F;whatever?secret=whateveritis<p>4. pass git init; push to remote<p>Now you you have MFA on any device that has git and your gpg key.

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

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

MFA still means single point of failure - the person who has all the MFA is the one who can be hacked, like in this social engineering scenario.

I just call them one-time passcodes (otp)<p>Most of the time I am not using multifactor or 2factor the way it was designed<p>But it is accurately a one time passcode

Where can one find a breakdown of how to build implement a TOTP generator? For curiosity&#x27;s sake

Stopped reading at &quot;deepfake&quot;.<p>It&#x27;s the new advanced persistent threat, a perfect phrase to divert any resposibility.<p>(Yes, there are deepfakes. Yes, there are APTs. This is likely neither.)

I wonder how long it&#x27;ll be before a similar attack happens before someone&#x27;s&#x2F;a companies passkeys are synced to the cloud.

Excellent write-up, thank you.

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