Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A clickjacking vulnerability in WhatsApp that enables phishing attacks

00xbyte.github.io

Post reply on HN
Print view View original

41–50 of 84 posts

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#41

Post by paulryanrogers »

acdha wrote: post #17
tambourine_man wrote: post #7

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.

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.

> Like most phishing techniques, passkeys will end it eventually.

This assumes passkeys will be widely adopted. And that users will know to stop wherever the passkey doesn't work. I have doubts about both.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#43

Post by jpc0 »

paulryanrogers wrote: post #41
acdha wrote: post #17

Earlier quoted context omitted.

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.

> Like most phishing techniques, passkeys will end it eventually. This assumes passkeys will be widely adopted. And that users will know to stop wherever the passkey doesn't work. I have doubts about both.

So Google and Amazon have support, and it seems depening on which AB group you are in Apple does too?

I think it is a significant benefit and likely to be implemented specially concidering client support is already there and there are good libraries available to do it.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#44

Post by amadeuspagel »

darkwater wrote: post #38

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

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.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#45

Post by yorwba »

henearkr wrote: post #18
IshKebab wrote: post #11

Earlier quoted context omitted.

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.

How can they blacklist this character while still supporting URLs in right-to-left languages?

You don't need RIGHT-TO-LEFT OVERRIDE to support URLs in right-to-left languages. It's an extremely rare codepoint that's used to force left-to-right characters to be displayed as if they were right-to-left characters. The only use case I can think of off the top of my head is some kind of interlinear phonetic transcription where you want Latin characters to flow the same direction as the corresponding Arabic for ease of cross-referencing.

For ordinary bidirectional texts, RIGHT-TO-LEFT ISOLATE, its sibling LEFT-TO-RIGHT ISOLATE and POP DIRECTIONAL FORMATTING are plenty:

⁧عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329‬

Where I used RIGHT-TO-LEFT ISOLATE in the beginning to make sure the Arabic text in front of the colon is to the right of it, and then POP DIRECTIONAL FORMATTING in the end to restore the original directionality. (Amusingly, HN's URL parser treats the POP DIRECTIONAL FORMATTING as part of the URL, which breaks the link.)

Otherwise it would show up like below, where "in front of the colon" means "left of it" (as is customary in English text):

عنوان URL لهذا التعليق هو: https://news.ycombinator.com/item?id=38734329

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#46

Post by rollcat »

dclowd9901 wrote: post #39
Flimm wrote: post #6

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

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

And therefore, future bounty hunters will make sure to offer their next 0day to the highest bidder instead.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#47

Post by josu »

amadeuspagel wrote: post #44
darkwater wrote: post #38

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

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.

> They have to remove the preview feature.

They can just disable it for contacts that you don't have on your contact list.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#49

Post by darkwater »

amadeuspagel wrote: post #44
darkwater wrote: post #38

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

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.

Yes, preview is generated by the sender to avoid receiver's address leak to a sender-controlled host, but what I'm saying is that WA should enforce on the receiver side that both point to the same URL. As said initially, they are most certainly doing it this way to unfurl URL shorteners, which would other be the easiest way to phish people. At the same time it's also noteworthy that the preview can fail to be generated on the sender side and the message will be send out anyway, so yeah, I agree with you that they could just remove the preview feature. Probably in their opinion the trade-offs are worth, I guess.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#50

Post by chatmasta »

LelouBil wrote: post #31
pera wrote: post #22

Earlier quoted context omitted.

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 app…

> I won't mention the details here but Google Search sometimes rewrite URLs in such way that an attacker can spoof the actual URL. I think I saw something like this a while ago, with some fake KeePass website maybe.

This is an actual feature for AdWords (which show up in search results). But at least there's some moderation of the rendered domain in that case.
Post reply on HN