Android, Linux, macOS, iOS में Bluetooth की-इनपुट injection vulnerability

 (github.com/skysafe)
2 पॉइंट द्वारा GN⁺ 2023-12-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CVE-2023-45866 कई operating systems के Bluetooth stack में authentication bypass vulnerability है, जिससे user confirmation के बिना fake keyboard connect कर key input inject किया जा सकता है
  • नज़दीक मौजूद attacker बिना special equipment के, सिर्फ Linux computer और सामान्य Bluetooth adapter से app install करने, arbitrary commands execute करने, messages भेजने जैसी actions की कोशिश कर सकता है
  • vulnerable conditions platform के हिसाब से अलग हैं: Android में Bluetooth enabled होना मुख्य factor है, Linux/BlueZ में discoverable/connectable state, और iOS व macOS में Magic Keyboard pairing status असर डालता है
  • Android 11-14 में 2023-12-05 security patch level से mitigation मिलती है, लेकिन Android 4.2.2-10 के लिए fix नहीं है, और BlueZ में 2020 का fix default रूप से disabled था
  • password या biometric authentication मांगने वाली actions सिर्फ key input injection से पूरी नहीं की जा सकतीं, लेकिन unpatched devices short-range Bluetooth attacks के exposure में रह सकते हैं

Authentication के बिना Bluetooth key input injection

  • CVE-2023-45866 Android, Linux, macOS, iOS में unauthenticated Bluetooth keystroke injection allow करने वाली vulnerability है
  • कई Bluetooth stacks में attacker user confirmation के बिना discoverable host से connect कर सकता है और key input inject कर सकता है; यह authentication bypass संभव बनाता है
  • नज़दीक मौजूद attacker vulnerable device से unauthenticated Bluetooth connection बनाकर key input के रूप में ये actions कर सकता है
    • app install करना
    • arbitrary commands execute करना
    • messages भेजना
  • attack के लिए special hardware की जरूरत नहीं है; Linux computer और सामान्य Bluetooth adapter से इसे किया जा सकता है
  • पूरी exploit details और PoC script ShmooCon सप्ताह के दौरान 12-14 जनवरी को public की जाएंगी

Platform-wise attack conditions

  • यह vulnerability Bluetooth host state machine को धोखा देकर user confirmation के बिना fake keyboard से pairing कराने के तरीके से काम करती है
  • underlying unauthenticated pairing mechanism Bluetooth specification में मौजूद है, और implementation-specific bugs इसे attack surface के रूप में expose करते हैं
  • unpatched devices पर जरूरी conditions operating system के हिसाब से अलग हैं
    • Android: Bluetooth enabled हो तो vulnerable है
    • Linux/BlueZ: Bluetooth discoverable/connectable state में होना चाहिए
    • iOS और macOS: Bluetooth enabled हो और Magic Keyboard phone या computer से paired हो तो vulnerable है
  • attacker target phone या computer से pair होने के बाद victim के privileges के साथ key input inject कर सकता है
  • password या biometric authentication की जरूरत वाली actions सिर्फ key input injection से perform नहीं की जा सकतीं

MouseJack के बाद सामने आई पुरानी vulnerability

  • 2016 में public हुई MouseJack research Bluetooth नहीं, बल्कि peripherals के custom wireless protocols को target करती थी
  • यह research Apple Magic Keyboard को target कर Bluetooth और Apple environment की जांच करने के दौरान शुरू हुई
  • macOS और iOS में unauthenticated Bluetooth keystroke injection मिला, और दोनों platforms पर Lockdown Mode में भी इसका exploit किया जा सकता था
  • बाद में Linux और Android में भी similar vulnerabilities confirm हुईं, जिससे यह simple implementation bug से ज्यादा protocol flaw के करीब लगने लगा; Bluetooth HID specification जांचने पर पता चला कि यह दोनों ही है
  • कुछ vulnerabilities MouseJack से भी पुरानी हैं, और Android 4.2.2 तक keystroke injection reproduce किया जा सका

Android impact और patch status

  • testing में vulnerable पाए गए Android devices और versions ये हैं
    • Pixel 7, Android 14
    • Pixel 6, Android 13
    • Pixel 4a (5G), Android 13
    • Pixel 2, Android 11
    • Pixel 2, Android 10
    • Nexus 5, Android 6.0.1
    • BLU DASH 3.5, Android 4.2.2
  • 2023-12-05 security patch level Android 11-14 की vulnerability को mitigate करता है
  • Android 4.2.2-10 के लिए कोई available fix नहीं है
  • disclosure timeline इस प्रकार है
    • 2023-08-05: vulnerability Google को report की गई
    • 2023-12-06: public disclosure
  • Google ने कहा कि Android 11-14 को प्रभावित करने वाले issue का fix affected OEMs को उपलब्ध कराया गया है, और currently supported सभी Pixel devices को December OTA update से fix मिलेगा

