MediaTek Wi-Fi chipset में गंभीर exploit: zero-click vulnerability

MediaTek Wi-Fi chipset में गंभीर भेद्यता: Zero-Click vulnerability (CVE-2024-20017) routers और smartphones के लिए खतरा

अवलोकन

• SonicWall Capture Labs threat research team ने CVE-2024-20017 भेद्यता की पहचान की, उसके प्रभाव का आकलन किया और mitigation उपाय विकसित किए
• CVE-2024-20017 एक गंभीर zero-click भेद्यता है जिसका CVSS 3.0 score 9.8 है, और यह MediaTek Wi-Fi chipset MT7622/MT7915 तथा RTxxxx SoftAP driver bundle को प्रभावित करती है
• MediaTek SDK version 7.4.0.1 और उससे पुराने version, तथा OpenWrt 19.07 और 21.02 प्रभावित हैं, जिनका उपयोग Ubiquiti, Xiaomi, Netgear जैसे विभिन्न manufacturers के products में होता है
• यह भेद्यता बिना किसी user interaction के remote code execution की अनुमति देती है, और MediaTek ने इसे कम करने के लिए patch जारी किया है
• यह भेद्यता मार्च में disclose और patch की गई थी, लेकिन हाल ही में public हुए PoC के कारण इसके exploit होने की संभावना बढ़ गई है

तकनीकी अवलोकन

• यह भेद्यता wappd में मौजूद है, जो MediaTek MT7622/MT7915 SDK और RTxxxx SoftAP driver bundle में शामिल एक network daemon है
• wappd wireless interface और access point को configure और manage करता है, खासकर Hotspot 2.0 technology के संदर्भ में
• wappd की architecture में network service स्वयं, device के wireless interface के साथ interact करने वाले local service sets, और Unix domain socket के ज़रिए components के बीच communication channel शामिल हैं
• यह भेद्यता buffer overflow के कारण होती है, जहां attacker द्वारा नियंत्रित packet data से सीधे लिया गया length value memory copy में इस्तेमाल किया जाता है

भेद्यता कैसे trigger होती है

• यह भेद्यता IAPP_RcvHandlerSSB function में होती है, जहां attacker-controlled length value को IAPP_MEM_MOVE macro में पास किया जाता है
• packet length 1600 bytes की अधिकतम सीमा से अधिक न हो, इसके अलावा कोई boundary check नहीं किया जाता
• attacker को packet भेजते समय expected structure को attack payload के आगे जोड़ना होता है
• RT_IAPP_HEADER structure की length छोटी होनी चाहिए, और RT_IAPP_HEADER.Command field 50 होनी चाहिए

Exploitation

• public exploit code ROP chain का उपयोग करके global address table overwrite technique के माध्यम से remote code execution हासिल करता है
• system() call का उपयोग attacker को reverse shell भेजने वाले command को execute करने के लिए किया जाता है
• reverse shell को Bash और Netcat tools से सेट किया जाता है

SonicWall protection

• SonicWall customers को इस भेद्यता के exploitation से बचाने के लिए निम्न signatures जारी किए गए हैं
  • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
  • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2

Mitigation recommendations

• क्योंकि exploit code public हो चुका है, users को strongly recommend किया जाता है कि वे संबंधित chipset के लिए latest firmware version में upgrade करें

संबंधित लिंक

• MediaTek security bulletin
• CoffinSec ब्लॉग
• Security Online जानकारी
• GitHub repository

GN⁺ का सार

• यह लेख MediaTek Wi-Fi chipset की एक गंभीर zero-click भेद्यता पर केंद्रित है, जो बिना user interaction के remote code execution की अनुमति देती है
• SonicWall research team ने इस भेद्यता की पहचान की और mitigation उपाय विकसित किए, तथा users को latest firmware में upgrade करने की सलाह दी
• यह भेद्यता विभिन्न manufacturers के routers और smartphones को प्रभावित करती है, और हाल ही में public हुए PoC के कारण इसके exploit होने की संभावना बढ़ गई है
• समान functionality वाले products में Qualcomm के Wi-Fi chipsets शामिल हैं, और security updates को नियमित रूप से जांचना महत्वपूर्ण है

[GN⁺]

Hacker News की राय

