Pwnd Blaster: स्पीकर को छुए बिना स्पीकर के ज़रिए PC हैक करना

 (blog.nns.ee)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Creative Sound Blaster Katana V2X को Bluetooth की लगभग 15m रेंज के भीतर मौजूद हमलावर pairing या physical contact के बिना CTP commands और firmware update चलाकर surveillance device या remote Rubber Ducky में बदल सकता है
  • USB पर CTP static key आधारित challenge-response authentication मांगता है, लेकिन Bluetooth path वही CTP commands को GATT characteristic के ज़रिए बिना authentication स्वीकार करता है, जिससे जानकारी पढ़ना और settings बदलना संभव हो जाता है
  • firmware container FBOOT, FMAIN, CHK2 से बना है, और signature verification के बिना केवल SHA-256 checksum CHK2 सही होने पर patched firmware स्वीकार कर लिया जाता है
  • PoC में BLE के ज़रिए लगभग 10 मिनट तक custom firmware upload किया गया, जिसके बाद reboot हुआ स्पीकर USB HID keyboard की तरह echo pwned टाइप करके उसे execute करता है
  • Creative ने SingCERT के माध्यम से संपर्क किए जाने के बाद कहा कि यह “cybersecurity risk पेश नहीं करता”, इसलिए इसे vulnerability नहीं माना, और latest firmware अब भी vulnerable है; केवल CTP-over-Bluetooth को रोकने वाला unofficial patch उपलब्ध है

भेद्यता का सार

  • Katana V2X एक soundbar है जो USB के ज़रिए PC से जुड़ता है, और Creative app CTP के माध्यम से DSP, LED configuration, output source जैसी settings बदलता है
  • USB पर CTP commands लिखने के लिए पहले challenge-response authentication से गुजरना पड़ता है, और key एक static value है जिसे Creative App में शामिल binary से derive किया जा सकता है
  • firmware update भी CTP के ऊपर ही चलता है, और शुरुआती firmware image को Wireshark से USB traffic capture करके निकाला गया था
  • Bluetooth Low Energy में कभी-कभी pairing के बिना भी device से connect करके GATT characteristic पढ़ना और लिखना संभव होता है; pairing encryption बनाती है, लेकिन connection के लिए हमेशा ज़रूरी नहीं होती
  • Katana V2X firmware के अंदर internal CTP handler केवल USB ही नहीं बल्कि Bluetooth से भी जुड़ा हुआ था, और laptop से 5a 09 01 02 को characteristic 9e9daaec-3a10-4fe8-b69f-7397aff77886 में लिखने पर characteristic 9e9daaeb-3a10-4fe8-b69f-7397aff77886 से पूरा firmware version string पढ़ा जा सका

firmware verification और OTA attack chain

  • firmware container में recovery mode से जुड़ा FBOOT, normal boot में चलने वाला main firmware FMAIN, और पूरे container का SHA-256 checksum CHK2 मौजूद है
  • FBOOT और FMAIN /home/jieyi/mcuos2.5/kernel/freertos-8.2.3/ string से संकेतित FreeRTOS-आधारित code हैं, और FMAIN, FBOOT से लगभग 6.5 गुना बड़ा है
  • device ने patched firmware को तब स्वीकार किया जब CHK2 सही था, और WELCOME string को PATCHED में बदलने वाला firmware flash करने पर boot के समय segment display पर PATCHED दिखा
  • उसी firmware update प्रक्रिया को BLE पर फिर से लागू करने वाली Python script ने pairing या authentication के बिना custom firmware upload किया, और BLE speed की वजह से इसे पूरा होने में लगभग 10 मिनट लगे
  • स्पीकर में microphone है, इसलिए सैद्धांतिक रूप से custom firmware इसे covert monitoring device की तरह चला सकता है, जो बातचीत सुनकर Bluetooth के ज़रिए attacker तक भेजे

