How do Pentesters approach attacking 2FA (two factor authentication)?

Question

I'm looking for practical ways to attack 2FA. What do you need to consider and how would you go about testing the effectiveness of 2FA? My only thoughts are that you would attack the implementation itself.

Answer 1

Your goal as a pentester is to identify previously unknown or unrecognized threats.

Be extremely clear that anything you do here must be explicitly authorized by your client. Failing to do so can get you in serious trouble. If you are wondering about details on that ask in the Law Stack Exchange.

Attacking two factor can be easy if it is misconfigured. In many cases there are reset or bypass mechanisms that fall back to email. If it is properly configured it becomes impractical to attack directly and you need to look at avenues of capturing tokens or compromising an authenticated application directly.

If the second factor is a hardware token, you will need to MitM the application that is consuming the token. If the application is HTTP or another unencrypted transport this can be achieved with network capture (not really MitM but you need a MitM position to do the capture). If the application is using TLS with an invalid cert you can achieve this via DNS poisoning (waiting for DNS requests for the target domain and sending several DNS replies with large TTLs directing the user to your MitM with its own self-signed cert. If the application is using HTTPS with valid certificates you could compromise an endpoint via other techniques and capture token entry on the user agent directly. It may be worth compromising an application that consumes the token. If they are using a TOTP token system you can compromise the weakest of the services using the same token serial and then reuse the token within the expiry window. If they are using a managed one time token system like Safenet Cryptocard this will not work since the token is consumed on use regardless of timeout. The trick there would be to capture the token on the first attempt, substitute a fake value to the real authenticator, and side-channel a separate session to authenticate. That way the user will think they've mistyped and just re-attempt. While you are in that position you may be able to directly hijack the session cookies or other tokens directly if complementary defenses like device/IP locked sessions or anti-CSRF are not employed.

If the second factor is already done over email then your attack vector is network capture of inbound SMTP at the MX. This may not be practical if the customer is using a secure outsourced provider. It should be relatively easy if they run their own mail servers.

If the second factor is done over SMS it may be possible to shoulder-surf tokens of you are physically present since many phones are autonaticLly configured to show texts even when locked. There are more sophisticated attacks involving compromising phones that can be used otherwise.

Social engineering is the ultimate hack here though. If you can somehow get a user to call you for help by posing as IT Support or otherwise they may just tell you the token directly as you "help" them fix their issue.

Answer 2

Reminds me of this recent article.

_{(Mouse over for spoiler)}

A phishing attack got him using a domain name similar to Google's with a valid cert.

Other methods could be:

• Predictable OTP tokens.
• MITM where no encryption or authentication is present to protect the the data in transit, so the OTP can be intercepted and used by the attacker.
• Weak encryption or authentication that also allows the above.
• Logic flaws in implementation - e.g. allowing a OTP from another user account, allowing reuse of OTPs, etc.
• Weaknesses in trusted device tokens (predictability, leakage, etc). This is where say a cookie is dropped on the device used to authenticate in order to mark it as a trusted device that does not need the second factor in future.
• XSS allowing the token to be retrieved.
• CSRF allowing two factor authentication to be disabled.
• 2FA reset (e.g. lost device) using a mechanism much less secure (e.g. a physical attack where the email account is left logged into and disabling 2FA just involves clicking a link).

Answer 3

2FA is much more secure an hence harder to break. However I remember hearing about a method in the past for services using SMS verification as the 2nd factor. If you had got the password, and also the phone number, you could try a SE attack on the mobile provider and try to get the agent to do message redirects to your number. Hence all SMS verification codes would go to the attacker.