URL rendering trick enabled WhatsApp, Signal, iMessage phishing
A rendering technique affecting the world’s major messaging and messaging platforms, including Instagram, iMessage, WhatsApp, Signal, and Facebook Messenger, has allowed threat actors to create legitimate-looking phishing messages for the past three years.
Vulnerabilities render bugs causing incorrect display of application interface URLs with injected RTLO (right-to-left override) Unicode control characters, making the user vulnerable to URI spoofing attacks.
When injecting an RTLO character into a string, a browser or messaging application displays the string right-to-left rather than its normal left-to-right orientation. This character is mainly used for displaying messages in Arabic or Hebrew.
This allows phishing attacks to spoof trusted domains on messages sent to users on WhatsApp, iMessage, Instagram, Facebook Messenger and Signal, making them appear as legitimate and trustworthy subdomains of apple.com or google .com.
The vulnerabilities have been assigned to the following CVEs and are known to work in the following versions of instant messaging applications:
CVE-2020-20093 – Facebook Messenger 227.0 or earlier for iOS and 188.8.131.52.116 or earlier on Android
CVE-2020-20094 – Instagram 106.0 or earlier for iOS and 184.108.40.206 or earlier on Android
CVE-2020-20095 – iMessage 14.3 or older for iOS
CVE-2020-20096 – WhatsApp 2.19.80 or earlier for iOS and 2.19.222 or earlier on Android
Signal does not have a matching CVE ID because the particular attack method was leaked to them recently.
Discovery and PoC
The CVE identifiers are so old because the initial discovery of the vulnerabilities was in August 2019 by a researcher named “zadewg”.
Independent security researcher Sick.Codes noticed the flaws when the CVE program recently posted them on Twitter and decided to investigate further.
Sick.Codes contacted the researcher to ask if he had just made his repository public or not, and the researcher replied in surprise that the CVEs were released now, after all this time.
The researcher was reluctant to share more information about the exploit method, which had only been demonstrated on video, so Sick.Codes decided to replicate the exploit on their own and write a proof of concept (PoC) for this one.
The two security researchers have agreed to publish the PoC immediately on GitHub as the vulnerabilities may have been under active exploitation for a long time now.
The exploit is a one-liner abusing iOS and Android’s reliance on gTLDs and bidirectional text display support and is as simple as adding a single control character ‘u202E ‘ between two valid URLs.
For example, the published PoC abuses google.com for the hidden, clickable URL and sets bit.ly/3ixIRwm as the destination.
After the injected RTLO control character, the URL is reversed because it is treated as a “right-to-left” language (Arabic, Hebrew, etc.), so the threat actor needs to take this into account when registration of the destination domain.
For example, using a specially crafted URL “gepj.xyz” would appear as the harmless JPEG image file “zyx.jpeg”, while creating “kpa.li” would appear as an APK file “li.apk” , etc.
In reality, these destinations could host anything, so identity theft is very elusive and difficult to spot.
However, BleepingComputer noticed some quirks while testing this bug in iMessage, Signal, and even Gmail. For example, while combined URLs may appear as one URL, they are actually treated as two URLs.
This means that if a user clicks on the left side of the URL, they will go to Google.com, and if they click on the right side, they will go to BleepingComputer.com.
Even weirder, while iMessage on iOS 15 shows the text upside down in the message list preview screen, it removes the reversed string in the actual message.
Other tests conducted by BleepingComputer show that this rendering flaw does not work as expected in Gmail, Outlook.com or ProtonMail.
While the URL is displayed as a single string with the text reversed, the Unicode RTLO character in the hyperlink is converted to its hex equivalent, leaving a URL like:
Impact and Fixes
The single-line PoC is publicly available and simple to use, even by people with poor technical understanding or no hacking skills.
In fact, there is plenty of evidence of RTLO-based exploitation in the wild, even when it involves more complex technical concepts.
The same attack is likely applicable to many other instant messaging and messaging apps, but only those mentioned above have been confirmed as vulnerable.
Telegram was also vulnerable, but it was the first to fix the problem via a security update.
Additionally, the Signal development team immediately responded to Sick.Codes’ report and informed the researcher that a fix would be coming in the next version of the app.
Sick.Codes told BleepingComputer that the messaging apps listed above are still vulnerable to this rendering method.
NIST is currently investigating the scope and impact of the vulnerabilities, so whether they had been patched in previous releases will soon be determined by the organization.
As such, users of the mentioned apps should be careful when receiving messages containing URLs, always click on the left side and stay alert for incoming app security updates that may fix the problem.
Sick.Codes said the render method is still functional in all apps tested and suggests users of all instant messaging apps are:
“Disable link previews in everything, especially messaging apps and anything related to notifications. Don’t visit strange websites with pop-ups. Don’t click random prizes.
You already have a phone, so use your bookmarks and make sure you keep it up to date. Given the number of zero days floating around, especially those recently leaked for iOS, it would be perilous to trust URLs in instant messengers. »
Since Unicode RTLO characters have a legitimate use, it’s unclear if messaging apps will fix this problem, as it could break legitimate functionality.
Bleeping Computer has contacted the vendors of the affected apps to find out when this will be fixed, and we’ll update this post as soon as we receive a response.