मिस्र में commercial surveillance vendor द्वारा दुरुपयोग की गई 0-day vulnerability

 (blog.google)
1 पॉइंट द्वारा GN⁺ 2023-09-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google TAG और The Citizen Lab ने iPhone को निशाना बनाने वाली 0-day exploit chain को वास्तविक हमलों में पाया, और Intellexa ने इसका उपयोग करके Predator spyware को चुपके से इंस्टॉल किया
  • Apple ने iOS 16.7 और iOS 17.0.1 में CVE-2023-41991·41992·41993 को patch किया, और Google ने iOS users को तुरंत update करने की सलाह दी
  • हमला तब हुआ जब target किसी HTTP site पर गया; MITM injection के जरिए traffic intercept करके उसे c.betly[.]me और sec-flare[.]com पर redirect किया गया, इसलिए अलग से click करने या phone call का जवाब देने की जरूरत नहीं थी
  • iOS chain में Safari remote code execution, certificate validation issue, और XNU Kernel local privilege escalation शामिल थे, जिसके बाद एक छोटा binary यह तय करता था कि Predator full implant इंस्टॉल किया जाए या नहीं
  • Android को निशाना बनाने वाले हमले भी मिस्र में देखे गए, और Chrome के CVE-2023-4762 का उपयोग करने वाली शुरुआती renderer remote code execution vulnerability को 5 सितंबर को patch किया गया

Intellexa की Predator installation के लिए exploit chain

  • Google Threat Analysis Group(TAG) ने The Citizen Lab के साथ मिलकर वास्तविक हमलों में इस्तेमाल हो रही iPhone के लिए 0-day exploit chain खोजी
  • commercial surveillance company Intellexa द्वारा विकसित इस chain का उपयोग devices पर Predator spyware को गुप्त रूप से इंस्टॉल करने के लिए किया गया
  • Apple ने iOS 16.7 और iOS 17.0.1 में निम्न vulnerabilities को patch किया
    • CVE-2023-41991
    • CVE-2023-41992
    • CVE-2023-41993
  • तेज patching से users की सुरक्षा मजबूत हुई, और सभी iOS users को इन्हें जल्द से जल्द इंस्टॉल करने की सलाह दी गई है

MITM के जरिए delivery method

  • Intellexa exploit chain को man-in-the-middle(MITM) attack के जरिए deliver किया गया
  • MITM attack में attacker target और उस website के बीच घुस जाता है, जिससे target जुड़ना चाहता है, और traffic को intercept करता है
  • जब target किसी http site पर जाता है, तो attacker नकली data वापस भेजकर उसे किसी दूसरी website पर भेज सकता है
  • https sites में traffic encrypted होता है और certificates के जरिए यह verify किया जा सकता है कि मिला data इच्छित website से ही आया है
  • इस campaign में target किसी भी http site पर जाता, तो traffic injection के जरिए उसे चुपचाप c.betly[.]me Intellexa site पर redirect कर दिया जाता
    • अगर user अपेक्षित target होता, तो उसे फिर sec-flare[.]com exploit server पर भेजा जाता
    • document खोलने, किसी खास link पर click करने, या phone call का जवाब देने जैसी user action की जरूरत नहीं थी

iOS exploit chain की संरचना

  • target को exploit server पर redirect किए जाने के बाद iOS exploit chain चलती थी
  • यह chain तीन vulnerabilities से बनी थी
    • CVE-2023-41993: Safari में initial remote code execution (RCE)
    • CVE-2023-41991: certificate validation issue
    • CVE-2023-41992: XNU Kernel में local privilege escalation (LPE)
  • इसके बाद एक छोटा binary चलता था, जो तय करता था कि Predator full implant इंस्टॉल किया जाए या नहीं
  • TAG को पूरा Predator implant हासिल नहीं हो सका
  • Google ने Google vulnerability disclosure policy के अनुसार इस exploit का तकनीकी deep-dive analysis प्रकाशित करने की योजना बनाई है