• MediaTek के vendor SDK driver source code को mt76 से compare करके देखने के नाते, यह बहुत चौंकाने वाला नहीं है। अच्छे शब्दों में कहें तो भी यह काफ़ी बिखरा हुआ है
  दुर्भाग्य से, mt76 से थोड़ा ज़्यादा throughput मिलता है, इस वजह से vendor driver डालकर बनाए गए कुछ third-party firmware builds भी चल रहे हैं
  अच्छी बात यह है कि MediaTek और WiSoC division में कुछ engineers हैं जो free और open source software community से सक्रिय रूप से संवाद करते हैं, और mt76-based एक छोटा OpenWrt fork भी खुद maintain करते हैं: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

  • ऐसे hardware/firmware को देखकर हमेशा ऐसा क्यों लगता है जैसे proof-of-concept code को production environment में deploy कर दिया गया हो। क्या सही जानकारी वाले लोगों को hire नहीं किया जा सकता
  • जानना चाहूंगा कि इस program का goal क्या है, या उस feed में से कितना upstream project में merge हुआ है—क्या इस बारे में कोई press release या जानकारी है

• title की wording थोड़ी misleading है। घर में mt76 Wi-Fi वाले कुछ routers हैं, इसलिए लगा कि firmware या silicon bug होगा और link खोला, लेकिन पता चला कि यह vendor के SDK के फालतू code का bug है, तो राहत मिली
  mainline kernel और hostapd में mt76 support काफ़ी अच्छा है, फिर भी किसी ने उसे इस्तेमाल करने की कोशिश क्यों की, यह समझ नहीं आता

  • “vendor के SDK के फालतू code का bug है, तो राहत मिली” कहना थोड़ा मुश्किल है, क्योंकि चिंता करने वाले vendors एक से ज़्यादा हैं
    इसमें लिखा है कि “Ubiquiti, Xiaomi, Netgear आदि सहित कई manufacturers के products में इस्तेमाल हुए driver bundle”
    हालांकि Ubiquiti जैसे कुछ vendors ने कहा है कि वे actual products में इसे use नहीं करते: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
  • OpenWRT 21.02.x series mainline kernel 5.4 पर based होने के बावजूद प्रभावित बताई गई है। इस तरफ़ के लोग Linux wireless networking को अच्छी तरह जानते हैं, और मेरी जानकारी में mainline kernel का mt76 driver भी एक OpenWRT developer ही maintain करता है

• original blog: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

  • wappd service मुख्य रूप से Hotspot 2.0 और संबंधित technologies का उपयोग करके wireless interfaces और access point behavior को configure और coordinate करने के लिए इस्तेमाल होती है
    application structure कुछ जटिल है, लेकिन मूल रूप से इसमें एक network service, device के wireless interfaces से interact करने वाली local services, और Unix domain sockets का उपयोग करने वाला components के बीच communication channel शामिल है
    थोड़ी राहत की बात यह है कि यह baseband firmware के अंदर का bug नहीं लगता, बल्कि wireless network card के core operation के लिए जरूरी न होने वाली किसी “value-added” service की समस्या जैसा लगता है
    यह उन कुछ devices के driver packages की याद दिलाता है, जहां actual driver छोटा और शांत होता है, लेकिन 99% users को जिन features की ज़रूरत नहीं होती और जिन्हें वे चाहते भी नहीं, उनके लिए कई digits बड़ा bundleware साथ में install कर दिया जाता है। Printers और GPUs इसमें खास तौर पर खराब हैं

• MediaTek के naming convention में कोई logic है या नहीं, या हर device बस MTxxxx है और x incrementing value या random number है, यह जानने की उत्सुकता है
  मेरे पास mt6631 Wi-Fi chip वाला device है, और यह affected list में नहीं है, इसलिए ठीक मान सकता हूं, लेकिन product family में यह कहां आता है, समझना मुश्किल है

• कहा गया है कि OpenWrt 19.07 और 21.02 प्रभावित हैं, लेकिन देखने में official OpenWrt builds Mediatek SDK नहीं बल्कि सिर्फ mt76 driver इस्तेमाल करते लगते हैं

  • Ubiquti भी ऐसा ही है: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    UBNT hardware में इस्तेमाल होने वाले कुछ chipsets के लिए vulnerable driver है, लेकिन कहा गया है कि कोई भी product उस driver का उपयोग नहीं करता

