Updates on CyberSecurity, WordPress and what we're cooking in the lab today.

Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites

This entry was posted in General Security on April 14, 2017 by Mark Maunder   142 Replies

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.

Did you enjoy this post? Share it!


3.71 (480 votes) Your rating:

142 Comments on "Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites"

AF April 14, 2017 at 3:39 pm • Reply

Thanks for the heads up!

Emb April 14, 2017 at 3:47 pm • Reply

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.

Jeremy April 18, 2017 at 11:15 am • Reply

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.

Marco Mariani April 19, 2017 at 2:51 am • Reply

Thanks!

Kai M. April 14, 2017 at 3:49 pm • Reply

Thanks Mark, great article - notified friends and family on this matter!

Keep up the good work!

-Kai

Odira Ndubuisi April 14, 2017 at 3:53 pm • Reply

Thanks for the information. This is really an interesting one.

E April 14, 2017 at 3:54 pm • Reply

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...

j April 15, 2017 at 12:55 am • Reply

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.

Ryan April 15, 2017 at 3:13 am • Reply

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.

Wendy April 14, 2017 at 3:54 pm • Reply

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. :-)

Mark Maunder April 14, 2017 at 4:19 pm • Reply

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. :-)

Victoria Cottrell April 15, 2017 at 8:18 pm • Reply

Good newas that Chrome isn't involved! Thanks for the heads up😉

Bruce Williamson April 14, 2017 at 3:55 pm • Reply

You mentioned both Firefox and Chrome. What about Safari on the Mac?

Mark Maunder April 14, 2017 at 4:15 pm • Reply

As we mention above, Safari is not affected.

James April 14, 2017 at 3:58 pm • Reply

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).

Mark Maunder April 14, 2017 at 4:14 pm • Reply

Which browser?

Perry April 14, 2017 at 3:58 pm • Reply

Is IE11 or Edge affected by this?

Russ April 17, 2017 at 7:20 am • Reply

The article said IE and Safari aren't effected. And I just tried Edge and it's not effected.

silverwood1 April 14, 2017 at 3:58 pm • Reply

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!

Tim April 15, 2017 at 11:29 am • Reply

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.

Shane April 14, 2017 at 4:00 pm • Reply

Thanks for the email high lighting this issue guys. Much appreciated.

Beata April 14, 2017 at 4:00 pm • Reply

Thank you for the warning - is the IE browser affected as well? Thank you.

Mark Maunder April 14, 2017 at 4:13 pm • Reply

Not that we know of.

RW April 14, 2017 at 4:00 pm • Reply

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.

ratamies April 19, 2017 at 8:11 am • Reply

In Opera 46.0.2567.0 (developer version) it is fixed.

Jeremy April 14, 2017 at 4:04 pm • Reply

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)

rawthey April 15, 2017 at 1:46 am • Reply

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).

Elaine W April 16, 2017 at 6:15 am • Reply

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/

Huff April 18, 2017 at 7:00 am • Reply

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.

carl April 14, 2017 at 4:06 pm • Reply

...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...!!

Gerard April 14, 2017 at 4:17 pm • Reply

You can add Opera 44.0.2510.1159 to the list, no surprises there since it's based on Chromium.

Mark Maunder April 14, 2017 at 4:20 pm • Reply

Thanks Gerard.

Steve April 17, 2017 at 4:28 pm • Reply

I could not replicate on Opera mobile, however (Android, full browser). Chrome mobile does show epic.

Derek April 14, 2017 at 4:18 pm • Reply

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.

Eric Johnson April 14, 2017 at 4:19 pm • Reply

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.

chuckzwood April 14, 2017 at 4:23 pm • Reply

I use FF, had no idea about this very scary problem. Thank you very much for posting the article and fix for FF!!!

CD Mazoff April 14, 2017 at 4:23 pm • Reply

Thank you!!! I shared this on my FB page and have notified colleagues!!

Roland April 14, 2017 at 4:28 pm • Reply

Thanks for the alert. Happy Easter!

Alexander Schestag April 14, 2017 at 4:28 pm • Reply

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.

Ann P April 16, 2017 at 12:13 pm • Reply

How to you fix this in Thunderbird? I've looked thru the settings and can't find anything. Thanks!

Bill Gray April 18, 2017 at 5:40 pm • Reply

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.

Jeff April 14, 2017 at 4:29 pm • Reply

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.

Erika April 14, 2017 at 4:39 pm • Reply

Chrome Canary looks good. But regular Chrome is still showing your demo site as epic.com.

Nevada Website Design April 14, 2017 at 4:43 pm • Reply

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!

Mike Conkey April 14, 2017 at 4:43 pm • Reply

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!

Aly Hasan April 18, 2017 at 12:15 pm • Reply

