macOS में पासवर्ड लीक हो सकने वाली NetAuthAgent कमजोरी

 (wts.dev)
1 पॉइंट द्वारा GN⁺ 2025-03-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple ने macOS Sequoia 15.1, Sonoma 14.7.1, Ventura 13.7.1 में CVE-2024-54471 को पैच किया, जिन्हें 28 अक्टूबर 2024 को जारी किया गया था; अपडेट से पहले के वातावरण में NetAuthAgent के जरिए संग्रहीत credentials उजागर हो सकते थे
  • समस्या की जड़ यह थी कि NetAuthAgent का MIG server संदेश भेजने वाले की जांच किए बिना file server credentials को lookup, create और कुछ मामलों में overwrite करने वाले routines खुले छोड़ रहा था
  • attacker com.apple.netauth.user.gui Mach service को message भेजकर Keychain के internet password items को उसकी ओर से lookup करा सकता था, और username व password प्राप्त कर सकता था
  • असर सिर्फ Finder के “Connect to Server” से सेव किए गए FTP, Samba, WebDAV और printer server credentials तक सीमित नहीं था; अलग exploit chain के जरिए iCloud account information और API tokens तक उजागर हो सकते थे
  • पैच के बाद NetAuthAgent, Mach message के audit token से भेजने वाली process की entitlement जांचता है, और com.apple.private.netauth.useragent.allow=true न होने पर response नहीं देता

CVE-2024-54471 पैच का दायरा

  • CVE-2024-54471 Apple security update में शामिल कर ठीक की गई macOS vulnerability है
  • पैच वाली सभी versions 28 अक्टूबर 2024 को release हुईं
    • macOS Sequoia 15.1
    • macOS Sonoma 14.7.1
    • macOS Ventura 13.7.1
  • जिन macOS devices को इन versions पर update नहीं किया गया है, उन्हें तुरंत update करना जरूरी है

macOS IPC और Mach-आधारित संरचना

  • macOS और अधिकांश Apple OS kernels XNU हैं, जो BSD-family components और काफी बदले हुए Mach kernel variant को शामिल करने वाला hybrid kernel है
  • आधुनिक macOS में भी Mach चार abstractions पर आधारित है
    • task: execution environment जहां threads चलते हैं, और resource allocation की मूल unit
    • thread: CPU usage की मूल unit
    • port: kernel द्वारा सुरक्षित message queue के बराबर communication channel
    • message: threads के बीच communication में इस्तेमाल होने वाले typed data objects का समूह
  • Mach ports userspace में सीधे expose होने वाली queues नहीं हैं, बल्कि हर task के port namespace के अंदर port right के रूप में संभाले जाते हैं
  • मुख्य अधिकार दो प्रकार के हैं
    • send right: एक ही port के लिए कई tasks के पास हो सकता है
    • receive right: सिर्फ एक task के पास हो सकता है
  • यह structure एक client-server model बनाता है, जिसमें एक server task कई client tasks के messages receive करता है
  • macOS का bootstrap server सभी tasks को ऐसा port देता है जिसके लिए उनके पास send right होता है, और clients को string name से registered Mach service का send right request करने देता है

MIG server में बना authentication gap

  • MIG Mach messages भेजने/receive करने को functional interface में wrap करने वाला tool है
  • MIG pseudo-C IDL और compiler से मिलकर बना है, और IDL file से ये files generate करता है
    • client के लिए C source
    • server के लिए C source
    • दोनों तरफ इस्तेमाल होने वाला C header
  • हर function को routine, और routines के collection को subsystem कहा जाता है; subsystem number और routine index message ID में reflect होते हैं
  • macOS के userspace communication में MIG को आम तौर पर XPC API ने पीछे छोड़ दिया है, लेकिन XPC भी Mach messages के ऊपर ही बना है
  • MIG server में अपने आप कोई enforced authentication mechanism नहीं होता, इसलिए अगर server sender को verify न करे तो send right वाला कोई भी task remote routines call कर सकता है
  • MIG servers खोजने में blacktop का ipsw CLI उपयोगी है, और NDR_record symbol import करने वाली binaries ढूंढने का तरीका इस्तेमाल होता है
    • यह तरीका सिर्फ MIG servers ही नहीं, MIG clients भी साथ में ढूंढ सकता है
    • server और client code को disassembler या decompiler में अपेक्षाकृत आसानी से अलग पहचाना जा सकता है

