WhatsApp क्लिकजैकिंग vulnerability से phishing attack संभव

• WhatsApp message में सामान्य site जैसा दिखने वाला link और preview दिखाते हुए, असल click को attacker की site पर भेजने वाली phishing vulnerability मिली
• वजह यह है कि message body का link और preview data अलग-अलग भेजे जाते हैं, और matchedText हटाकर preview mismatch बनाया जा सकता है
• U+202E Right-To-Left Override character URL के display direction को उलट देता है, जिससे असली domain को सामान्य domain जैसा दिखाया जा सकता है
• attacker impersonation target का mirror domain तैयार करने के बाद original site का preview बनाए रखकर सिर्फ text value बदल सकता है और victim को धोखा दे सकता है
• Meta ने जवाब दिया कि वह URL normalization logic को dynamically adjust कर सकता है, और users को link click करने से पहले उसे copy करके असली address verify करना चाहिए

---

WhatsApp link preview और actual link के अलग होने की जगह

• researcher यह confirm करना चाहता था कि WhatsApp message recipient link preview render करते समय HTTP request trigger करता है या नहीं, इसलिए उसने एक दोस्त को webhook.site link भेजा
• HTTP request केवल sender side से एक बार हुई, और यह confirm हुआ कि recipient अलग से link render नहीं करता
• इस behavior की वजह से माना गया कि WhatsApp message में link और preview information साथ में include होकर भेजी जाती है, और researcher ने test किया कि क्या दोनों को अलग-अलग बनाया जा सकता है

Issue #1: link preview mismatch

• WhatsApp Web message को proxy से सीधे modify करने की कोशिश की गई, लेकिन WhatsApp के E2EE की वजह से Burp Suite जैसे tools से simple tampering मुश्किल थी
• इसके बजाय message WebSocket से encrypted होकर भेजे जाने से ठीक पहले JavaScript में breakpoint लगाकर message object देखा गया
• message object में link body और preview information अलग properties के रूप में मौजूद थीं
  • text: message body
  • canonicalURL: preview के नीचे दिखने वाला domain
  • matchedText: यह canonicalURL से compare की जाने वाली value लगती है, और test किया जाता है कि यह value text में भी दिखाई देती है या नहीं
• instagram.com के message object में text को google.com में बदलने पर preview गायब हो गया और सिर्फ Google link बचा
• matchedText property delete करने पर actual link और preview अलग-अलग होने वाला mismatch message बनाया जा सका

Issue #2: U+202E से link display disguise

• actual link body सामने न आए, इसके लिए fuzzing की गई कि क्या Unicode characters text display बदलते हैं
• U+202E एक Right-To-Left Override character है, जो text को user के लिए reverse order में display कराता है
• सिर्फ U+202E इस्तेमाल करने पर link का रूप अजीब दिखता था और click होने की संभावना कम लगती थी, इसलिए ऐसा reversed string बनाना जरूरी था जो normal URL जैसा दिखे

mirror URL बनाने का तरीका

• लक्ष्य ऐसा URL बनाना था जो reverse होने पर https://instagram.com जैसा दिखे
• simple reversed string moc.margatsni//:sttph बनती है, लेकिन .margatsni जैसा TLD register नहीं किया जा सकता
• समाधान यह था कि वास्तव में register किए जा सकने वाले TLD को subdomain जैसा दिखने के तरीके से इस्तेमाल किया जाए
  • उदाहरण के लिए Netherlands TLD .nl इस्तेमाल करने पर ln.instagram.com जैसा दिखने वाला string बनाया जा सकता है
• URL को ऐसा दिखना चाहिए कि वह https:// से शुरू होता है, इसलिए valid path //:sptth को पीछे जोड़ा गया
• नतीजतन https://moc.margatsni.nl//:sptth, U+202E के साथ combine होने पर https://ln.instagram.com//:sptth जैसा दिख सकता है
• researcher ने इस तरीके को 2K2E कहा

attack flow

• attacker उस site का mirror domain खरीदता है जिसे impersonate करना है
  • उदाहरण: ln.instagram.com जैसा दिखाने के लिए moc.margatsni.nl खरीदा जाता है
• पहले original domain link वाला message बनाकर उस site का preview हासिल किया जाता है
  • example object में text, matchedText, canonicalUrl सभी में https://instagram.com/ होता है
  • description, title, jpegThumbnail, thumbnailDirectPath जैसी preview-related values भी शामिल होती हैं
• इसके बाद matchedText हटाकर text value को \u202ehttps://moc.margatsni.nl//:sptth के रूप में बदला जाता है
• final message Instagram preview दिखाता है, लेकिन click करने पर attacker के तैयार किए गए domain पर जा सकता है

Meta की प्रतिक्रिया और दूसरे platforms से तुलना

