<--

Revised Homograph Attacks - Part 3

By Tzachy Horesh (@tzachyh)
February 28, 2021

*

Preface

In the previous parts we covered email homograph attacks and bypassed browser’s IDN policy.

In this post we’ll talk about IM Homograph attacks, their current state, and bypass (most of the) restrictions that were put in place if any.

Originally, we only tested a few IM clients and found them to be vulnerable, but didn’t continue the research further. Then, thanks to Julio Cesar Fort’s post, we decided to expand the research and checked more IM clients.

A while back, we contacted most of the vendors with the issues found and reported our findings. A few months passed and finally we got back to this research and on the way, we added a few more applications to our check list. For the reported applications, some implemented mitigations by now, and some didn’t, as you’ll be able to see.

Intro

In the previous posts, we covered Homograph attacks from the basics up to the very technical level. To catch up, you can read the previous blogposts, part1 and part2.

If you have read the other posts, click here to skip this section, as it is the same intro to Homograph attacks.

If not, you might want to read this intro.

So what exactly is a Homograph attack?

From Wikipedia:

The internationalized domain name (IDN) homograph attack is a way a malicious party may deceive computer users about what remote system they are communicating with, by exploiting the fact that many different characters look alike.

This is the best known, most prevalent form of attack (2019) for this attack surface. Another example of homograph abuse is plagiarism, where the attacker replaces characters with seemingly identical ones, but with a different Unicode value - thus fooling automated checkers and passing the work off as original.

Over time, several mitigations were developed, the best-known of which is presenting the user the domain in its Punycode form. In short, Punycode transforms a Unicode string into an ASCII string, so “wikipedia.org” with a Cyrillic “e” will be displayed as “xn–wikipdia-g8g.org”.

Let’s look at the previous blogpost example, can you tell which character is different?

Upon closer look, we can easily see that the last h is not the same.

The characters that can be confused with one another are called “confusables”, and for every character, there is a list of confusables (which may be empty).

Many of them look almost the same, enough to fool even a security-aware user.

However, all of these characters are different and have different code points:

“հ” (U+0570) (Armenian Small Letter Ho)

“h” (U+0068) (Latin Small Letter H – the “h” that we regularly use)

“һ” (U+04BB) (Cyrillic Small Letter Shha)

“Ꮒ” (U+13C2) (Cherokee Letter Ni)

The reason we see them as different in other contexts, like in this blog post, versus the URL bar of the browser or an application, is the fact that different applications use different fonts and implementation of these fonts to show those characters.

Now that we have a basic understanding of this attack vector, let’s look at various IM applications.

IM Tested Application

We examined 24 applications - mainly across Android and iOS, but also in web and Windows clients, where available.

Of these, only Discord, Signal, TikTok and Twitch were found to be not vulnerable. Discord presents all links in their Punycode form. Signal fixed some issues it had in CVE-2019-9970. Tiktok doesn’t allow links at all and displays anything as plain text. Twitch displays text on mobile platforms, while in the Web and Windows clients, it displays broken links for non-full ASCII links.

The applications were tested against a few URLs, 11 of which were chosen to be presented here as they highlight various problems in the applications. Other than https://www.facebookmail.com, all the domains are in the top 5K domains in Chromium. This is indicative of their popularity, and thus should be more prone to phishing attacks. As a result, mitigations against these attacks should be in place in various IM applications.

Research Method

We tested single script, mixed script, and whole script links, with all but one link taken from domains.list. The only link that wasn’t taken from that list used a character from one of the other links, in order to see whether there was any reliance on this list (domains.list) or similar, popularity-wise.

  • https://www.rottentomatœs.com
  • https://www.faceþookmail.com
  • https://www.faϲebook.com
  • https://օքքօ.com
  • https://օէէօ.de
  • https://www.googlẹ.com/
  • https://www.gṃail.com/
  • https://www.youtuþe.com
  • https://www.аррӏе.com/
  • https://www.ɡᵯɑıǀ.com
  • https://www.ßooking.com

Platforms Tested

We tested the Android, iOS, web and Windows clients (when available). Although some had Mac and Linux clients, we felt the results of testing the above clients uncover the design flaws the applications had, and we estimate they will persist on the other clients as well.

General Observations

