Phear of Phishing

I knew that an aquaintance of mine, Oliver Paukstadt, had been in contact w/ Apple about something related to IDN. Up until recently I was unaware of the exact details but I feared that due to his actions the last vendor I know off would stop rendering my emoji domain as unicode but would also go ahead and display punycode instead.

Luckily I dodged that bullet ;-)

But I wondered what’s it all about CVE-2017-7106. The gist seems to be about unicode confusables as he is keen to demonstrate over at Thinking Objects’ blog. While I can see where he is coming from (just visit to.com and his demo tᴏ.com from an iOS10 device) but I still am not convinced that this is solving any real issue. Just to be clear, this is not meant to belittle any of his work.

Just stick with me and have a look at the following two address bars in iOS11:

The first image shows a supposedly correct punycode notation, the second displays something that is looking like punycode but then again it’s not. The first dash is actually the unicode glyph for the En dash. Even worse, if you quickly type two normal dashes on iOS11 they are automatically replaced by the En dash. So I wonder how many people would not only miss that one but actively fall into this trap. And if I would be out spear phishing one victim is all it takes.

Yes, this wouldn’t be a viable phishing campaign as other browsers like e.g. firefox are transliterating xn–t-26l.com into xn--xn-t-26l-tn3d.com but don’t feel too safe already.

Let’s say iOS11 would also transliterate the above example into punycode thus obviously showing that something is very phishy. But imagine all the non English folks that would like to use their language naturally without the need to convert anything to 7-bit ASCII. They’d be trained to see punycode everywhere and so we open the door for an old attack: typosquatting.

I don’t think a lot of people would spot the difference between xn--t-26l.com and …