Linux/BlueZ impact और patch

  • testing में vulnerable confirm हुए Ubuntu versions 18.04, 20.04, 22.04, 23.10 हैं
  • Google के अनुसार ChromeOS vulnerable नहीं है, और direct test नहीं किया गया, लेकिन BlueZ configuration vulnerability को mitigate करता हुआ दिखता है
  • Linux vulnerability 2020 में CVE-2020-0556 के रूप में fix की गई थी, लेकिन वह fix default रूप से disabled था
  • ChromeOS इस fix को enable करने वाला एकमात्र known Linux-based OS है
  • CVE-2023-45866 के लिए BlueZ patch 2020 वाले fix को default रूप से enable करता है
  • संबंधित BlueZ patch:
  • Ubuntu संबंधित जानकारी:
  • Debian संबंधित जानकारी:
  • Fedora संबंधित जानकारी:
  • disclosure timeline इस प्रकार है
    • 2023-08-10: vulnerability Canonical को report की गई
    • 2023-09-25: vulnerability Bluetooth SIG को report की गई
    • 2023-10-02: CERT/CC में case खोला गया
    • 2023-12-06: public disclosure

macOS और iOS impact

  • macOS पर testing में vulnerable confirm हुए devices ये हैं
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • macOS का Lockdown Mode attack को रोक नहीं पाता
  • macOS Sonoma 14.2 vulnerability को fix करता है
  • macOS disclosure timeline इस प्रकार है
    • 2023-08-01: vulnerability Apple को report की गई
    • 2023-12-06: public disclosure
  • iOS पर testing में vulnerable confirm हुआ device iPhone SE है, जो iOS 16.6 चला रहा था
  • iOS का Lockdown Mode भी attack को रोक नहीं पाता
  • iOS disclosure timeline इस प्रकार है
    • 2023-08-04: vulnerability Apple को report की गई
    • 2023-12-06: public disclosure

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