We observed a few ways the applications displayed the link and categorized them in the following way:

  • Link - The application displayed the link to the phishing domain in Unicode, and all the users had to do was press the link to get to that domain. This was marked in red in our matrices, as users might easily be fooled to click such links.
  • Broken link - The application shows broken links - i.e, the links are being displayed in Unicode, but are cut-off (usually, at the first occurrence of a non-ASCII character). This was marked yellow, as it might cause users to copy and paste the link, as it looks like (and actually is) a bug in the application.
  • Warning - The application shows a warning that alerts the user about clicking the link, or informs the user that the link is suspicious. This was marked either yellow or green, depending on the kind of warning.
  • Text - The application shows the link as plaintext, that isn’t clickable. This was marked green, as users won’t be able to click such links.
  • Punycode - The application shows the link in its Punycode form. This was also marked green, as it’s highly unlikely that users will click such links.
  • ßooking.com - This link can be displayed in 3 ways: in its Unicode form, in its comparable version “ssooking.com” (“ß” in German is actually “ss”), and in its Punycode form “xn–ooking-9sa.com”. This was mainly to detect which mechanisms an application uses when displaying characters like these as some display this class of characters as is.

Results

Let’s look at how IM clients behaved, and, in some cases, implemented weak mitigations.

Facebook Whatsapp

Whatsapp implemented warnings that alert users about using suspicious links. However, this can be bypassed in various ways. Upon clicking the suspicious link, the user is prompted to take a good look at the link to decide whether to follow it. But the link is presented in its Unicode form (as opposed to Punycode), which makes it really hard for most users to detect whether it is a phishing attempt or not. Moreover, a bit of inconsistency was found between the iOS version and the other platforms: the iOS version warns the user when clicking the link “https://www.ɡᵯɑıǀ.com”, whereas the versions for other platforms do not. Also, although WhatsApp displays a snippet of the link that contains a Punycode form of the link, the sender can decide to eliminate the snippet and present only the link in its Unicode form. This mitigates a security feature that WhatsApp could have had.

We can see (from left to right) the Android, iOS, web, and Windows clients here.

Versions checked:

  • iOS 2.20.92
  • Android 2.20.198.15
  • Windows 2.2035.14

Facebook Instagram

Instagram didn’t seem to implement any protections against using suspicious links on any platform.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 157.0
  • Android 157.0.0.37.120

Facebook Messenger

Facebook Messenger displays the Unicode link to the user, alongside the title and the Punycode form of the link at the bottom of the message. This is only done if there is a successful connection to the domain to fetch the title, etc. Otherwise, just the link is displayed. The full display of the above components might be reasonable when only the link, title and the Punycode form of the link are being displayed, but can be less effective when a snippet of the site is also attached as part of the link message, as can be seen below in the Android version. Here, the iOS version was tested on iPhone 5s which has a relatively small screen, so the link didn’t have the paragraph shown in the Android version. In the web version, a small window is being opened, and so the UI looks about the same as in the iPhone version, that is, with no large messages.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 280.0
  • Android 280.0.0.16.110

Google Messages

Google Messages behaves a bit differently on different phones. This means that every phone might need to be checked for vulnerabilities on its own. We checked 3 this app on 3 phones: Google Pixel 2, and 2 other Android phones. The app behaved similarly on the last 2, but different on the Pixel 2. We found out that Google’s SMS messages try to block suspicious links, but fail to do so in various circumstances. In case a suspicious link is identified, it’ll be displayed as plaintext, with no link available. When a live link is available on Pixel 2, it might display (based on some internal logic) a small snippet of the site with the title and the link in some form, and the link inside the snippet can be displayed either in its Unicode form or its Punycode form. There’s also a web client for this application, which behaves differently: most links are broken, and 2 of the links in the Android version are displayed as text.

We can see (from left to right) the web and the Android clients for the Pixel 2 and the other Android phones here.

Version checked:

  • Android 6.4.044

Google Hangouts

Google Hangouts doesn’t seem to implement any security mechanisms and displays any link in its Unicode form.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 35.2
  • Android 35.0.327050771

Google Meet

Google Meet implemented some security mechanisms that, in various cases, display a suspicious link as plaintext in the iOS and web versions. In the web version, however, due to an implementation flaw, many non-ASCII links are displayed as broken links, apparently due to a lack of proper support for Unicode characters.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 45.0.0
  • Android 44.5.324814572

Goto Meeting

Goto Meeting mostly displays links in Unicode on all platforms. However, on the iOS and web platforms there were a few links (different for each platform) that were displayed as plaintext, which means there is some security mechanism in place, although it needs to be improved as it can be bypassed easily even on the above platforms.

We can see (from left to right) the Android, web, Windows, and iOS clients here.

Versions checked:

  • iOS 7.10.1
  • Android 4.4.0.5
  • Windows 10.12.0 Build 18425