USB keyboard injection तरीका

  • Katana V2X सामान्य configuration में PC से USB के ज़रिए जुड़े trusted device की तरह काम करता है
  • device पहले से पूरा keyboard नहीं है, लेकिन volume और play/pause जैसे media control के लिए खुद को HID Consumer Control device के रूप में सेट करता है
  • firmware के USB report descriptor में दूसरा report descriptor entry जोड़कर device को keyboard के रूप में भी report कराया जा सकता था
  • firmware के भीतर HID data भेजने का routine पहले से मौजूद था, और दबाई जाने व छोड़ी जाने वाली keys का data देकर उसे call करने के तरीके से key input भेजा जा सकता था
  • execution flow को जटिल तरीके से bypass करने के बजाय, सामान्य उपयोग में लगभग कुछ न करने वाले diagnostic FreeRTOS task को overwrite करके custom code को boot पर चलाया गया
  • यह task लगभग 20 सेकंड तक USB subsystem के तैयार होने का इंतज़ार करता है, फिर लगभग 20ms के अंतराल पर echo pwned टाइप करता है, Enter दबाता है, और समाप्त हो जाता है
  • अंतिम patch में 83-byte का USB report, key input injector के लिए 102-byte ARM/Thumb assembly, और भेजे जाने वाले हर key input के लिए 2 bytes शामिल थे
  • वास्तविक attack में powershell.exe जैसे program को खोलकर malicious one-liner paste किया जा सकता है, और अगर attacker normal mode तथा recovery mode दोनों के firmware update routines को disable कर दे, तो malicious firmware हटाना और आगे patch लगाना असंभव हो सकता है
  • स्पीकर का Bluetooth power-saving mode में भी हमेशा चालू रहता है, और इसे बंद करने का कोई तरीका दिखाई नहीं देता

mitigation और disclosure timeline

  • Creative के पास public security contact नहीं था, और वेबसाइट के support form के अलावा सामान्य संपर्क माध्यम भी मुश्किल से मिले
  • support form के ज़रिए दो बार संपर्क की कोशिश के बाद SingCERT mediator के रूप में शामिल हुआ
  • Creative ने SingCERT को लगभग दो महीने बाद जवाब दिया और कहा, “यह cybersecurity risk पेश नहीं करता, इसलिए हम इसे vulnerability नहीं मानते”
  • Creative की ओर से कोई patch उपलब्ध नहीं है, और latest firmware भी vulnerable है
  • unofficial mitigation firmware में CTP-over-Bluetooth को block करता है, और इस बदलाव से Creative mobile app के टूटने की संभावना है
  • v2x-patcher Creative server से official firmware डाउनलोड करता है, memory में patch करता है, और फिर USB से जुड़े Katana V2X पर upload करता है
  • सभी tests और reverse engineering firmware version 1.3.230619.1820 पर किए गए थे

