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

71–80 of 84 posts

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#71

Post by altfredd »

josephcsible wrote: post #64

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?

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.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#72

Post by dixie_land »

altfredd wrote: post #71
josephcsible wrote: post #64

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?

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.

Exactly, somethings should've just been left ASCII. The push to use Unicode in many components for "inclusiveness" are simply political.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#73

Post by kevincox »

eviks wrote: post #42

> 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?

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.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#74

Post by darkwater »

chimeracoder wrote: post #54
darkwater wrote: post #49

Earlier quoted context omitted.

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

> 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. How do you do that without having the receiver make an HTTP request to that address, in order to follow all redirects?

Exactly, that's why I say that they chose the trade-off of easy-to-send shortener over more complicated/manually crafted attacks like the one in the article.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#75

Post by ptx »

dixie_land wrote: post #72
altfredd wrote: post #71

Earlier quoted context omitted.

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.

Exactly, somethings should've just been left ASCII. The push to use Unicode in many components for "inclusiveness" are simply political.

Or perhaps KOI-7 N1, another 7-bit text encoding [0]. The Cyrillic alphabet should be good enough for anyone. As you say, no need to let Americans use their native alphabet just to feel included.

[0] https://en.wikipedia.org/wiki/KOI-7

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#76

Post by robertlagrant »

kevincox wrote: post #73
eviks wrote: post #42

> 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?

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, inc…

Another comment picked what I think is the best option: the sender generates it, and receiver verifies it, but only on click. That way the receiver's already going to leak their IP, so WhatsApp can verify before opening up the web page.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#77

Post by kevincox »

robertlagrant wrote: post #76
kevincox wrote: post #73

Earlier quoted context omitted.

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, inc…

Another comment picked what I think is the best option: the sender generates it, and receiver verifies it, but only on click. That way the receiver's already going to leak their IP, so WhatsApp can verify before opening up the web page.

Verifies what? That the preview matches? What if it changed between the send and the click legitimately? Also what is the threat model here? If the sender controls the URL they can generate any preview that they want.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#78

Post by Thorrez »

blincoln wrote: post #62

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

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.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#79

Post by 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

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#80

Post by jpc0 »

paulryanrogers wrote: post #58
jpc0 wrote: post #43

Earlier quoted context omitted.

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.

Large providers have supported other standards and not seen uptake. I'll believe it if/when it happens. Lack of understandably is the primary downside of passkeys, and I doubt it will be overcome in this decade. Authentication is like investing, one must understand the options for it to be effective.

Understating isn't too though for me.

I click a button, my phone/computer asks for biometrics etc and the passkey is loaded.

When more poviders make it a default it will be even better. This isn't like enrolling 2fa, its more akin to hardware tokens without th hassel of carrying around a hardware token...

Post reply on HN