NetAuthAgent द्वारा संभाले जाने वाले credentials

  • NetAuthAgent macOS में FTP, Samba, WebDAV जैसे file server credentials handle करने वाला user agent है
  • Finder के “Go → Connect To Server” से file server से connect करते समय दिखने वाला authentication dialog NetAuthAgent या related processes द्वारा दिया जाता है
  • जब user password save checkbox चुनता है, तो credentials macOS Keychain में store होते हैं
  • NetAuthAgent खुद passwords सीधे store नहीं करता, बल्कि Keychain को central secret store की तरह इस्तेमाल करता है
  • Keychain items की अपनी access control list होती है, जो सामान्य तौर पर applications को उन secrets तक पहुंचने से रोकती है जिन तक उन्हें नहीं पहुंचना चाहिए
  • लेकिन अगर कोई particular process दूसरी processes की Keychain lookup उनकी ओर से करने वाला mechanism expose करे, तो पूरा security model कमजोर हो सकता है

कमजोर NetAuthAgent MIG service

  • NetAuthAgent ने bootstrap server से lookup की जा सकने वाली MIG server service expose की थी
  • service name com.apple.netauth.user.gui है
  • यह server file server credentials को read, create और कुछ मामलों में overwrite करने वाले routines देता था
  • पैच से पहले ये routines message sender को verify नहीं करते थे
  • Routine 19, message ID 40219, Keychain के internet password class items की lookup को proxy कर सकता था
  • यह routine serialized options dictionary को out-of-line data descriptor के रूप में लेता था, और username व password को दो out-of-line data descriptors के रूप में return करता था

attack flow और PoC संरचना

  • PoC ने Mach messages और MIG clients handle करने के लिए Swift में लिखे security research tool Kass का इस्तेमाल किया
  • NetAuthAgent client इन values से defined है
    • service name: com.apple.netauth.user.gui
    • subsystem base routine ID: 40200
  • lookup options Property List के रूप में serialize होते हैं, और Scheme, Host, AlternatePort, Path जैसे fields शामिल कर सकते हैं
  • macOS Keychain API SecItemCopyMatching, जब secret value request नहीं की जाती, तब unauthorized processes द्वारा भी Keychain items का metadata पाने के लिए इस्तेमाल किया जा सकता है
  • access control list भी metadata के रूप में accessible थी, जिससे यह check किया जा सकता था कि item की trusted application list में /System/Library/CoreServices/NetAuthAgent.app शामिल है या नहीं
  • attack code उन internet password items को iterate कर सकता था जिन्हें NetAuthAgent access कर सकता था, और नीचे की जानकारी निकाल सकता था
    • display name
    • protocol
    • host
    • port
    • path
    • username
    • password

file server credentials leak का असर

  • पैच से पहले NetAuthAgent के लिए send right हासिल करने वाली malicious process सभी file server credentials leak कर सकती थी
  • enterprise environments में ये credentials SSO credentials हो सकते थे, जिससे attacker को company systems के कई resources तक access मिल सकता था
  • Finder के Connect to Server feature का इस्तेमाल कितना व्यापक है, यह पता नहीं है, लेकिन कई universities और educational institutions के help documents students और staff को इस feature का इस्तेमाल बताते थे, और कुछ ने Keychain में save checkbox चुनने की सिफारिश की थी
  • print server vendors के printer connection guides भी मिले, और NetAuthAgent printer server credentials भी handle करता है
  • कम से कम एक document ने stored password update करते समय Keychain Access app को आम users के लिए handle करना मुश्किल बताकर save checkbox न चुनने की सलाह दी थी
  • managed devices में अगर वही credentials superuser credentials के रूप में भी इस्तेमाल होते हों, तो privilege escalation हो सकती है, लेकिन managed device testing न होने से इसकी पुष्टि नहीं हुई
  • अगर personal user ने Finder से NAS access किया और credentials save किए हों, तो NAS credentials भी attacker के सामने उजागर हो सकते थे
  • अगर वही credentials दूसरे internet accounts में reuse किए गए हों, तो वे accounts भी compromise हो सकते हैं
  • FTP, Samba और WebDAV के interfaces अच्छी तरह defined हैं, इसलिए credentials leak के बाद server files की browsing और exfiltration automate करना आसान है

