Phishing with an Apple as bait

The Apple approach is to make technology as easy to use as possible. Consequently, technical details are pushed into the background to the greatest possible extent. This is also the reason why in many Apple products all IDN domains were visibly displayed to the user; an option to change this behaviour does not exist.

Hier geht’s zur deutschen Version.

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:

Character Unicode Name
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
xn--t-26l.com tᴏ.com to.com
xn--mx-igb.net ɡmx.net gmx.net
xn--lie-t6x.com liᴠe.com live.com

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.

Noteworthy here are two documents from the Unicode Technical Standard: number #39 UNICODE SECURITY MECHANISMS and #36 UNICODE SECURITY CONSIDERATIONS.

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.

References: Apple iOS 11 and Safari 11

3 Kommentare

    1. Hallo,

      I do not think your concept is a problem, because using U+2013 as a replacement for HYPHEN-MINUS is not allowed with most registries.

      Having a look on IANA’s collection of „IDN tables“, which represent permitted code points (letters) allowed for Internationalised Domain Name registrations, do not list U+2010 to U+2015 anywhere.
      Other MINUS-lookalikes like U+3127 from Bopomofo, U+174d from Buhid or U+2cbb from Coptic are not allowed to be mixed with latin characters.

      But in general I agree with you, IDN is like Pandora’s box.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

CAPTCHA *