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

51–60 of 84 posts

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#51

Post by thiagoharry »

berdario wrote: post #30
WilTimSon wrote: post #26

Earlier quoted context omitted.

It wouldn't really solve the problem, sadly. The percentage of people who'd bother to read that warning is likely quite low.

I don't think that's a good reason for not including such a warning. "quite low" for a service with billions of users, can still allow for million of users who would benefit from seeing the warning.

This does not solve the issue for arabic users. Sounds not good for me declaring the problem solved just because it was solved for people speaking certain languages. Or attacking the problem excluding certain languages.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#52

Post by flutas »

LelouBil wrote: post #33
isaacfrond wrote: post #27

Earlier quoted context omitted.

That was the initial idea, but it failed because Whatsapp traffic is end to end encrytped. The second idea, which actually worked, was to put a breakpoint in Whatsapp while running in an emulator.

No, not an emulator. Just using your browser's JavaScript debugger. You can do that on any website.

Yeah, the article also says "WA web’s javascript was uglified and minified, however after a while of searching I found the right place."

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#53

Post by pera »

chatmasta wrote: post #50
LelouBil wrote: post #31

Earlier quoted context omitted.

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

I know you are referring to those fake KeePass malware ads, but just to clarify: the issue I reported was not related to AdWords - it was for normal search results

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#54

Post by chimeracoder »

darkwater wrote: post #49
amadeuspagel wrote: post #44

Earlier quoted context omitted.

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

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#55

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

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#56

Post by o11c »

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?

The receiver can do the verification while clicking (which would make the request anyway).

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#57

Post by jeroenhd »

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.

Passkeys work, password managers with autofill should also work. You can override password managers, but "why can't I find my credentials" makes you look at the URL again at least once.

For Bitwarden, this will be the hostname, and as such, will tell you that you don't have any passwords for moc.margatsni.nl

There are design issues at play here, but mitigations for most types of phishing are already available. Websites need to implement Passkey support, but any username+password website should work perfectly fine with password managers.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#58

Post by paulryanrogers »

jpc0 wrote: post #43
paulryanrogers wrote: post #41

Earlier quoted context omitted.

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

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.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#59

Post by jeroenhd »

moritzwarhier wrote: post #29
rany_ wrote: post #9

Earlier quoted context omitted.

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…

Unicode is hell really.

The RTL override is necessary for embedding right-to-left content inside left-to-right text. If you ever want to combine Arabic and English in one sentence, you'll probably want an override in there.

You could use HTML and other formatting tricks to do the same, but this control character is a very valid and useful part of Unicode.

Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks

#60

Post by blincoln »

aeonik wrote: post #12

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).

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.
Post reply on HN