Keychain का उपयोग कर अतिरिक्त दुरुपयोग

  • क्योंकि NetAuthAgent ने Keychain items create करने वाला routine भी expose किया था, malicious process arbitrary data को password field में डालकर छिपा सकती थी
  • यह तरीका disk पर सीधे write करने की activity से बच सकता है, इसलिए security software को bypass करने वाला data hiding method बन सकता है
  • Keychain के suspicious items को explicitly inspect करने वाले security software के बारे में कोई जानकारी नहीं है
  • malicious process legitimate credentials को Keychain में store भी कर सकती थी
  • अकेले इस behavior का असर सीमित हो सकता है, लेकिन attacker-controlled file server credentials store करने के बाद user को social engineering से लुभाने वाले combined attack में इसका इस्तेमाल संभव है

iCloud API tokens तक पहुंचने वाली exploit chain

  • Connect to Server इस्तेमाल न करने वाले users भी इस vulnerability के प्रभाव से मुक्त नहीं थे
  • अधिकांश macOS devices में ऐसे Keychain items होते हैं जिनकी ACL इतनी broad होती है कि NetAuthAgent उन्हें access कर सके
  • इस Keychain item में disk की एक specific file को decrypt करने वाली decryption key होती है
  • उस file में user की iCloud account information और API tokens होते हैं
  • attacker Keychain item और ज्ञात location की file का इस्तेमाल कर ये जानकारी प्राप्त कर सकता था
    • first name और last name
    • email address
    • email aliases
    • enabled features और endpoints
    • कई long-lived API tokens

iCloud tokens से संभव actions

  • Wojciech Reguła की पिछली research ने वही API tokens दूसरे तरीके से खोजकर दिखाया था कि नीचे का data leak हो सकता है
    • Contacts
    • Calendars
    • Reminders
    • Find My के जरिए user location
  • इन results में Reminders को छोड़कर बाकी items reproduce हुए
  • new accounts और migrated accounts के Reminders को Apple ने अधिक सुरक्षित CloudKit में move कर दिया है, जहां वे सिर्फ encrypted form में accessible हैं
  • अतिरिक्त रूप से संभव actions ये थे
    • contact photos leak करना
    • CloudKit lookup, लेकिन decryption संभव नहीं
    • iCloud key-value store data leak करना
    • iCloud backup metadata leak करना, जिसमें device serial number शामिल है
    • Find My से user के दूसरे devices की location leak करना
    • Find My से user के friends की location leak करना
    • Find My के जरिए lock, erase और play sound actions करना
  • CloudKit data decryption की जांच की गई, लेकिन पूरी नहीं हो सकी
  • यह संभावना खारिज नहीं की गई कि commercial forensic vendors इस API token और जरूरत पड़ने पर iOS device PIN का साथ में इस्तेमाल कर CloudKit data या iCloud backups में मौजूद CloudKit data decrypt कर सकते हैं

Apple का fix करने का तरीका

  • पैच के बाद NetAuthAgent message receive करते ही पहले sender की entitlement check करता है
  • entitlement code signing के समय binary से जुड़ने वाला key-value pair है
  • standard security settings वाले macOS में Apple Mobile File Integrity process execution के समय restricted entitlement check करता है, और proper provisioning profile न हो तो process terminate कर देता है
  • provisioning profile पर Apple का sign होना जरूरी है, इसलिए इस check को bypass करना मुश्किल बनाने के लिए design किया गया है
  • NetAuthAgent जिस entitlement की मांग करता है, वह यह है
    • key: com.apple.private.netauth.useragent.allow
    • value: boolean true
  • इस entitlement के बिना sender को NetAuthAgent response नहीं देता
  • Mach message receive करते समय kernel द्वारा लगाए जाने वाले trailer में audit token शामिल होता है
  • receiving task audit token से sender task को identify कर सकता है, और kernel से उस task की entitlement dictionary मांगकर value check कर सकता है