Android-targeted हमले और Chrome vulnerability

  • attackers के पास मिस्र के Android devices पर Predator इंस्टॉल करने के लिए exploit chain भी थी
  • TAG ने Android exploit delivery के दो तरीके देखे
    • MITM injection
    • target को सीधे भेजा गया one-time link
  • TAG को केवल Chrome की initial renderer remote code execution vulnerability मिली, जो CVE-2023-4762 का दुरुपयोग करती थी
  • इस bug को एक अलग security researcher पहले ही Chrome Vulnerability Rewards Program में report कर चुका था, और इसे 5 सितंबर को patch कर दिया गया
  • Google का आकलन है कि Intellexa ने पहले इस vulnerability को 0-day के रूप में इस्तेमाल किया था

Chrome की MITM defense और Google की response

  • Chrome कई वर्षों से पूरे web पर HTTPS universal adoption को बढ़ावा देता रहा है
  • Chrome का “HTTPS-First Mode” MITM network injection के जरिए exploit delivery की संभावना को कम कर सकता है
    • यह सभी pages को पहले HTTPS में load करने की कोशिश करता है
    • HTTP request पर लौटने से पहले बड़ा warning दिखाता है
  • यह setting उन users के लिए default रूप से enabled है जो Advanced Protection Program में enrolled हैं और Chrome में signed in हैं
  • Google ने सभी users को MITM attacks से बचाव के लिए “HTTPS-First Mode” enable करने की सलाह दी है
  • यह campaign दिखाता है कि commercial surveillance vendors का प्रसार online users की सुरक्षा के लिए गंभीर जोखिम पैदा कर सकता है
  • TAG commercial spyware industry पर कार्रवाई और research publication जारी रखेगा, और public तथा private sectors के साथ मिलकर संबंधित response को आगे बढ़ाएगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-23
