3 पॉइंट द्वारा GN⁺ 2025-03-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • IoT डिवाइसों में व्यापक रूप से इस्तेमाल होने वाले ESP32 में ऐसे Bluetooth command मिले हैं जो सार्वजनिक दस्तावेज़ों में नहीं हैं, और 2023 तक यह chip 1 अरब से अधिक डिवाइसों में मौजूद होने के कारण इसका प्रभाव क्षेत्र बड़ा है
  • Tarlogic Security ने RootedCON में ESP32 Bluetooth firmware के vendor-specific command 29 सार्वजनिक किए और संकेत दिया कि इनके जरिए RAM·Flash read/write, MAC address spoofing, और LMP/LLCP packet injection संभव हो सकता है
  • ये command trusted device impersonation, unauthorized data access, network के भीतर lateral movement, और long-term persistence तक ले जा सकते हैं, और इन्हें CVE-2025-27840 के तहत ट्रैक किया जा रहा है
  • वास्तविक remote exploitation इस बात पर निर्भर करती है कि डिवाइस का Bluetooth stack HCI command को कैसे handle करता है, और malicious firmware·malicious update·या पहले से हासिल root access होने पर इसकी प्रासंगिकता बढ़ जाती है
  • Espressif ने कहा कि ये internal testing के लिए debug command हैं और अपने आप में ESP32 के लिए security risk नहीं बनाते, लेकिन भविष्य के software update में undocumented command हटाए जाएंगे

ESP32 में बचे हुए undocumented Bluetooth command

  • चीनी निर्माता Espressif के ESP32 microchip में ऐसे Bluetooth command शामिल हैं जो सार्वजनिक दस्तावेज़ों में नहीं हैं
  • ESP32 एक microcontroller है जो IoT डिवाइसों को Wi-Fi और Bluetooth connectivity देता है, और 2023 तक इसका उपयोग 1 अरब से अधिक डिवाइसों में हो चुका था
  • मिले हुए command का इस्तेमाल निम्न कामों के लिए किया जा सकता है
    • trusted device की तरह दिखने के लिए spoofing
    • unauthorized data access
    • network के भीतर दूसरे डिवाइसों तक पहुँचना
    • long-term persistence हासिल करना

Tarlogic की खोज और research tool

  • स्पेन की Tarlogic Security के Miguel Tarascó Acuña और Antonio Vázquez Blanco ने Madrid के RootedCON में अपने research result प्रस्तुत किए
  • शोधकर्ताओं का कहना है कि Bluetooth security research में रुचि कम हुई है, लेकिन इसका कारण यह नहीं है कि protocol या implementation अधिक सुरक्षित हो गए हैं
  • हाल में प्रकाशित कई attack में या तो working tool नहीं थे, या वे general-purpose hardware पर काम नहीं करते थे, या पुराने और बिना maintenance वाले tool पर निर्भर थे जो modern system के साथ ठीक से फिट नहीं बैठते थे
  • Tarlogic ने C-आधारित नया USB Bluetooth driver विकसित किया
    • यह hardware-independent है और cross-platform काम करता है
    • यह OS-specific API पर निर्भर हुए बिना hardware तक direct access दे सकता है
    • यह Bluetooth traffic तक raw access संभव बनाता है

command जो low-level control की अनुमति देते हैं

  • ESP32 Bluetooth firmware में छिपे हुए vendor-specific command की पुष्टि हुई
    • Opcode है 0x3F
    • यह Bluetooth function को low level पर control करने देता है
  • मिले हुए undocumented command कुल 29 हैं
  • मुख्य क्षमताएँ निम्न से जुड़ी हैं
    • RAM और Flash पर memory manipulation
    • MAC address spoofing के जरिए device impersonation
    • LMP/LLCP packet injection
  • क्योंकि Espressif ने इन command को सार्वजनिक रूप से document नहीं किया था, इसलिए संभव है कि इन्हें सुलभ बनाने का इरादा नहीं था या वे गलती से रह गए
  • इस समस्या को CVE-2025-27840 के तहत ट्रैक किया जा रहा है

