1 लाइन के कोड से iPhone को brick किया जा सकता था: इसकी कहानी

 (rambo.codes)
2 पॉइंट द्वारा GN⁺ 2025-04-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Darwin Notification सिस्टम की विशेषताओं और कमजोरियों का इस्तेमाल कर iPhone को brick किया जा सकने वाले एक मामले का परिचय
  • इस कमजोरी को CVE-2025-24091 के रूप में दर्ज किया गया, और रिपोर्ट करने वाले को $17,500(25 लाख वॉन) का bug bounty मिला
  • बिना किसी विशेष permission के system-level notifications भेजे जा सकते थे, जिसका दुरुपयोग कर पूरे iOS device को निष्क्रिय किया जा सकता था
  • सिर्फ एक सरल one-line code से "Restore in Progress" मोड को मजबूरन ट्रिगर कर बार-बार reboot कराने वाला Denial of Service (DoS) attack संभव होने की पुष्टि हुई
  • iOS 18.3 update में महत्वपूर्ण Darwin Notification भेजने के लिए restricted entitlement अनिवार्य कर यह कमजोरी ठीक की गई

Darwin Notifications

  • Darwin Notifications iOS और macOS में processes के बीच सरल संदेशों के आदान-प्रदान के लिए CoreOS-level mechanism है
  • इसमें notify_post से event भेजा जाता है, notify_register_dispatch से event प्राप्त किया जाता है, और state value को पढ़ा या लिखा जा सकता है
  • बिना किसी विशेष permission के receive और send दोनों संभव थे, और कोई security verification process नहीं था
  • सिस्टम के कई components इस legacy API पर निर्भर थे

कमजोरी का अवलोकन

  • Apple operating systems के सभी processes Darwin Notifications प्राप्त कर सकते थे, और इसके लिए किसी विशेष permission की जरूरत नहीं थी
  • Sandboxed apps से भी Darwin Notification भेजना संभव था, जो एक संरचनात्मक खामी थी
  • data transfer की मात्रा सीमित होने के कारण sensitive data leak का जोखिम बहुत बड़ा नहीं था
  • लेकिन कुछ महत्वपूर्ण system notifications (जैसे restore start notification) भेजने पर पूरे सिस्टम पर असर पड़ सकता था
  • इसी वजह से Denial of Service (DoS) attack की संभावना सामने आई

EvilNotify और VeryEvilNotify

  • EvilNotify app के जरिए कई तरह की system प्रतिक्रियाएँ जबरन उत्पन्न की जा सकती थीं
    • liquid detection icon दिखाना
    • Wi-Fi बंद कर cellular का मजबूरन इस्तेमाल
    • lock screen और control center gestures को block करना
    • Find My Lost Mode में प्रवेश आदि
  • खास तौर पर, notify_post("com.apple.MobileSync.BackupAgent.RestoreStarted") की सिर्फ एक लाइन से डिवाइस को Restore in Progress स्थिति में डाला जा सकता था
  • यह मोड इसलिए fail हो जाता था क्योंकि डिवाइस वास्तव में restore नहीं हो रहा होता था, और इसका एकमात्र समाधान "restart" बटन दबाना था
  • VeryEvilNotify app ने widget extension का उपयोग कर reboot के बाद भी अपने-आप attack दोबारा शुरू होने लायक implementation बनाई
  • widget extension को सिस्टम background में समय-समय पर चलाता था, और वह notify_post function को call कर "restore in progress" मोड को बार-बार trigger करता था
  • नतीजतन, डिवाइस को पूरी तरह brick करने जैसा असर पैदा किया जा सकता था