security structure की कमजोर कड़ी

  • file server credentials भले ही इस तरह store किए गए हों कि सिर्फ specific applications access कर सकें, अगर वही application दूसरी applications के lookup commands स्वीकार कर ले तो वह application weak link बन जाती है
  • iCloud API tokens भले ही disk पर encrypted file में store हों, अगर decryption key broad ACL वाले Keychain item में है तो वही ACL weak link बन जाती है
  • macOS में process injection को मुश्किल बनाने वाले security controls हैं, और कुल मिलाकर security infrastructure मजबूत माना जाता है
  • लेकिन इस vulnerability की तरह sender verification की एक simple missing check भी file server credentials और iCloud API tokens exposure तक ले जा सकती है

users के लिए recommended actions

  • अगर अभी संभव हो तो Advanced Data Protection enable करने की सिफारिश है
  • अगर आप iCloud को web browser से इस्तेमाल नहीं करते, तो iCloud data web access disable करना भी एक option है
  • iCloud website कभी-कभी Apple के iCloud apps से अलग API endpoints इस्तेमाल करती है
  • इस vulnerability से अब tokens access नहीं किए जा सकते, लेकिन वे पहले की vulnerabilities से expose हो चुके हैं और भविष्य में दूसरी vulnerabilities से expose होने की संभावना भी है
  • इस exploit का malicious actors द्वारा इस्तेमाल या खोजे जाने का कोई evidence नहीं है
  • फिर भी अगर credentials abuse को लेकर खास चिंता है, तो passwords बदलने चाहिए
  • जिन devices पर अक्टूबर 2024 के बाद macOS update नहीं हुआ है, उन्हें तुरंत update करना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-03-21