Hacker News की राय

  • अच्छी बात है कि और जानकारी आई है, लेकिन सिर्फ़ Chrome patch का ज़िक्र होना थोड़ा परेशान करता है। सोच रहा हूँ कि Android पर sandbox escape क्या था
    भले ही Android के Chrome process के अंदर code execution संभव हो गया हो, persistence हासिल करना संभव नहीं होना चाहिए, इसलिए ज़रूर कोई और vulnerability भी है
    इस बार attack vector targeted campaign में HTTP man-in-the-middle attack और one-time links था, लेकिन ऐसा कोई कारण नहीं दिखता कि कोई इसे ad campaign या SMS/Discord/Matrix जैसे spam में डालकर बड़े पैमाने पर फैलाए, botnet बनाए या users के credentials चुरा ले

    • असल मुद्दा यही है। Blog post में वह जानकारी नहीं है, इसलिए बातों के बीच पढ़ना पड़ता है, और ऐसा लगता है कि Android side पर अभी कोई unpatched issue है
    • कहा गया है कि वे बाद की Android chain के steps capture नहीं कर पाए और सिर्फ़ शुरुआती execution component ही मिला
      यानी sandbox escape और privilege escalation bugs missing हैं
      साथ ही, यहाँ लगता है कि legal interception capability का इस्तेमाल करके ISP-level man-in-the-middle attack के ज़रिए deliver किया गया था, लेकिन phishing link के ज़रिए one-click तरीके से इस exploit को deliver न कर पाने की कोई वजह नहीं है
    • निर्माताओं द्वारा छोड़ दिए गए लाखों Android devices हैं, इसलिए यह भी हो सकता है कि कुछ details इसलिए हटाई जा रही हों क्योंकि यह flaw अभी patch नहीं हुआ है और शायद कभी patch नहीं होगा
    • लेख का मुख्य फोकस iPhone exploit chain है: Safari exploit → PAC bypass → kernel exploit
      Android version भी काफ़ी मिलता-जुलता था, लेकिन लगता है Linux kernel mitigations bypass करने के लिए दो और exploits चाहिए थे
      PZ पर एक अच्छा technical analysis लेख है
    • Mobile environment के बारे में बहुत नहीं जानता, लेकिन Chrome sandbox से बाहर निकलने पर आप basic operating system में नहीं पहुँच जाते क्या? वहाँ से कोई अतिरिक्त vulnerability exploit किए बिना persistence बनाना संभव नहीं है?

  • HTTPS न होने से तो बेहतर है, और यह attack शुरुआती payload injection के लिए HTTP का इस्तेमाल करता है, लेकिन कुछ देशों के state-backed attackers शायद CA या CDN infrastructure को सीधे bypass या compromise भी कर सकते हैं

    • अगर वे इस तरह certificates forge करते हैं, तो सभी browsers के notice करने और उस CA को हटाने की संभावना ज़्यादा है, इसलिए safeguards मौजूद हैं
    • या फिर वे हमें, जिसे हम सब प्यार करते हैं, LetsEncrypt से प्रमाणित spoofing domain पर click करवा सकते हैं
      लगता है कि बस एक HTTP 302/307 redirect response चाहिए जो client को c.betly[.]me पर भेज दे। HTML redirect payload या शायद DNS भी संभव हो सकता है
    • अहम बात यह है कि device compromise करने के लिए किसी भी HTTP site पर बस एक बार visit करना काफ़ी था या है

  • Predator spyware पर Darknet Diaries का हाल का संबंधित episode है: https://darknetdiaries.com/episode/137/

  • ऐसे 0-day हमें यह सिखाते हैं कि अगर आप किसी शक्तिशाली adversary के target हैं, तो बेहद paranoid होकर काम करना होगा और attack surface को जितना हो सके कम करना होगा
    अगर James Bond को M से सुरक्षित communication करनी हो, तो बेहतर है कि वह सिर्फ़ उसी एक function के लिए बना custom hardware mobile device इस्तेमाल करे। उसे किसी anonymous third-party prepaid device से random message board पर पहले से सहमत rotating geo-locked codebook order में encrypted messages छोड़ने चाहिए। इससे ज़रा भी कम operational security हुई तो खेल खत्म
    अगर आम इंसान connected digital devices को सामान्य तरीके से इस्तेमाल करता है, तो मान लेना चाहिए कि उस device में डाली गई चीज़ पहले ही चोरी हो चुकी है। अगर किसी चीज़ को सच में private रखना है, तो उसे digital पर न डालें; कागज़ या पुराने analog tape जैसी जगह रखें। तब कम से कम उसे physical रूप से चुराना पड़ेगा, जो स्थिति के हिसाब से बहुत मुश्किल हो सकता है, लेकिन इसका मतलब यह नहीं कि वह ज़रूर ज़्यादा सुरक्षित है। आखिरकार किसी न किसी तरह हार ही होती है
    असली रास्ता बस यही है कि transparency और checks and balances वाले मजबूत democratic governments हों, privacy laws का सख्त enforcement हो, और Citizen Lab जैसी activities को मजबूत support मिले

  • इस vulnerability का इस्तेमाल Egyptian authorities ने बहुत संभवतः current president Abdel Fatah El Sisi के खिलाफ़ election में खड़े Ahmed El Tantawy candidate का phone hack करने के लिए किया था
    https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

  • लेख में नहीं बताया गया, लेकिन iOS के Lockdown Mode ने इस exploit chain को रोक दिया था

  • एक बात समझ नहीं आती: spyware vendors और 0-day बेचने वाली companies, दोनों के पास 0-day खोजने के लिए dedicated लोग होते हैं। Google और Apple बस इन लोगों को hire क्यों नहीं कर लेते?
    Google और Apple बहुत competitive salaries दे सकते होंगे, तो वे ऐसा क्यों नहीं करते, यह समझ नहीं आता। क्या उन्हें लगता है कि skilled 0-day hunters को practically सबको खींच लाने की cost, patch जारी करने की cost से ज़्यादा है?

    • मैं ठीक यही काम करता हूँ। 0-day researcher के तौर पर काम करता हूँ
      Employee perspective से salaries लगभग similar हैं। Big Tech का काम कम दिलचस्प है। आप बहुत सारे bugs खोजने वाली बड़ी bug-finding machines बनाते हैं, और मिले हुए bugs को bug tracker में डाल देते हैं, जहाँ वे शायद 3 महीने बाद ठीक हों। Offensive security का काम ज़्यादा दिलचस्प है। उथली vulnerabilities Big Tech ढूँढ लेता है, इसलिए आपको बस कुछ चाहिए और target system को गहराई से समझना पड़ता है। Vulnerability से code execution तक जाने का knowledge भी चाहिए। Exploit लिखना आसान काम नहीं है। जिन companies को मैं unethical मानता हूँ, वहाँ engineers क्यों काम करते हैं, यह समझाना मुश्किल है, लेकिन शायद वे मेरी तरह feel नहीं करते
      Employer perspective से यह सवाल है कि “हर साल X vulnerabilities खोजने की rate के लिए कितना खर्च करेंगे।” अगर code में bugs होने के बावजूद उसे market में सबसे secure code माना जाता है, तो security budget बढ़ाना company के interest में नहीं हो सकता। Security budget बढ़ाएँगे तो किस department का budget घटेगा, और company health पर net effect क्या होगा, यह देखना पड़ता है
      अगर vulnerabilities ठीक करनी हैं, तो vulnerabilities खोजने और exploit करने की कीमत इतनी बढ़ानी होगी कि buyers afford न कर सकें। और जैसे-जैसे offensive security की progress discovery और exploitation की cost घटाती है, वैसे-वैसे उस price को लगातार उससे ऊपर रखना होगा। Defensive companies आम तौर पर bug prevention से पैसा नहीं कमातीं, और offensive companies मुख्य रूप से bugs खोजकर पैसा कमाती हैं, इसलिए mismatch पैदा होता है। Company हो या कोई भी organization, ultimate vulnerability finite resources हैं
    • Google के पास पैसे और reputation से खरीदी जा सकने वाली best teams में से एक है: https://en.m.wikipedia.org/wiki/Project_Zero
      दुनिया भर के independent researchers के साथ collaboration भी शानदार है। लेकिन रोज़ लिखे जाने वाले software की मात्रा देखते हुए फिर भी कुछ issues छूट सकते हैं
    • यह कुछ ऐसा लगता है जैसे US government budget देखकर पूछना कि “संभावित criminals को सबको खरीदकर US में crime का बड़ा हिस्सा कम क्यों नहीं कर देते”
    • उनमें से कुछ लोग salary की परवाह किए बिना शुरू से ही Google या Apple में काम करना नहीं चाहेंगे
      आज उन्हें hire कर भी लें, तो कल ऐसी companies में काम करने वाले नए लोगों की भरमार हो जाएगी, इसलिए यह अंतहीन cycle बन जाएगी
    • आइडिया अच्छा है, लेकिन एक तरह से यह उसी मुश्किल सवाल जैसा है कि “दुनिया का सबसे अमीर देश दुनिया के सभी best military generals को hire करके बाकी देशों में एक भी क्यों नहीं छोड़ देता”
      इसके असंभव होने के कई कारण हैं, लेकिन आखिरकार बात इस पर आकर टिकती है कि दुनिया और इंसानियत इतनी बड़ी और जटिल है कि कोई एक entity सब कुछ, या ज़्यादातर भी, अपने पास नहीं रख सकती। हर चीज़ में बहुत विविध heterogeneity built-in है। पैसे से परे worldviews और loyalties भी बहुत हैं

  • Firefox में भी Https First है, लेकिन लगता है dom.security.https_first setting चालू करनी पड़ती है
    अगर संभव हो तो “HTTPS-Only Mode” निश्चित रूप से सबसे अच्छा है

    • फिर भी “allow anyway” दबाने की इच्छा पर काबू पाना होगा। सच कहूँ तो risk जानने के बावजूद शायद मैं भी दबा दूँगा। क्योंकि मैं बस उस site पर जाना चाहता हूँ
      जब तक prompt बेहद suspicious न दिखे—जैसे किसी ऐसी site पर दिखे जिसके बारे में आप जानते हैं कि वह HTTPS support करती है, जैसे Google.com—तब तक यह कुछ हल नहीं करता

  • इस लेख में linked Citizen Lab post में man-in-the-middle attack की details हैं। इसे attack कहना भी मुश्किल है; network को ज़रूरत पड़ने पर content injection करने के लिए ही design किया गया है