reverse engineering details

  • FMAIN.bin एक single image नहीं था, बल्कि scatter-loaded structure थी, जिसमें अलग-अलग file offsets अलग-अलग addresses पर load होते हैं
  • Ghidra auto analysis के लिए सही base address और memory map की ज़रूरत थी, और अनुमान लगाने के बाद device memory read से verify किए गए layout को लागू करने पर valid analysis result मिला
  • string pointers सीधे load नहीं होते थे, बल्कि movw और movt pairs के रूप में load होते थे; और उसी register में load होने वाले pairs को खोजकर जो valid memory को point करते थे, DATA references बनाने वाली script ने लगभग 13,000 references बनाए
  • हर बार firmware दोबारा flash किए बिना test करने के लिए CTP opcode 0x54 के echo handler को overwrite किया गया ताकि वह read, write और execute commands संभाल सके
  • अंतिम custom handler 96 bytes का था, और यह original handler के लगभग 106-byte आकार के भीतर समा गया
  • कई key inputs को mem-exec के ज़रिए USB handling task context में चलाते समय vTaskDelay delays जमा होने लगे, जिससे per-task watchdog के कारण device reboot हो गया
  • USB task से key input code सीधे call करने के बजाय उसे diagnostic service task में inject करने पर watchdog समस्या खत्म हो गई

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • यह देखकर हंसी आती है कि कुछ टिप्पणियाँ लेख को ठीक से पढ़े बिना, या बिल्कुल पढ़े बिना लिखी गई हैं। यह असल में Bluetooth डिवाइस बोर्ड के पब्लिक S3 bucket जैसी स्थिति है
    फिर भी किया गया काम वाकई शानदार है। मुझे लगा था कि USB से जुड़े डिवाइस को attack vector में बदलना इससे कहीं कठिन होगा, लेकिन सिर्फ keyboard का रूप धारण करके local terminal खोलना और malicious commands चलाना ही काफी है, यह काफ़ी मज़ेदार है। यह admin privileges वाला terminal नहीं है, इसलिए नुकसान कुछ हद तक सीमित रहेगा, लेकिन Windows में बहुत से users UAC prompt को बस क्लिक करके आगे बढ़ा देते हैं, इसलिए काफ़ी PCs पर full access मिल सकता है

  • SingCERT के ईमेल के मुताबिक vendor ने कहा कि “यह cyber security risk पैदा नहीं करता, इसलिए हम इसे vulnerability नहीं मानते।” बिना pairing के, किसी और के कंप्यूटर से USB द्वारा जुड़े डिवाइस पर wireless arbitrary firmware लिख पाना security vulnerability नहीं है, यह कहना है

    • मानो कहना हो, “सिर्फ कुछ अक्षर ही टाइप करवा सकते हैं, इसमें क्या ख़तरा है?”
      इससे यह सोचने पर मजबूर होना पड़ता है कि और कितनी peripheral कंपनियाँ ऊपर-ऊपर से तो चल रही हैं लेकिन security team के बिना काम कर रही हैं। ऐसे vulnerabilities शायद और भी बहुत हों, बस अभी मिले नहीं हैं। मेरा भाई एक बार रात 2 बजे इसलिए जाग गया था क्योंकि मोहल्ले के बच्चों ने Bluetooth speaker से connect होकर fart sounds को full volume पर loop में चला दिया था; वह malicious Bluetooth उपयोग का सिर्फ हिमखंड का सिरा था
    • अगर कोई Creative showroom, sales event, या CES जैसी जगह पर जाकर सारे devices को “patch” कर दे, तो उनका जवाब बहुत जल्दी बदल जाएगा
    • risk पर वह quote लगता है कि risk की अवधारणा को पूरी तरह गलत समझता है। पहले vulnerability होती है, फिर उसमें impact और likelihood जोड़ने पर risk बनता है
      परिभाषा के अनुसार, कम impact या कम likelihood के कारण low risk वाली vulnerabilities हमेशा मौजूद रहती हैं। CVE का score होता है, लेकिन वास्तविक risk और mitigation से पहले/बाद risk को स्वीकार करना है या नहीं, यह use case तय करता है। “no risk => no vulnerability” डिज़ाइन के हिसाब से गलत तर्क है; ज़्यादा से ज़्यादा “no vulnerability => no risk” से सहमत हुआ जा सकता है
    • यही बात macOS या Windows चलाने वाले किसी भी कंप्यूटर पर कही जा सकती है। आपका अपना software चला पाने का तथ्य अपने आप में vulnerability नहीं होता
      लेकिन reflashing interface का Bluetooth पर खुला होना अजीब है। मेरी जानकारी में speaker के साथ pair करने के लिए physical access चाहिए होता है
      सुधार: मैं गलत था। यह pairing के बिना काम करने वाला BTLE endpoint है। उस स्थिति में यह पूरी तरह बेतुकी vulnerability है। उम्मीद है इसे इस तरह patch किया जाएगा कि अपना software चलाने की क्षमता छीने बिना समस्या ठीक हो
    • मुझे याद भी नहीं कि मैंने Creative Labs के बारे में पहले क्या सीखा था, लेकिन इस मामले में उतरते समय भी पूरा भरोसा था कि Creative Labs किसी न किसी तरह इसे बिगाड़ेगा

  • लेख अच्छी तरह लिखा गया है और समझने में आसान है, इसलिए skim करने लायक है
    सार यह है कि Creative Sound Blaster Katana V2X soundbar पर Bluetooth के जरिए arbitrary firmware rewrite करने का तरीका मिल गया, और इसके लिए न के बराबर authentication या user interaction चाहिए
    यह soundbar USB के जरिए host computer से सीधे जुड़ता है, इसलिए firmware में descriptors जोड़कर इसे keyboard की तरह पहचान दिलाई जा सकती थी। उसके बाद PC को keystrokes भेजना आसान था। soundbar में microphone भी है, इसलिए attacker इसे bugging device में बदल सकता है
    Creative और SingCERT को इसकी रिपोर्ट दी गई, लेकिन कंपनी ने 2 महीने बाद जवाब दिया कि “यह cyber security risk पैदा नहीं करता, इसलिए हम इसे vulnerability नहीं मानते।”
    लेखक ने faulty transport protocol को disable करने वाला firmware patcher जारी किया। यह थोड़ा rough तरीका है और शायद official Bluetooth app functionality भी तोड़ दे, लेकिन manufacturer के सहयोग के बिना शायद यही सबसे अच्छा संभव उपाय था

  • पुराने manufacturers में भी अक्सर पहले device बनाया जाता है और software को बाद में जोड़ने वाली चीज़ की तरह देखा जाता है। सिर्फ security ही नहीं, patching, updates, और बदलते ecosystem जैसे software lifecycle पर भी लगभग ध्यान नहीं दिया जाता
    मैंने ऐसे मामले भी देखे हैं जहाँ device brand ने software किसी छोटी outsourcing development firm को दे दिया, फिर वह कंपनी बंद हो गई, गायब हो गई, या business ही समेट गई, और manufacturer के पास source code तक नहीं बचा। फिर device चलाने वाले software को सुधारने या fix करने की क्षमता ही नहीं रहती, और बाद में middleware, UI, और ad-hoc connection layers ऊपर-ऊपर चढ़ते जाते हैं

    • यह जितनी बार होता है, उतना डरावना है। आज के दौर में जब सस्ते computer और phone peripherals हर मिनट भारी मात्रा में बिक रहे हैं, तो कोई संस्था इन सब पर निगरानी और regulation कैसे करे, इसका व्यावहारिक तरीका लगभग नहीं है
      सच कहें तो “छोटे outsourced developers” के बजाय supply-chain hackers जैसे लोगों द्वारा firmware लिखे गए devices भी कम नहीं होंगे

  • इतना छोटा क्यों सोच रहे हो? speaker खुद भी attacker बन सकता है
    LLM इस्तेमाल करने वाला कोई भी script kiddie supply chain के रास्ते फैलने वाला worm बना सकता है। factory floor पर ही speakers hack करके उनमें Rickroll जैसा संगीत बजवाया जा सकता है
    तब भी क्या Creative यही कहेगा कि “यह cyber security risk पैदा नहीं करता”?
    बोनस यह कि अगर security hole बंद करते समय legitimate firmware flashing तक disable कर दी जाए, तो manufacturer को repair के लिए speaker को jailbreak करना पड़ेगा

    • डिवाइस में worm flash करो और RMA में भेज दो, बस
    • पहले शायद यह संभव था। नए models धीरे-धीरे कड़े restrictions ला रहे हैं, पुराने models को खत्म कर रहे हैं, और अब तो government ID तक मांगते हैं

  • यह अच्छा नहीं लगता कि manufacturer ने इसे vulnerability मानने से इनकार किया, इसलिए लेखक को third-party patch जारी करना पड़ा

    • इसमें हैरानी की क्या बात है? लेखक की hacking शानदार है, और अगर कोई target बनता है तो impact बड़ा हो सकता है, लेकिन बड़े पैमाने पर देखें तो असर बहुत छोटा है। manufacturer के पास चिंता करने की खास वजह नहीं है
      victim बनने के लिए आपके पास यह device होना चाहिए, attacker को यह पता होना चाहिए, और वह पास की दूरी पर होना चाहिए। Fight Club की लाइन याद आ जाती है
      A = field में लगे speakers की संख्या
      B = hack होने की संभावना वाला अनुपात
      C = औसत out-of-court settlement
      निर्णय: अगर recall या repair न करने की लागत recall की लागत से ज़्यादा हो जाए, तभी recall शुरू होगा। सबसे बड़ी लागत तब होगी जब लोग आगे से उनके speakers खरीदना बंद कर दें, लेकिन ऐसा होता नहीं दिखता

  • अगर मैं Mossad जैसी किसी संस्था को चला रहा होता, तो बजट का बड़ा हिस्सा खर्च करके बाज़ार में उपलब्ध सभी Bluetooth डिवाइस खरीद लेता, और काम की कमी झेल रहे Israeli computer science graduates को ऐसी vulnerabilities ढूँढ़ने पर लगा देता, फिर उन्हें आसानी से deploy किए जा सकने वाले tools के suite में बदल देता
    उदाहरण के लिए, अगर मैं चाहता कि Iranian government offices तक पहुँच रखने वाली कोई asset मोबाइल फ़ोन लेकर इमारत के अंदर घूमे और जितने संभव हों उतने कंप्यूटर अपने क़ब्ज़े में कर ले। सोचता हूँ, शायद वे वास्तव में यही कर भी रहे हैं

    • बात कुछ उलटी है। Israel में वैसे भी computer science graduates इतने ज़्यादा नहीं हैं। सबसे बेहतरीन talent तो पहले ही Unit 8200 से होकर आता है
      यह असल में लगभग पूरी तरह socialized computer engineering master's program जैसा है, और क्योंकि यह signals intelligence organization है, वहाँ ऐसी चीज़ें सिखाई जाती हैं। 2~3 साल की service पूरी होने पर student loans नहीं होते, सरकार startup seed funding भी काफ़ी देती है, और TLV ecosystem एक छोटे Bay Area की तरह चलता है
      माता-पिता के साथ रहना भी सामाजिक रूप से ज़्यादा स्वीकार्य है, इसलिए 20s के काफ़ी लोग बिना कर्ज़ के, कम monthly खर्च के साथ, military service से मज़बूत technical capability लेकर, startup hub में रहते हैं और capital तक उनकी पहुँच भी अच्छी होती है। नतीजा यह है कि खासकर cyber security में बहुत से unicorns निकलते हैं(https://www.techaviv.com/unicorns)
      US से तुलना करें तो वहाँ 4 साल undergraduate पर फोकस करना पड़ता है, भारी कर्ज़ लेना पड़ता है, किराया देना पड़ता है, और seed funding ढूँढ़ने के लिए संघर्ष करना पड़ता है। “टूटी हुई system की बची-खुची चीज़ों का थोड़ा फ़ायदा उठा लें” वाली सोच शुरू से ही successful system बनाने के नज़रिए को चूक जाती है
    • ऐसी training किसी भी देश के national security या intelligence budget में rounding error के बराबर होगी। अब तो AI से devices की शुरुआती scanning करके manual analysis के लायक candidates चुनने का काम भी automate किया जा सकता है
      अगर यह standard practice नहीं है तो मुझे काफ़ी हैरानी होगी। हाँ, यह भी हो सकता है कि productivity सोच से कम हो, इसलिए मेहनत के लायक न हो। फिर भी इस मामले को देखकर लगता है कि इससे अच्छे नतीजे मिल सकते हैं, और हमें इसे उन दूसरे intelligence तरीकों से तुलना करके देखना चाहिए जिनके बारे में हम नहीं जानते
    • उस प्रस्ताव के साथ-साथ, bug वाले यानी backdoor डाले हुए devices सीधे बनाकर बेचना शायद और आसान हो सकता है
      marketing आसान है, या bug ढूँढ़ना? :-)
    • ऐसा हो ही नहीं सकता कि दुनिया की सारी intelligence agencies यह न कर रही हों
    • NSO Group(https://en.wikipedia.org/wiki/NSO_Group) शायद कुछ ऐसा ही है। हो सकता है Israeli intelligence agencies सस्ते कबाड़ devices, या ऐसे महंगे कबाड़ devices में vulnerabilities डालती हों और NSO या NSO जैसी Israeli संस्थाएँ उनका इस्तेमाल करती हों। यह भी पहले से पता है कि वे pagers बेचते हैं

  • मैं firmware लिखता हूँ, खासकर Bluetooth-enabled devices firmware पर काम करता हूँ, और मेरी कंपनी ने इस website को block कर रखा है

  • जिसे technology से प्यार है, वह ऐसा ultra-smart speaker खरीदता है जो घर के सभी computers से connect हो जाए और Miles Davis बजते ही fresh coffee बना देने वाले ultra-smart coffee maker को भी control करे
    जिसे technology समझ में आती है, वह toaster के बगल में एक कुल्हाड़ी रखता है

    • यही hacker का मूल अर्थ है

  • मुझे अभी से इंतज़ार है कि कोई आधा-अधूरा channel इस पर वीडियो बनाएगा और लगभग 4 business days बाद उसे मेरे YouTube home screen पर धकेल देगा

    • तुम्हें पता है, अगर YouTube watch history save करना बंद कर दो, तो home screen ही गायब हो सकती है?
    • फिर भी वे पहले LinkedIn पर डालकर सारा नाम कमा सकते हैं