IDN Homograph Attacks: More Steps, Same Deception

by Ian Briley

An IDN homograph attack is just the super ivory-tower way of saying typosquatting using characters not typically found in American English but look close to existing American English letters. For example, the Greek O, Latin O, and Cyrillic O are not assigned the same Unicode but look very similar.

This isn’t limited to look-alike characters across different typesets, you can use 1 or lower case l, O and 0 (zeros), etc. Sounds great for an attacker, right? In the example below I changed the i in ian to í.

 

So, let’s say we want to buy the look-alike ianscooldomain.cool, here is the kicker nowadays…

A lot of domain registrars have now started requiring you to select a language for a domain. You no longer can just choose look-alike characters from the Unicode dataset and plug and play. Failing to select the correct language that would have all the expected characters would lead to the issue below and the registrar won’t allow you to create the domain.

This can limit what characters you realistically have access to, but this doesn’t close the door completely. So realistically we just need to choose a language that has access to all the desired characters in our fake domain. For example, for íanscooldomain.cool I’d just need to choose Spanish because all the Unicode characters in that domain appear in a Spanish character set.

If I wanted something more exotic, I could use an Eastern European language such as Polish. Polish has a mixture of Latin and “modified” Latin characters such as “a, ą, e, ę, i, o, ó, u, ą, ę” so if I wanted to register https://www.rędsiege.com/ I’d simply use a language that uses the ę (along with the standard Latin character set). The extra fun thing with this is based on how the browser, word processor, or instant messenger, displays the link, the tail on the ę can get “lost” as shown below. Someone quickly glancing at the link might never really notice that’s not a typical Latin e.

So, when you register a domain, why does it look weird? This, my good friend, is Punycode. The big thing to take away is that Punycode is just a means of taking Unicode characters and converting them to ASCII.

This is the only time you need to be careful and understand your intended target environment or application. Depending on the application it may or may not show the end user the Punycode encoding. For example, if I put this link into a Microsoft Word document and a user hovers over the link, they’ll see the Punycode. That’ll probably raise some red flags and kill your engagement rate.

But on Slack, not so much. Which then you’d obviously go the extra step and insert a link into a normal looking domain using our specially crafted domain. This could be nefariously hard for some users to detect.

So how do we defend ourselves against this?

The answer that everyone hates: it depends.

Good news: All the old wisdom still holds true, it’ll just depend on your application and your organization’s general use case for special characters.

Obviously user training is always an option but for more technical means, you can force most major browsers to show users Punycode if it’s detected.

Let’s say your organization almost never deals with any individuals that use Cyrillic letters, you could have an email rule that just drops emails that contain these letters.

You can set up regexes to watch DNS registration for your domain looking for common swap-outs such as i and í. If you want to get real paranoid you could even extend it to detect swap-outs such as B and β.

At the end of the day, just because people are starting to crack down on an abuse vector doesn’t mean you should drop your defenses against it. If there’s a will, there will almost always be a way!

---

About Ian Briley, Security Consultant

Ian Briley has over 10 years of experience in information security consisting of The United States Armed Forces, the Healthcare industry, Security Operation Centers, and Security Consulting. Ian is an experienced presenter, trainer, developer, maker, and researcher. Ian enjoys attending local security focused groups and learning more about cloud-based environments and solutions

Certifications:
CRTO, GWAPT, eJPT, CySA+, SSCP, SEC+