Attacker is now able to bypass 2FA – how to prevent

Date: 20 Dec 2019

Organisation : The Hong Kong Computer Society Cyber Security Specialist Group

Writer : Mr. Nelson YUEN, member of Executive Committee

2-Factor Authentication (2FA) has been rolled out in many organizations as their baseline security and is one of the items in top of mind in many CISO. World is changing fast; attackers keep pushing the line to compromise organization’s security infrastructure. Today, I would like to explain a little bit detail about how attacker can bypass 2FA in digital world.

Firstly, let’s talk about token-based authentication, which is widely used in public SaaS apps. Token-based authentication is stateless. Thus, applications will not store any information about users on the server or in a session. Every single request will require the token which should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests. Token-based authentication provides security and scalability benefits since tokens stored on client side are completely stateless, and ready to be scaled. Load balancers are able to pass a user along to any of their servers since there is no state or session information anywhere. The token, not a cookie, is sent on every request, and since there is no cookie being sent, this authentication approach helps to prevent Cross-Site Request Forgery attacks.

SaaS applications combine token-based authentication with 2FA to provide strong authentication. However, it is still vulnerable to well-crafted phishing attack.

Attacker can purchase a domain name which could be character omission or induce bit flipping of the target attack application’s domain.

And then attackers leverage Evilginx2, which is a man-in-the-middle attack framework used for phishing login credentials along with session cookies, and in turn allows bypassing 2FA protection.

A phished user receives an email and is asked to visit the logon page.
Phishing URL directs the user to a fake domain hosted on Evilginx Server, which is a proxy of the legitimate web application service logon page. The site contents of the fake site look the same as that of the legitimate web application service with domain name slightly different from that of the legitimate web application.
When the user enters the username and password, they will be passed to a website via the Evilginx Server.
The web application service triggers 2FA request to the user.
The user responses to the 2FA request.
Web application service verifies and authenticates the 2FA.
Web application service issues a token to the user via Evilginx Server.
Evilginx Server captures the token and attackers can use the token on another machine to access resources or services to which the user has granted access.

There are couple of ways organization could do to avoid this kind of attack.

Implement access broker for cloud app, such as adopting Identity and Access Management (IAM) solution on cloud with conditional access policy for company web /SaaS Web application. By deploying conditional access policy, IAM will check the status of a device requesting for access, i.e. whether it is a company managed device or an unknown device; or IAM will check the sign-in location of the device, i.e. whether the request for access is generated from office network or off-site.
Combine other factors on top of merely 2FA to form a Multiple Factor Authentication (MFA).
Implement adaptive MFA, which selects the right MFA based on dynamic intelligence such as unfamiliar sign-in location, Tor network, etc.
Deploy Fast IDentity Online (FIDO) Alliance’s Universal Second Factor Authentication (U2F). The U2F protocol is designed to take the website's domain as one of the key components in negotiating the handshake. If the domain in the browser's address bar does not match with the domain used in the data transmission between the website and the U2F device, the communication will simply fail.
Regularly conduct attack simulation for users as part of enterprise security awareness program.