The fault here lies with victims answering a prompt to enter their 2FA out of the blue. Just as with passwords and other such info, the bank will never request it for no reason.
A hardware token using webauthn protocol is most secure though, yes.
> Mitch said his financial institution has in the past verified his identity over the phone by sending him a one-time code to the cell phone number on file for his account, and then asking him to read back that code.
The advice from Krebs about phone calls is never talk to "the bank" (etc) when they call you, always you have to call them back. But the bank _will_ really sometimes contact you "out of the blue" to ask you about potential fraud on your account. You just have to hang up and call them back, you can't tell the difference based on "reasons".
It is very hard for the end-user to tell what 2FA request is "for no reason". I think we need to focus not on what the "reason" is or if it's "out of the blue", but, the equivalent of "call them back" for online too -- don't click on a link in an email, etc.
No matter what, it's not easy, especially for less technical users. The linked account is a security professional that fell for it -- I personally don't have the hubris to think I never would.
There have been times when an actual bank asks me to do something I know is insecure, and I consider resisting it, but I just didn't have the energy for it, I figured it really was the real bank just being idiotic and I wanted to get on with my day (and guess what, it was, I was right).
[1]: https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo...
You need to start from a reasonable root of trust like your local government. Go down to city hall and ask them to pull the business license for the organization, and visit the address on file there and work your way down through the organization to the department you’re trying to contact.
How?
Then the attacker can intercept any outgoing call.
> OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”)
What are you saying is the distinction that an ordinary user should be expected to distinguish, between a phone call that says it's from your bank alerting you to fraud and asking you to read back a 2FA code, and... a different kind of phone call that says it's from your bank alerting you to fraud and asking you to enter an OTP code in a different way?
It's a pretty similar thing. In these particular cases, you and I could realize that a bot asking you to use keypad to enter the code is more suspicious than a human asking you to read it. But it's not like humans can't scam you too, as in the other story I linked to from krebs. And it's all a bit subtle and overwhelming for the average user (who of course encounter bot voice systems all the time when dealing with 'legitimate' businesses these days).
For most hacks, the answer is, more or less, "Nothing." For a social engineering hack like this, you can be aware and avoid falling victim to this.
For me, reading this article, that's the meat of it -- I am trying to figure out how vulnerable I specifically am to this, and what I need to do to stay safe (and what I need to recommend to my family and friends). Sometimes it's "hope the organizations that have your data are secure", but this time it's the same advice I usually give, "Don't ever tell anyone anything, and NEVER give out passwords to anyone."
OK, but if the legit banks are actually *asking you to read back 2FA codes on the phone"... I assume you include a 2FA code as a "password" since that's what we're talking about... you'd just refuse to talk to them when they call you about potential fraud? Find a new bank that doesn't do that?
Krebs advice to "never give out personal info or 2FA codes when they call you, always call them back at the number on your card" seems like a more useful/actionable appraoch to me than your "never give them personal info or 2FA codes at all".
So, anyway, yeah, krebs advice is "actionable", but... it's not easy. To remember, or to do when you're busy and trying to get on with your day dealing with banks and other bureacracies that routinely "legitimately" ask you to do crazy things.
You find independent corroboration of what they're telling you. If the only evidence you can find in your account that something went wrong is what someone is telling you over the phone, it's almost certainly itself an attempt at fraud.
If you can't, reveal nothing and reach out to them separately (call the bank back) to find out more.
I think we'll both be in pretty good shape!
Note in the linked krebs story the person thought they were doing that "corroboration"....
> But Mitch knew enough of scams to understand that fraudsters can and often do spoof phone numbers. So while still on the phone with the caller, he quickly logged into his account and saw that there were indeed multiple unauthorized transactions going back several weeks.
https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo...
He "independently corroborated", they were calling him about fraud, and there WAS fraud! The whole thing is the story of a guy who is actually a security professional and thought he was being smart, and got tricked, and is now really embaressed.
I am sure you will reply that you are smarter than him and will never be tricked, you will do the correct corroboration, not corroborate the wrong thing. Everyone who ever gets tricked also thinks that, but you are probably more correct than they.
But that's why I think it's better to make the "rules" as simple as possible, not be like, oh, sure, I'm going to embark on some spur-of-the-moment "independent corroboration" investigations... you start playing games, they're probably better at the games than you. (I mean, not you, I know you are better than anyone else, but the other people who may be reading this and may be mere mortals, like me). And still you (I mean "one", not you of course, I'm speaking of typical people) might get tricked, because the system is not set up in such a way that it's easy to avoid universally.
Don't forget that you have to call them back by looking up your bank's phone number yourself from a trusted source (perhaps their HTTPS website). Obviously just calling back the number they called you from (or provided to you) is useless.
It should say "Call us back at the number on the back of your card", or some such.
I'm sure they're afraid that a lot of users won't figure that out, but it still seems like a weird tradeoff.
I just checked my own debit and credit cards. 27 (twenty-seven) of them have a phone number printed on the card itself, only one doesn't - that's SoFi Money debit card, it says "for assistance please visit the SoFi app or SoFi.com." it's also just one extra step to phone support - I opened the app and clicked "help" and there was "Call Money support" as the first option.
The script went something along the lines of:
"Hi, we need to authenticate a recent transaction of $high_value_item, well send you a verification code to prove we are $company_x." <receipt of OTP code via SMS from $company_x> "Can you repeat the verification code to authenticate?" "Of course this isn't a scam, we must be $company_x, how else could I send you the verification code?"
I can definitely see general members of the public falling for this sort of scam - because they are being led to believe it's not a one-time-password that they're relaying at all, and some organisations do use verification codes of that sort, although usually it's to verify ownership of a particular mobile telephone number when setting up an account or pairing an app or similar.
I wouldn't expect non-technically savvy folk to immediately spot the difference between a verification code and a one-time-password.
It might be good if the OTP SMS message had text along the lines of "Do not give this code to anyone under any circumstances, regardless of who they claim to be employed by." - not that I would expect it to help in all cases.
(tbh - I was actually quite impressed, the English skills of the person on the other end of the telephone were significantly better than the average tech support call center person).
However, each PIN entry is accompanied by "code check": bank's support person says their 4 digit code, and you can verify that it matches on request for PIN screen. This neatly prevents someone pretending to be a bank during a call, because each PIN request uses a different "code check".
Attacker wants Victim's code. Attacker calls the Bank impersonating Victim, and also calls Victim impersonating the Bank. Bank tells Attacker the code check, Attacker tells Victim the code check, Victim sees the match and enters their PIN into the Smart-ID app, and Attacker's phone session with Bank is now fully authenticated and has no more need for Victim.
WebAuthn is really what is good enough. Luckily it's well supported on all important platforms so there's really no excuse using anything worse.
Phishing is enormously more common than sim-swapping because, as described in TFA, it can be fully automated. Going from SMS to TOTP fixes a rare attack but does not fix a common attack.
In one of the linked articles the scammers pretended to send a one-time token and asked the victim to read it back. This is the same process my top-10 US-based bank uses, so it wouldn’t necessarily raise any red flags.
For example a phishing site could trick me into authenticating into a fake site, and give them a session at the real site as a result. They won't have my actual credentials but they could have a session which is enough to do a lot of damage.
I don't think Webauthn guarantees that the site I'm authenticating to is the site I'm supposed to (though I may be wrong here, I didn't read into it too deeply). As far as I know it still relies on TLS for that, and regular phishing and typosquatting show that this is not airtight. It would be great if the authentication worked both ways, the server would authenticate to the client as well as it does to the server.
It does raise a few other questions too. If every site uses Webauthn, I will have to update every site when I get a new yubikey. That's going to be a PITA.
A solution for that would be using an identity service.. Like "Sign in with Google". But I would never trust a commercial service like Google, Facebook, Microsoft for this. It would have to be something open and privacy-safe.
The fake site needs to be hosted somewhere, presumably not on the same origin as the real site. As such, your key will be unable to sign a message for the phishing site regardless of how hard you try.
This is the core difference with SMS/TOTP. With those models nothing stops you from handing the material over to a site on a different origin and letting them reflect that material to the target site. With webauthn, the thing you hand the phishing site is useless for authenticating on the target site.
WebAuthn needs the DNS name of the site to exactly match. This isn't for humans, who think 1 and I are pretty similar, it's for a machine, which thinks they're different. Phishing and typosquatting don't get you google.example they get your google.comsecurityupdatelogin.example or goggle.example which do not match. Now, in principle you could attack the Ten Blessed Methods to get yourself a real, legitimate (albeit fraudulently obtained) certificate for the exact DNS name of a real popular site, but that's not easy, and indeed making it more difficult is a continuing focus of Web PKI work. Also, defenders can make it arbitrarily harder if they put work in.
I never tired of explaining the clever trick that makes this possible, so here goes (for the easy case of a cheap Security Key, something like an iPhone can do fancier tricks with more complicated explanations)
When you enroll at some.example, your Security Key is told we're enrolling at SHA256("some.example"). A button flashes and you push it. The Security Key picks a completely random public/private key pair. It uses the private key to sign a document, "Hello, I am this Security Key, I checked a human was present" and it encrypts the private key with its own symmetric key and with that SHA256("some.example") parameter as "Extra data" in an AEAD (Authenticated Encryption, Extra Data) cipher to produce a large opaque blob it will claim is a "random identifier". It sends the public key, the "random identifier" and the signed message back to your web browser. You are enrolled.
When you come back to the site, the site says oh, your account requires a Security Key, prove you still have it. It sends one or more of those "random identifiers" corresponding to enrolled Security Keys. Your browser talks to any Security Keys plugged in, hey, I'm at SHA256("some.example") and it asked if anybody can prove I'm still some-huge-identifier ?
Your Security Key tries to decrypt some-huge-identifier using its symmetric key, and the Extra Data SHA256("some.example"). Maybe it gets a success and a private key. The little button flashes and you push it. In this case it can sign a message using the private key, "Yes, I'm still me, I checked a human was present"
But, if anything goes wrong, that decryption will fail. If this is some-other.example, SHA256("some-other.example") won't match and decryption fails. If the site picks random gibberish instead of your identifier, decryption fails. If you plugged in the wrong Security Key, decryption fails.
You are unable to even try to authenticate to the wrong site. And if they enroll you which they can do, now they've got useless credentials for you to sign into their site that are unrelated to the credentials on other sites. They're even deliberately not correlated and they aren't even wasting space on your Security Key, the Security Key (this is why the trick was so clever) doesn't store anything to make all this work! All the storage is in the Relying Parties, and it's all storage of public data that's harmless when inevitably crooks steal it.
I really appreciate the breakdown of how it works! I agree this makes phishing almost impossible (at least without obtaining a valid cert which is in itself really hard for a non state actor)
I recently got a mail from an insurance company that they were upgrading the login method (red flag). The domain in the link contained wasn't the main domain but a separate customer service domain (red flag 2).
And the main login didn't work as expected before clicking the link in the mail (at least that redirected to the main domain).
It really can't get much worse.
Put differently: if you assume the user to be infallible, there's very little reason to use 2FA of any kind. (Don't believe me? Describe to me a threat which applies to an infallible password-only user which is mitigated by non-FIDO2 second factors.)
It also isn't defeated by 2FA, since they've physically installed something on your machine to detect your keypresses. They just capture your password and the sms code.
- They can install a wifi-enabled* keylogger that exfiltrates your OTP. Yes, they have to use the OTP before you do, but that seems solvable to me--just program the keylogger to transpose one of the six characters that comes after your (now known) password.
- They exploit any number of likely plug-and-play vulnerabilities in common OSes (e.g. https://www.thetechherald.com/tech-news/disable-plug-n-play-...).
- They steal your computer. Are you using FDE? If not, your cookies are sitting there on disk waiting for them.
- They...steal your phone next time you forget it at your desk. ;)
Are there scenarios where TOTP can protect against a non-phishing attack? Yeah, I can construct one if I really have to. (I think you're thinking too locally; my top argument for TOTP would be that I can rarely be sure the identity provider has implemented reasonable quotas against password brute-forcing--and who knows how well they secure things like server logs against rogue insiders?)
But if you tell me you use TOTP because you're afraid of a local attacker plugging in a keylogger--and not because of phishing--I think your priorities are out of whack. :)
* Or they use a covert channel, but I'm not serious about this part: https://dl.acm.org/doi/10.5555/1267336.1267341
deployment of a keylogger means your host is compromised, from there you can do so much you really don't need someone's password...
2FA is for plain phishing attacks. building phishing attacks against 2FA is significantly harder and usually easier to detect\protect from.
> The fault here lies with victims answering a prompt
> to enter their 2FA out of the blue.
If one is using a dozen services that auth with 2Fa and needs to log in once per day, that's a lot of windows of opportunity. Multiply that by 86,400 numbers phished that day.
Now, granny may not be down with the latest Tik Tok trends, but she has seen keys before, and the analogy is strong - so I think she can get this right.
To be fair, scammers have been successful with scams that involve an actual bike courier (presumably the scammer or a friend) coming to pick up your bank card, but that at least feels a bit reasonable because it does say the card remains property of the bank, so, sure, have your card back. And I'm also guessing this is a much higher friction scam than the average "Phone support in India" setup. I reckon scam dozens of people for their card this way and somewhere around the 100 victims mark the guy opening the door to your courier has a baseball bat, or worse, and your courier has a bad day.
At present, you are right. In the future, this may not be true, especially the "will stop nearly all attempts" part of what you are saying because the weakness in any security strategy is people.