Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites
Update on April 19th at noon Pacific time: Chrome has just released version 58.0.3029.81. We have confirmed that this resolves the issue and that our ‘epic.com’ test domain no longer shows as ‘epic.com’ and displays the raw punycode instead, which is ‘www.xn--e1awd7f.com’, making it clear that the domain is not ‘epic.com’. We encourage all Chrome users to immediately update to the above version of Chrome to resolve the issue. The original post follows:
This is a Wordfence public service security announcement for all users of Chrome and Firefox web browsers:
There is a phishing attack that is receiving much attention today in the security community.
As a reminder: A phishing attack is when an attacker sends you an email that contains a link to a malicious website. You click on the link because it appears to be trusted. Merely visiting the website may infect your computer or you may be tricked into signing into the malicious site with credentials from a site you trust. The attacker then has access to your username, password and any other sensitive information they can trick you into providing.
This variant of a phishing attack uses unicode to register domains that look identical to real domains. These fake domains can be used in phishing attacks to fool users into signing into a fake website, thereby handing over their login credentials to an attacker.
This affects the current version of Chrome browser, which is version 57.0.2987 and the current version of Firefox, which is version 52.0.2. This does not affect Internet Explorer or Safari browsers.
We created our own example to demonstrate how an attacker can register their own domain that looks identical to another company’s domain in the browser. We decided to imitate a healthcare site called ‘epic.com’ by registering our own fake site. You can visit our demo site here in Chrome or Firefox. For comparison you can click here to visit the real epic.com.
Here is what the real epic.com looks like in Chrome:
Here is our fake epic.com in Chrome:
And the real epic.com in Firefox:
And here is our fake epic.com in Firefox:
As you can see both of these domains appear identical in the browser but they are completely different websites. One of them was registered by us, today. Our epic.com domain is actually the domain https://xn--e1awd7f.com/ but it appears in Chrome and Firefox as epic.com.
The real epic.com is a healthcare website. Using our unicode domain, we could clone the real epic.com website, then start emailing people and try to get them to sign into our fake healthcare website which would hand over their login credentials to us. We may then have full access to their healthcare records or other sensitive data.
We even managed to get an SSL certificate for our demonstration attack domain from LetsEncrypt. Getting the SSL certificate took us 5 minutes and it was free. By doing this we received the word ‘Secure’ next to our domain in Chrome and the little green lock symbol in Firefox.
How is this possible?
The xn-- prefix is what is known as an ‘ASCII compatible encoding’ prefix. It lets the browser know that the domain uses ‘punycode’ encoding to represent Unicode characters. In non-techie speak, this means that if you have a domain name with Chinese or other international characters, you can register a domain name with normal A-Z characters that can allow a browser to represent that domain as international characters in the location bar.
What we have done above is used ‘e’ ‘p’ ‘i’ and ‘c’ unicode characters that look identical to the real characters but are different unicode characters. In the current version of Chrome, as long as all characters are unicode, it will show the domain in its internationalized form.
How to fix this in Firefox:
In your firefox location bar, type ‘about:config’ without quotes.
Do a search for ‘punycode’ without quotes.
You should see a parameter titled: network.IDN_show_punycode
Change the value from false to true.
Now if you try to visit our demonstration site you should see:
Can I fix this if I use Chrome?
Currently we are not aware of a manual fix in Chrome for this. Chrome have already released a fix in their ‘Canary’ release, which is their test release. This should be released to the general public within the next few days.
Until then, if you are unsure if you are on a real site and are about to enter sensitive information, you can copy the URL in the location bar and paste it into Notepad or TextEdit on Mac. It should appear as the https://xn--….. version if it is a fake domain. Otherwise it will appear as the real domain in its unencoded form if it is the real thing.
Spread the word
The concept of an IDN homograph attack has been around since 2001 when Israeli researchers Evgeniy Gabrilovich and Alex Gontmakher first wrote about it.
Web browsers have attempted various fixes but the current implementations in Chrome and Firefox are clearly not doing a good enough job. To Chrome’s credit, they are about to fix that. Thankfully there is a manual fix for Firefox.
We would like to encourage you to spread the word. This new twist on phishing is getting a lot of attention today, Friday April 14th and is making the rounds currently in the security community. Xudong Zheng wrote about this earlier today and it is also being discussed on the netsec subreddit.
We think here is a high possibility that this may be exploited in phishing attacks before the Chrome fix is released to the general public, which is why we are posting this public service announcement.
Comments
3:39 pm
Thanks for the heads up!
3:47 pm
Surprising nobody thought of that before! Thanks for the warning.
In Chrome, you can also copy the URL and paste it in the same place (F6, Ctrl+C, Ctrl+V). It will show the https://xn--….. version.
11:15 am
It's actually pretty common, but most registrars have safeguards in place to prevent punycode spoofing.
Obviously the registrar these sites are coming from doesn't care about security.
2:51 am
Thanks!
3:49 pm
Thanks Mark, great article - notified friends and family on this matter!
Keep up the good work!
-Kai
3:53 pm
Thanks for the information. This is really an interesting one.
3:54 pm
We definitely fell for the hack today and have no idea what to do at this point. Even with following all of the advice out there on the internet, when I try to sign in to my website it is still saying that it is "not secure" in the Chrome browser. Is it our computer that is hacked? I am so confused about what we are supposed to be doing and our computer is being actively hacked right now...
12:55 am
Hi E.
Stop that! If your domain was secure before, but now it is insecure, the domain is the hacked version! Every time you change your password and log back in on that site, you're giving the credentials away.
3:13 am
Hi E, chances are your problem is something different. Since the beginning of this year, all non-HTTPS websites are marked as insecure in all browsers. You'll have to install a TLS certificate to remove the insecure mark. Even a free certificate such as the one given by Let's Encrypt (https://letsencrypt.org/) should be sufficient.
Alternatively, if your site actually already have HTTPS, it's possible that your site have an outdated/weak ciphersuite setting or only supports an older/vulnerable version of SSL. You'll need to update your webserver configuration to fix this. I find Qualys SSLabs SSL Test (https://www.ssllabs.com/ssltest/) test very helpful to determine good configuration.
3:54 pm
Good to know! Interestingly, I tried clicking over to your fake site in Firefox (both regular and developer editions) and I was blocked, saying it was unsafe. So that's good to know too. Not so with Chrome, which did not give me a warning at all. Thanks for letting us know! You guys are awesome. :-)
4:19 pm
Thanks. Fixed that. The demo now works in Firefox too. I had linked to the domain without the www prefix. Try it now and it'll work in both browsers.
PS: I'm aware we could have it work both ways. But this was set up in haste, so rather than fix the certificate config, I just changed the link from our post. :-) Also, it's Friday easter weekend at 7pm on the east coast, so it's a bit tough to round up someone to fix that certificate right now. :-)
8:18 pm
Good newas that Chrome isn't involved! Thanks for the heads up?
3:55 pm
You mentioned both Firefox and Chrome. What about Safari on the Mac?
4:15 pm
As we mention above, Safari is not affected.
3:58 pm
Thank you for this! I do notice, at least on my computer, that the https is flagged as belonging to xn--e1awd7f.com, not epic.com (who happens to be about 30 miles away from me).
4:14 pm
Which browser?
3:58 pm
Is IE11 or Edge affected by this?
7:20 am
The article said IE and Safari aren't effected. And I just tried Edge and it's not effected.
3:58 pm
Wow, besides my WP site getting hacked by Turkish hackers, which is why we use your product, we now have this. Thanks for your work and is there any issue in Safari? Well i checked and its saying
Safari can't verify the identity of the website "xn--elawd7f.com"
This certificate is not valid (host name mispatch)
So you get the Apple effect, it caught the fake site the moment you went there. I use all 3 browsers, each works best with certain things as Safari is not perfect. Though like Apple computers & phones, their hardware/software marriage from the same company with tight security makes them the premiere computer hardware that does not get spoofed by these types of things, nor are susecptable to the pleothora of virus, trojan horse & malware PC uses have to deal with. While more than 1/2 of you will disagree, its the truth.
So, with WP you get what you pay for, a free site that is constantly being hacked. Wonder if its time to ditch the entire platform & just have your own site, plenty of low cost basic ones out there, though you lose a lot of the protection like Wordfence & others. Keep up the great work!
11:29 am
This has nothing to do with "hardware/software from the same company". This is a pure software bug, which should have been fixed years ago in all browsers.
It's an embarrassment to our industry that a security hole first described in 2001 was first closed in 2005 by one company, and still around in 2017 in browsers by other major web companies.
4:00 pm
Thanks for the email high lighting this issue guys. Much appreciated.
4:00 pm
Thank you for the warning - is the IE browser affected as well? Thank you.
4:13 pm
Not that we know of.
4:00 pm
Opera 44.0.2510.1218 is also affected.
There's a "security advisory" from 2005: http://www.opera.com/security/advisory/788 which doesn't say much, and appears to be out-of-date.
8:11 am
In Opera 46.0.2567.0 (developer version) it is fixed.
4:04 pm
Copying and pasting the link into Mac TextEdit Version 1.12 (329) did NOT reveal the Punycode on my machine (running Sierra 10.12.4)
1:46 am
I'm running FreeBSD with KDE desktop and copying and pasting the link also did NOT reveal the Punycode in either vi or the KDE editor (kate).
6:15 am
Copying and pasting the link from Firefox version 52.0.2 into notepad didn't reveal the Punycode for me either. It pasted as https://www.еріс.com/
7:00 am
I pasted it into "Notepad++" and it turned to "www.????.com" (question marks instead of "epic").
But pasting it in notepad did not reveal the true address to me either.
4:06 pm
...nice to know there are folks like you all "out there" looking after our safety and security online... thank you for an informative article and the public service warning...!!
4:17 pm
You can add Opera 44.0.2510.1159 to the list, no surprises there since it's based on Chromium.
4:20 pm
Thanks Gerard.
3:33 am
Hi Mark, Opera issued security patch to prevent possible phishing with Unicode domains. Please see http://www.opera.com/blogs/desktop/2017/04/opera-stable-44-0-2510-1449-update/
4:28 pm
I could not replicate on Opera mobile, however (Android, full browser). Chrome mobile does show epic.
4:18 pm
This been going on for a while now the most used I see is paypal and amazon letting you know your account will get suspended if you don't take action or you forgot your password and it look legit once you add your info It's a wrap for you they have what they need investigate all of my emails before opening.
4:19 pm
Good Grief that is insane. Thank you for the heads up on this one and for the manual fix in Firefox. One note on the manual fix, after entering about:config Firefox gives a warning "This might void your warranty!" which is, frankly, funny. I didn't know Firefox had a warranty. :) Ha! Anyways, did the change and it worked as advertised.
Thanks for looking out for us.
4:23 pm
I use FF, had no idea about this very scary problem. Thank you very much for posting the article and fix for FF!!!
4:23 pm
Thank you!!! I shared this on my FB page and have notified colleagues!!
4:28 pm
Thanks for the alert. Happy Easter!
4:28 pm
You should recommend the same manual fix for Thunderbird as it is affected by the same problem as Firefox and Chrome and it can be fixed the same way as in Firefox.
12:13 pm
How to you fix this in Thunderbird? I've looked thru the settings and can't find anything. Thanks!
5:40 pm
Use the 'hamburger' icon, then Preferences. Click on the Advanced tab, then on the Config editor button.
Alexander, thanks for mentioning this. I'd assume the most common way of using this vulnerability would be to e-mail a link.
4:29 pm
Thanks for the heads up - good to know!
The best way to combat these types of attacks - visit the domains directly. You'll never need to worry about these types of exploits.
The only time you should be clicking in links in emails is when you are expecting to verify your email account, meaning you yourself triggered the email minutes ago, and are expecting it.
4:39 pm
Chrome Canary looks good. But regular Chrome is still showing your demo site as epic.com.
4:43 pm
I am telling all my clients, friends, family, everyone I can....WordFence, thanks for the email I received with the link to the article on the browser phishing attack issue. Also, the recent article about home router security check.....very helpful!
4:43 pm
Once again you and your team have provided a very valuable service with your public announcement regarding this latest threat to Internet users! Thank you from a very happy customer of Wordfence!
12:15 pm
I am happy
4:46 pm
Thank you SO much for this very helpful article. I've shared on G+, FB and Twitter. There is just no end to the evil that can be done, too bad the ones behind it can't see that doing good with their amazing brains is SO much more satisfying. Happy Easter!
4:56 pm
Gotta hand it to Wordfence -- you're doing a great job with providing security PSAs like this one. I am proud to be running Wordfence on my websites. Keep up the great work!
4:58 pm
Firefox: Right Click on link and select Copy Link Location - This won't 'copy' the punycode
5:06 pm
Hey Mark,
This is one of the reasons I use toolbar from Moz that shows domain authority.
If the domain is not real epic.com and a site that was just setup recently it will show it clearly.
In this case fake epic.com will have 0 domain authority and real one probably 60+.
This strategy works great for old sites that attackers are trying to go after but not fresh new ones where there is no data on moz.
5:14 pm
Chrome should act to this problem real soon.
5:25 pm
There's a chrome extension called Punycode Alert. Do you know anything about it and would it help with this current issue?
9:50 pm
Jeff: I installed it, but it didn't alert me to the punycode site Mark put up.
10:51 pm
That's too bad, thank you for trying it and letting me know.
2:26 am
We have developed the extension and when watching the post we suppossed. This seems to be something that has been broken lately because the extension simply worked.
In fact, previous measures by Chrome Browser seemed not to automatically translate punycode domains written in languages which were not the ones of the current browser. Thus, trying to trick a Spanish user using cyrlic characters was a bit more difficult because xn-- tag was displayed. We are working on this to upgrade the extension asap.
5:30 pm
"ordinary" people will never fix their browsers for this. It's up to browser manufacturers to resolve this pronto wit at very least a warning popup.
5:48 pm
Simply fascinating. I had no idea that IDNs nor Punycode (!) existed. Thank you for the information/warning!
5:48 pm
This should be an easy fix for the Google chrome team, I wonder whats taking them so long to fix this dangerous bug.
6:37 pm
Can i suggest you add something along the lines of 'by double clicking on false' in the How to fix this in Firefox section. i.e. Change the value from false to true by double clicking on 'false'. And thanks for yet another great article!
7:11 am
Thanks, double clicking on false was what I needed to know.
Also, Thanks to Wordfence for this important advice.
6:44 pm
My firefox v.52.0.2 did not have the code in about:config. I simply copied your code - "network.IDN_show_punycode" and then right clicked the about:config list and selected New and then String from the drop down menues that appeared. network.IDN_show_punycode automatically listed as "true." I then moused over your false link and it showed as https://www.xn--e1awd7f.com/
Thanks for the heads up!
6:57 pm
Interesting info. Thanks for this.
7:05 pm
After changing the value on the network.IDN_show_punycode as per your instructions, I also noted that there about 20 network.IDN.whitelisted.xn-- codes, currently set to true.
Are these supposed to be there, or should I set them all to false.?
Am using Firefox.
12:17 am
Yes those are suppose to be there.
Some are TLDs which are explained at http://kb.mozillazine.org/Network.IDN.whitelist.*
Others are domains including things like testing ones as noted at http://kb.mozillazine.org/Network.IDN.whitelist.*
Also those settings only apply if network.IDN_show_punycode is set to true, if you set it to false as this article shows, then those other settings have no effect so you don't need to worry about them.
7:22 pm
Anyone know what the version number will be for the upcoming Chrome "Canary" release so we can easily check to see if it has updated to that?
10:06 pm
Just installed Chrome Canary and it doesn't alert to the punycode threat issue
7:50 pm
Caveats and ConclusionsEDIT
Netscape 7.1/Mozilla 1.4 has solid support for Internationalized Domain Names and is the first browser with built-in support for new RFC's for IDN established by IETF. This means that there is no longer any need to use a plug-in to process non-ASCII domain names.
Netscape/Mozilla's support for IDN is not without some bugs. One notable bug is that non-ASCII names are not always displayed correctly in some UI areas such as Preference panels, Bookmarks and History. Non-ASCII names are not always correctly displayed in the location bar due to the fact that ACE to Unicode conversion is not implemented yet. Of particular concern for Japanese users is the one in which Full-width Japanese Roman characters are not normalized to ASCII roman characters. (Cf. bug 210734.) This forces the Japanese user to shift out of the Japanese input mode to write the top domain names such as .jp causing inconvenience. For other bugs, see this link.
IDN is a global trend and is likely to be adopted by a large number of sites making it easier for average Internet users to find web sites. Many web sites around the world are expected to register native language host names with the appropriate domain name registrars for their top domains. Netscape 7.1 and Mozilla 1.4 are playing a significant role in aiding the development of IDN further.
7:52 pm
https://developer.mozilla.org/en-US/docs/Mozilla/Internationalized_domain_names_support_in_Mozilla
8:16 pm
I visit a lot of Korean sites. If I change my punycode settings in Firefox, will this have any impact on the URLs of the Korean sites?
9:29 pm
Yes. You will no longer be able to see the hostnames with international characters.
9:15 pm
Whileas this exploit does work there is actually a very good work-around.
1) Open the Chrome Developer Tools (also known as Inspect Element, CTRL-Shift-I)
2) Click the security tab
3) See the real SSL certificate and check if it's signed for the correct domain name.
10:13 pm
Thank you so much!
10:34 pm
OMG ! I have check out your demo site and its look like a real epic.com with SSL. This will be a very danger for all of us.
10:43 pm
Very good post + information, thank you!
12:38 am
IE does not have this problem. Try clicking the links above in IE and you see the xn.. name.
12:45 am
Thank you so much.
12:56 am
Once again Mark you've saved our skins. I never open websites from an email anyway.
Thanks again.
Regards.
3:11 am
Thanks a lot for this article.
I currently use Chrome. To test the domain name, I simply "copy" and then immediatly "paste" in the adress bar, which replaces https://www.epic.com/ by https://www.xn--e1awd7f.com/. This is a very quick and easy way (instead of going to notepad).
Hervé
3:19 am
Maxthon seems to be effected by this exploit too. This show us why SSL should not be free.
4:28 am
Thanks to share with us
5:00 am
I've only tested this on Chrome Dev on Android and it is not fooled by the trick. Hopefully ChromeOS is safe too.
5:27 am
Thanks so much for this information.
5:39 am
I checked my history in Chrome, opened the full list, searched for 'xn' (no quotes) - it came up with "this is a demonstration website" and www.epic.com - but since it *found* this with xn, I would know to check this further. (Was this a site where I used credentials?) Of course, this is only helpful if you keep history.
5:50 am
If you view the SSL certificate in Chrome or Firefox, it will display the real name. But Chrome hid that option in recent versions. Either way, it's unlikely that the average user will do it.
7:27 pm
if you view page source, the real name will be there
5:57 am
Another way for companies to protect their users would be to register the unicode version of their domain and redirect it to their real website.
6:18 am
Amazing work! Thumbs up (Y)
6:56 am
Seems to me this problem is mostly caused by Domain Registrars not conforming to the ICANN IDN guidelines. If the domain registrar has an anti-spoofing policy, but does not implement it, then Mozilla.org may add the domain to their whitelist and the Mozilla IDN display algorithm will then display it as 'intended' rather than as 'punycode' or 'unicode'.
7:45 am
Just got the Windows 10 Creators update, including updated Edge browser, which handles your demo site properly, showing the unicode not the International characters.
Thanks for calling attention to this hijack.
7:54 am
Having the browser show punycodes or any non-latin characters highlighted in some fashion (e.g. some gentle red tint) may help make this issue much easier to detect...
8:43 am
Thanks again, we are alerting our entire client base about this now.
A sidebar note - that much as Mac's Safari gives us tons of headaches - its gone from being fairly reliable to one of the most trouble-prone browsers - I was grateful to at least see an accurate renderig of the unicode in the URL.
Should I be surprised that 24, 48 hours can go by and Google's Chrome team has yet to release a fix?
10:37 am
Thanks for the update! I recommend using the Chrome extension named "Netcraft Extension". This one reveals the true URL in the address bar and helps prevent phishing.
10:39 am
In Mozilla SeaMonkey I see the same behaviour as in Firefox, but if one check the SSL it is clearly stated it was issued to "www.xn--e1awd7f.com".
Safari shows "www.xn--e1awd7f.com" in the URL bar even if I copy-paste "https://www.еріс.com/"
PS: the punycodes characters are shown smaller than the "real" ones, so a very careful look in the status bar could alert the visitor that something is suspicious.
10:49 am
Hi Great post i have been saying this to all my clients for ages. In chrome i click {inspect ) then click on tab {security } this then asks to refresh page and you can see the actual domain name.
all well and good for us techies but im sure we dont do for all the https sites we goto.
11:59 am
I'm curious if there is a location currently where people are tracking websites that have been effected by this?
I shared the article on FB with all of my family & friends and also shared it with my contractors and work contacts to be sure everyone is aware.
3:48 pm
I tried the original fake epic.com in Firefox and it wouldn't let me in, saying my connection was insecure, that the owner of epic.com had configured the site improperly, and that for my protection Firfox would not connect to it.
After I changed the punycode, it allowed me to see the demonstration site.
4:10 pm
After pasting the URL from my location bar (Mozilla SeaMonkey 2.52a1, equivalent to Firefox 55.0a1) into a text editor, it still looks like www.epic.com, but on looking closer, the "epic" is in Cyrillic, as follows:
• е U+0435 CYRILLIC SMALL LETTER IE
• р U+0440 CYRILLIC SMALL LETTER ER
• і U+0456 CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
• с U+0441 CYRILLIC SMALL LETTER ES
This is of course with the preference network.IDN_show_punycode defaulted to false. Toggling it to true displays the punicode, both in the statusbar on mouseover at the link, and in the location bar after clicking the link.
Best regards,
Tony.
6:38 pm
I also tried to use proxy server and port on my web router on any IP address that is open. That way if an attacker on the web hacking my Android and my Chromebook I don't think he would tried to get inside my open portal using a proxy server and and port
12:07 am
So this is still a "click the link" type of problem though? From the description of how it works, it appears to me that typing the url in the address bar yourself should avoid the issue as well, as they will be the actual characters and not the look alike characters, is this right?
1:05 am
Thank You so much for this... I hate fiddling with any of the software on my computer, but even I could figure this fix, so it is fool proof - lol
3:59 am
Unicode org actually do have a report of common features (=== vulnerability) all developers should aware of it exists.
http://www.unicode.org/reports/tr36/
4:31 am
The copy+paste mitigation described here does not work in all browsers/OSes!
In Firefox on Linux, for instance, copy and pasting does *not* show the punycode - when I paste, I get the same unicode homoglyph characters as the location bar displays.
Please update your post to stop giving this dangerous advice!
6:05 am
Hi Mark,
How did you manage to create such unicode format, can you post a link of unicode generator, I found one but its showing xn-.....
thank.
10:20 am
The team did it by hand but with some help from tools to find unicode letters that are similar to ASCII IIRC. I'll post some additional details tomorrow when they're back in the office.
7:08 am
You made a nice test and exemple. To aware of phishing attach, I added a simple Tampermonkey userscript in Chromium to detect if url contains "xn--". If it has, then the script will show punycode url at the beginning of the body.
var url= window.location.href;
if (url.indexOf("xn--") != -1) {
document.body.insertAdjacentHTML("afterbegin", 'Punycode url: '+ url + '');
}
11:42 am
Doesn't seems to affect Edge and Vivaldi.
2:43 pm
For firefox not even copy&paste works. It copies it as unicode, just as displayed. And it looks the same on different fonts, even in terminals with a font designed for legibility. When i copy it into a hexdump on a terminal i still get:
https://www.epic.com/
0000000 072150 070164 035163 027457 073567 027167 070145 061551
https://www.еріс.com/
0000020 061456 066557 005057 072150 070164 035163 027457 073567
0000040 027167 132720 100321 113321 100721 061456 066557 005057
So copy&paste isn't a secure solution as well.
On the other hand, chromium (not chrome) displays the xn- version by default.
2:44 pm
Nice detail: The font in your blog displays subtle differences on the i and c.
3:03 pm
I tried accessing the fake site in Vivaldi and it appears to be immune already. It gave me "https://xn--e1awd7f.com/" in the address bar. Woot!, etc.
My setup...
Vivaldi 1.8.770.56 (Stable channel) (32-bit)
Revision: e2cd2e0f9cc4bf56968f7869149c05302db06306
OS: Linux
4:51 pm
Setting network.IDN_show_punycode to false simply turns off IDN support at all, which is not an option for most of this world.
An old good IE was actually having protection against domain spoofing. If domain consist of any non-local (of installed system locales) characters then it will highlight it as IDN or possible spoofing. Firefox dev has been told many times about it. If it's not there, then they are not much aware of security in their browser.
8:49 pm
Thank you for this valuable information. I never click on links in emails, even if they look like legitimate websites and some may be. Long ago I learned to type the URL of the website I wanted. I use Chrome and when I went to your demo webpage and copied it into another address bar in Chrome, it came up with the "xn" URL. Chrome has yet to fix but at least I can test it by copying URL to see if legitimate. I hate it that Chrome removed the Security info for Certificates as if we are to trust that they report a Secure website when in reality it may be fake. Scary and think of all those unsuspecting users who don't know this type of information. Chrome needs to jump on this ASAP.
8:58 pm
As many of your readers have replied, simply copy the URL and paste into common text editors does not reveal the punycode characters. Instead, copy the URL and instantly paste into the address bar do. I thinkg that part need to be updated.
Also, could I repost a translated version (Simplified Chinese) to my own blog?
9:00 pm
Yes, please do.
10:52 pm
Copying the link from a web page or web based email client such as Gmail and pasting it into notepad does not show the unicode.
Copying the unicode URL from the browser address bar and pasting it back into Chrome or notepad does show the unicode, but by that time the damage could already be done.
Wil.
4:27 am
You lost all your credibility at the line "Merely visiting the website may infect your computer".
Quitting this website for good now.
9:58 am
Sorry to lose you. I'll explain for the rest of us: There are tools that will help you set up a web server and when a victim visits they will detect the browser version, which vulnerabilities it has and automatically fire off exploits tailored to that browser. When one is successful the tool will drop you right into a shell on the victim workstation. Check out Metasploit browser autopwn for an example: https://community.rapid7.com/community/metasploit/blog/2015/07/15/the-new-metasploit-browser-autopwn-strikes-faster-and-smarter--part-1.
Phishing attacks may infect your workstation, they may direct you to a website with a malware attack like the one I've described, or they may direct you to a website with a fake login page.
5:22 am
Browsers should release a patch that color in red every non "standard" character.
4:40 pm
"Riccardo" Mon 17 Apr 2017 05:22 « Browsers should release a patch that color in red every non "standard" character »
The problem is: the characters looking as « e », « p », « i », « c », that they used, are full standard Cyrillic.
Versailles, Thu 20 Apr 2017 01:39:20 +0200
8:00 am
I remember this risk being discussed way back in 2010 when IDN were introduced. I had even written an article about it. It's a wonder it took this long to get noticed and exploited. Thanks for the reminder!
9:15 am
Is this still an issue with Chrome as of today.?
9:52 am
Yes. Try the demo if you're using Chrome.
9:34 am
There are a bug report into Firefox Mozilla bug about this security issue; the report has been closed in the past days as wontfix and reopened again... now someone in the conversation is again suggesting to close it as wontfix. I AM asking on this security issue why Edge browser is not affected and Firefox is... and why they cannot solve this security issue... Mark and Wordfence I hope you may want help Firefox to find a way to fix this security Issue.... I will be not happy on know Firefox will not fix this securty issue by telling is a behaviro of registrars.
9:34 am
Thanks a 1e6!
Shared!
9:50 am
You're welcome. :) Nice use of exponential notation.
9:48 am
Just an FYI, Vivaldi (alternative to chrome/firefox/opera, Blink-engine based) _does_ show the punycode in the URL bar on your test without needing to tweak some setting first.
https://forum.vivaldi.net/topic/16057/chrome-firefox-unicode-phishing-test/2
9:52 am
When attempting a manual fix of Firefox this warning message appears after typing about:config
This might void your warranty. Changing these advance settings can be harmful etc. etc.
Should we go ahead and click the "I accept this risk" button?
10:00 am
If you're comfortable changing the internals of Firefox you can go ahead and do that. As far as I'm aware, it's a joke. Firefox doesn't come with any warranty, implied or otherwise. My guess is if you read the license docs you'll discover that.
2:48 pm
The problem with a global "fix" like you suggest is that you will make sites with a legitimate use for unicode characters look like they have broken URLs.
Umóⁿhoⁿ is not likely to ever have a OS or browser localization but having a domain name spelled/displayed correctly would be nice.
8:17 pm
Again, great work! I updated my config parameter in my old version of Firefox (48.0.2) to show the unicode, and it works fine. Yeah, yeah, I need a later version of Firefox, but that is the latest one I can use on Snow Leopard, and upgrading to latest OS comes with some other unsavoury consequences that I am avoiding until I upgrade my Mac entirely - once I can afford to ; )
8:41 pm
In Chrome on Android, using the "i" in a circle (info) option on the 3 dots menu shows the punycode. Unfortunately it also identifies the site as "secure" and shows the certificate as being for "epic.com". Bringing up certificate details then shows the punycode certificate name. Seems like some of the Chrome team coded it right and others not so much.
7:32 am
I've designed a powershell command to handle this manually for all profiles on a machine, as I have to do this enterprise wide.
My issue is with the Macs. I can't seem to find the entry in prefs.js inMac OSX. I tried adding it in, but Firefox for the mac completely ignores it. How can I correct this via command line for the mac so I can write a BASH to fix it company wide?
7:52 am
Please excuse my ignorance, but this only applies to someone actually clicking on a link which appears in their email? If that is the case, I'm assuming just typing the actual URL in your chrome browser will by pass the phishing attack and takes you to the trusted site...
Would that be true?
9:29 am
Opera Mini also fell victim to this. Well done, sir!
2:04 pm
This is really scary.
Thank for letting me know. Shared with my Facebook friends and waiting for chrome and Firefox updates.
3:08 pm
It gets worse. Toms Hardware New reports : Google discovered in 2015 that Symantec issued certificates for its Google.com domain even though it never requested those certificates. This led both companies to investigate Symantec's certificate issuing process, and eventually they discovered several mis-issued certificates. Google said roughly 30,000 certificates were improperly issued;
3:15 am
Which tool can detect id an ASCII domain exists in any of the IDNs available? Can this be detected?
3:54 am
Thanks, Mark...
Wait...how do we know this is really Mark?
How do we know this is really Wordfence?
Oh nooooooo, it's more diabolical than I thought!!!!
5:05 am
Seems Mozilla has decided where to stay....
https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ
11:22 am
Chrome has been updated to version 58.0.3029.81 (64-bit) and now the websites are displayed correctly.
11:45 am
I just updated to Google Chrome Version 58.0.3029.81 (64-bit). The described issue appears to be fixed in this version based on how the URL appears in the new version.
11:04 pm
So then the browsers need to take the green lock or secure label out of the address bar?
11:24 pm
Really a good one, thanks for sharing this article.
The above issue is resolved after upgrading the chrome Version to 58.0.3029.81!!!!!
12:41 pm
It is still not fixed on Chrome OS Version 58.0.3029.68. Bad!
2:22 pm
Fixed in 58.0.3029.89
5:44 pm
Thanks for the information :)
7:31 am
I don't see an app update from Chrome yet for my iPhone, and after testing via the demonstration url above - it still shows that it isn't revealing the right url. Are there any updates on this? It's too much of a bother to open up a text document (notes) to check on the iPhone. I know I can use Safari, but I prefer Chrome.
11:45 am
Thanks man.
5:47 pm
Today, i update my Chrome to Version 58.0.3029.81 (64-bit) on my mac. And now, seems like The issue above has been fixed..
Thanks for warning..
8:22 pm
It's fix on Chrome for me too. Version 58.0.3029.81 (64-bit)