I am happy

Donna April 14, 2017 at 4:46 pm • Reply

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!

Brian April 14, 2017 at 4:56 pm • Reply

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!

Chok April 14, 2017 at 4:58 pm • Reply

Firefox: Right Click on link and select Copy Link Location - This won't 'copy' the punycode

Anu April 14, 2017 at 5:06 pm • Reply

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.

Bahawalpur April 14, 2017 at 5:14 pm • Reply

Chrome should act to this problem real soon.

Jeffrey April 14, 2017 at 5:25 pm • Reply

There's a chrome extension called Punycode Alert. Do you know anything about it and would it help with this current issue?

Peter Reck April 14, 2017 at 9:50 pm • Reply

Jeff: I installed it, but it didn't alert me to the punycode site Mark put up.

Jeffrey April 14, 2017 at 10:51 pm • Reply

That's too bad, thank you for trying it and letting me know.

febrezo April 16, 2017 at 2:26 am • Reply

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.

Perry Bernard April 14, 2017 at 5:30 pm • Reply

"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.

Brad April 14, 2017 at 5:48 pm • Reply

Simply fascinating. I had no idea that IDNs nor Punycode (!) existed. Thank you for the information/warning!

Tim April 14, 2017 at 5:48 pm • Reply

This should be an easy fix for the Google chrome team, I wonder whats taking them so long to fix this dangerous bug.

Chris G April 14, 2017 at 6:37 pm • Reply

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!

Aaron April 17, 2017 at 7:11 am • Reply

Thanks, double clicking on false was what I needed to know.
Also, Thanks to Wordfence for this important advice.

Gene Eberts April 14, 2017 at 6:44 pm • Reply

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!

Jetta April 14, 2017 at 6:57 pm • Reply

Interesting info. Thanks for this.

ian April 14, 2017 at 7:05 pm • Reply

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.

Justin April 15, 2017 at 12:17 am • Reply

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.

Marc April 14, 2017 at 7:22 pm • Reply

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?

Peter April 14, 2017 at 10:06 pm • Reply

Just installed Chrome Canary and it doesn't alert to the punycode threat issue

t dye April 14, 2017 at 7:50 pm • Reply

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.

t dye April 14, 2017 at 7:52 pm • Reply

https://developer.mozilla.org/en-US/docs/Mozilla/Internationalized_domain_names_support_in_Mozilla

Cat Travers April 14, 2017 at 8:16 pm • Reply

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?

Mark Maunder April 14, 2017 at 9:29 pm • Reply

Yes. You will no longer be able to see the hostnames with international characters.

Lunorian April 14, 2017 at 9:15 pm • Reply

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.

Simon April 14, 2017 at 10:13 pm • Reply

Thank you so much!

Neeraj Singh April 14, 2017 at 10:34 pm • Reply

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.

E.R. April 14, 2017 at 10:43 pm • Reply

Very good post + information, thank you!

Kev April 15, 2017 at 12:38 am • Reply

IE does not have this problem. Try clicking the links above in IE and you see the xn.. name.

Ahmed April 15, 2017 at 12:45 am • Reply

Thank you so much.

Paul Bailey April 15, 2017 at 12:56 am • Reply

Once again Mark you've saved our skins. I never open websites from an email anyway.
Thanks again.

Regards.

Hervé Iniguez April 15, 2017 at 3:11 am • Reply

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é

DarkAM April 15, 2017 at 3:19 am • Reply

Maxthon seems to be effected by this exploit too. This show us why SSL should not be free.

Haji Sheikh Pervaiz Manzoor Vohra April 15, 2017 at 4:28 am • Reply

Thanks to share with us

Russ Greeno April 15, 2017 at 5:00 am • Reply

I've only tested this on Chrome Dev on Android and it is not fooled by the trick. Hopefully ChromeOS is safe too.

Brenda April 15, 2017 at 5:27 am • Reply

Thanks so much for this information.

Suzanne A. April 15, 2017 at 5:39 am • Reply

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.

Eric April 15, 2017 at 5:50 am • Reply

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.

Wellington April 16, 2017 at 7:27 pm • Reply

if you view page source, the real name will be there

Eric April 15, 2017 at 5:57 am • Reply

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.

sTeaLTh April 15, 2017 at 6:18 am • Reply

Amazing work! Thumbs up (Y)

Mike April 15, 2017 at 6:56 am • Reply

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'.

Louis J. Bruno April 15, 2017 at 7:45 am • Reply

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.

Dror Harari April 15, 2017 at 7:54 am • Reply

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...

jeffseaver April 15, 2017 at 8:43 am • Reply

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?

Mark Arambula April 15, 2017 at 10:37 am • Reply

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.

Gabriele April 15, 2017 at 10:39 am • Reply

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.

