Phishing with an Apple as bait
As already described in the articles „Die Geschichte des ᴏ“ and „Wie ich zum Opfer wurde“, it is possible to dupe an experienced security and awareness expert with the help of internationalised domains. This is because the software on the handheld device does not give him a means to distinguish between an ᴏ and an o.
I have redacted part of these findings and reported them to Apple as a security issue. During the course of the release of iOS 11, the security risks have now been mitigated. In this post, I would like to take another in-depth look at the risk and impacts, and evaluate the modifications that Apple have now made.
The risk from Small Capital Letters
Within the framework of the rule code for .com and .net domains, there are still some particularly dangerous characters that can be used for homoglyph attacks despite all the rules that are already in place:
The extremely inconspicuous group of Small Capital Letters. These always become a problem if the lowercase letter is a miniature version of the capital letter.
The phishing potential of domains containing these characters is huge: identities can be simulated that are confusingly similar to the target domain.
Small Capital Letters
These are the characters that represent a problem. Depending on the browser and character set that are being used, the difference compared to the normal letters in this representation can no longer be detected:
|ᴄ||U+1D04||LATIN LETTER SMALL CAPITAL C|
|ᴏ||U+1D0F||LATIN LETTER SMALL CAPITAL O|
|ꜱ||U+A731||LATIN LETTER SMALL CAPITAL S|
|ᴜ||U+1D1C||LATIN LETTER SMALL CAPITAL U|
|ᴠ||U+1D20||LATIN LETTER SMALL CAPITAL V|
|ᴡ||U+1D21||LATIN LETTER SMALL CAPITAL W|
|ᴢ||U+1D22||LATIN LETTER SMALL CAPITAL Z|
|ɡ||U+0261||LATIN SMALL LETTER SCRIPT G|
Strictly speaking, the ɡ at the end of this list is from another part of the Unicode tables, but it has the same result: namely a letter that is very similar to the normal Latin alphabet. This ɡ has been known to be a risky character for a relatively long time, and is used as an example in this analysis to assess how to prevent homoglyph attacks.
Deceptively genuine looking domain names
We have registered several domains with the characters listed above, and we use them as examples in our awareness projects.
Here are a couple of domains that represent a risk of optical collisions:
|xn notation||Unicode Domain||Risk of confusion|
The risk with regard to these domains arises from how they are rendered in the clients.
In the technical representation xn--, the domains are totally harmless. The domain is more or less unreadable for people. In the Unicode representation, depending on the local typeface there is only a very minor variation between the special characters, or they can only be distinguished in a direct comparison. You can also do the first test by looking at the table: Can I tell the difference between the letters in the text on my device?
How does my software behave?
To check out how the URLs are rendered in your browser, you can use this link: http://cᴄ.oᴏ.sꜱ.uᴜ.vᴠ.wᴡ.zᴢ.mailgw.de/
Very different effects can be seen here depending on the device and software.
The latest operating systems and applications are usually able to render IDN domains as Unicode characters. The other way round, the acceptance of Unicode characters and the corresponding translation for the technical notation for executing requests, also usually works as a rule.
As ever since their introduction IDN domains have repeatedly attracted negative attention on account of character similarities or collisions, rules and recommendations have been adopted not only for domain registrars, but also for programmers and certain kinds of applications.
Where can these domains show up?
The use of these domain names in URLs is possible practically everywhere.
Either as the sender in emails, but also as a link or download target address in email content, and likewise in all web pages as targets or links.
These are also the primary attack mechanisms for phishing, namely confusingly similar email and web addresses. Consequently, the targets of such attacks are email clients and web browsers.
On pre-iOS 11 Apple iPhones and iPads, all characters, including the critical homoglyphs, are rendered in the Safari browser as Unicode characters:
A small detail as an aside: The small capital ꜱ wasn’t even included in the character set and was replaced by a placeholder.
Since iOS 11, URLs with these domain names are only rendered in the xn notation:
From an optical point of view, harmless IDN domains such as http://belwü.de/ are still rendered in Unicode. Apple thus implements the rules as do Google and Microsoft for the most part, whereby these browser makers, and Firefox as well for instance, still provide configuration options for forcing total disabling of Unicode rendering.
All in all, Apple has now also drawn level with the software on its devices to give users the chance to differentiate between IDN domains with homoglyphs and those with normal characters. Irrespective of this, it remains to say that surprises will always spring up where Unicode domains are concerned.
Initial further tests have shown that especially webmailers, be they professional services or free software for private use, are also vulnerable for senders and links in content with IDN domains.