18 Sep Bypassing 2FA is possible
Every day we hear that a new breached occurred and millions of passwords have been stolen. For that reason, we hear recommendations from experts that we should enable two-factor-authentication (2FA). Of course, it helps, and you should enable it on every possible account, but in this post, I’ll show you that even two factor authentication can be bypassed if we don’t pay attention where we enter our information.
Before showing how to execute this attack, I want to explain a little bit how it works. Basically, to gain access to 2FA-enabled accounts we shouldn’t get just the credentials. In case we did it, we wouldn’t be able to log-in using just that. Instead, we should get the session cookie. For those who don’t know, a cookie is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with the next request to the same server. Typically, it’s used to tell if two requests came from the same browser — keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies). If we were able to get it, we could import the cookie into our browser and get access to the account.
There are many tools out there that we could use, but in this occasion I’ve chosen Evilginx -v2.3 at the moment of writing this article- (https://breakdev.org/evilginx-2-3-phishermans-dream/). According to the author, Evilginx is a “Standalone man-in-the-middle attack framework used for phishing login credentials along with session cookies, allowing for the bypass of 2-factor authentication” (https://github.com/kgretzky/evilginx2). The way Evilginx works can be seen in the following diagram where our server acts as the man-in-the-middle.
Now let’s go with the attack itself. If you want to try it, it won’t take you more than an hour the get everything up and running and start using it. This work is merely a demonstration of what adept attackers can do. It’s your responsibility to use it just for educational purposes or with the client authorisation.
What would you need to start? First, you would need a domain. You can buy very cheap ones. In my case I bought not-linkedin.info for around 4 USD. Secondly, you would need a server to host Evilginx. Personally, I used the cheapest Digital Ocean Ubuntu droplet that it’s about 5USD/month. And finally, I’ve set up my DNS servers with Cloudflare using the free version. In a couple of clicks you are all set up. It’s never been that easy.
Once it’s all ready, we start the tool and configure it with the domain and server information. As you can see LinkedIn is not the only available option. In addition, you can create your customs phishlets and adapt every page that you want to phish.
config domain <domain>
config domain not-linkedin.info
config ip <ip>
config ip 188.8.131.52
phishlets hostname <phishlet> <domain>
phishlets hostname linkedin not-linkedin.info
phishlets enable <phishlet>
phishlets enable linkedin
To run a campaign, we should create a lure. For that we run the following command. We can also configure a redirect URL, but that step is not mandatory.
lures cerate <phishlet>
lures create linkedin
Once the lure is created, we get the phish URL. That URL is the one that we should send to the victim.
The victim would see the following page. As you can observe, the site it’s with HTTPS and the look and feel it’s exactly as the original site.
If the victim enters credentials, in our console we will see:
At that time, our man-in-the-middle server would redirect the login action to LinkedIn Server and LinkedIn is going to trigger the 2FA challenge. Once that happens, the victim will receive the text message with the one-time-code.
The victim enters that code. Note that the victim is still in our fake domain.
Once that happen, we redirect the code to LinkedIn Server, who after validating it, it creates a session that we intercept. After that the victim is redirected, in this case to google.com. It can be redirected where you want or not redirected at all.
To see all captured credentials, we just run the command sessions <id>. We can observe username, password, and session cookie. We copy that cookie and import it into Chrome using EditThisCookie extension.
We refresh the page and BINGO, we bypassed 2FA.
We just demonstrated that even 2FA is bypassable. Anyway, you should still enable it everywhere possible as it solves a lot of vulnerabilities just as weak or reusable passwords and makes account takeover more difficult. However, this post tries to show that the most important fix against phishing is not 2FA or any other technical solution. It’s user awareness what prevents phishing. Just be careful where you enter your information.
For more information please go to the author site and tool documentation.