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