macOS के Zero-Click Calendar invite vulnerability chain

 (medium.com/@mikko-kenttala)
1 पॉइंट द्वारा GN⁺ 2024-09-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS Calendar के invite attachment processing की खामी के कारण हमलावर Calendar sandbox के अंदर arbitrary file write·delete कर सकते थे, और यही समस्या आगे remote code execution तथा Photos data access chain तक पहुंची
  • पहले चरण CVE-2022-46723 में ATTACH सेक्शन के FILENAME=../../../PoC.txt जैसे path traversal input को सही तरह sanitize नहीं किया गया, जिससे attachment file इच्छित location के बाहर save हो सकती थी
  • remote code execution chain ने Monterey से Ventura में upgrade होने की प्रक्रिया के दौरान Calendar के Open File behavior का उपयोग किया, और कई files inject करके DMG·SMB mount·custom URL scheme को जोड़ा
  • Photos चरण में defaults import से malicious settings लागू की गईं, जिससे System Photo Library को /var/tmp/mypictures/Syndication.photoslibrary पर बदल दिया गया और iCloud original photos ऐसी directory में sync होने लगीं जो TCC से protected नहीं थी
  • Apple ने अक्टूबर 2022 से सितंबर 2023 के बीच सभी संबंधित vulnerabilities को patch किया; Photos vulnerability को CVE-2023-40434 और Gatekeeper bypass को CVE-2023-40433 के रूप में handle किया गया

Calendar attachment file path traversal

  • malicious Calendar invite में file attachment शामिल हो सकती थी, और attachment filename validation की कमी के कारण directory traversal संभव था
  • हमलावर ATTACH सेक्शन में FILENAME=../../../PoC.txt की तरह arbitrary path निर्दिष्ट कर सकता था
    • सामान्य save location ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/ है
    • vulnerable behavior में file ~/Library/Calendar/PoC.txt पर save हो जाती थी
  • अगर उसी नाम की file पहले से मौजूद हो तो नई file PoC.txt-2 के रूप में save होती थी, लेकिन बाद में हमलावर द्वारा भेजे गए event या attachment के delete होने पर मूल PoC.txt हटाया जा सकता था
  • इस behavior का उपयोग filesystem के Calendar sandbox के भीतर existing files delete करने के लिए भी किया जा सकता था
  • vulnerability कम से कम macOS Monterey 12.5 के latest version में मौजूद थी, और macOS 13.0 beta4 में अब vulnerable नहीं पाई गई

Remote code execution तक बढ़ाई गई chain

  • macOS Ventura रिलीज़ से ठीक पहले मिली vulnerability को version upgrade process और Calendar की Open File feature के जरिए remote code execution तक बढ़ाया गया
  • हमलावर ने Calendar arbitrary file write vulnerability से कई files inject कीं और उन्हें इस तरह configure किया कि Monterey से Ventura में upgrade के दौरान RCE chain काम करे

  • Inject की गई files की संरचना

    • 000Hacked-$RANDOM.calendar
      • इसमें “Siri Suggested” Calendar जैसा दिखने वाला Calendar data होता है
      • इसमें recurring event और reminder features शामिल हैं, और यह अन्य injected files खोलने के लिए काम करता है
    • CalendarTruthFileMigrationInProgress
      • यह file पुराने format से नए database में existing Calendar के upgrade·merge को trigger करती है
    • CalPoCInit.dmg
      • पहला Calendar reminder ~/Library/Calendars/CalPoCInit.dmg खोलने के लिए सेट होता है
      • DMG के अंदर .DS_Store का Bookmark बाहरी Samba server की background image reference शामिल करता है
      • CalPoCInit.dmg खुद quarantine state में हो, तब भी mount quarantine flag के बिना होता है
    • stage1.url
      • दूसरा Calendar reminder ~/Library/Calendars/stage1.url खोलने के लिए सेट होता है
      • इस file में file:///Volumes/CalPoCPayload/MyMidiTest.app URL शामिल है, जो पिछले चरण में mount हुए Samba volume के अंदर के app की ओर इशारा करता है
      • Finder /Volumes/CalPoCPayload/ खोलते ही indexing अपने आप होती है, और MyMidiTest.app index हो जाता है
      • app bundle का Info.plist mymiditest custom URL scheme handler register करता है
    • stage2.url
      • तीसरा Calendar reminder ~/Library/Calendar/stage2.url खोलने के लिए सेट होता है
      • यह file mymiditest:// को refer करती है, जिससे malicious app बिना user interaction के execute हो जाता है