attack की संभावना और व्यावहारिक सीमाएँ

  • शोधकर्ताओं का मानना है कि ये command OEM-स्तर के malicious implementation या supply chain attack के जोखिम तक ले जा सकते हैं
  • remote exploitation की संभावना इस पर निर्भर करती है कि डिवाइस का Bluetooth stack HCI command को किस तरह process करता है
  • निम्न स्थितियों में remote exploitation की संभावना बढ़ सकती है
    • attacker ने पहले से root access हासिल कर लिया हो
    • malware पहले से मौजूद हो
    • low-level access खोलने वाला malicious update वितरित किया गया हो
    • malicious firmware या rogue Bluetooth connection शामिल हो
  • सामान्य रूप से, डिवाइस के USB या UART interface तक physical access अधिक व्यावहारिक attack scenario माना जाता है
  • Tarlogic के अनुसार, ESP32 वाले IoT डिवाइस से समझौता होने पर हमलावर ESP memory में APT छिपा सकते हैं, Wi-Fi/Bluetooth के जरिए डिवाइस को control कर सकते हैं, और दूसरे डिवाइसों पर Bluetooth या Wi-Fi attack चला सकते हैं
  • RAM और Flash को modify करने वाले command ESP32 chip के पूर्ण control और chip-level persistence तक ले जा सकते हैं

Espressif की सफाई और fix plan

  • BleepingComputer ने शुरुआत में Espressif से टिप्पणी माँगी थी, लेकिन तुरंत जवाब नहीं मिला
  • बाद में Espressif ने Tarlogic की खोज पर आधिकारिक बयान जारी किया
  • कंपनी ने कहा कि मिले हुए function internal testing के लिए debug command हैं
    • ये Bluetooth technology में इस्तेमाल होने वाले HCI (Host Controller Interface) protocol implementation का हिस्सा हैं
    • HCI का उपयोग product के भीतर Bluetooth layers के बीच communication के लिए होता है
  • Espressif का कहना है कि debug command की मौजूदगी अपने आप में ESP32 chip के लिए security risk नहीं बनाती
  • फिर भी undocumented command हटाने के लिए software fix दिया जाएगा

शब्दावली संशोधन और article update

  • 9 मार्च 2025 के update में, undocumented command को “backdoor” कहने पर उठी चिंताओं को दर्शाते हुए title और main text को संशोधित किया गया
  • 8 मार्च 2025 को Tarlogic का पक्ष जोड़ा गया
  • 9 मार्च 2025 को CVE ID जोड़ा गया
  • 10 मार्च 2025 को Espressif का आधिकारिक बयान जोड़ा गया