Hacker News की राय

  • लेख अच्छी तरह लिखा गया है, और इससे Apple द्वारा कुछ हद तक दबाने की कोशिश की गई वह zero-day याद आ गई जिसमें खाली password दो बार आज़माने पर root login bypass हो जाता था। करीब 2017 में, शायद 2018 में।
    root login box कहीं भी admin username डालकर password खाली छोड़कर login करने पर, पहली बार password गलत बताता था, लेकिन warning बंद करके दूसरी बार दबाने पर उसी user के रूप में login हो जाता था।
    उस दिन यह 100% reproduce हो रहा था और social media पर फैलने के बाद जल्द ही patch कर दिया गया, फिर भी यह बहुत बड़ा oversight लगा। लगता है Mac authentication mechanisms के आसपास अब भी पुराने अवशेष बचे हैं, और Mach kernel के port system का ज़िक्र भी दिलचस्प है।

    • खाली password दो बार वाली बात देखकर वह समय याद आया जब एक बिल्ली keyboard पर बैठकर Sun 3/60 को hack कर गई थी।
      username buffer 256 random characters तक पहुंचते ही XDM crash हो गया और root shell खुल गया। हालांकि यह 90s की शुरुआत की बात है, जब security को लेकर सब कहीं ज़्यादा भोले थे।
    • लगता है यह 2017 का था, और उस समय submit किए गए पोस्ट का शीर्षक था “macOS High Sierra: Anyone can login as “root” with empty password” - 3001 points | 1073 comments - https://news.ycombinator.com/item?id=15800676
    • वह तो कुछ भी नहीं। पहले कई सालों तक page file से किसी भी user का FileVault password grep की एक line से निकाला जा सकता था, और यह 100% काम करता था।
    • Mach के बारे में जानते हुए उसके core system को न जानना उल्टा हैरान करने वाला है। मेरे लिए तो port system ही Mach को समझाने वाली सबसे प्रतिनिधि बात है।
    • password-less login से जुड़ा CVE-2011-3226 भी मैंने report किया था, और यहां इसका reference है: https://support.apple.com/en-us/103345

  • “ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf

  • लेख में एक छोटा correction किया गया: entitlement check kernel की Mach layer में नहीं होता।
    https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
    यह XNU के व्यवहार को समझाने वाले हिस्से में factual error ठीक करने वाला एक-word change है।

  • “अगर कोई process ऐसा mechanism expose करता है जिससे दूसरा process keychain query को प्रभावी तौर पर proxy कर सके, तो यह पूरे system की security कमजोर कर सकता है” वाला हिस्सा confused deputy problem जैसा लगता है: https://en.wikipedia.org/wiki/Confused_deputy_problem
    capability-based design को इस तरह की problems को systematic तरीके से रोक पाना चाहिए।

    • Entitlements को भी capability की एक किस्म माना जा सकता है। अगर ऐसा है तो बात सही है, और असली समाधान भी यही था कि daemon से सीधे बात करने के लिए entitlement जरूरी बना दिया जाए।

  • जिज्ञासा है कि लेखक ने असली PoC code कहां दिया है। Mitigation testing थोड़ी करना चाहता हूं, लेकिन example code दिखता तो है पर अधूरा लगता है।
    realistic risk कितना है?

    • PoC code काम करना चाहिए। बस dependency के तौर पर Kass install करना होगा। ऐसा करने के बाद भी कोई और problem है तो जानना चाहूंगा कि क्या है।
      risk के लिहाज से, कोई भी app जो NetAuthAgent के लिए send right हासिल कर सकता है—असल में लगभग हर non-sandboxed app—FTP, WebDAV, Samba जैसे file drives के stored credentials को NetAuthAgent से चुपचाप request कर सकता है। इससे iCloud contacts और calendars का पूरा leak, और अन्य iCloud-related data leak भी हो सकता है।
      sandboxing इसे मुश्किल बनाता है, असंभव नहीं। अगर system up to date है तो risk 0 है, और patch पिछले साल October में आ गया था, इसलिए सच कहें तो अब तक update हो जाना चाहिए। अगर आपने update नहीं किया है और आगे भी नहीं करने वाले हैं, तो device पर चल रहे हर process को पूरी तरह verify न करने तक risk कहीं ज्यादा है।

  • बहुत detailed लेख है, और अलग-अलग kernels का इतिहास भी cover किया गया, यह अच्छा लगा। हालांकि अगर लेख किसी गंभीर security issue पर है, तो शुरुआत में impact scope, attack conditions, और यह logical error है या memory corruption जैसी बहुत छोटी explanation हो तो अच्छा होगा।
    बस इतना संक्षेप में हो कि बाकी पढ़ना है या नहीं, यह तय किया जा सके।

    • feedback के लिए धन्यवाद। readers को आगे पढ़ने के लिए जानबूझकर मुख्य बात थोड़ी देर से रखी थी, लेकिन वह perspective भी पूरी तरह समझ आता है।

  • सच में दिलचस्प लेख है। Mach और Darwin kernel बनने की प्रक्रिया में इतनी सारी backstories हैं, यह पता नहीं था।

  • अब तक तो Mach macOS bugs का स्थिर source जैसा लगने लगा है। पता है Apple इसे काफी lock down कर रहा है, लेकिन क्या Mach से पूरी तरह बाहर निकलने का कोई रास्ता है?

    • यहां bug की वजह Mach नहीं, बल्कि entitlement check की कमी लगती है। Entitlements सच में बहुत अच्छा security system है, लेकिन opt-in है।
      अगर daemon entitlement check नहीं करता, तो वह सुरक्षित नहीं है। messaging mechanism को दोष देने के बजाय उसके usage को दोष देना चाहिए।
      असल में किसी भी locked-down messaging system में simple message passing से आगे, जैसे sender verification, कुछ न कुछ चाहिए। Mach जैसे low-level communication protocol से यह अपने आप नहीं मिलता। जब तक Apple MIG compiler को revamp करके entitlement checks add नहीं करता, तब तक ऐसा ही है।
      entitlement checks के साथ इस्तेमाल किया जाए तो Mach शानदार है।
    • हाल ही में एक लेख था कि ज्यादा से ज्यादा हिस्सों को Mach से बाहर ले जाया जा रहा है। कुछ L4 में, कुछ user space में move हो रहे हैं।
      technically, ज्यादा अलग-अलग components साथ मौजूद होंगे, जिससे potential attack surface बढ़ भी सकता है। लेकिन ज्यादा specialized surface control को सरल बनाते हैं, और नतीजतन उस surface को बेहतर तरीके से protect कर सकते हैं।