Homograph Attack Using Unicode
Introduction
This attack consist of tricking the user with a domain that look legit, like goog1e.com. It’s old and basically everyone has heard about it “Be careful on what you click…” and such recommendations, even my parents are aware of it. A new way of using this technique has emerged : Homograph attacks based on encoding.
New… and old
Using Punycode, it’s easy to register xn–pple-43d.com which correspond to apple.com. End user will not be able to see the difference between the two, and will believe they are going to the legitimate Apple Website. You can have fun with this tool for example if you want to test this. This technique is well suited for phishing, as well as credit card skimming.
Ascii Characters
This attack is due to the font used by web browsers, where different ASCII characters will have the same font assigned. Can you see the difference between ‘р’ and ‘p’ ? I guess no, the first one is the Cyrillic Small Letter Er, and the second a regular ‘p’.
Non Ascii Characters
The trouble doesn’t end here. As you can use ASCII characters, you can also use non Ascii characters. This can take the form of https://apple.com∕freeIphone12.com .
Can you guess where the non ASCII characters is ?
Yeah, this is the ‘∕’ after the apple.com. Turns out this is a mathematical operator, not a slash.
Mitigation
This attack targets the web browsers, and some took care of it. I wasn’t able to use this technique on Chrome (up to date) and Microsoft Edge. But in Firefox it worked just fine.
Chrome warning
Edge not working
Firefox OK
You can read more about Chrome IDN policiy here
Firefox stated that’s a domain registrars issue, not them here
Our IDN threat model specifically excludes whole-script homographs, because they can’t be detected programmatically and our “TLD whitelist” approach didn’t scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.
But you can add protection by setting network.IDN_show_punycode to true inabout:config.
I think there is also a way to monitor and have alerts on this issue by using a regex in your SIEM (If you got the URI in your logs of course) : ^https?:\/\/(.*)xn--(.*). This should cover every possible ways of I am aware of.