IDN homograph attacks belong to the #phishing strategies. Usually the bait emails include a spoofed (homograph) internationalized domain name (IDN). Creating such IDNs is based upon the identical appearance of different logical #characters. Also known as script #spoofing, the hacking technique uses different characters for the fake URL, yet this is visually undetectable and thus the unaware target of the attack cannot spot the duplicate. Two characters may be used to impersonate one different character, capital letters replace small caps, or different alphabets are exploited based on similar characters.
Examples of IDN homograph attacks:
In 2005 a spoofed PayPal site lured scam victims.
In 2015 a security consultant experimentally deployed a spoofing attack on Lloyds Bank Domain. Instead of using “l” for the IDN’s first letter, Paul Moore used capital “i”. The difference remained unobserved at browser level and the spoofed site even tested better than the original with Qualy’s SSL Server Test.
Similar to these is also the recent Skype spoof messaging attack. The hackers impersonated real contacts from the targets’ Skype contact list and sent a message containing an infected link, even when the real account owners were not logged in. This is an example of ID spoofing. There also exists E-mail address, GPS, IP and ARP (Address Resolution Protocol), or referrer (Ref-tar) spoofing.
IDN spoofing details:
We have established that homograph attacks use the fact that on the Internet URLs may be created using characters from various alphabets.
Some of the stereotype-spoofing alphabets whose characters fit this kind of attack are the Cyrillic, the Greek, the Armenian or the Hebrew (more rare than the others, though) alphabets. The possibilities are much wider, depending of the attackers’ creativity and time invested in the exploit.
The simpler (older versions) of homograph attacks used fake URLs – with simple ASCII alphanumeric characters. Zero stands for the letter “o”, for example.
Since 2003 non-English characters were made available in creating URLs, therefore non-ASCII URLs appeared. The non-ASCII addresses are translated into Punycode, represented by the “xn” prefix to the domain name. These are the internationalized #domain names or IDNs, per se. The producers can choose the Unicode address display, or the Punycode display (when not all the characters involved belong to the same language set). Unicode supports around 100 thousands characters and attackers can exploit similar looking characters in various combinations.
The only protective layer against suck attacks might manifest at the browser level, but so far the web browser vendors could not prevent this types of exploits.
Preventing homograph attacks:
• A circumspect attitude towards links included in emails or other types of messages is beneficial;
• Unknown URLs may be malicious, so stick with the links and pages you know to be safe; when banking and noticing changes, telephonically confirming them with your account administrator would be recommended;
• Choose a browser that tries to minimize such risks. For example, Google Chrome displays an IDN-only version if all the characters belong to the same language set;
• Check for characters like %00, %01, @ in the full URL version – these are most commonly found in spoofed IDNs;
• Try to use cryptographic network protocols (against spoofing in general). Transport Layer Security (TLS), Secure Shell (SSH), HTTP Secure (HTTPS) serve as attack deterrents because they encrypt data before sending it and authenticate data when receiving it;
• Acquire a proper defense software (usually employed against DNS and ARP spoofing);
• Use packed filters that might block or filter out packets that show discrepancies.
Current status of homograph attacks:
A 2006 article coming from Vienna University of Technology presents several techniques of protection against URL manipulation. Categorizing the types of attacks, Viktor Kramer establishes a few requirements to be fulfilled in striving to defend users against fake domains.
The first line of defense consists of the domain registrars. These could require strict RFC compliance, an easy user interface, and methods of user alerting.
Such measures (the mentioned articles enumerated more, also detailing them) are to be combined with “usable client-side protection mechanisms”, in order to ensure a better protection for Internet users.
Nine years later and a lot more of sensitive data circulating over the World Wide Web, and the protection systems seem not to have evolved very far. The spoofing attacks continue to be a subcategory of phishing and the guidelines for avoiding the latter apply to spoofing.
The human reaction when confronted with a malicious email or other type of message continues to remain the key element in avoiding such scams. Practical precautions like directly contacting the email author, reading messages in plain text to avoid active script elements or supplementary authentication measures are some of the simpler ways of trying to stay safe.
In the business world, guarding your communications from such invasive attacks can be crucial. Sensitive data should remain confidential and circulate only between commercial partners. Messages should be controlled by their authors and protected so as not to transmit malicious content. It is a matter of trust, as well as one of good name to ensure secure communication channels.
