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

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.

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

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

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

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.

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.

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

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

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!

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.

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.

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!

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!

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.

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!

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!

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.

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.

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

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.

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

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?

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.

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.

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:

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.

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

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?

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.

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:

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.

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.

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?

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!

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.

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.

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.

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

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.

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?

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

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;

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.