9

Given

  1. Attacker is targeting a user of bank.com.
  2. bank.com uses SMS or Google Authenticator 2FA, where the user enters the 2FA code into a form.

Scenario

  1. Attacker registers domain name baank.com
  2. Attacker creates a web page that scrapes the login page of bank.com and presents it from the domain baank.com (or working as a MITM proxy to send user supplied details back to bank.com if needed).
  3. Attacker sends a phishing email to the user getting them to log in to baank.com instead of bank.com.
  4. User fills in their username, password, and 2FA (as per usual).
  5. Attacker now has the users credentials as well the 2FA that the user supplied.
  6. Attacker immediately (maybe through a script) logs in to the bank account since he has the username, pass, and 2FA.

Question

Am I missing something or does user-entered 2FA not help in this scenario?

Improve this question
3
21

2FA alone does not help in this scenario. If the 2FA input screen on bank.com does not have other protections, like TLS, pinning/HSTS, MITM protection, and/or verify the client or detect login anomalies, then there is a vulnerability.

This is a case where an integrated password manager in the browser can help the end-user, by not providing the credentials to begin with.

Other types of 2FA, besides user-entered codes, offer greater protection.

Improve this answer
12
  • quick question about password managers, off topic a little bit but connected to this 2FA question, how would they be able to know if the dns entry was altered in the hosts file? is there something the logs ip as well as dns entry and lets you know once it changes? – Coderxyz Oct 27 '20 at 19:20
  • 1
    checking against IP would not be practical since IPs can change or services can use a pool of IPs – schroeder♦ Oct 27 '20 at 19:21
  • 3
    U2F protects against phishing by mixing the hash of the root domain into encrypted answer. It uses public key encryption, which prevents the need to share the secret, unlike TOTP. Since Google switched their 100,000+ employees to U2F security keys many years ago, they haven't had a single successful phishing attack against them. And they're a big target. – Bengie Oct 28 '20 at 1:26
  • @Bengie that's why I've tried to be very clear about "user-entered" 2FA in the question. Other types of 2FA don't have the same problems. – schroeder♦ Oct 28 '20 at 9:37
  • 2
    @Coderxyz If the user has compromized your computer that completely to alter a protected hosts file, you are probably out of luck. No need to use 2FA at all or redirect the user, simply steal the auth once the user logs into their bank, or generate requests using the user's own browser with the auth. Besides compromising the host file though they would have to forge an SSL certificate to validate the domain if they don't have complete control of the browser or add their own root cert to the user's certificate store. But again there would be more transparent means at that level. – Jason Goemaat Oct 28 '20 at 12:07
14

Security keys like yubikey, titankey, nitrokey, and solokey use the U2F protocol, which is immune to phishing by mixing the domain into the nonce. In order for this to happen, the attacker would have to have control of the domain. And if you're talking about a browser, they are configured to also require the page to be a valid HTTPS connection. Meaning the attacker would also have to have control of the site's private certificate.

At this point the attacker already has control of everything.

I want to say it's something like this

response = secretkey_encrypt(HMAC(CHALLENGE, SHA256(base domain)))

Improve this answer
3
  • how does the U2F get the domain? I was under the impression they were basically a preprogrammed keyboard and could only send info and not receive it. – MikeSchem Oct 29 '20 at 0:01
  • 2
    The browser needs to incorporate the protocol. – schroeder♦ Oct 29 '20 at 12:49
  • Wouldn't be easier to use a client side certificate? – Margaret Bloom Oct 29 '20 at 20:47
5

It reduces the window in which an attack may be carried

Consider the case where the connection does not have 2FA, only user and password. The victim provided his bank credentials and doesn't even realize it was a phishing after the fact. The attacker can later use them to log in as the user and empty the account. Perhaps during the night, when the user is more likely not to notice. Or leverage that access through several days to overcome the daily transfer limit. Or three months later, when he completely forgot about that phishing, those credentials could have been sold to someone else that then uses it for money laundering.

As you rightly note, the use of 2FA does not prevent that as a result of a phishing, an attacker logged into the account at that same time. The previous scenarios are no longer feasible. The attack must be carried out at the time the user is entering their credentials. Even a minute later, the second factor will have expired. It does not completely prevent the attacker logging in (for that you would need a U2F/FIDO/WebAuthn device, also verifying the site you log into) but it does raise the effort required.

Plus, when using SMS, some sites actually describe the action that is going to be performed, so such description may serve as an additional layer of defense ("The page states it needs my code to give me a free gift, but the SMS says it will authorize a transfer of several thousand dollars?" 🤔).

On the other hand, some scenarios are solved by the use of a second factor, such as a shoulder-surfer discovering the credentials or the concern that the password could be bruteforced.

Improve this answer
4

Going into incorrect URLs would of course pose a risk even with 2FA. You correctly identified that. 2FA is aimed more towards leaked passwords for the correct URL. There will always be risks where human naivety is concerned, so providing people check the URLs, in most scenarios 2FA does help.

Improve this answer
0

Now what your are missing out is that when the victim input his/her login details using your phishing page the user will not receive any 2FA code unless you have a background listener that does the login on the real bank site using the details supplied by the victim so that the victim can supply the 2FA code received immediately and then the listener service uses the supplied 2FA to complete the login process.

this is one of the reason why it is recommended to upgrade from 2FA to authenticator app.

see the article below for more details about authentication.

SMS-based two-factor authentication is not safe — consider these alternative 2FA methods instead

Improve this answer
3
  • It doesn't matter if it is SMS or a TOPT app. The same process applies if it is user-supplied. TOTP just adds a 30 second timer. Yes, the phishing page would need to enter the creds on the legitimate page, but that is possible to code. As I mention, though, the login pages would need to be designed to look for anomalies to prevent this from happening. If they don't then this attack is trivial. – schroeder♦ Oct 27 '20 at 19:35
  • yea, I kinda envisioned using a proxy server really that would forward all user request to the web server as well, I added this to my question for clarity, thanks. – MikeSchem Oct 27 '20 at 19:35
  • @schroeder of course it might still works on other forms authentication thanks for your correction. – Oliverkahn Oct 27 '20 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.