1 टिप्पणियां

 
GN⁺ 2025-03-09
Hacker News की राय
  • मुझे लगता है शीर्षक थोड़ा भ्रामक है। अगर मैंने सही पढ़ा है, तो यहां जिस backdoor की बात हो रही है, वह कंप्यूटर को अपने USB Bluetooth adapter की memory और low-level functions पढ़ने-लिखने देने वाली चीज है।
    ऐसा नहीं लगता कि इसे wireless तरीके से exploit किया जा सकता है। ऐसे undocumented debugging commands आम हैं, और मैंने WiFi adapters और GPS receivers में भी इसी तरह की functionality देखी है। इन्हें बस chip firmware या vendor driver को reverse engineer करके खोजा गया था, documented नहीं थे, और अपने आप में इनका बड़ा असर नहीं था। अगर यह unsigned firmware की अनुमति देता है, तो वही समान रूप से vulnerable है।
    अगर इसे host के अलावा कहीं और से इस्तेमाल किया जा सकता है, तो बात पूरी तरह अलग हो जाएगी।

    • open hardware के नजरिए से ऐसे भड़काऊ शीर्षक सच में नुकसानदेह हैं। debugging interfaces और firmware updates को “backdoor” और “security vulnerability” कहने पर स्वाभाविक प्रतिक्रिया सब कुछ lock down कर देने की होती है।
      Espressif इस क्षेत्र में लगभग असाधारण रूप से open रहा है। उसने अपने chips के लिए open source Rust toolchain में भी योगदान दिया है, और license code की वजह से release न कर पाने वाले modem stack को publicly reverse engineer करने के लिए प्रोत्साहित तक किया है। मुझे अच्छा नहीं लगता कि थोड़ा भी open रुख दिखाने की कीमत खराब और नुकसानदेह publicity बने।
    • HCI commands में अतिरिक्त flaws के बिना remote access नहीं होता। article में मुख्य वाक्य यह है:
      “device में Bluetooth stack HCI commands को कैसे handle करता है, इस पर निर्भर करते हुए, malicious firmware या malicious Bluetooth connection के जरिए backdoor का remote exploitation संभव हो सकता है।”
      संक्षेप में, अगर आपके पास safe driver stack है और आप सारे local code पर trust करते हैं, तो HCI vendor extensions समस्या नहीं हैं।
      हालांकि HCI extensions आसानी से security holes बन सकते हैं। समस्या यह है कि HCI attacker-controlled input, complex interface और कठिन parsing को मिला देता है। कुछ साल पहले BleedingTooth vulnerability ने दिखाया था कि गलती करना आसान है।
      ऐसी functionality हो तो दूसरी vulnerabilities से pivot करना भी आसान हो जाता है, लेकिन ज्यादातर systems में यह low-hanging fruit जैसा है।
      [0] https://google.github.io/security-research/pocs/linux/bleedi...
    • अगर अपने Bluetooth adapter की memory पढ़ने-लिखने वाला कंप्यूटर Web Bluetooth API पर चलने वाले software से ऐसा कर सके तो? उम्मीद है यह इतना खराब नहीं होगा, लेकिन अगर ऐसा है तो यह ऊपर वाली व्याख्या से डरावने ढंग से मेल खाता है।
      web API वाले सबसे खराब मामले को छोड़ भी दें, तो मान लीजिए आप risk से बचने के लिए किसी आधे-अधूरे भरोसे वाले software को 3 nested VMs के अंदर चलाते हैं। वह software Bluetooth access की जरूरत के लिए कोई plausible वजह देता है, और आप exception allow कर देते हैं। परिणाम पसंद नहीं आता, आप software हटा देते हैं और तीनों VM layers भी reset कर देते हैं। लगता है सब खत्म हो गया, लेकिन access मिलने पर malware ने ESP में जो install किया था, वह अब भी बचा हो सकता है।
      अपने subordinate device तक undocumented access, खासकर जब persistence जुड़ी हो, सच में बहुत खराब चीज बन सकती है।
    • किसी attacker के लिए, जिसने किसी दूसरे exploit से पहले ही access हासिल कर लिया हो, यह काफी उपयोगी हो सकता है।
      आप ऐसी स्थिति सोच सकते हैं जहां ESP32 standalone SoC नहीं, बल्कि host system से serial link के जरिए जुड़ा WiFi/Bluetooth “modem” के रूप में इस्तेमाल हो रहा हो।
      theory में attacker undocumented commands से आसपास के Bluetooth devices scan कर सकता है, spoof कर सकता है या attack कर सकता है। शायद ESP32 को host करने वाले device पर root privileges हासिल किए बिना भी यह संभव हो।
    • पढ़कर लगा कि सच में मामूली बात को बहुत बढ़ा-चढ़ाकर पेश किया गया है।
      उन्हें यह जानकर हैरानी होगी कि root privileges के साथ OS के अंदर से disk drive firmware फिर से लिखा जा सकता है।
  • researchers ने जो पाया है, वह एक undocumented hardware feature है जो पहले से code execution privileges रखने वाले व्यक्ति को ESP32 WiFi stack में उम्मीद से ज्यादा गहरी low-level access देता है।
    इसे “backdoor” कहना pure clickbait है।

  • उलझन है। क्या इसका मतलब है कि Bluetooth stack में कुछ undocumented commands हैं? अगर केवल वही code access कर सकता है जो पहले से device पर चल रहा है, तो इसे backdoor कहना मुश्किल लगता है।

    • “device में Bluetooth stack HCI commands को कैसे handle करता है, इस पर निर्भर करते हुए, malicious firmware या malicious Bluetooth connection के जरिए backdoor का remote exploitation संभव हो सकता है।”
      यह remote code execution जैसा नहीं लगता।
    • सहमत। यह काफी आम बात है और firmware update से बुरा भी नहीं है। हालांकि संभावित trap यह है कि in-band debugging शायद host permissions की वही मांग न करे जिसकी firmware update से उम्मीद होती है।
      इसलिए user-space program, या इससे भी बुरा WebBLE program, adapter में persistent malicious payload जोड़ सकता है। drive बदलने के बाद भी बचा रहने वाला tracking beacon डरावना है, लेकिन remote code execution नहीं है।
  • theory में, connected Bluetooth radio chip itself तक low-level access होना चाहिए, इसलिए मुझे लगता है यह कुछ हद तक expected नहीं है क्या?
    ऐसे low-level interface वाले devices बेहतर होते हैं। समस्या उसके अस्तित्व में नहीं, बल्कि documentation की कमी में हो सकती है।
    पहले Qualcomm radio chips में USB के जरिए memory read/write commands से locked devices को unlock करके ownership ले लेते थे। वह पूरी तरह out-of-band read/write था, इसलिए शायद उतना अच्छा नहीं था, लेकिन अगर इसे केवल flashed code से ही access किया जा सकता है, तो यह बल्कि बेहतर है।

  • Spanish slides: https://www.documentcloud.org/documents/25554812-2025-rooted...

  • संक्षेप में, firmware को reverse engineer करके ऐसे HCI commands पाए गए जो memory read/write, packet भेजने, MAC address सेट करने जैसे काम करते हैं
    यह असल में कोई backdoor नहीं है। researchers ने इसे ऐसा कहा है या presentation Spanish में होने की वजह से मुझे समझ नहीं आया, या journalists ज़्यादा clicks पाने के लिए इसे backdoor कह रहे हैं—यह भी नहीं पता
    इन commands का इस्तेमाल करने के लिए device को HCI commands भेजने की arbitrary access permission चाहिए। यानी आप पहले से ही device और उसके काम करने के तरीके को control कर रहे हैं। यह wireless link के ज़रिए remotely exploit होने वाली चीज़ नहीं है। कोई भी exploit हो, उसके लिए पहले से पूरे device का control होना ज़रूरी है, और उस point पर MAC address बदलना या packets भेजना कोई चौंकाने वाली बात नहीं है
    research दिलचस्प है, लेकिन इसे “backdoor” के तौर पर package किया जाना सच में उत्साह ठंडा कर देता है। wording की ज़िम्मेदारी किसकी है, पता नहीं, लेकिन लगता है journalists की होगी
    ज़्यादा परिचित तुलना के तौर पर सोचें कि किसी common IoT chip का Ethernet controller firmware के निर्देश पर MAC address बदल सकता है या arbitrary packets भेज सकता है—ऐसा discover किया गया। फर्क बस इतना है कि यह Bluetooth है; बात वही है

    • researchers खुद ही इसे backdoor कह रहे हैं। website पर डाली गई English announcement है
      https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
    • MAC address setting से जुड़ा मज़ेदार तथ्य: online बिकने वाले बहुत सस्ते USB Bluetooth adapters में से काफी के पास वही MAC address होता है। शायद unique value में बदलने की मेहनत नहीं की गई
      इसलिए https://macaddresschanger.com/ जैसे Windows tools और Linux का bdaddr मौजूद हैं। ज़्यादातर CSR design के clones लगते हैं, और address set करने वाला command भी अच्छी तरह known है। https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...
    • क्या यह नहीं दिखता कि अगर Ethernet cable लगी कोई भी arbitrary device अपना MAC address बदल सकती है और arbitrary packets भेज सकती है, तो वह अपने-आप में worm की तरह फैल सकने वाला threat actor बन सकती है?
      यहां तो Ethernet cable की requirement भी हटा दी गई है
      “Free Candy / BLE Persistent Threats” लिखा हुआ white van चलाते हुए, China जाते रास्ते में metal detectors से गुजरते समय devices को loot किया जा सकता है
      wireless है, worm की तरह फैल सकता है, arbitrary packets भेजता है, arbitrary devices को spoof कर सकता है—फिर भी आपको समस्या नहीं दिखती?
  • मुझे ऐसे sensational articles पसंद नहीं हैं। अब लगता है Espressif पर और ज़्यादा closed होने का pressure महसूस होगा

    • अगर यह documented होता, तो शुरुआत से ही समस्या नहीं बनता
  • desktops और laptops पर हम kernel space में चलने वाले opaque binary blob drivers आराम से install कर लेते हैं, cloud-controlled अपने phone पर root access भी नहीं होता, लेकिन ESP32 के कुछ undocumented low-level commands—जिनके लिए device पहले से compromised होना चाहिए—newsworthy threat vector बन जाते हैं
    सच में उत्सुक हूं कि translation में कहीं कुछ छूट तो नहीं गया। पहले के समय में होता तो मैं बस इसे cool मानता और इसे software-defined radio में बदलने का तरीका ढूंढता

    • कोई फिर से exaggerated hype पर पल रहा है। कम जानकार public को डराता है और reverse engineering community को नुकसान पहुंचाता है
  • research खुद अच्छी है, लेकिन title खराब है। attack vector के तौर पर देखें तो physical access चाहिए, और लगभग हर case में यही काम दूसरे तरीकों से भी पहले से किया जा सकता है
    “common Bluetooth chip में undocumented commands मिले” जैसा title बेहतर होता

    • hardware hacking के नज़रिए से यह दिलचस्प हो सकता है। existing hardware से extra functionality निकालने का legitimate तरीका लगता है
  • यह title झूठ है। Bluetooth chip में backdoor का मतलब ऐसा होना चाहिए जिससे wireless attacker को chip पर code execution मिल सके
    यह article connected device के device driver को chip पर code execution पाने देने के बारे में है, जो कोई security boundary violate नहीं करता
    अगर media ecosystem ठीक से काम कर रहा होता, तो correction report की ज़रूरत होती और article लिखने वाले outlet की reputation को भी बड़ा नुकसान होना चाहिए था। अफसोस, ऐसा कुछ नहीं होगा