• Meta ने जवाब दिया कि वह कई platforms और environments support करता है, इसलिए platform-specific URL normalization methods server-side logic से अलग हो सकते हैं
• उसने बताया कि actual spam और abuse होने पर URL normalization logic को dynamically adjust करने वाला system मौजूद है
• researcher ने आकलन किया कि Meta इस security issue को actively solve करने के बजाय, केवल system द्वारा spam detect किए जाने पर respond करना चाहता है
• X, TikTok, Pinterest U+202E character के लिए sanitization processing करते हैं, इसलिए वे WhatsApp से अलग हैं

users के लिए possible mitigation

• WhatsApp links पर सिर्फ उनके displayed appearance के आधार पर भरोसा करना मुश्किल है
• 2K2E phishing से बचने के लिए link click करने से पहले उसे copy करके clipboard preview में actual address verify करना चाहिए
• clipboard preview U+202E character sanitized state में link address दिखा सकता है
• researcher ने बाद में ऐसी अन्य services भी खोजीं जिनमें proper sanitization processing नहीं थी और जो 2K2E के लिए vulnerable थीं

[GN⁺]

Hacker News की राय

• यह किसी feature के काफ़ी चतुर misuse का combination है, लेकिन कुल security impact कम ही माना जाएगा
  सबसे अच्छे मामले में भी यह बस recipient से browser में link खुलवा देता है, इसलिए अगर attacker पुलिस/इंटेलिजेंस एजेंसी जैसा न हो, तो आम तौर पर device के unpatched software का फायदा उठाने जैसे follow-up attack की जरूरत पड़ेगी
  तकनीकी तौर पर इसे clickjacking कहना ठीक नहीं है। Clickjacking आम तौर पर बहुत specific technique है, जिसमें invisible HTML frame को दूसरे content के ऊपर overlay किया जाता है
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • मैं भी इसे clickjacking नहीं कहूंगा। असली clickjacking में victim से उसकी जानकारी के बिना account-related action करवाया जाता है, और सिर्फ़ unintended link खोलना उतना गंभीर नहीं है
  • अगर वह link Instagram जैसा ही login screen दिखाए, तो WhatsApp preview में एक बार धोखा खाकर confirm करने के बाद कितने प्रतिशत users URL फिर से check करेंगे, पता नहीं

• सब लोग UTF right-to-left characters पर ही focus कर रहे हैं, लेकिन Meta को कम से कम यह problem स्वीकार करनी चाहिए थी कि preview URL message URL से अलग हो सकता है
  मैं समझता हूं कि यह shortened URL expand करने के लिए किया जाता है, लेकिन Meta और WhatsApp ज़रूर कोई smart workaround implement कर सकते होंगे

  • नहीं। end-to-end encryption में preview sender या receiver side पर ही generate करना पड़ता है। अगर receiver preview बनाए, तो IP leak होता है। आखिरकार preview feature हटाना पड़ेगा

• Clickjacking में आपको लगता है कि आप किसी element पर click कर रहे हैं, लेकिन असल में अक्सर transparent तरीके से ऊपर रखे दूसरे element द्वारा click event intercept किया जाता है
  दिखाई दे रही lower layer पर focus देकर और onblur event fire होना detect करके, user को event न मिले तब भी attacker click का पता लगा सकता है
  OP ने जो खोजा है वह बढ़िया है, लेकिन clickjacking नहीं है। मैंने भी पहले RTL characters से screensaver file, यानी Windows में सिर्फ़ extension अलग वाली ordinary executable file को Word document जैसा दिखाया था। शायद दोस्त या teacher के साथ prank करना चाहता था, लेकिन वजह ठीक से याद नहीं
  OP ने एक step आगे बढ़कर दूसरे system में display बदलने का तरीका खोज लिया। इसमें user इस बात को लेकर confuse नहीं होता कि कौन-सा element click कर रहा है, बल्कि link कहां जाएगा इसे लेकर confuse होता है, इसलिए यह clickjacking नहीं है; article की शुरुआत में link किया गया Wikipedia page भी यही confirm करता है
  मैंने असल में clickjacking का abuse होते नहीं देखा, लेकिन OP ने जो तरीका खोजा है वह abuse हो सकता है
  सच कहूं तो user link click करते समय final domain पहचान पाएगा, यह उम्मीद मैंने बहुत पहले छोड़ दी थी। ज्यादातर लोग concept ही नहीं समझते, और बाकी लोगों के लिए भी पहचानना मुश्किल है
  जो लोग सोचते हैं कि वे पहचान सकते हैं, वे भी तब frustrate हो जाते हैं जब सारे links sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o जैसी जगहों पर जाते हैं। हम रोज़ लोगों को tracking के लिए obfuscated suspicious garbage links दबाने की training दे रहे हैं, और किसी को फर्क नहीं पड़ता

