A clickjacking vulnerability in WhatsApp that enables phishing attacks(00xbyte.github.io) |
A clickjacking vulnerability in WhatsApp that enables phishing attacks(00xbyte.github.io) |
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
They can just disable it for contacts that you don't have on your contact list.
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
Just this simple visa.securesite.com fools a lot of people. And I don’t see a good solution in the near future.
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.
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.
Making entire text rendering stack vulnerable by default under pretext of catering to less than 1% of world population is ridiculous.
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.
I think I saw something like this a while ago, with some fake KeePass website maybe.
This is an even bigger issue with the UI design, why should poor users compare links and previews to be safe?
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.
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.
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).
>web’ s
All 's have a space after them.
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.
How do you do that without having the receiver make an HTTP request to that address, in order to follow all redirects?
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.
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.
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.
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...
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.
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
"quite low" for a service with billions of users, can still allow for million of users who would benefit from seeing the warning.
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.
Unicode is extremely useful and a great engineering success. My comment was a bit tongue-in-cheek, sorry.
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)