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.
A clickjacking vulnerability in WhatsApp that enables phishing attacks
61–70 of 84 posts
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#62This 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
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#63Earlier quoted context omitted.
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.
That's a good point, but the algorithm for detection/flagging doesn't have to be what the grandparent post proposed.
Maybe something like: strip all tags (leaving only the unstyled text) and check:
- there shouldn't be any RLM within the URL
- RLM marks are accepted before/after the URL only if the URL uses only characters for a language that is RTL and the surrounding text uses characters for a language that is LTR (or viceversa, LTR and surrounding text is for RTL text)... Otherwise the text is flagged
- flag URLs that contain both characters for RTL and LTR languages (with possible exceptions for ccTLD/TLDs? )
Of course, this leaves some open problems (how big should the sample of the "surrounding text"?)
And also, Meta could roll out this logic/algorithm in public Facebook/Instagram posts, where it has more control of it... Rolling it out in WhatsApp first could be more problematic, since due to e2e, Meta wouldn't be able to easily spot false positives (messages with URLs that are flagged as potentially malicious, but which are actually fine)
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#64RTL 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?
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#65What's up with the font? >web’ s All 's have a space after them.
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 Microsoft YaHei) to kill the association works, but I'm pretty sure that breaks any attempt to render MS YaHei.
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#66Amazing 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.
Probably just painfully stepping through the debugger.
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#67Earlier quoted context omitted.
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.
Yes, hell is other people (pun not meant in a culturally divisive way).
Unicode is extremely useful and a great engineering success. My comment was a bit tongue-in-cheek, sorry.
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#68Earlier quoted context omitted.
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.
Yes, hell is other people (pun not meant in a culturally divisive way). Unicode is extremely useful and a great engineering success. My comment was a bit tongue-in-cheek, sorry.
I guess I misunderstood you, apologies!
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#69Earlier 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.
Your first assumption is dubious: Apple, Microsoft, and Google all have well-integrated support and usage is increasing on mainstream sites. It seems unlikely that there will be strong popular backlash against something which is easier to use in addition to being safer.
The second is flat out wrong. Passkeys and U3/F/FIDO2 do not depend on the user at all. Even if I completely fool you, the credential you get for example.com cannot be used on example.org because the protocol incorporates the host name. That’s why the security community is pushing them since phishing is so common and this shuts that down entirely. The attacks now tend to involve getting people to downgrade to password + SMS/TOTP so the more those fade from common usage the better everyone will be.
Re: A clickjacking vulnerability in WhatsApp that enables phishing attacks
#70Earlier quoted context omitted.
Yes, hell is other people (pun not meant in a culturally divisive way). Unicode is extremely useful and a great engineering success. My comment was a bit tongue-in-cheek, sorry.
I guess I misunderstood you, apologies!
No need to apologize, my comment really wasn't very clear. Have a nice weekend!