This post was written by Adam Wosotowsky.
This past week, a new web-based phishing scam has emerged that manages to sneakily impersonate legitimate URLs. You heard correctly – this cyberthreat manages to appear to as a secure, trusted website, one such example being apple.com. The deceiving type of attack can be classified as a homograph attack, and it’s extremely challenging to detect.
How We Got Here
This misdirection attack, while not new, is an excellent demonstration of the secondary problems associated with internationalization and support for a unified multi-language architecture across core internet protocols. Many core internet services operate on a strictly limited character set called ASCII, which was developed nearly 60 years ago at the birth of interconnected computers or, in this case, automated telegraph machines. Today, it is basically the available characters on a modern English keyboard.
Over time, programmers developed new character sets to allow users from all over the world to read/write in their native languages. This development increased access for users everywhere, but required supporting long lists of different character sets to display each language correctly. To manage this, they developed a new character set named Unicode, which unified all character sets under one flexible standard.
The core services and protocols that run the internet, including DNS (hostname resolution) and SMTP headers (email), process ASCII content at their cores. This maintains functional backward compatibility with new protocol standards on legacy installs as well as facilitates code security by limiting the scope of legitimate inputs. To bridge the gap between Unicode and ASCII, an ASCII encoding of Unicode called “Punycode” was developed. Punycode allows a full array of characters from other languages to be displayed in an email’s “From” and “Subject” headers and for domain names to be displayed by your browser as their intended character set, even though the domain name from the DNS perspective is plain ASCII.
How the Attack Works
The mechanism for the lookalike domain attack uses a Punycode-encoded domain with foreign letters that look just like English letters so that your browser interprets the domain to be visually identical to the domain you are expecting. As seen in this example from Xudong Zheng, this was “apple” using five encoded letters, which allows a domain to completely look like “apple.com” in the content, in the mouseover, and in the browser window—even though the domain itself is actually https://www.xn--80ak6aa92e.com. With the addition of a trusted website certificate to authenticate https://www.xn--80ak6aa92e.com, someone browsing to the site would even see a valid padlock. Keep in mind that your browser knows and works with the ASCII domain name, so it just shows you the translation.
The danger of this type of misdirection is obvious: a phishing email or link in a forum or social network could send unsuspecting victims to a malicious website that could attempt to steal your identity by asking for credentials or push malware through a drive-by download.
There would be little or no warning for the average user who runs a fully featured browser. What’s more– this problem is going to be even worse on tablets or cellphones where you don’t have a mouseover and you just click things by touching them. It’s realistic to expect to see this technique used in the “Android security update” scam, where legitimate affiliate advertising networks are used to push apocalyptic warnings about infection unless you install this “security update” and infect yourself.
Mitigating the Risk
Our advice: NEVER install an app from anywhere outside of your official vendor supplied app store. Also, much like having anti-virus and keeping it up-to-date, practice good security habits, like using a web filter plugin on your browser.
Also, while this attack does seem dangerous, there are a few things that are working against it and can prevent the technique from seeing a mass adoption in the wild:
- With the media attention, browsers are looking for a middle-ground to make users more aware of the actual ASCII domain name, in addition to the Punycode interpreted version. How this works itself into cellphone browsing with its high cost of screen real estate remains to be seen.
- This technique requires the purposeful registration of a malicious domain (as opposed to a compromised domain). And there are many pro-spamming organizations actively work against internet security by supporting anonymous domain registration—often preventing the culprit from being positively identified and prosecuted without enormous international cooperation and effort. However, there is often a pattern to purposely registered abusive domains that can be used to aggressively block them once seen. There are certainly many phishing/malware groups that rely on purposely registered domains, but many of the most effective campaigns use compromised domains knowing they will be blocked quickly (by anti-abuse researchers) and tossed away.
- The domain is still a domain, and domain reputation components of web filters and email scanners work effectively on many phishing attacks. Those tools still apply and are not hampered by odd looking domain names.