7 ms·
A clickjacking vulnerability in WhatsApp that enables phishing attacks
- coderag 3y agoInteresting attack and a nice write up. I see Google services are also mentioned. Are they taking any action on this unlike Meta?
- Aachen 3y agoClickjacking is where you perform a click on some element, but actually the click event is caught by a different element, typically laid transparently above the thing you think you're clicking on. The click can be detected by the attacker, despite you not getting the event, by making your visible underlying layer have focus and look for the onblur event to fire. 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
- neverrroot 3y agoUsing a unicode character to reverse order of characters and create links that have “trusted” value like: ln.instagram.com//:sptth. Neat and indeed something that could be well exploited.
- j4yav 3y agoReally interesting approach to use right to left override in that way, that's very clever.
- AlexSW 3y agoInteresting ideas and vulnerability! With a nice and concise summary. Thanks for sharing
- iLoveOncall 3y agoI remember this already existed on Windows Explorer 2 decades ago, it's funny to see it "rediscovered".
- rany_ 3y agoThe 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/ 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.
- moritzwarhier 3y agoUnicode is hell really.
- jeroenhd 3y agoThe 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.
- moritzwarhier 3y agoYes, 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.
- 3y ago
- Flimm 3y agoIt's disappointing that Meta chose not to fix this and chose not to reward this researcher with a bug bounty.
- IshKebab 3y agoI expect they probably didn't make clear exactly what they wanted fixed (blacklisting the RTL character) and Meta thought they wanted all misleading URLs fixed which is not really possible.
- acdha 3y agoThat’s still a Meta problem. Simply confirming the PoC should have made it clear that they need to fix something.
- AlecSchueler 3y agoPOC?
- henearkr 3y agoHow can they blacklist this character while still supporting URLs in right-to-left languages?
- amenhotep 3y agoThe client should probably be aware of whether the user might be expecting RTL text and maybe display a warning if not? Arabic users receiving a URL containing the character shouldn't raise any eyebrows, but if a random Anglo user clicks on one it might be worth displaying a warning that it's backwards text? At least the first time.
- tambourine_man 3y agoNice hack. The real problem is not WhatsApp or the Unicode reverse character, though, it’s that URLs are hard. Just this simple visa.securesite.com fools a lot of people. And I don’t see a good solution in the near future.
- acdha 3y agoThis 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.
- paulryanrogers 3y ago> 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.
- jpc0 3y agoSo 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.
- paulryanrogers 3y agoLarge 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.
- 3y ago
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- aeonik 3y agoVery 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).
- ajb 3y agoThe article says "I decided to intercept a message via WA web".
- isaacfrond 3y agoThat 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.
- blincoln 3y agoThe 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.
- Dah00n 3y agoWhat's up with the font? >web’ s All 's have a space after them.
- qwertox 3y agoNot on my machine, not on Firefox or Chrome.
- stjohnswarts 3y agoyeah looks fine on firefox/mac
- jeroenhd 3y agoI 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 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_all_curly_quotes_in_firefox_have_a_huge/ 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.
- fruit2020 3y agoWhat’s happening with the Whatsapp osx app. It’s so bad to use nowadays, slow, buggy.
- Jleagle 3y agoIt's an Electron app, they also have a native one in beta you can download
- perryizgr8 3y agoThe native mac os app is worse imo. On the other hand the windows app is one of the best windows messaging apps I've used. They need to re think their strategy on macos.
- darkwater 3y agoEveryone fixing on the UTF RTL character but Meta should have at least acknowledged the issue with the preview URL that can be different from the message URL. I understand that this is probably to unfurl shortened URLs, but there has to be some clever workaround that Meta & Whatsapp can implement
- amadeuspagel 3y agoNo. 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.
- josu 3y ago> They have to remove the preview feature. They can just disable it for contacts that you don't have on your contact list.
- darkwater 3y agoYes, 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 generated on the sender side and the message will be send out anyway, so yeah, I agree with you that they could just remove the preview feature. Probably in their opinion the trade-offs are worth, I guess.
- chimeracoder 3y ago> 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?
- Erratic6576 3y agoPreview and message are sent separately. My intuition tells me the preview is used to track user activity. I wish I could contact the author to know more about how WhatsApp tracks activity
- kioleanu 3y agoThey cache the preview for subsequent messages containing the same link. For example, if a link is making the rounds and gets sent 200k times in an hour, they don't call the URL 200k times to build the preview, as that's a huge waste of resources on both sides, with a huge chance that the servers containing the link gets DDOSed
- eviks 3y ago> Exactly as I suspected, the link and the preview were sent separately! This is an even bigger issue with the UI design, why should poor users compare links and previews to be safe?
- kevincox 3y agoIt's a security tradeoff. Given that you want to provide a link preview (which is a nice feature) you have a few options: 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.
- robertlagrant 3y agoAnother comment picked what I think is the best option: the sender generates it, and receiver verifies it, but only on click. That way the receiver's already going to leak their IP, so WhatsApp can verify before opening up the web page.
- kevincox 3y agoVerifies what? That the preview matches? What if it changed between the send and the click legitimately? Also what is the threat model here? If the sender controls the URL they can generate any preview that they want.
- bugsliker 3y agoI love that this is categorized as "reverse engineering" at the bottom of the post.
- rashidujang 3y agoAmazing 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.
- j0hnyl 3y agoProbably just painfully stepping through the debugger.
- charcircuit 3y agoThis 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.
- blincoln 3y agoThis 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 https://owasp.org/www-community/attacks/Clickjacking [2] https://portswigger.net/web-security/clickjacking https://portswigger.net/web-security/clickjacking
- Thorrez 3y agoYeah, I wouldn't call this clickjacking, because real clickjacking is a technique the makes a victim perform some account action without knowing it. Simply opening an unintended link isn't as bad as that.
- Rygian 3y agoIf that link shows a login screen identical to the Instagram one, what percentage of users do you think will double-check the URL a second time, after mistakenly confirming it in the WhatsApp preview?
- josephcsible 3y agoRTL 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?
- altfredd 3y agoOperating systems notwithstanding, there should definitely be such option for every OS widget, that displays text (including Android TextView). And it should default to disabling all BiDi backdoors unless developer explicitly vetted specific text span to enable them. Making entire text rendering stack vulnerable by default under pretext of catering to less than 1% of world population is ridiculous.
- dixie_land 3y agoExactly, somethings should've just been left ASCII. The push to use Unicode in many components for "inclusiveness" are simply political.
- ptx 3y agoOr perhaps KOI-7 N1, another 7-bit text encoding [0]. The Cyrillic alphabet should be good enough for anyone. As you say, no need to let Americans use their native alphabet just to feel included. [0] https://en.wikipedia.org/wiki/KOI-7 https://en.wikipedia.org/wiki/KOI-7