A clickjacking vulnerability in WhatsApp that enables phishing attacks

[blincoln]

This is a pretty clever combination of feature misuse, although I think I'd rate the overall security impact fairly low, because the best-case scenario is that you cause the recipient to open a link in their browser. That can be useful in some cases, but unless the attacker is a police force, intelligence agency, or similar, there would usually need to be some kind of follow-up attack, e.g. exploiting unpatched software on the device.

In the interest of technical accuracy, I don't think I'd label this one "clickjacking" specifically. "Clickjacking" usually refers to a very specific technique that involves invisible HTML frames overlaid on top of other content.[1][2]

[1] https://owasp.org/www-community/attacks/Clickjacking [2] https://portswigger.net/web-security/clickjacking

[Thorrez]

Yeah, I wouldn't call this clickjacking, because real clickjacking is a technique the makes a victim perform some account action without knowing it. Simply opening an unintended link isn't as bad as that.

[Rygian]

If that link shows a login screen identical to the Instagram one, what percentage of users do you think will double-check the URL a second time, after mistakenly confirming it in the WhatsApp preview?

[darkwater]

Everyone fixing on the UTF RTL character but Meta should have at least acknowledged the issue with the preview URL that can be different from the message URL. I understand that this is probably to unfurl shortened URLs, but there has to be some clever workaround that Meta & Whatsapp can implement

[amadeuspagel]

No. End-to-end encryption means that the preview has to be generated either by the sender or the receiver. Having the receiver generate the preview would leak his IP. They have to remove the preview feature.

[Aachen]

Clickjacking is where you perform a click on some element, but actually the click event is caught by a different element, typically laid transparently above the thing you think you're clicking on. The click can be detected by the attacker, despite you not getting the event, by making your visible underlying layer have focus and look for the onblur event to fire.

What OP found is cool. I've also used RTL characters to make screensaver files (so just normal executables with a different extension in Windows) that looked like Word documents, I forgot why, maybe to prank a friend or teacher or so. OP has gone one step further and found a way to alter the displaying on another system. I'm not sure what this is called, though it's not clickjacking (the Wikipedia page OP links to in the article lede confirms that) because the user doesn't mistake which element they're clicking on, they mistake where a link will lead. I've also never seen a clickjacking being abused in practice, but what OP found I can imagine will be abused!

Honestly I've long given up on users being able to tell which domain they'll end up on when clicking a link. A majority doesn't understand the concept anyway, and the remainder can't tell. Those who think they can tell (such as yours truly) end up getting frustrated when all links go to sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. We're training people to click random tracking obfuscated fishy looking garbage every day and nobody bats an eye at it

[tambourine_man]

Nice hack. The real problem is not WhatsApp or the Unicode reverse character, though, it’s that URLs are hard.

Just this simple visa.securesite.com fools a lot of people. And I don’t see a good solution in the near future.

[acdha]

This specific example is poor sanitization because it actively misleads the users who try to understand what they’re clicking on.

Your example of the generic confusion around host names and domains is a harder problem but people have tried to mitigate it somewhat by doing things like highlighting the domain name portion. Like most phishing techniques, passkeys will end it eventually.

[josephcsible]

RTL has been a huge source of security vulnerabilities for its entire existence. Why don't operating systems have a setting to disable all RTL, so that people who don't know any such languages aren't unnecessarily exposed to the dangers with zero benefit?

[altfredd]

Operating systems notwithstanding, there should definitely be such option for every OS widget, that displays text (including Android TextView). And it should default to disabling all BiDi backdoors unless developer explicitly vetted specific text span to enable them.

Making entire text rendering stack vulnerable by default under pretext of catering to less than 1% of world population is ridiculous.

[Flimm]

It's disappointing that Meta chose not to fix this and chose not to reward this researcher with a bug bounty.

[pera]

I reported a similar issue to Google early this year and they declined the submission because it "can only result from social engineering" and "we think that addressing it would not make our users significantly less vulnerable".

I won't mention the details here but Google Search sometimes rewrite URLs in such way that an attacker can spoof the actual URL.

My advice is to never trust URLs displayed by websites and apps.

[smashah]

They're to busy sending legal threats to OSS projects

[IshKebab]

I expect they probably didn't make clear exactly what they wanted fixed (blacklisting the RTL character) and Meta thought they wanted all misleading URLs fixed which is not really possible.

[dclowd9901]

They’ll fix it. They just won’t reward the bounty hunter.

[eviks]

> Exactly as I suspected, the link and the preview were sent separately!

This is an even bigger issue with the UI design, why should poor users compare links and previews to be safe?

[kevincox]

It's a security tradeoff. Given that you want to provide a link preview (which is a nice feature) you have a few options:

1. Generate on the sender side. Downside: Can be spoofed.

2. Generate on the receiver side: Downside: Leaks receiver IP.

3. Generate via third party: Downside: Leaks information to the third party.

