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.