Gatekeeper bypass और app execution

  • mymiditest:// execution संभव होने का कारण यह था कि app exploit द्वारा बनाए गए Samba mount के अंदर था, और उस location पर quarantine flag नहीं था
  • mymiditest app चरण 3 के लिए ज़रूरी files /var/tmp/ में लिखता है और open /var/tmp/PhotosPoC.sh से Terminal में script चलाता है
  • पूरी chain को Calendar sandbox से बाहर निकलने के लिए कई files inject करने, SMB trick से Gatekeeper mitigations को bypass करने, और फिर arbitrary code execute करने के लिए तैयार किया गया था

Photos settings बदलकर iCloud photos तक पहुंच

  • remote code execution के बाद का चरण Photos settings बदलकर user के संवेदनशील photo data, खासकर iCloud Photos, तक पहुंचने पर केंद्रित था
  • सामान्यतः Photos जैसे संवेदनशील files तक पहुंच को TCC सीमित करता है, लेकिन Photos settings बदलने पर System Photo Library ऐसी path की ओर point कर सकती थी जो TCC से protected नहीं थी
  • हमलावर अलग System Photo Library उपयोग करने वाली Photos settings file बना सकता था और उसे defaults import से import कर सकता था
  • PoC chain में चरण 2 अपने आप ऐसी settings तैयार करता है जो /var/tmp/mypictures/Syndication.photoslibrary को System Photo Library के रूप में उपयोग करती हैं
    • संबंधित malicious settings files /var/tmp/mypictures/*.plist में बनाई जाती हैं
    • चल रहे Photos-संबंधित applications को बंद किया जाता है
    • मूल settings /var/tmp/mypictures/*-orig.plist में backup की जाती हैं
    • malicious settings /var/tmp/mypictures/ से import की जाती हैं
    • नई photo library open /var/tmp/mypictures/Syndication.photoslibrary से Photos में खोली जाती है
  • Syndication.photoslibrary एक खाली template library है, और जब Photos नई System Photo Library के रूप में चलती है तो iCloud sync enabled हो जाता है और original files unprotected directory में download हो जाती हैं
  • disk पर sync हुई files को /var/tmp/PoCLoot$RANDOM/ के नीचे नई directory में copy किया जाता है
  • PoC में छोटे बदलावों के साथ data को बाहरी resource पर copy किया जा सकता था या curl command से बाहरी web server पर post किया जा सकता था

Patch timeline और बाकी bounty issue

  • पूरी chain को macOS की security barriers को क्रम से पार करना पड़ा
    • Calendar में कई files inject करके sandbox bypass किया गया और अगले चरण को सक्रिय किया गया
    • SMB trick से Gatekeeper mitigations को bypass करके arbitrary code execute किया गया
    • TCC protection bypass करके iCloud Photos जैसे संवेदनशील data तक पहुंचा गया
  • patch से पहले malicious Calendar invite को Apple iCloud users को भेजकर बिना user interaction के iCloud Photos चुराई जा सकती थीं
  • Apple ने अक्टूबर 2022 से सितंबर 2023 के बीच सभी संबंधित vulnerabilities को patch कर दिया

  • Timeline

    • 2022-08-08: Calendar sandbox के भीतर arbitrary file write·delete report की गई
    • 2022-10-24: macOS Monterey 12.6.1 और Ventura 13 में fix किया गया
      • इस item के लिए कोई CVE नहीं था, और Ventura beta3 vulnerable था
    • 2022-11-14: Calendar vulnerability को arbitrary code execution और Gatekeeper bypass तक बढ़ाने वाला PoC सौंपा गया
    • 2022-12-04: iCloud Photos access PoC सौंपा गया
    • 2023-02-20: Calendar vulnerability में CVE-2022-46723 credit और CVE जोड़ा गया
    • 2023-03-27: Gatekeeper bypass macOS Ventura 13.3 में fix किया गया
      • इस समय कोई CVE या credit नहीं था
    • 2023-09-26: Photos vulnerability CVE-2023-40434 fix की गई और credit दिया गया
    • 2023-10-09: Gatekeeper bypass और Photos vulnerability से संबंधित bug bounty की घोषणा की गई
    • 2023-12-21: Gatekeeper bypass को CVE-2023-40433 credit दिया गया
    • 2024-09-12: मूल Calendar arbitrary file write·delete vulnerability CVE-2022-46723 के लिए अब भी bounty नहीं है
    • 2024-10-20 update: Apple ने तय किया कि CVE-2022-46723 Calendar arbitrary file write·delete vulnerability bounty के योग्य नहीं है, क्योंकि इसका असर केवल macOS Monterey पर था और Ventura में beta stage के दौरान ही यह समस्या मौजूद नहीं थी

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

1 टिप्पणियां

 
GN⁺ 2024-09-14
Hacker News की राय

  • अच्छा है कि मैं iCloud Photo Library इस्तेमाल नहीं करता, लेकिन यह अजीब है कि अगर फोटो लाइब्रेरी की location बदल दें, तो नई location को कोई protection नहीं मिलता
    /var/tmp/mypictures/Syndication.photoslibrary को system photo library के तौर पर set करके Photos खोलने पर मुझे लगा था कि Photos app इस directory को protect करेगा, इसलिए exploit fail हो जाएगा
    Sonoma 14.6.1 पर जल्दी से test करने पर, Option key दबाकर Photos खोलकर ~/Pictures में नई photo library बनाने पर, जिस app के पास full disk access या photo permission नहीं थी, उसे उस folder तक access deny हो गया
    लेकिन जब नई photo library /tmp में बनाई, तो वही app access कर सका, और यह behavior confusing और inconsistent है
    अगर Apple सच में photo library को file system में कहीं भी move करने की feature support करना चाहता है, तो protection भी ठीक से apply करनी चाहिए

    • कुछ हद तक समझ आता है। /tmp ऐतिहासिक रूप से directory hierarchy में ऐसी जगह रही है जहां कोई भी read/write कर सकता है, और private data store करने के लिए अच्छी choice नहीं है
    • TCC लंबे समय से इसी तरह थोड़ा अजीब और छेदों से भरा रहा है
    • Linux में अब macOS की तुलना में हर चीज़ को isolate करना कहीं आसान है
      AppArmor या Firejail के बिना भी, ज़्यादातर services को by default dedicated temporary directory मिलती है

  • इस थ्रेड में bug bounty भुगतान की बात बहुत हो रही है, लेकिन अगर कोई बड़ी tech कंपनी, जो लगातार bounty program चलाती है, bounty नहीं दे रही है, तो आम तौर पर उसके पीछे कोई वाजिब वजह होने की संभावना ज्यादा होती है
    ऐसे programs के incentives लगभग पूरी तरह legitimate submissions पर bounty देने की दिशा में aligned होते हैं
    यह उन दुर्लभ मामलों में से है जहाँ incentives काफी अच्छी तरह aligned होते हैं: कंपनी खास तरह की research को बढ़ावा देने के लिए bounty program बनाती है, और legitimate bounty न देना उस लक्ष्य के खिलाफ है
    vendor की तरफ वाला व्यक्ति अपनी जेब से पैसा खर्च नहीं कर रहा होता, और रकम भी कंपनी के लिए कोई meaningful scale की नहीं होती
    आम तौर पर program operations team के सदस्य bounty कम देने के बजाय ज्यादा भुगतान करने के लिए motivate होते हैं

    • नहीं। वजह यह है कि Apple के bug bounties की जांच और भुगतान करने वाली product security team बुरी तरह managed और inefficient है
      हाल ही में इसे SWE program office से SEAR (security engineering & arch) में move किया गया, और manager को भी हाल ही में निकाल दिया गया और वह AirBNB चला गया
      टीम के ज्यादातर लोग नए graduate level के ICT2·ICT3 हैं, ऐसे लोग जो कंपनी में दूसरी जगह coding interview भी पास नहीं कर पाएंगे, और वे मुख्यतः bug triagers की तरह काम करते हैं
      वे computer के सामने काम करने से ज्यादा समय conferences में जाने और hackers के साथ घूमने में बिताते हैं
      ‘ongoing investigation’ portal का graph बस लगातार ऊपर जाता रहता है, यानी emails जमा होती जा रही हैं और उन्हें catch up करने की कोशिश तक नहीं की जा रही
      जिन लोगों को bounty मिलनी चाहिए लेकिन नहीं मिल रही, उन्हें progress देखने के लिए Twitter पर SEAR के head Ivan पर public pressure डालना होगा
    • सही हो सकता है। Apple का खराब bug bounty program शायद जानबूझकर की गई दुर्भावना नहीं, बल्कि incompetence का नतीजा हो
      लेकिन security researchers या public के लिए क्या इससे फर्क पड़ता है? नहीं। वजह जो भी हो, Apple को अपना bounty program ठीक करना चाहिए
      आखिर यह blog post भी पहले से बड़े ढेर में जुड़ा सिर्फ एक और उदाहरण है[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • जब तक आपका मतलब यह नहीं कि लेखक ने स्थिति को तोड़-मरोड़कर पेश किया है, मुझे समझ नहीं आता कि ऐसा कौन-सा “बहुत अच्छा कारण” हो सकता है, जबकि साफ record है कि किसी ने bug के fix होने से बहुत पहले उसे report किया था
      best case में भी यह typical धीमी bureaucracy जैसा लगता है, और यह कोई खास अच्छी वजह नहीं है
      अगर कंपनी सच में ऐसी चीजों को encourage करती है, तो approval में 1 साल से ज्यादा लगने की वजह नहीं होनी चाहिए
      logic सही हो सकता है, लेकिन ऐसी स्थिति देखकर यह मानना मुश्किल है कि “कंपनी कंजूस है या लगभग हर दूसरी स्थिति की तरह जरूरत से ज्यादा bureaucratic है” वाली बात “ऊपर से criteria पूरा दिखने वाली bounty न देने का कोई legitimate reason है” से कम plausible है
      अगर लेखक ने incident को सही तरह describe किया है, तो कहीं ज्यादा plausible लगता है कि बाकी हर जगह काम करने वाले incentives इस area में भी घुस आए हैं
    • क्या आपने कभी Apple को security/privacy issue report किया है? मैंने किया है। अभी भी Apple के पास मेरा कम से कम एक open issue है
      उनमें से एक को बिना side effects के code की एक line से fix किया जा सकता है, लेकिन वह 2 साल से open है
      Apple security team या तो interested नहीं है या incompetent है; दोनों में से जो भी हो, अच्छा नहीं है
      computing में मेरे सबसे गुस्से और frustration वाले experiences में से एक था
      वे साफ तौर पर चाहते हैं कि issue को public में share न किया जाए, लेकिन उसे अनिश्चितकाल तक लटकाए रखते हैं
      सच कहूं तो अब मेरी limit करीब आ रही है
      मुझे bounty की परवाह भी नहीं, बस चाहता हूं कि bug fix हो जाए
      अगर भरोसा हो कि वे मामले को seriously handle कर रहे हैं, तो मैं जितना हो सके उतना समय दूंगा, लेकिन ऐसा भरोसा करना मुश्किल है
    • बड़ी tech कंपनियों द्वारा सीधे payment refuse करने के documented cases बहुत रहे हैं
      कभी बाद में participation rules बदल देना, कभी security researcher को ongoing bounty program से चुपचाप block कर देना, कभी good-faith disclosure को law enforcement तक पहुंचा देना, या admins का बेहद petty व्यवहार करना
      “कंपनी के लिए रकम मायने नहीं रखती” वाली बात के कारण यह गड़बड़ handling और भी समझ से बाहर लगती है

  • quarantine flag को छेड़ने का यह एक और तरीका है। दूसरा यह link है: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    ऐसा लगता है कि बहुत सारी अलग-अलग systems इस quarantine flag को modify कर सकती हैं

  • “हमलावर पीड़ित को फ़ाइल attachment वाली एक malicious calendar invite भेज सकता है… fix से पहले, किसी भी Apple iCloud user को malicious calendar invite भेजकर user interaction के बिना iCloud Photos चुराए जा सकते थे।”
    यह scope कितना बड़ा है? क्या इसका मतलब है कि macOS पर कहीं से भी कोई भी, iCloud इस्तेमाल करने वाले किसी भी व्यक्ति को मनमाना invite भेज सकता है? ऐसा कौन नहीं चाहेगा?

    • व्यंग्य करने की कोशिश नहीं है, लेकिन invite को इसके अलावा और कैसे काम करना चाहिए?
    • समझ नहीं आ रहा। calendar invite पाना किसी दूसरे email को पाने से कैसे अलग है? क्या macOS design के हिसाब से calendar invite के लिए कुछ अपने-आप process करता है?
    • क्या Google Calendar भी ऐसा ही नहीं है?
    • यह सिर्फ iCloud-specific नहीं लगता। आम तौर पर invites email से अपने-आप detect हो जाते हैं
      Calendar invites लंबे समय से spam का source रहे हैं, इसलिए यह चौंकाने वाली बात नहीं कि vulnerabilities भी होंगी

  • “अगर हमलावर द्वारा specified file पहले से मौजूद है, तो specified file PoC.txt-2 नाम से save होती है। लेकिन अगर हमलावर द्वारा भेजा गया event/attachment बाद में delete किया जाता है, तो original नाम वाली file (PoC.txt) हट जाती है। इस vulnerability का इस्तेमाल file system ‘sandbox’ के अंदर मौजूद files delete करने के लिए किया जा सकता है।”
    यह खराब engineering है

  • यहां bounty की स्थिति मुझे खास पसंद नहीं आई। Security researchers के लिए Apple या दूसरी FAANG-level companies में इतना लंबा इंतज़ार करना आम है क्या?

    • बहुत आम है

  • सिर्फ पहला step ही अपने-आप में बेतुकी vulnerability है। Apple ने इसे कैसे consider नहीं किया?
    “हमलावर ATTACH section में FILENAME=../../../PoC.txt की तरह file के लिए arbitrary path set करके directory traversal attack सफल कर सकता है।”

    • यह एक बड़ी समस्या दिखाता है जो हर company में हो सकती है। Apple में किसी ने ज़रूर इसे safely handle करने वाला library function लिखा होगा, लेकिन लोगों को वही function इस्तेमाल करने के लिए कैसे मजबूर किया जाए?
      खासकर अगर code reviewer को भी उस library के बारे में पता न हो, तो शुरुआत से फिर unsafe implementation करने से रोकना मुश्किल है
      क्या इस तरह की समस्या का कोई modern solution है?

  • जब भी बड़े scale का non-memory-safety security hole सामने आता है, अजीब तरह से excitement होती है
    मुझे पता है यह थोड़ा petty है, लेकिन Rust में लगी सारी time और energy आखिरकार बस एक path traversal bug से बेकार हो जाने की कल्पना मुझे पसंद है

  • क्या Lockdown Mode इसे रोकता है?

    • पूरी तरह guess है, लेकिन उम्मीद है ऐसा ही हो
      पुराने zero-click image attachment exploits को देखते हुए लगता है कि Lockdown Mode ऐसी चीज़ों को रोकने के लिए बनाया गया था, और शायद सभी files को उसी तरह treat किया जाता होगा

  • वाह। काफ़ी old-school exploit है
    file name के अंदर path जैसी चीज़ों के बारे में मुझे याद है कि करीब 10 साल पहले पढ़ा था