iMessage

In Apple’s SMS messaging app, some links were displayed as plaintext, but mostly the links were displayed in Unicode. The ßooking.com link was displayed as ssooking.com, so it seems there was some effort to mitigate phishing attempts, but still a lot of work needs to be done to eliminate most of this attack vector.

We can see the iOS client here.

Versions checked:

  • iOS 12.4 (OS version)

Microsoft Skype

Skype developers had put much work into security mitigations against phishing attacks. This can be seen in the 1st matrix below, as links are mostly displayed in Punycode, other than two links that were displayed in Unicode in the web client, and as plaintext in the mobile apps. This, however, has two big caveats: The Skype for Business for the Windows platform displays any link as is, which means that businesses that use Skype are vulnerable to phishing attacks. The 2nd and bigger issue was discovered when sending the links from the web client. The 1st matrix holds true when sending links from any client other than the web client. When sending the links from the web client, all the links (other than 2 links in the mobile clients) were displayed as is, which means phishing can occur to any Skype user.

Skype - when sending links with any client but the web client: Skype - When sending links from the web client to any other client:

We can see (from left to right) the Android, web, Windows, Skype For Business (Windows), and iOS clients here (When sent from the web client).

Versions checked:

  • iOS 8.64
  • Android 8.61.0.96
  • Windows 8.64.0.80
  • Skype For Business (Windows) (Lync) Part of Office 2016

Microsoft Teams

Microsoft Teams didn’t seem to implement any security features in any of its Android, iOS, or web versions, as all the links tested were displayed in their Unicode form.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 2.0.20
  • Android 1416/1.0.0.2020081801
  • Windows 1.3.00.21759 (64-bit)

Slack

