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

111–120 of 287 posts

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

#111

Post by hn_throwaway_99 »

devjab wrote: post #105
hn_throwaway_99 wrote: post #38

Earlier quoted context omitted.

> Very sophisticated attack, I would bet most people would fall for this. No. If you think people at your company would fall for this, then IMO you have bad security training. The simple mantra of "Hang up, lookup, call back" ( https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo... ) would have prevented this. Literally like 99% of social engineering attacks would be prevented this way. Seriously, make a lit…

I’ve done 6 different versions of “security training” as well as “GDPR training” over the past few years. I think they are mostly tools to drain company money and wasting time. About the only thing I remember from any of it is when I got some GDPR answer wrong because I didn’t resize your shoe size was personal information and it made me laugh that I had failed the whatever quiz right after I had been GDPR certified…

To emphasize, I 100% agree with you. I'm not arguing for more security training, I'm arguing for less.

"Hang up, look up, call back". That's it. Get rid of pretty much all other "security training", which is just a box ticking exercise for most people anyway.

I also agree with the comment about better security tools, but that's why I think "hang up, look up, call back" is still important, because it teaches people to be fundamentally suspicious of inbound requests even in ways where security tools wouldn't apply.

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

#112

Post by fn-mote »

halfcat wrote: post #104
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 sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. What do you use to accomplish this?

After the sync, you have exactly two devices that you can use to answer the MFA challenge, instead of one. It's a backup.

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

#113

Post by thayne »

bawolff wrote: post #86
luma wrote: post #76

Earlier quoted context omitted.

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…

> attacker has hacked the server and added javascript

adding javascript doesn't necessarily mean the server is hacked. XSS attacks usually don't require actually compromising the server. Or a malicious browser plugin could inject javascript onto a site.

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

#114

Post by hinkley »

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…

Advice I haven't even followed myself:

It's probably a good idea to program your bank's fraud number into your phone. The odds that someone hacks your bank's Contact Us page are small but not zero.

The bedrock of both PGP and .ssh/known_hosts could be restated as, "get information before anyone knows you need it".

Fraud departments contacting me about potentially fraudulent charges is always going to make me upset. Jury is still out on whether it will always trigger a rant, but the prognosis is not good.

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

#115

Post by hinkley »

bawolff wrote: post #86
luma wrote: post #76

Earlier quoted context omitted.

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…

rogue javascript. It's naughty, not red.

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

#116

Post by dataflow »

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 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 someone to pick up, and hoping you're not reaching a number that'll make you go through fifteen transfers to get to the right agent. People have stuff to do, they don't want to wait around with one hand occupied waiting for a phone call to get picked up for fifteen minutes. When the alternative is just telling your information on the phone... it's only natural that people do it.

Of course it's horrible for security, I'm not saying anyone should just give information on the phone. But the reality is that people will do it anyway, because the cost of the alternative isn't necessarily negligible.

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

#117

Post by GauntletWizard »

hinkley wrote: post #114
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…

Advice I haven't even followed myself: It's probably a good idea to program your bank's fraud number into your phone. The odds that someone hacks your bank's Contact Us page are small but not zero. The bedrock of both PGP and .ssh/known_hosts could be restated as, "get information before anyone knows you need it". Fraud departments contacting me about potentially fraudulent charges is always going to make me upset. J…

At least once I have gotten a terribly phrased and link-strewn "Fraud Alert" from a bank, reported it to said bank's anti-phisihing e-mail address, gotten a personalized mail that responded that it was in fact fraud and that they had policies against using third party subdomains like... And then found out the day later that yes, that was their real new anti-fraud tool and template.

There will need to be jail time for the idiots writing the government standards on these fraud departments before we get jail time for the idiots running these fraud departments before it gets better.

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

#118

Post by hinkley »

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.

Blizzard was one of the first large customers of TOTP, and what we learned from that saga is that 1) keyloggers are a problem and 2) impersonating people for TOTP interactions is profitable even if you're only a gold farmer.

The vector was this: Blizzard let you disable the authenticator on your account by asking for 3 consecutive TOTP outputs from your device. That would let you delete the authenticator from your account.

The implementation was to spread a keylogger as a virus, and when it detected a Blizzard login, it would grab the key as you typed it, and make sure Blizzard got the wrong value when you hit submit. Blizzard would say try again, and the logger would collect the next two values, log into your account, remove the authenticator and change your password.

By the time you typed in the 4th attempt to log in, you'd already be locked out of your account, and by the time you called support, they would already have laundered your stuff.

This was targeting 10 million people for their imaginary money and a fraction of their imaginary goods. On the one hand that's a lot of effort for a small payoff. On the other, maybe the fact that it was so ridiculous insulated them from FBI intervention. If they were doing this to banks they'd have Feds on them like white on rice. But it definitely is a proof of concept for something much more nefarious.

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

#119

Post by timando »

bawolff wrote: post #86
luma wrote: post #76

Earlier quoted context omitted.

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…

> 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 can only hack the server that hosts your SPA, but not your API server, they can inject javascript to it, but can't do a lot beyond that

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

#120

Post by josho »

dataflow wrote: post #116
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 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…

Great point. But it could be easily solved with something like: “Call the number on the back of your credit card. Push *5 and when prompted enter your credit card number and you will be immediately connected back to my line”
Post reply on HN