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

[Batu69]

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.

 

Article source

[CrAKeN]

 

Punycode phishing attack to soon become obsolete

 

Chrome and Firefox are adding some extra protections to their systems to protect users from a nasty phishing trick. 

 

Normally, when you click on a link to a site, you expect to be taken to that particular site. Thanks to a researcher, however, it was discovered that it's not always the case due to a vulnerability of most browsers in the way they translate special characters. 

 

For example, a website address that starts with xn-- tells your browser that the domain name is encoded using Punycode, which allows special characters to be displayed. This ability is quite important because a large part of Internet users don't speak English, or it's not their first language, and their mother tongues include such special characters. 

 

This, however, also lets cybercriminals execute what is called a homograph attack. Basically, it tricks the browser into believing a certain domain that includes special characters is actually a different domain, one that people trust. By spoofing the domain, users will believe they are in the right location. 

 

Chrome and Firefox will display a mess of characters as the right URL. Furthermore, the scammer can even apply for a SSL certificate for the Punycode name and, given what has surfaced in recent scandals, will likely even get it. Then, you'll find yourself on a site you think you know, with a "secure" tag near the address bar, indicating that everything is right in the world. What is the next thing you do? You log in. What is the next thing that happens? The cybercriminals steal your credentials. 

 

Chinese security researcher Xudong Zheng came up with a proper example of this situation with the site epic.com. By using the Punycode trick, the fake site looks legit, complete with the SSL certificate to back it up. 

 

Fixes, coming right up

 

Homograph attacks have been around for the better part of the decade, and it's proven to be a difficult technique to fight against. Chrome and Firefox, however, may soon get some protection. 

 

Chrome Canary has already been updated with a new feature that protects users from such attacks. Canary, as you may know, is the experimental version of the browser, so it may take a while before the consumer version gets the update. Once they do, however, they will be protected automatically. 

 

Mozilla is also protecting its users. In fact, they can go ahead and do a little tweaking to get the desired effect. You'll just have to type about:config in the address bar, agree to the warning Firefox displays and enter Punycode in the search box that shows up, as well as a line that reads network.IDN_show_punycode. This means that you will start seeing the proper Punycode addresses instead of the encoded versions. 

 

“In this vulnerability an anti-phishing mechanism wasn’t implemented properly in some web browsers, and like in many other cases, improper implementation renders the mechanism ineffective, in this case exposing users to phishing attacks that are hard to identify. In most of the cases these scenarios end with account takeover, where the attacker obtains control of the user’s account," said Itsik Mantin, Director of Security Research at security company Imperva. 

 

"In order to protect website users, forcing them to use strong passwords and to replace them frequently is insufficient, since in this case it would be completely ineffective to prevent the attack. Site administrators should assume that the credentials of some of their users were stolen (which in almost 100% of the cases will be true), and take adequate measures to identify account takeover, like irregular device, irregular geo-location or abnormal activity in the account.”

 

Source

[Batu69]

Topic merged.