Overall I think that 1 is the best option. The sender can "spoof" all of their messages anyways, including the preview as part of the message is really no different. The problem here is that it isn't obvious that this content comes from the sender, it is displayed as a separate bubble and I would bet that 99% of users don't realize that the content is from the sender.

Plus the URL is all that really matters anyways. If you are clicking on an attacker-controlled URL they can make the preview display anything they want. So you gain very little by forcing the preview to be "authentic".

Option 3 can be good as well. Especially if implemented with something like double-blinding. So you connect to one party which forwards you to a second party. This way the first sees your IP and the second sees the destination IP but neither sees both (unless they collude). However that is a lot of infrastructure to set up and maintain for relatively little benefits.

[bugsliker]

I love that this is categorized as "reverse engineering" at the bottom of the post.

[AlexSW]

Interesting ideas and vulnerability! With a nice and concise summary. Thanks for sharing

[charcircuit]

This isn't clickjacking. Clickjacking is when an attacker hijacks a click go actually click on something else that the user was not intending to or was aware of clicking. The existing of the RTL codepoint to make text go from right to left is an i18n feature and using it confuse people is not a novel vulnerability.

[iLoveOncall]

I remember this already existed on Windows Explorer 2 decades ago, it's funny to see it "rediscovered".

[rany_]

The attack still works and it is less obvious than you might expect. For context, an SCR file is a regular executable, treated the same as a .EXE or .COM.

From https://attack.mitre.org/techniques/T1036/002/:

> RTLO is a non-printing Unicode character that causes the text that follows it to be displayed in reverse. For example, a Windows screensaver executable named `March 25 \u202Excod.scr` will display as `March 25 rcs.docx`. A JavaScript file named `photo_high_re\u202Egnp.js` will be displayed as `photo_high_resj.png`

I think the examples are pretty scary if you ask me, but most anti-virus software do warn you when they come across those types of files.

[aeonik]

Very cool attack, and easy to read write up.

I have one basic question: It was mentioned that attacking the encryption was skipped in favor of using a debugger.

Was this debugger applied to the WhatsApp Web app? Or was the debugger deployed on the phone? Was it an emulator?

For some reason I didn't think WhatsApp had a web app (I don't use it).

[ajb]

The article says "I decided to intercept a message via WA web".

[blincoln]

The article doesn't make it 100% unambiguous, IMO, but the debugger screenshot looks like a desktop browser's debugger. You could also potentially do the same thing in the mobile app using Frida.

[coderag]

Interesting attack and a nice write up. I see Google services are also mentioned. Are they taking any action on this unlike Meta?

[rashidujang]

Amazing article! In case the author sees this, it'd be great if the author can deep dive into how he "found the right place" in finding the correct breakpoint to produce the decrypted message. It seems to me that if you're able to do this there's a lot of interesting things one could do.

[j0hnyl]

Probably just painfully stepping through the debugger.

[neverrroot]

Using a unicode character to reverse order of characters and create links that have “trusted” value like: ln.instagram.com//:sptth. Neat and indeed something that could be well exploited.

[Erratic6576]

Preview and message are sent separately. My intuition tells me the preview is used to track user activity. I wish I could contact the author to know more about how WhatsApp tracks activity

[kioleanu]

They cache the preview for subsequent messages containing the same link. For example, if a link is making the rounds and gets sent 200k times in an hour, they don't call the URL 200k times to build the preview, as that's a huge waste of resources on both sides, with a huge chance that the servers containing the link gets DDOSed

[j4yav]

Really interesting approach to use right to left override in that way, that's very clever.

[Dah00n]

What's up with the font?

>web’ s

All 's have a space after them.

[jeroenhd]

I see it too, because I block web fonts. Enabling web fonts resolves the issue.

For me, this is some kind of Linux + Firefox + certain fonts issue with the ’ character (right single quotation mark, not '). We're not the first to run into it: https://bugzilla.mozilla.org/show_bug.cgi?id=48152 but reproducing seems quite hard.

According to https://www.reddit.com/r/firefox/comments/is9twh/why_would_a..., this happens when you have Chinese (I'm guessing Asian) fonts installed.

The reason, as far as I can tell:

- font-family is "Source Sans Pro","Microsoft Yahei",sans-serif

- Source Sans Pro has no fallback font

- the fallback font for Microsoft Yahei is Noto Sans CJK SC (result of ~ $ fc-match 'Microsoft Yahei') because YaHei is a CJK optimised font. This is configured in /etc/font/conf.d/30-cjk-aliases.conf

- Noto Sans CJK SC is a wide font (common for CJK fonts)

I think the solution to this problem is altering config files in /etc/fonts/conf.d somehow but I haven't figure out what I need to change exactly. Commenting out lines 466-473 (the alias containg <family>Microsoft YaHei</family>) to kill the association works, but I'm pretty sure that breaks any attempt to render MS YaHei.

[qwertox]

Not on my machine, not on Firefox or Chrome.

[fruit2020]

What’s happening with the Whatsapp osx app. It’s so bad to use nowadays, slow, buggy.

[Jleagle]

It's an Electron app, they also have a native one in beta you can download