This Phishing Attack is Almost Impossible to Detect but we Added a Fix

Last updated on March 23rd, 2018 at 06:23 am

The Homograph Phishing Attack is Back and It’s Impossible to Detect

News has come in of a Chinese info researcher who has reportedly re-discovered the vulnerability of web browsers to a certain phishing scam that can catch even the most careful users off the guard. The researcher has confirmed that the vulnerability is absolutely impossible to track in most versions of Firefox, Opera, and Chrome browsers. More gravely, it is also quite impossible to trace the trick on the mobile versions of these browsers.

Legitimate looking domains could be fake

The major gaffe caused by the homograph fishing attack is to fake absolutely bogus domain names and make them resemble the exact replicas of services like Apple, Google or Amazon. Most users will not be able to tell the reason why a legitimate domain displays an uncanny error message. In the process, they might end up furnishing sensitive credentials of login and financial accounts.

This could be particularly offensive if the attack is meant to steal sensitive data or asks users to reaffirm their login credentials before moving any further.

Look at these Sample Fake Website

You could say it is almost impossible to beat the website apple.com and yet not be at Apple’s website. However, this is exactly what the researcher has negated in this demo page here. You could experience a slight downtime too as many people are looking up the page right now (including some at Apple, hopefully).

The Fake Apple Website

Real Apple Website

The discoverer of the attack Xudong Pengm has written a detailed blog on the same. He says:

“For regular users, it is nearly impossible to say that the site is fraudulent (or at least unauthentic) without looking up the URL of the site or its SSL certificate very carefully.”

In case your browser field is displaying the words “apple.com” and is instead showing the error message instead of the original website, it is a sure case of your web browser being vulnerable to the mischievous homograph attack.

In another website sample research website, Wordfence has successfully mocked the domain name “epic.com” through the use of a complex system of nomenclature while buying the domain.

The attack is quite old in itself

The first accounts of homograph attack age back to 2001. However, most browsers have had a hard time trying to fix the attack by themselves. It is a totally spoof attack where researchers/hackers replace the words of the English alphabet with Unicode characters.

Irrespective of how careful you are of such attacks, it is almost impossible to detect the flaw.

Domains are bought using Unicode characters

There are many Unicode characters that represent letters of different languages including Cyrillic, Greek, Armenian in domains that are internationalized for more convenience. On casual glance, these letters look exactly identical to Latin letters. However, they are treated differently by some browsers, showing totally different names in the browser field.

Punycode Attacks

Many modern web browsers make use of “Punycode.” It is a special type of encoding by web browsers that helps to convert Unicode characters to the limited character sets that represent ASCII. This is the accepted set of variations supported by the International Domain Names or IDNs mechanism.

Zheng states that in case someone chooses all the characters from the same foreign language while registering the domain, the loophole of browsers will convert it to the targeted domain name instead of rendering the Punycode format.

xn--80ak6aa92e.com is Equals to Apple.com when converted by browsers

Using the same loophole in the browsers, Zheng registered a domain as xn--80ak6aa92e.com. In most browsers, it swiftly bypasses the protection and appears as apple.com. This includes Chrome, Firefox, and Opera. However, quite interestingly, Internet Explorer, Apple Safari, Vivaldi, Microsoft Edge, and Brave have not shown vulnerability to this kind of attack.

It is noteworthy that the xn-- prefix refers ASCII compatibility coding prefix. This tells web browsers that there is Punycode encoding in the domain.

Instead of the ASCII “a” which is (U+0041), Zheng uses the Cyrillic “a” (U+0430). In this case, this one simple replacement bypasses browser protection.

Zheng has been in touch with the associated browsers and has informed Google and Mozilla in the month of January.

They are Trying Fixes

At the moment, Mozilla is trying different methods to generate a fix. But Google has already been successful in patching this vulnerability in its experimental version of Chrome Canary (59). They have promised that a permanent fix will be rolled out with the Stable 58 version of Google Chrome. The Stable 58 is due for launch later this year.

In the meantime, there are millions of users who are (unknowingly) using Punycode in their browsers. It is highly recommended that they disable Punycode support in their browsers for a while to be able to defend this almost untraceable attack.

Warding off phishing attacks

To use temporary mitigation manually, Firefox users can use this simple method:

Hit about:config in the address field of the browser
Search with Punycode
Locate the title network.IDN_show_punycode and right click; use Toggle and change the setting to True from False. (See image below)

To the dismay of several users, there is no similar available setting that would work for Chrome or Opera and disable the Punycode manually. Chrome users have to be patient and wait for the Stable 58 version of chrome that comes out in a few weeks.

For the moment, there are some browser add-ons that can be used to alert non-techy users every time a domain name contains Unicode characters.

Use Good Password Managers

One good way to bypass such phishing attacks is to make use of a really good password manager. They will store all your login credentials and automatically identify the actual and authentic URLs to which they are linked.

So, the first sign of warning would be the password manager not prompting you to a stored password in the login field.