1 टिप्पणियां

 
GN⁺ 2023-12-17
Hacker News की राय

  • इसे जांचने के लिए मुझे थोड़ा खोजबीन करनी पड़ी, और सुरक्षित रहने के लिए Android पर Bluetooth को इस्तेमाल न होने पर बंद रखना बेहतर है। हालांकि इस्तेमाल के दौरान यह फिर भी असुरक्षित रहता है।
    मेरे Pixel को 2023-12-05 security update मिल चुका है और इसमें यह समस्या ठीक हो गई है, लेकिन Pixel के अलावा बाकी devices के बारे में मुझे नहीं पता।
    Linux पर /etc/bluetooth/input.conf खोलकर ClassicBondedOnly=true सेट कर सकते हैं। मेरे मामले में नई लाइन जोड़ने की जरूरत नहीं पड़ी, सिर्फ comment हटाना पड़ा। अगले bluetoothd version में default true होने वाला है, लेकिन अभी भी इसे manually सेट किया जा सकता है, और उसके बाद Bluetooth service restart करनी होगी।
    macOS या iOS के बारे में नहीं जानता क्योंकि मेरे पास वे devices नहीं हैं।

    • iOS update के बाद Bluetooth का हमेशा फिर से on हो जाना मुझे हमेशा खराब लगता था। मैं उसे वास्तव में इस्तेमाल भी नहीं करता, इसलिए यह क्यों होता है यह बात मुझे लंबे समय तक अजीब लगी।
      Wi-Fi भी Control Center में पूरी तरह बंद नहीं किया जा सकता, जैसे छेदों वाला cheese हो।
    • Fedora 38 के bluez v5.70-4 में लगता है 7 दिसंबर से default true है।
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • अफसोस है कि iOS पर Bluetooth बंद करना इतना झंझटभरा है। Android में swipe करके click करना होता है, लेकिन iOS में swipe, long press दो बार, और click दो बार करना पड़ता है।
      Android से आने के बाद कुछ समय तक कोशिश की, लेकिन आखिरकार छोड़ दिया।
    • उस पेज को देखने पर लिखा है कि यह सिर्फ उन चीज़ों पर काम करता है जिनमें password या biometric authentication की जरूरत नहीं होती।
      फोन इस्तेमाल में न हो तो उसे proactively lock रखना चाहिए, और अगर इस्तेमाल के दौरान key input भेजा जाए तो वह स्क्रीन पर दिखेगा, इसलिए सिर्फ Bluetooth on होने से बात इतनी डरावनी नहीं लगती।
    • मुझे जानना है कि GrapheneOS ने sunfish(4a) branch में इसे ठीक किया है या नहीं। मेरे पास Pixel 4a है इसलिए मैं Android 13 पर अटका हूं, और कार का दरवाज़ा खोलने के लिए Bluetooth चाहिए।
      अगर GrapheneOS ने इसे ठीक कर दिया है, तो शायद आखिरकार switch करने की वजह मिल जाए, लेकिन मौजूदा फोन ठीक चल रहा है इसलिए नया फोन खरीदना justify करना मुश्किल है।

  • यह दिलचस्प है कि Windows का बिल्कुल जिक्र नहीं हुआ। ऊपर से यह अच्छी खबर लगती है, लेकिन risk level का आकलन करने के लिए यह जानना जरूरी है कि Windows वास्तव में क्यों प्रभावित नहीं है।
    उदाहरण के लिए अगर Windows Bluetooth stack में BlueZ के ClassicBondedOnly=false जैसा कोई mechanism है, तो hardening करने वाले environment में यह देखना होगा कि वह value true है या नहीं।
    या फिर stack पूरी तरह अलग तरीके से काम करता हो, तो ध्यान देने वाली बातें भी बिलकुल अलग हो सकती हैं।
    मुझे PoC और demo से भरे बहुत से videos की उम्मीद है, लेकिन Windows की market share भी बड़ी है और घबराने वाले system administrators भी बहुत होंगे, इसलिए इस पर जानकारी मिलना अच्छा होगा। “अभी Windows पर attack करके नहीं देखा” भी उपयोगी जानकारी है।

    • हो सकता है यह खास हमला Windows पर काम न करता हो।
      लेकिन अगर आप Flipper Zero से Bluetooth device बनाएं, तो Windows client connect करते ही उसे keyboard मान लेता है और मनचाहा PowerShell command चलवा सकता है। मैंने खुद बस YouTube खोलकर RickRoll करने तक ही इसे इस्तेमाल किया है, कोई अवैध चीज़ नहीं की।
      अब मैंने Bluetooth सब जगह बंद कर दिया है, लेकिन Linux को खराब किए बिना bluez हटाने का तरीका नहीं पता।
    • शायद इसलिए कि Windows में Bluetooth आम दिनों में भी कम ही सही से काम करता है।
    • आपने कहा कि Windows Bluetooth stack, BlueZ के ClassicBondedOnly=false के बराबर है, क्या आपका मतलब ClassicBondedOnly=true था?
    • मेरा मानना है कि वजह बस यह है कि अभी तक Windows पर इसे आजमाया ही नहीं गया।

  • इंडस्ट्री ने फोन से physical audio connection हटाकर सबको wireless की तरफ धकेल दिया, और अब ऐसी खबर सामने आ रही है। बहुत बढ़िया, शाबाश।

    • USB-C DAC सस्ते हैं और आसानी से मिल जाते हैं।
    • यह vulnerability जुड़े हुए wireless keyboards और mice में key input inject करने की है.[1] फोन इंडस्ट्री के USB-C अपनाने के बाद wired connection पहले से कहीं आसान हो गए हैं।
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • यह vulnerability Bluetooth host state machine को धोखा देकर fake keyboard को user confirmation के बिना pair करा देती है। इसका आधार बनने वाला unauthenticated pairing mechanism Bluetooth specification में defined है, और implementation bugs इसे attackers के लिए exposed कर देते हैं।
    लेकिन इसे चुपचाप pair होने लायक बनाना क्यों चाहा गया होगा? मैं उस problematic mechanism के original purpose को थोड़ा और विस्तार से समझना चाहूंगा।

    • Bluetooth specification के हिसाब से यह कई non-computer devices के कारण है। उदाहरण के लिए पहला controller PlayStation से pair करते समय USB mouse लगाकर “allow pairing” पर click न करना पड़े, इसके लिए।
      वास्तव में प्रभावित devices में इसे क्यों रहने दिया गया, यह मुझे नहीं पता।
    • यह बस ज्यादा भोले समय का पुराना design है। नई specifications में इसकी अनुमति नहीं है, लेकिन compatibility अधिकतम रखने के लिए Bluetooth stacks में नया behavior disabled रखा गया था।

  • यह issue macOS 14.2 और iOS 17.2 में ठीक कर दिया गया है।
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • Arch Linux में यह bluez 5.70-2 से ठीक किया गया है [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • यह बात असर छोड़ती है: “उस समय Bluetooth इतना intimidating था कि मैंने बस मान लिया कि यह सुरक्षित होगा।” लगता है कि जटिल तकनीकी स्टैक के ऊपर कहीं न कहीं ऐसे लोग होंगे जो इसे सच में समझते हैं, और यह रेत पर बना महल नहीं होगा जिसे बस एक डंडे से टिकाकर रखा गया है — यह मिथक शायद उसी दबदबे की भावना से पैदा होता है

  • फोन या कंप्यूटर के खिलाफ यह व्यावहारिक होगा या नहीं, इस पर संदेह है, लेकिन अगर आपकी ज़िम्मेदारी kiosk को इस तरह मैनेज करने की है कि कोई उसे छेड़ न सके, तो ज़िंदगी थोड़ी और दिलचस्प हो गई है

    • करीब 10 साल पहले मैंने गलती से एक password-less VNC खुली हुई Linux मशीन को इंटरनेट पर expose कर दिया था। कुछ ही मिनटों में किसी ने कनेक्ट किया और automated key input से कुछ चलाने की कोशिश की, लेकिन वह साफ़ तौर पर Windows को target करने वाला व्यवहार था
      अगर एक भी backdoor सफलतापूर्वक लगा दी जाए, तो उसके बाद काम किया जा सकता है
      अगर यह targeted attack हो, तो स्क्रीन lock न लगे इसके लिए हर 1 मिनट में Shift key input भेजना, और बाद में खुद मशीन के सामने जाकर कुछ करना ही काफ़ी हो सकता है
    • कंप्यूटर पर ज़हरीला sudo या su कहीं छिपाकर $PATH में जोड़ना भी संभव लगता है

  • USB भी ऐसा ही है। “केवल charging” पोर्ट में keyboard जोड़ने पर वह काम करता है। मैंने इसे Android पर खुद आज़माया है, और यहाँ मुझे यह कहकर डांटा गया कि इसका वास्तविक दुरुपयोग संभव नहीं है

    • क्या Android पोर्ट का इस्तेमाल सिर्फ charging के लिए होता है? यह HDMI के लिए भी बहुत उपयोगी है, और peripherals के लिए भी इस्तेमाल हो सकता है
      फिर भी मैं इसे vulnerability नहीं मानता। यह बस एक उपयोगी feature है। यहाँ समस्या यह है कि कोई व्यक्ति यह काम यूज़र की नज़र में आए बिना, संवेदनशील काम के दौरान भी कर सकता है
      कल पोस्ट हुआ शानदार प्रोजेक्ट https://mitxela.com/projects/smsc भी इसी तरह फोन पर इस्तेमाल किया जा सकता था
    • मैं जानना चाहूँगा कि physically “केवल charging” पोर्ट वाला Android डिवाइस आखिर है कौन सा

  • Linux vulnerability 2020 में fix हो गई थी (CVE-2020-0556), लेकिन वह fix default में disabled ही रही। कहा जाता है कि सिर्फ ChromeOS ने उस fix को enable किया था, जबकि Ubuntu, Debian, Fedora, Gentoo, Arch, Alpine ने advisory जारी की थी

    • यह जाँचने में कि क्या यह NixOS में गया था, 30 सेकंड ही लगे[1]। फिर 30 सेकंड और देखने पर पता चला कि पोस्ट आने के एक दिन बाद, 2023-12-08 08:23 GMT+13 पर patch कर दिया गया था
      लेकिन अगर distro advisory में बस यह कहा जाए कि upgrade कर लेने से यह ठीक हो जाएगा[2], तो “fix default में off थी” का मतलब समझ नहीं आता। क्या इसका मतलब है कि upgrade के बाद भी manual config change चाहिए? NixOS का fix तो default को पलटता हुआ दिखता है
      अगर मतलब यह है कि जिन users ने explicitly ClassicBondedOnly=false सेट किया है, उन्हें इसे बदलना होगा, तो इसे कहीं अधिक स्पष्ट तरीके से लिखा जा सकता था
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1