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

131–140 of 287 posts

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

#131

Post by skeaker »

V__ wrote: post #37
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.

One possibility would be to just call the employee and record their voice. One could pretend to be a headhunter.

This would almost certainly be it. Calling someone to record them and using their voice later to impersonate them was done even before deep-fake voices were a concept. With the tools available now, even a short call + the grainy connection of a phone voice line would be more than enough to make a simulated voice work.

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

#132

Post by dmazzoni »

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.

Employees are only human. Even smart, savvy, well-trained employees can be fooled by good social engineering every once in a while.

The key to good security is layering. Attackers should need to break through multiple layers in order to get access to critical systems.

Compromising one employee's account should have granted them only limited access. The fact that this attack enabled them to get access to all of that employee's MFA tokens sounds like indeed the right thing to focus on.

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

#133

Post by macNchz »

tyingq wrote: post #123
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. Bu…

Definitely, sometimes they'll have a case number or agent id you can use to get back to them, but there are cases where you have to assume if it's important to them they'll continue to nag or reach out on another channel.

I have had at least one situation where I spent a while trying to get back to a quite convincing/legitimate sounding caller this way, where, as I escalated through support people it became increasingly clear that the initial call had been a high quality scam, and not in fact a real person from the bank.

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

#134

Post by alsodumb »

dvdhsu wrote: post #89
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 interes…

Thanks for the reply! What's expecting one.

Since you might have you delete the reply anyway, can I get a candid answer on why hardware 2FA tokens weren't a part of the default workflow before the incident? Was it concerns about the cost, the recovery modes, or was it just the trust in the existing approach?

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

#135

Post by hnburnsy »

dvdhsu wrote: post #89
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 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.

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

#136

Post by munk-a »

tyingq wrote: post #123
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. Bu…

My mother recently started having to deal directly with utility bills and the like and this was some information we impressed very early on. You should never agree to billing or hand over CC/account information in a phone call you didn't initiate. She hasn't run into an issue yet - most utilities, online stores and other entities have call in numbers if you need to resolve a billing dispute. That random company you bought a plumbing valve from has an office somewhere with a secretary that gets a phone call maybe three times a month from customers looking to resolve issues - and Amazon has mostly centralized support for small sellers and has lines you can call to resolve any disputes you have which may forward you to the original sale party but often just resolve the issue directly.

Honestly, the worst experiences are usually with large companies that funnel all customers into massive phone centers - I've probably lost the better part of a week to Comcast over my lifetime.

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

#137

Post by darkerside »

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…

This comment reads more poorly to me than the actual blog post. It _should_ be your intention to shift partial blame to Google, and you should own it. It's ridiculous that they make an operation like syncing your MFA keys seem so innocuous. I just changed phones, so I'm just seeing this user flow for the first time, and it is ghastly how they've made it the default path.

Changing things to make it less offensive to someone who was offended really waters down your position.

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

#138

Post by skeaker »

xorcist wrote: post #56

Stopped reading at "deepfake". It's the new advanced persistent threat, a perfect phrase to divert any resposibility. (Yes, there are deepfakes. Yes, there are APTs. This is likely neither.)

I am (genuinely, really asking) curious why you think so. I've got no hand in this, but the skepticism around phishing attacks from this site of all places really surprises me. People like Kevin Mitnick have done more sophisticated phishing with fewer tools. Why wouldn't someone intent on running a social engineering scam use one of the widely available voice faking technologies that are available now? Keep in mind that they're simple enough to use that people are making memes with voices generated from ~5 seconds of voice recordings.

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

#139

Post by tomatocracy »

bawolff wrote: post #64
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. 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.
Post reply on HN