Win I am righting something four a blog, I make shore that I am using the write homophones. Eye cannot tell you enough how embarrassing it is win I use the wrong word.
For grammarians—who are really grammar pedants with a penchant for pointing out other folks’ grammatical faux pas—homographic mistakes are the ones most likely to set them off on an eloquently stated tirade. Homophones, if you recall (or have an elementary school-age child still in the house) are those pesky words that are spelled differently but sound the same. The most common of horrific homographic mistakes is to substitute “their” or “there” when you really meant “they’re.” Others abound; we don’t need to point them out, most folks know them when they see them.
Turns out that attacks based on this pervasive grammarian concept are a threat not only to the health and well-being of pedant grammarians, but to users everywhere. They’ve been dubbed “homograph attacks” and, like their language counterparts, they are not new, having first surfaced back in the early aughts, after which they slowly disappeared. They are, however, resurfacing with news that Chrome 57 and Firefox 52 are vulnerable to these attacks today, and they are an excellent mechanism for attackers to execute a phishing attack.
The attacks rely on the historical foundations of the Internet and its origins in the United States. The addressing schemes were designed only to handle English—and to be precise, only ASCII text. Obviously, this became problematic as the Internet expanded to other countries, whose citizens, to many Americans’ surprise, didn’t speak English or rely on ASCII text. As El Reg notes,1 an effort was undertaken by “largely American engineers to resolve this by assigning ASCII-based codes to specific symbols.” El Reg goes on to note that the problem with this approach crops up because some letters (such as a, B, C, i, I, O, and p) are different in other languages but look almost identical to English letters.
By stringing together those codes, you can craft a word that appears to spell out “apple” but doesn’t. It’s a hack, and a ubiquitous one at that. Using what’s called Punycode2 (RFC 34923)—an intermediary between ASCII and Unicode—to code a URI will trick people into thinking they’re visiting apple.com when, in reality, they’re being delivered into the hands of a crafty phisherman. Even hovering over the link won’t give any indication that the link is illegitimate.
Aha, you might be thinking. But, if the link is fake, it won’t be secure, and thus the threat can be easily avoided. Not so, my friend. Wordfence4 has a great blog on this subject (including test domains) and they note, “We even managed to get an SSL certificate for our demonstration attack domain from LetsEncrypt.5 Getting the SSL certificate took us 5 minutes and it was free.” The cost of entry into the phishing tournament has been greatly reduced, thanks to the ability to obtain SSL certs easily and quickly. Secure HTTP is no longer a distinguishing factor when trying to sort out cloned sites from the real thing.
This problem has been exacerbated by the growth of IDNs (Internationalized Domain Names). Symantec, back in 2011, explained that “IDNs allow domain names to include Arabic, Chinese, Russian, Latin (with diacritics), and many other characters….”6 ICANN, who oversees IDNs, is concerned about the abuse but, at the same time, reluctant to place restrictions that might negatively impact the use and availability of IDNs. It remains a problem with little impetus to solve today. After all, as of 2012, over 70 percent of the world's Internet users were non-English speakers, which makes IDNs important to the Internet. The aforementioned Register article on the topic provides a comprehensive overview of what (little) effort has gone into finding a resolution.
Obviously, the concern for C-level executives is in the exploitation of something over which they have little control—inbound email and the itchy mouse fingers that click on links that appear (and sometimes don’t appear) legitimate. There are a couple of options to address the potential of employees falling victim to a homograph attack. These options primarily rely on the seriousness with which employees embrace and follow security policies. And although we know from the 2017 State of Application Delivery report7 that that seriousness—or lack of it—is one of the top security challenges cited by organizations, still, it’s all we currently have.
First is the use of browser settings to restrict IDNs, which may or may not be a workable solution for many organizations. If you have the luxury of restricting them and happen to have control over the desktop browsers used by employees, you could force a change to the configuration that will highlight the problem by ensuring internationalized domains are displayed in the address bar rather than the deceitfully interpreted ones. If you or your organization rely on Chrome, Google is rolling out a new version in response to the threat, so updating to Chrome 59 would be a good place to start. As noted by pretty much everyone, Internet Explorer and Safari browsers are not impacted.
One potential response that is under your control is your defensive domain purchasing strategy. Many phishing schemes rely on purchasing domains that closely resemble that of the targeted domain. This includes buying up Top Level Domains (TLDs) that organizations have deliberately—or inadvertently—overlooked that could be used in nefarious phishing schemes. Even if you’ve snatched up the domains most likely to be exploited by attackers, new TLDs are being released which will also have IDN expansions. It’s a sure bet that there will be an increasing net you’ll have to throw out to keep those pesky attackers at bay.
A potential change to your strategy that won’t necessarily break the bank is to consider acquiring those IDNs that, when translated to Punycode, map to your domain. That would prevent attackers from using them for phishing (or other illegitimate) uses. While it won’t provide SEO value, it will keep the risk of mimicry in the service of scams from having a deleterious impact on your brand.
MODIFIED: Jul 24, 2017