Do you trust this URL: www.apple.com? It looks like a link to the Apple site, but it's not! Don't you see what's wrong with that link? Don't worry, you're not the only one, most people won't notice the difference, and here's what it's all about.
https://www.apple.com looks like a link to the Apple site, but it's actually another link that looks a lot like the original and leads to another site. The difference is in the letter "a", which is actually Unicode Cyrillic "a" (U + 0430), and not the standard ASCII "a" (U + 0061).
Fake apple.com domain / original apple.com domain |
IDN Homograph attack
The word "a" is just one such case, there are many examples. We from the Balkans know that because we also have Cyrillic, which is widely used on the Internet. Hackers register domains that are the same as the domains of known sites, but instead of ASCII letters, they insert a similar Unicode letter (as in this example Cyrillic "a"). We can't see the difference and that's why this type of phishing is called "IDN Homograph attack" - more.
However, luckily for us, web browser developers are installing protection that essentially displays the domain in "Punycode" format. This means that, in this example, the link "apple.com" will be displayed as "xn-pple-43d.com" (but will not load because it is not currently registered). Punycode, therefore, converts Unicode characters to ASCII by assigning them some of the available characters from that table. If you want you can try an online converter that does it - punycoder.com
Chrome has converted a Unicode domain to ASCII |
To protect yourself from these attacks, you can use the "IDN blocker" add-on for your web browser - Chrome, Firefox, Opera. Plugins of this type recognize Unicode characters in domains and block access to them. This is the only way, for now, to protect users from "Unicode domain" phishing attacks.
Cyrillic domains?
You may be wondering what about our Cyrillic domains? Well, they are made up entirely of Unicode characters! Here is one well-known Cyrillic domain that I will use as an example for this article - њњњ.срб
The first thing you will notice if you copy the link is that it will be converted to Punycode! So I couldn't copy and paste the link њњњ.срб into the article, because it converts immediately, I already had to manually compile the link word for word.
The good thing is that it doesn't convert to Punycode when you click on it (at least not visually, maybe something in the background happens before re-displaying the original - I haven't tested it), and also the converted domain works. Example: http://њњњ.срб will be converted to http://xn--g2aaa.xn--90a3ac/ when copying, and if you try to go to that Punycode domain, the web browser will convert it back to њњњ.срб and load.
Then where is the problem?
Web browsers, for now, only have protection in the form of converting Unicode characters to ASCII so that the user can see that the domain is not original.
The problem is that "Unicode domain" phishing protection is also blocked by valid domains, ie all our Cyrillic ones (among other things). These filters detect Unicode characters in domains and block them all because they simply do not know whether the domain was created for phishing purposes or not.
The plugin blocked the Cyrillic domain |
If we try to visit the domain I took as an example in this article - њњњ.срб - with protection enabled, it will be blocked!
The solution?
Of course, most of these plugins also offer a whitelist, so you can add the domain you want and it won't be blocked. But, that is certainly not the solution, because who will add every Cyrillic domain to the list? There may not be many of them, but what about the domains in other countries that are on their alphabet?
Even if a rule/law is introduced according to which all .срб (and other national) domains have the right to "pass" through these filters, hackers can certainly then register a fake .срб, or some other national, domain of a company (what, that the company opened its headquarters in Serbia and registered a domestic domain - who will suspect) and thus "bypass" protection.
I don't see any solution for now, and it seems that the creators of popular web browsers don't see it either, because I see they are not in a hurry with the implementation of more specific protection.
However, I am not so expert in the field of domains and all these procedures of their registration and law, so I would still leave it to you to suggest possible solutions in the comments below.
Comments
Post a Comment