• AMD CPU वाले laptops खरीदो तो हमेशा MediaTek RZ616 Wi-Fi card साथ आता है, समझ नहीं आता क्यों
  मैंने सभी को Intel Wi-Fi card से replace कर दिया है, और अब मेरे पास RZ616 cards का ढेर है जो भविष्य के microplastics बनेंगे

  • Intel Wi-Fi cards दो तरह से बेचता है। जिन models का आख़िरी digit 1 होता है, वे CNVI protocol इस्तेमाल करते हैं और सिर्फ Intel chips पर काम करते हैं, और OEMs को बहुत सस्ते में बेचे जाते हैं
    जिन models का आख़िरी digit 0 होता है, वे standard PCIe इस्तेमाल करते हैं और OEMs के लिए करीब 10 dollars महंगे होते हैं
    AMD ने OEMs को Intel के xx1 chips जैसी price range में बेचने लायक चीज़ बनाने के लिए MediaTek MT7921 और MT7922 को क्रमशः RZ608 और RZ616 के रूप में rebrand किया
  • Lenovo भी MediaTek से नाराज़ हुआ और AMD platforms पर WLAN के लिए Qualcomm chips solder करना शुरू किया, लेकिन Linux पर firmware और driver interaction bug की वजह से फिर फंस गया। Lenovo Linux को officially बेचता और support करता है, फिर भी ऐसा हुआ
    Qualcomm में जब chipset generation latest नहीं रह जाती, तो mainline kernel support की क्षमता काफ़ी पतली हो जाती है। आजकल Qualcomm को move कराने के लिए जबरदस्त vendor pressure चाहिए
  • iwlwifi की अपनी समस्याएं भी हैं, और सबसे बड़ी बात यह है कि इसमें 5GHz AP mode नहीं है। Intel firmware license भी MediaTek से ज़्यादा restrictive है, और यह fullmac है, इसलिए firmware कहीं ज़्यादा काम अपने ऊपर लेता है
    निजी तौर पर मैं softmac को ज्यादा पसंद करता हूं। आजकल अच्छे options कम हैं, और ath9k का golden age बीत चुका है
  • सिर्फ “MediaTek पर भरोसा नहीं” से आगे, क्या आपने सच में इसे इस्तेमाल किया है, यह जानना चाहूंगा
    काम के लिए मैंने Intel ThinkPad और AMD ThinkPad लगातार इस्तेमाल किए, और AMD वाले MediaTek chipset Wi-Fi ने Intel वाले Intel chipset से कहीं बेहतर काम किया
    Intel side पर network connection एक घंटे में कई बार drop होता था, और 5GHz पर भी ssh इस्तेमाल करते समय latency तुरंत महसूस होने जितनी भयानक थी। अभी जो MT7921 device इस्तेमाल कर रहा हूं, वह Linux पर पिछले 2–3 साल से बहुत stable रहा है
    आखिरकार chipset और laptop combination के हिसाब से चीज़ें काफ़ी बदलती लगती हैं

• याद है कि मेरा phone भी MediaTek chipset इस्तेमाल करता है। और धुंधली याद है कि manufacturer ने बाद में MediaTek से दूर जाने की वजह उन products की, खैर, quality बताई थी
  phone में Wi-Fi कैसे configured होता है, मुझे नहीं पता। क्या यह check करने का कोई तरीका है कि मेरा phone प्रभावित है या नहीं? मेरे पास unlimited cellular data और अच्छी coverage है, इसलिए Wi-Fi बहुत कम इस्तेमाल करता हूं, लेकिन फिर भी जान लेना अच्छा होगा

  • termux में "sudo su" चलाएं और फिर ls /sys/module देखें
    output lsmod जैसा दिखेगा

• आजकल जब लोग उपलब्ध silicon जो भी हो खरीद रहे हैं, तब भी मुझे समझ नहीं आता कि ये C-grade vendors PC strategy follow करके firmware को पूरी तरह खोलकर open source community पर क्यों नहीं छोड़ देते

  • आम तौर पर FCC regulations, जिनमें authorized bands के बाहर transmit करना मुश्किल बनाना होता है, ऐसी स्थिति पैदा करते हैं

• लिखा है “affected versions में MediaTek SDK 7.4.0.1 और उससे नीचे, तथा OpenWrt 19.07, 21.02 शामिल हैं”, “vulnerability MediaTek MT7622/MT7915 SDK और RTxxxx SoftAP driver bundle में शामिल network daemon wappd में है”, लेकिन असल में OpenWRT wappd इस्तेमाल करता नहीं लगता

  • OpenWrt contributor के तौर पर मुझे समझ नहीं आता कि लोग OpenWrt और proprietary vendor SDK में फर्क क्यों नहीं करते। Nobara में bug होता तो Fedora का नाम नहीं लिया जाता
  • मैं अपने home network में कई Netgear APs पर OpenWRT चलाता हूं, इसलिए मुझे भी यही बात जाननी थी। इस explanation के हिसाब से क्या मैं ठीक हूं

• इसलिए free firmware की ज़रूरत है। Broadcom और Ralink से अब तंग आ चुका हूं