• शानदार hack है। असली problem WhatsApp या Unicode reverse characters नहीं, बल्कि यह है कि URL मुश्किल होते हैं
  visa.securesite.com जैसा simple example भी बहुत लोगों को fool कर देता है। निकट भविष्य में कोई अच्छा solution दिखता नहीं

  • इस specific case में, जब user click target समझने की कोशिश करता है, तो उसे actively mislead किया जाता है, इसलिए यह खराब sanitization जैसा है
    host name और domain को लेकर general confusion ज्यादा मुश्किल problem है, लेकिन browsers domain name वाले हिस्से को highlight करके इसे कुछ हद तक mitigate करने की कोशिश करते रहे हैं। ज्यादातर phishing techniques की तरह आखिर में passkeys ही शायद इसे खत्म करेंगे

• RTL अपने पूरे अस्तित्व में बहुत बड़ी security vulnerabilities का source रहा है। जिन लोगों को ऐसी languages नहीं आतीं, उन्हें बिना किसी benefit के risk में न डाला जाए, इसके लिए operating system में सभी RTL disable करने की setting क्यों नहीं है, समझ नहीं आता

  • operating system से अलग, text दिखाने वाले हर OS widget में ऐसा option होना चाहिए। Android TextView भी इसमें शामिल है
    जब तक developer किसी specific text range को explicitly review करके allow न करे, default में सभी bidirectional text bypasses disabled होने चाहिए
    दुनिया की 1% से कम population का ध्यान रखने के नाम पर पूरे text rendering stack को default रूप से vulnerable बनाना समझदारी नहीं है

• Meta ने इस problem को fix न करने और इस researcher को bug bounty भी न देने का फैसला किया, यह disappointing है

  • इस साल की शुरुआत में मैंने Google को similar problem report की थी, लेकिन “यह सिर्फ़ social engineering से हो सकता है” और “इसे fix करने से users meaningful तरीके से कम vulnerable नहीं होंगे, ऐसा हम मानते हैं” कहकर reject कर दिया गया
    details यहां नहीं बताऊंगा, लेकिन Google Search कभी-कभी URL rewrite करता है, और उस तरीके की वजह से attacker actual URL को spoof कर सकता है
    websites और apps में दिखने वाले URL पर कभी भरोसा न करना ही बेहतर है
  • शायद OSS projects को legal threats भेजने में बहुत busy हैं
  • शायद researcher यह clearly नहीं बता पाया कि क्या fix चाहिए, जैसे RTL characters block करने की demand, और Meta ने इसे सभी misleading URLs fix करने की मांग समझ लिया होगा। वह practically impossible है
  • वे fix तो करेंगे। बस bounty hunter को reward नहीं देंगे

• “जैसा expected था, link और preview अलग-अलग भेजे गए!” यह बात बड़ी UI design problem है। आम user को security के लिए link और preview compare क्यों करना चाहिए

  • यह security trade-off है। link preview जैसा useful feature देने के लिए कुछ options हैं
    1. sender side पर generate करें। downside है कि इसे forge किया जा सकता है
    2. receiver side पर generate करें। downside है कि receiver IP leak होता है
    3. किसी third party के जरिए generate करें। downside है कि third party को information leak होती है
       overall मुझे 1 सबसे अच्छा लगता है। sender वैसे भी अपने सारे messages “forge” कर सकता है, और preview को message के हिस्से के रूप में include करना बहुत अलग नहीं है
       यहां problem यह है कि यह clearly नहीं दिखता कि यह content sender से आया है। यह अलग speech bubble जैसा दिखता है, इसलिए 99% users को शायद पता नहीं होगा कि content sender-provided है
       ऊपर से core चीज URL ही है। अगर आप attacker-controlled URL click करते हैं तो attacker preview में अपनी मर्ज़ी की कोई भी चीज दिखा सकता है। इसलिए preview को “real” force करके मिलने वाला benefit बहुत कम है
       3 भी ठीक हो सकता है। खासकर अगर इसे double-blind जैसे तरीके से implement किया जाए, तो एक side से connect करके वह second side को forward कर सकती है। तब first IP देखता है और second destination, लेकिन जब तक वे मिलीभगत न करें, दोनों एक साथ दोनों चीजें नहीं देखते
       हालांकि इतनी infrastructure build और maintain करने के मुकाबले benefit relatively छोटा है

• article के बिल्कुल नीचे इसे reverse engineering के रूप में classify किया गया है, यह मुझे अच्छा लगा

• यह clickjacking नहीं है। Clickjacking में attacker click को intercept करके user से वास्तव में कोई दूसरा target click करवाता है, जिसे user ने intend नहीं किया था या जिसके बारे में उसे पता नहीं था
  text को right-to-left flow कराने वाले RTL codepoints internationalization feature हैं, और उनसे लोगों को confuse करना कोई नई vulnerability नहीं है