CERT Polska has observed an interesting phishing technique used in attack against users of a popular Polish content aggregator. We have also noticed the emergence of a new tool called “Modlishka” whose purpose is to simplify and automate phishing attacks. In this article, we describe the way these highly-automated attacks work and present our recommendations for creators of websites for defending about them.

 

Attack mechanism

The observed attack works by directing users to a fake domain, which often looks very similar to the real service. Unlike the phishing techniques previously observed, however, the fake server does not send the spoofed version of the page to the user but only mediates communication with the real service.

The user connects to fake-google.pl which then sends requests further to the real service at google.pl, simultaneously capturing all information (logins, passwords, 2FA codes, payment card details).

 

What makes the attack even more convincing is that such phishing service will look and behave in exactly the same way as the original internet service which it impersonates. It means that the victim is able to use the service in undisturbed way while allowing the attacker to capture (and possibly alter) all activity.

The fake service may have a valid Domain-Validation SSL certificate. Thus, the browser will display a characteristic padlock icon. It is worth remembering that a basic SSL certificate (without an organization name shown next to the icon) only assures us that we are connecting to a server which belongs to the rightful owner of the domain. The attacker has no problem obtaining a certificate because he is, after all, the actual owner of his phishing domain (e.g. fake-google.com). It is mentioning that such basic certificate can be obtained free of charge using LetsEncrypt or CloudFlare.

 

Implementation

Tools adopting the aforementioned technique are publicly available on GitHub under drk1wi/Modlishka and kgretzky/evilginx2. These projects are a practical implementation of the MitM proxy attack and are capable of capturing user credentials and session cookies. Moreover, by using these tools it is possible to strip all security-related headers such as Cross-Origin Resource Sharing or Content Security Policy. A different functionality allows injection of additional JavaScript code into original page content.

Even though these tools are said to be used only in carrying out controlled penetration tests, one should be aware that they can also be utilised to perform illegal phishing attacks.

 

Web Page Protection

As of today, we recommend four methods of protecting users from those kind of attacks. Each solution differs in the degree of complexity and the required amount of manual action from administrator.

 

Introduction of U2F two factor authentication

First solution consists of implementation of the Web Authentication API and allow users protect their accounts with U2F hardware tokens. Authentication with such a token is carried out at the level of the web browser and not within the application.

Sequence diagram of the U2F authentication. In this particular case, “relying party” is a web page, “client” is a user and “U2F Device” is a hardware USB token owned by the user. Elements marked in green depict phishing protection mechanism. Source: https://developers.yubico.com/U2F/Protocol_details/Overview.html

 

During the process, the web browser will attach information about requestor’s origin to each authentication request before forwarding it to the U2F device. Therefore, the phishing technique can be detected due to mismatch of the digital signature generated in the last step. As a result of that, a forwarded authentication attempt may be blocked or the website may go one step further and block the user’s account and flag it as possibly compromised.

 

Modification of e-mail 2FA scheme

Unfortunately, most common methods of two factor authentication are still vulnerable to the described attack. Because the attacker is essentially proxying all communication between the user and the actual web site, any code-based methods (e.g. “rewrite the code from your token”) can not protect users in this case. However, a small modification of existing authentication schemes could protect against such attacks. For instance, when using an e-mail based 2FA, you may ask user to click on a link instead providing a numerical code.

 

Exemplary e-mail message containing the authentication link

In order to additionally protect users, the web application should check if the proper session cookie already exists in order to verify if the authentication was initiated in the same browser. However, using such a method may cause problem to some users which do use a browser in an incognito mode or use a mail client with a different default browser than was used to initiate authentication. Thus, it’s worth to add a hint about manually copying an authentication link to the browser in case of troubles.

This methods, however, falls short for SMS authentication. This is due to the fact that the user would be forced to rewrite the URL manually to his browser or enable cellular network for each authentication. A similiar problem appears for Authenticator(ten od googla, tak?), it would have to be modified in a way to automatically send the code through HTTPS connection, instead of forcing the user to re-write it.

 

Detecting MITM with JavaScript

Finally, the attack could be mitigated using additional script which would check the hostname stored in window.location.host and inform the web page admin about the occurrence of MITM attack. It should be kept in mind that the phishing proxy operator (the attacker) might counter this technique by removing the script using regular expressions.

 

The exemplary script checks if the web page was loaded in a proper domain. If not, it will create an invisible image and cause a request to be sent to an original web page. Moreover, owner of the proper web page will learn about the phishing domain through ?domain= parameter. Redundant string concatenation is used to confuse the domain replacement procedure performed in proxies, as they automatically search for the original domain substrings and try to replace them.

 

Such technique may be developed by a web page author in the “arms race” style. One might add the abovementioned code to the one of scripts which is already used on the web page. The best effect could be achieved by chosing a script is required for the web page to work but is not a library. Moreover, obfuscation of the whole .js file may be employed. For example, by using common obfuscator like obfuscator.io or some custom piece of software. The attacker will still be able to bypass such protection but a lot more effor will have to be put in than just setting up the proxy using one shell command.

In CERT-Polska/anti-modlishka GitHub repository, we present a proof-of-concept for a more advanced mitigation. It uses obfuscated JavaScript in order to detect and block proxies such as Modlishka or Evilginx. Alas, such protection measures are bypassable by design with enough effort from the attacker side. However, implementing a similiar (not identical) mechanism in business-critical web applications is still considerable.

 

Using a “trap subpage” to block existing proxies

In case the site administrator already knows the domain of a phishing MITM proxy, he may take appropriate actions in order to block it, for instance by leading it into a “trap”.

Such technique is carried out by creating a new subpage (e.g. under the address /trap/<random_characters>). Upon visiting this page all visiting clients should be banned by blacklisting their ips. The site administrator should then navigate to the “trap” subpage in a phishing domain. This will force the attacker’s proxy server to connect the original site and thus get banned, rendering the phishing domain useless. Such subpage can not be visible to a normal user, its address should be unpredictable and changed from time to time.

Using TOR or VPN for navigating the attacker’s domain is advised, this way the admins IP address is not disclosed to the attacker. In case of large scale attacks, this technique may be automated when combined with the previously mentioned JavaScript phishing detectors.

 

Summary

In the article, we have presented the man-in-the-middle proxy based phishing technique. As of today, we see this technique being used against Polish bank organizations, who more often call it “webfake” or “redirect”. These entities often employ advanced antifraud systems, so most of them are able to detect such attacks at this moment. We don’t observe such techniques being employed on a large scale in other sectors. It’s however quite likely that such threats will appear in the future. Considering that, we recommend conducting relevant risk analyses and considering implementation of relevant prevention mechanisms.