Timeline और CVE पंजीकरण

  • 26 जून 2024: Apple को शुरुआती incident report submit की गई
  • 27 सितंबर 2024: Apple से संदेश मिला कि mitigation पर काम चल रहा है
  • 28 जनवरी 2025: समस्या का समाधान पूरा हुआ और bug bounty eligibility की पुष्टि हुई
  • 11 मार्च 2025: इसे आधिकारिक तौर पर CVE-2025-24091 के रूप में दर्ज किया गया और iOS/iPadOS 18.3 में ठीक किया गया
  • bug bounty राशि के रूप में 17,500 अमेरिकी डॉलर दिए गए

प्रतिक्रिया और mitigation

  • संवेदनशील Darwin Notifications भेजने के लिए अब restricted entitlement जरूरी कर दिया गया
  • उदाहरण के लिए, पहले का com.apple.MobileBackup.BackupAgent.RestoreStarted notification बदलकर com.apple.private.restrict-post.MobileBackup.BackupAgent.RestoreStarted कर दिया गया
  • notification प्राप्त करने वाले processes भी अब नया नाम इस्तेमाल करते हैं, ताकि अनधिकृत apps द्वारा मनमाना sending रोका जा सके
  • यह restricted entitlement व्यवस्था iOS 18.2 beta 2 से लागू होनी शुरू हुई थी और iOS 18.3 में पूरी तरह पूरी की गई

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

1 टिप्पणियां

 
GN⁺ 2025-04-28
Hacker News राय

  • यह दिलचस्प है कि यह API सेटिंग्स और नोटिफिकेशन पोस्ट करने से जुड़े सभी उपयोगों के लिए अनुमति नहीं मांगता

    • डिवाइस पर processes के बीच 64-बिट जानकारी साझा करने का एक तरीका मौजूद है
    • यह apps के बीच user tracking के लिए उपयुक्त फीचर है
    • अगर system value को store करता है और यह track नहीं करता कि वह किस app से आई, तो app को delete और reinstall करने के बाद भी persistent storage संभव है
    • इसका उपयोग IDFA या IDFV reset को bypass करने के लिए किया जा सकता है

  • वर्णित vulnerability डिवाइस को "brick" नहीं करती

    • recovery के लिए tethered restore की आवश्यकता होती है

  • $17,500 काफ़ी अच्छा है

    • अक्सर blog posts के लिए रकम कम होती है, या कंपनी vulnerability को fix कर देती है और reward नहीं देती
    • Apple ने 2019 के बाद इस मामले में सुधार किया है

  • शानदार काम

    • यह एक simple, effective और powerful vulnerability है
    • इससे 20 साल पहले कॉलेज के एक दोस्त के साथ सोची गई एक perfect server vulnerability याद आ गई
    • यह 2 साल पहले CVE-2022-23093 के रूप में सामने आई थी

  • कल्पना की जा सकती है कि जब iOS core team ने इसे review किया होगा, तब office में दिन कितना कठिन रहा होगा

  • code की एक line से डिवाइस को "recovery in progress" mode में डाला जा सकता था

    • कोई भी process notification भेजकर system को उस mode में होने का भ्रम दे सकता था

  • पुराने IRC दिनों की याद आती है

    • यह याद दिलाता है कि छोटा-सा बदलाव technology के लिए कितना ख़तरनाक हो सकता है
    • सोचता हूँ कि security आगे बढ़ रही है या बस लगातार leaks बंद कर रही है

  • इससे संकेत मिलता है कि अगर third-party app का अपना notification mechanism हो, तो उसकी भी इसी तरह नकल की जा सकती है

    • शायद डिवाइस को brick न किया जा सके, लेकिन दूसरे behaviors trigger हो सकते हैं

  • क्योंकि malicious app को user को सक्रिय रूप से install करना होगा, इसलिए इसकी priority कम हो सकती है

    • लेकिन उसका timeline भरोसा नहीं जगाता

  • यह लेख पढ़ने के लिए शानदार था

    • इसने दिखाया कि बहुत पुराना API कितना powerful था
    • यह iOS की low-level states को trigger करने वाला शानदार demo था
    • अब सोच रहा हूँ कि notify_post का क्या हुआ