Craig April 15, 2017 at 10:49 am • Reply

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.

Julie April 15, 2017 at 11:59 am • Reply

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.

MathAppeal April 15, 2017 at 3:48 pm • Reply

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.

Tony Mechelynck April 15, 2017 at 4:10 pm • Reply

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.

John Paul Aguilar Rios April 15, 2017 at 6:38 pm • Reply

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

voxleo April 16, 2017 at 12:07 am • Reply

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?

Helene Malmsio April 16, 2017 at 1:05 am • Reply

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

Dennis April 16, 2017 at 3:59 am • Reply

Unicode org actually do have a report of common features (=== vulnerability) all developers should aware of it exists.

http://www.unicode.org/reports/tr36/

Anonymous April 16, 2017 at 4:31 am • Reply

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!

Jamy April 16, 2017 at 6:05 am • Reply

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.

Mark Maunder April 16, 2017 at 10:20 am • Reply

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.

Kevin April 16, 2017 at 7:08 am • Reply

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 + '');
}

Yue April 16, 2017 at 11:42 am • Reply

Doesn't seems to affect Edge and Vivaldi.

allo April 16, 2017 at 2:43 pm • Reply

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.

allo April 16, 2017 at 2:44 pm • Reply

Nice detail: The font in your blog displays subtle differences on the i and c.

Dave Sailer April 16, 2017 at 3:03 pm • Reply

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

regs April 16, 2017 at 4:51 pm • Reply

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.

Jeri April 16, 2017 at 8:49 pm • Reply

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.

Joker Qyou April 16, 2017 at 8:58 pm • Reply

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?

Mark Maunder April 16, 2017 at 9:00 pm • Reply

Yes, please do.

Wil April 16, 2017 at 10:52 pm • Reply

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.

Flake April 17, 2017 at 4:27 am • Reply

You lost all your credibility at the line "Merely visiting the website may infect your computer".
Quitting this website for good now.

Mark Maunder April 17, 2017 at 9:58 am • Reply

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.

Riccardo April 17, 2017 at 5:22 am • Reply

Browsers should release a patch that color in red every non "standard" character.

Michel Merlin April 19, 2017 at 4:40 pm • Reply

"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

Nathalie April 17, 2017 at 8:00 am • Reply

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!

Doug April 17, 2017 at 9:15 am • Reply

Is this still an issue with Chrome as of today.?

Mark Maunder April 17, 2017 at 9:52 am • Reply

Yes. Try the demo if you're using Chrome.

Marco Borla April 17, 2017 at 9:34 am • Reply

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.

Amit April 17, 2017 at 9:34 am • Reply

Thanks a 1e6!
Shared!

Mark Maunder April 17, 2017 at 9:50 am • Reply

You're welcome. :) Nice use of exponential notation.

Scott R Godin April 17, 2017 at 9:48 am • Reply

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

maestra April 17, 2017 at 9:52 am • Reply

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?

Mark Maunder April 17, 2017 at 10:00 am • Reply

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.

Loren April 17, 2017 at 2:48 pm • Reply

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.

Lars Andersson April 17, 2017 at 8:17 pm • Reply

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 ; )

Stuartb3502 April 17, 2017 at 8:41 pm • Reply

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.

John April 18, 2017 at 7:32 am • Reply

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?

jskamm April 18, 2017 at 7:52 am • Reply

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?

hajma April 18, 2017 at 9:29 am • Reply

Opera Mini also fell victim to this. Well done, sir!

Amar April 18, 2017 at 2:04 pm • Reply

This is really scary.
Thank for letting me know. Shared with my Facebook friends and waiting for chrome and Firefox updates.

David Bowles April 18, 2017 at 3:08 pm • Reply

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;

Jean April 19, 2017 at 3:15 am • Reply

Which tool can detect id an ASCII domain exists in any of the IDNs available? Can this be detected?

Who Dat April 19, 2017 at 3:54 am • Reply

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!!!!

Marco Borla April 19, 2017 at 5:05 am • Reply

Seems Mozilla has decided where to stay....
https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ

psicho April 19, 2017 at 11:22 am • Reply

Chrome has been updated to version 58.0.3029.81 (64-bit) and now the websites are displayed correctly.

Bill April 19, 2017 at 11:45 am • Reply

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.

John April 19, 2017 at 11:04 pm • Reply

So then the browsers need to take the green lock or secure label out of the address bar?

Ram April 19, 2017 at 11:24 pm • Reply

Really a good one, thanks for sharing this article.

The above issue is resolved after upgrading the chrome Version to 58.0.3029.81!!!!!

Leave a Reply

Get the latest WordPress security updates and news

Sign up for WordPress security alerts, Wordfence product updates and security news via email.