Slack implemented some defense mechanisms against phishing attacks, that unfortunately behave differently across the various platforms. In the web and Windows clients, a few links were displayed as text only. None of the links on these clients display an alert when clicked upon. In all of the clients, links are displayed in Punycode/Unicode form when hovered upon, according to some internal logic - some of our tested links displayed in Unicode and others in Punycode. In the Android and iOS clients, some links warn the user when clicked upon, with the link displayed in both Unicode and Punycode form. It would be great if both mobile clients behaved the same and displayed warnings for the same links. However, it seems like the Android and iOS clients treat the links as 2 disjoint sets when deciding whether to warn the user, as can be seen below. There are also bugs in parsing the links in the mobile apps, which make some of the links unreachable through Slack, and these links will only show in their Unicode form in the warning message (the link will be seen as https:// or http:// in the warning, and will lead nowhere). This could lead users to copy and paste the links and avoid the security mechanism altogether. Moreover, like the Skype application, the link will be shown differently when being sent from the web/Windows client compared to mobile clients. When sent from mobile clients, the links will be shown in their Unicode form. When sent from the web/Windows clients, the links can either be displayed as Unicode, Punycode, or even changed to https:// (or http://).

We can see (from left to right) the Android, web, Windows, and iOS clients along with some alerts here.

Versions checked:

  • iOS 20.08.30
  • Android 20.08.30.0
  • Windows Production 4.3.4 64-bit 7fda658-s@1600362358

Snapchat

Here we saw 2 kinds of snippets, the “regular” one which we described above, and another one in which the snippet displayed even the upper link in Punycode form. To differentiate, we called this Punycode+ in our matrix. We saw that the iOS version showed all of the links in Punycode, whereas the Android version showed a few links in Unicode.

We can see (from left to right) the Android and the iOS clients here.

Versions checked:

  • iOS 11.0.2.67
  • Android 11.0.1.72

Telegram

Following CVE-2019-10044, Telegram implemented some security mechanisms which alert the user when clicking a suspicious link. On all of the clients, the links display in Unicode, but when clicking the link, an alert with the link will pop for links that aren’t composed entirely of ASCII characters. However, this mechanism behaves differently on the various clients. The web client will just direct the user to the site. On the Android version, a Punycode form of the link will be displayed. On the iOS version on the other hand, the Unicode characters (which are not in the ASCII range) are URL encoded. This can confuse users, who might think the application’s UI isn’t working properly. On the Windows client, the alert depends on the link. Sometimes it’ll display Punycode, and sometimes it’ll display http://https//domain where the domain is the original domain in Unicode. The http://https:// part will be added regardless if http/https scheme had been added to the domain or not. This also seems to be a bug that might cause users to click on the link, click the screenshot to see it for yourself.

We can see (from left to right) the Android, web, Windows, and iOS clients along with some alerts here.

Versions checked:

  • iOS 7.0.1
  • Android 7.0.1
  • Windows 2.3.1

Twitter

Twitter seems to do a decent job in blocking some of the suspicious links, and displaying others as text. However, two issue were observed: The 1st one was with broken links, which may cause the user to think that the application is defective, and copy the link entirely. The 2nd one is with processing links that are composed of whole script confusables. Here, Twitter displayed text for known links (https://www.аррӏе.com/), but failed when scripts other than Cyrillic were used and displayed a seemingly innocent link in those cases.

We can see (from left to right) the Android, web, and iOS clients here.

Versions checked:

  • iOS 8.36
  • Android 8.60.0-release.00

Viber

Viber didn’t seem to implement any security features in any of the Android, iOS, or Web versions, as all the links tested were displayed in their Unicode form.

We can see (from left to right) the Android, Windows, and iOS clients here.

Versions checked:

  • iOS 13.7.0
  • Android 13.7.0.6
  • Windows 13.7.0

Wickr Me

Wickr Me seems to implement some security features, but as can be seen below, most (if not all) were implemented in the iOS version only, which displays plaintext only for links that were considered suspicious. For all of the clients, all the links were displayed in Unicode. The Windows client didn’t allow clicking on some of the links, but didn’t give any indication as to why. This also can cause users to copy and paste the links and get phished. On the Android version, every link tested displayed in its Unicode form and could be clicked upon.

We can see (from left to right) the Android, Windows, and iOS clients here.

Versions checked:

  • iOS 5.62.6
  • Android 5.60.3
  • Windows 5.62.8 build 1

Wire

Wire has implemented some mitigations, but not on all platforms. The Android version displayed all the links in their Unicode form, whereas the other clients showed some links in Punycode form, and others in Unicode. Most protected was the iOS client, which displayed links in Punycode (the same links as in the web client) and showed some other links as plaintext, although it was bypassed as well, as can be seen in the list. The Windows client had some links presented in Unicode, but without the ability to click on them. As in other applications tested, this could cause users to copy and paste the link instead of ignoring it.

We can see (from left to right) the Android, web, Windows, and iOS clients here.

Versions checked:

  • iOS 3.64
  • Android 3.53.935
  • Windows 3.19.3731

Zoom

The Android and Windows clients of Zoom don’t seem to handle Unicode links correctly and display broken links. This doesn’t seem like a security feature, but more of Unicode incompatibility. In the iOS version, most of the links are displayed in Unicode correctly (and thus can be used to phish users). Some security mitigations were in place in the iOS version, though, as some of the links were displayed as plaintext. In the web client, every link is displayed as plaintext, even legitimate ones. This can cause users to copy and paste the links and, again, fall for phishing attempts. Unlike TitTok, where the chat does the same thing by displaying any link as text, Zoom is much more oriented towards business and learning, which means links sent via its chat are much more likely to get users phished.

We can see (from left to right) the Android, web, Windows, and iOS clients here.

Versions checked:

  • iOS 5.2.2
  • Android 5.2.45092.0831
  • Windows 5.0.2 (24046.0510)

Samsung SMS Messages

Samsung SMS Messages displays any link in Unicode, making it easy to manipulate users into clicking those links.

We can see the Android client here.

Versions checked:

  • Android 11.5.10.211

OnePlus SMS Messaging

The OnePlus SMS messaging app behaves differently when clicking on links and when double-clicking on them. At first, it shows Unicode links as either broken or as plaintext. In both cases, clicking the link will not open the full URL. However, when double-clicking on a link, a screen that presents just the URL in Unicode form appears. Clicking on this link will get the user to the requested site. Because of this, OnePlus users might inadvertently double click on links and get to the phishing domain (after another click, admittedly).

We can see the Android client here.

Versions checked:

  • Android 5.0.0.200316152604.b555a2b

Acknowledgments

The research was inspired originally by the work of Xudong Zheng and continued thanks to Julio Cesar Fort.

While reviewing the literature on this topic, we found a few other papers:

Adrian Crenshaw - Out of Character: Use of Punycode and Homoglyph Attacks to Obfuscate URLs for Phishing

The Tarquin - Weaponizing Unicode Homographs Beyond IDNs

And later in the research process we’ve discovered:

Deep Confusables - Improving Unicode Encoding Attacks with Deep Learning by Miguel Hernández (G@MiguelHzBz), José Ignacio Escribano (I@jiep) and Dr. Alfonso Muñoz (G@mindcrypt)