ASUS के प्री-इंस्टॉल्ड ड्राइवर सॉफ़्टवेयर में one-click RCE कमजोरी मिली

 (mrbruh.com)
2 पॉइंट द्वारा GN⁺ 2025-05-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ASUS के DriverHub सॉफ़्टवेयर में one-click remote code execution (RCE) कमजोरी मिली
  • लोकल स्तर पर origin validation की कमजोरी के कारण कोई malicious वेबसाइट RPC के जरिए admin privileges के साथ execution कर सकती है
  • UpdateApp endpoint का दुरुपयोग करने पर ASUS-signed executable और manipulated ini फ़ाइल के संयोजन से malicious code चलाया जा सकता है
  • इस कमजोरी को CVE-2025-3462, CVE-2025-3463 के रूप में सार्वजनिक किया गया, और ASUS ने जल्दी patch जारी किया
  • कमजोरी की रिपोर्ट के समय वास्तविक दुरुपयोग का कोई मामला नहीं मिला, और ASUS ने bug bounty की जगह hall of fame में नाम जोड़कर इनाम दिया

Introduction

  • यह कहानी नए PC parts खरीदने की चर्चा से शुरू होती है
  • ASUS motherboard खरीदने पर BIOS का automatic software install option डिफ़ॉल्ट रूप से enabled था
  • विकल्प बंद करना भूल जाने पर Windows login के बाद DriverHub install permission prompt मिला
  • WiFi driver की ज़रूरत होने के कारण जिज्ञासा में DriverHub इंस्टॉल किया गया

DriverHub

  • DriverHub एक background process है जो GUI के बिना चलता है
  • यह driverhub.asus.com से communicate करके बताता है कि कौन से drivers install/update करने हैं
  • लोकल में यह HTTP API (port 53000) को RPC के रूप में उपलब्ध कराता है
  • वेबसाइट इस local service को API requests भेजकर सीधे drivers manage कर सकती है
  • इससे यह स्पष्ट हुआ कि अगर security कमजोर हो तो attacker arbitrary requests भेज सकता है

Finding the Vulnerability

  • यह परीक्षण किया गया कि क्या कोई वेबसाइट DriverHub backend को arbitrary RPC requests भेज सकती है
  • इसे इस तरह बनाया गया था कि केवल “driverhub.asus.com” origin होने पर ही response मिले
  • यह जांचा गया कि origin check origin.includes("driverhub.asus.com") जैसे wildcard match से हो रहा है या नहीं
  • Origin को “driverhub.asus.com.mrbruh.com” करने पर request allow होना पाया गया
  • इससे पुष्टि हुई कि attacker किसी malicious साइट से RPC calls कर सकता है, जो गंभीर जोखिम है

The Extent of the Damage

  • reversing और JavaScript analysis के जरिए background में उपलब्ध API endpoints की सूची पता की गई
  • मुख्य endpoints:
    • Initialize: install status और जानकारी लौटाता है
    • DeviceInfo: installed ASUS software/drivers/hardware/MAC address लौटाता है
    • Reboot: तुरंत reboot करता है
    • Log: log files का सेट लौटाता है
    • InstallApp: दिए गए ID वाला app या driver install करता है
    • UpdateApp: दिए गए URL से executable download कर चलाता है (अगर ASUS-signed हो तो auto-execute)
  • खास तौर पर UpdateApp के exploit होने की संभावना पर ध्यान दिया गया

Achieving RCE

  • UpdateApp endpoint का विस्तार से analysis किया गया
  • “Url” parameter में .asus.com शामिल होने की शर्त थी, लेकिन bypass की संभावना मौजूद थी; filename URL के अंत से तय होता है
  • केवल ASUS-signed executables auto-run होते हैं, लेकिन unsigned files भी download होने के बाद delete नहीं होतीं
  • signature verification पास होने के बाद execution से ठीक पहले file replace करने वाले timing attack की संभावना देखी गई, लेकिन यह व्यावहारिक नहीं था
  • ASUS WiFi driver package की संरचना का analysis करते हुए पता चला कि AsusSetup.ini की SilentInstallRun property से arbitrary command चलाया जा सकता है
  • अंतिम attack chain:
    1. attacker यूज़र को driverhub.asus.com. * subdomain वेबसाइट पर ले जाता है
    2. साइट UpdateApp से malicious calc.exe की request करती है (सिर्फ download, execute नहीं)
    3. custom AsusSetup.ini की request की जाती है (SilentInstallRun=calc.exe सेट करके, यह भी execute नहीं होता)
    4. signed AsusSetup.exe की request की जाती है (यह admin privileges के साथ auto-execute होता है, -s flag से ini पढ़कर calc.exe चला देता है)
  • नतीजतन one-click remote admin-privileged arbitrary code execution (RCE) संभव हो जाता है

Reporting Timeline (DD/MM/YYYY)

  • 07/04/2025: कमजोरी पहली बार मिली
  • 08/04/2025: RCE proof तैयार कर कमजोरी report की गई
  • 09/04/2025: ASUS का auto-response मिला
  • 17/04/2025: patch जारी हुआ और patched build प्राप्त हुआ
  • 18/04/2025: patch live होने की पुष्टि हुई
  • 09/05/2025: CVE-2025-3462 (8.4 score), CVE-2025-3463 (9.4 score) सार्वजनिक हुए

Assessing the Damage

  • कमजोरी report करने के तुरंत बाद certificate transparency tracking script लिखा गया
  • driverhub.asus.com.* subdomain certificates के issuance history की निगरानी की गई
  • 1 महीने की monitoring में filter से मेल खाने वाली कोई साइट अपने test के अलावा नहीं मिली
  • इससे पहले से exploit होने के कोई संकेत नहीं मिले

Bug Bounty

  • ASUS से bug bounty payment के बारे में पूछा गया, लेकिन मना कर दिया गया
  • इसके बदले hall of fame में नाम जोड़ना इनाम के रूप में मिला
  • यह भी जोड़ा गया कि ASUS जैसी बड़ी कंपनी के पास भी पर्याप्त bounty policy नहीं है

Fun Notes

  • ASUS Security Advisory form submit करते समय PoC को Amazon CloudFront ने malicious request मानकर block कर दिया
  • DriverHub में “Install All” क्लिक करने पर दूसरे software (Norton360, WinRAR आदि) भी ज़बरदस्ती install हो गए
  • CVE description वास्तविकता के मुकाबले अस्पष्ट है, जिससे 'desktop/laptop पर असर नहीं' जैसी गलतफहमी हो सकती है (असल में DriverHub इंस्टॉल होने वाले सभी डिवाइस प्रभावित हैं)
  • WiFi अभी भी काम नहीं कर रहा, इसलिए external USB WiFi adapter खरीदना पड़ा
  • संपर्क के लिए Signal: paul19.84, email contact [at] mrbruh.com दिया गया है

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

1 टिप्पणियां

 
GN⁺ 2025-05-12
Hacker News टिप्पणियाँ
  • ऐसा लगता है कि Responsible Disclosure का नतीजा मानवता के लिए किसी आपदा जैसा है; कंपनियों को ग्राहक सुरक्षा को गंभीरता से लेने के लिए शायद ज़्यादा बार और ज़्यादा दर्द झेलना पड़े। अगर आप समस्या ढूँढकर उन्हें एक महीने तक ठीक करने के लिए समाधान बता दें, तो कंपनी के लिए वह बस बैकलॉग का एक टिकट भर होता है। लेकिन अगर मामला ऑनलाइन खबर बन जाए और CEO तक को सामने आना पड़े, तो वे कुछ घंटों में ही समाधान निकाल लेंगे। बेशक, अंत में सबसे बड़ा नुकसान उपयोगकर्ताओं को ही होता है, लेकिन ASUS खरीदकर भी वे वैसे ही पहले से कष्ट झेल रहे हैं।
    • इस बार ASUS की प्रतिक्रिया अपेक्षाकृत तेज़ थी। उन्होंने समस्या से इनकार नहीं किया, reverse engineering करने वाले पर मुकदमा नहीं किया, और तुरंत patch भी जारी किया। पहले ऐसे मामलों में महीनों लग जाते थे या पुलिस तक शामिल हो सकती थी। आम लोग vulnerabilities की परवाह भी नहीं करते; दुनिया ऐसी है जहाँ लोग 3 साल से update न हुए फ़ोन से financial transactions करते हैं। CVE मुद्दों से मीडिया भर देने पर भी लोग बस सुन्न हो जाएंगे। यूरोप में नए नियमों के तहत ज्ञात vulnerability वाले उत्पाद बेचना ही प्रतिबंधित है। इसलिए अगर ASUS ऐसे ही चलता रहा, तो motherboard का stock गोदामों में जमा होगा और distributors उन्हें बेचने से कतराएँगे। यह घरेलू उपकरणों पर भी लागू होता है; उदाहरण के लिए, अगर dishwasher में vulnerability हो, तो उस पूरे उद्योग को बड़ा नुकसान हो सकता है।
    • "Responsible" Disclosure नाम ही विडंबना से पूरी तरह गैर-जिम्मेदाराना व्यवहार है। ज़्यादातर कंपनियाँ एक हफ़्ते में patch नहीं करतीं, श्रेय नहीं देतीं, उपयोगकर्ताओं को सूचित नहीं करतीं, और अपनी गलती से सीखती भी नहीं। धीमा और सीमित disclosure ऐसे व्यवहार को और बढ़ावा देता है। सच में ज़िम्मेदार व्यवहार है तुरंत, पूरी तरह और सार्वजनिक रूप से खुलासा करना। और अगर यह भरोसा बन जाए कि कंपनी सही तरीके से प्रतिक्रिया देती है, तो 5 business days की advance notice पर विचार किया जा सकता है। धीमे और आंशिक खुलासे को "responsible disclosure" कहना सिर्फ़ शब्दों का खेल है।
    • समस्या की जड़ product liability पर कानून की कमी है। car manufacturers पर recall की बाध्यता होती है, लेकिन software/hardware कंपनियों पर दबाव बहुत कम है। मेरा मानना है कि ग्राहकों को ऐसे उत्पादों पर full refund मिलना चाहिए जिनमें vulnerabilities (CVE) ठीक नहीं की गई हों।
    • CGPGrey के शब्दों में, जो पहला समाधान दिमाग में आता है वह अक्सर खराब और अप्रभावी होता है। अच्छी security culture को आंतरिक समस्याएँ छिपाने के बजाय उन्हें सामने लाने के लिए प्रोत्साहित करना चाहिए। कंपनियाँ लालची होती हैं, इसलिए वे security समस्याएँ छिपाती हैं। अगर खोजते ही सब कुछ सार्वजनिक कर दिया जाए, तो ऐसा मुद्दा जिसे एक महीने में ठीक किया जा सकता था, वह सबके सामने exposed हो जाएगा और exploitation की संभावना बहुत बढ़ जाएगी।
    • एक business idea है, शायद पहले से मौजूद भी हो: एक public/intermediary platform जो रिपोर्ट करने वाले की privacy की रक्षा करे, vulnerability की वास्तविक exploitability की जाँच करे, तय schedule पर सार्वजनिक घोषणा करे, और कंपनियाँ अपने ऊपर असर डालने वाले advance feed की subscription लेकर भुगतान करें, जिससे reporter rewards, operating costs और profit sharing हो सके। यह bug bounty marketplace जैसा है, लेकिन कंपनी के नज़रिये से थोड़ा adversarial है। सोचता हूँ कि यह क़ानूनी होगा या extortion माना जाएगा।
    • मैं बार-बार यही कहता हूँ कि दूसरे उद्योगों की तरह उत्पाद दोषों के लिए कानूनी ज़िम्मेदारी होनी चाहिए। ज़्यादातर लोग सस्ती चीज़ों के अलावा ख़राब उत्पाद बर्दाश्त नहीं करते, तो software को अपवाद क्यों होना चाहिए।
    • बस अगले ही दिन vulnerability सार्वजनिक कर देना ही असली motivation होगा। सार्वजनिक शर्मिंदगी अगली security के लिए भी मददगार होती है।
    • “मानवता के लिए आपदा” जैसी अतिशयोक्ति बहस को बिगाड़ने का एक प्रतिनिधि उदाहरण है।
  • मैंने ASUS से bug bounty के बारे में पूछा, तो उन्होंने कहा कि उसके बदले मेरा नाम Hall of Fame में डाल देंगे। यह सोचकर कड़वा-सा हँसी आती है, जैसे ASUS कोई छोटा startup हो जिसके पास bounty देने की पूँजी ही नहीं।
    • Cisco जैसी छोटी कंपनियाँ भी इसी तरह बिना इनाम के सिर्फ़ नाम चढ़ाने की बात करती हैं। Cisco तो security advisory page तक भूल गया, इसलिए मान्यता पाने का मौका भी चला गया।
    • अगर bug bounty नहीं है, तो फिर exploit को black market में बेचना या full disclosure करना—बस यही विकल्प बचते हैं।
    • ऐसी बातों की वजह से ASUS का उत्पाद फिर कभी खरीदने का मन नहीं करता।
  • ASUS software quality में भी खराब है और security में भी लगातार समस्याएँ पैदा करने वाली कंपनी है। पहले भी motherboard में UEFI malware का मुद्दा था, और अनावश्यक software preinstalled आता है जिसे हटाना भी झंझट है। शिकायतों के बहुत से उदाहरण हैं, इसलिए देखने लायक है।
    • यह पहली बार नहीं था। पहले भी ऐसा ही मामला हुआ था, और मैंने अपने पुराने blog में उसका रिकॉर्ड भी छोड़ रखा है।
  • उनका कहना था कि सिर्फ़ उनका test domain (driverhub.asus.com.*) ही उस condition पर फिट बैठता है, इसलिए इसका exploitation नहीं हुआ। लेकिन यह तभी सही है जब किसी ने driverhub का subdomain अलग से register न किया हो। wildcard का उपयोग किया जाए तो यह certificate transparency logs में दिखाई नहीं देगा और exploitation संभव हो सकता है।
    • wildcard certificate सिर्फ़ एक स्तर नीचे के subdomain को cover करता है। उदाहरण के लिए, *.example.com सिर्फ़ test.example.com पर काम करेगा, test.test.example.com पर नहीं। अगर किसी ने *.asus.com.example.com wildcard इस्तेमाल किया हो, तो driverhub.asus.com.example.com वैध हो सकता है।
    • किसी ने कहा, बढ़िया विचार था इसलिए मैंने तुरंत जाँच की, और फिलहाल wildcard certificate में कुछ भी संदिग्ध नहीं दिख रहा।
    • wildcard certificate का blind spot होना सही बात है। अगर attacker के पास .example.com का wildcard certificate होता, तो वह असली driverhub.asus.com के बाहर भी exploitation कर सकता था। इसी वजह से CT logs की monitoring भर से ऐसे subdomain takeover vulnerabilities को पूरी तरह पकड़ना संभव नहीं है।
  • ASUS से bug bounty के बारे में पूछने पर उनका जवाब "हम एक छोटा startup हैं, bounty नहीं है, Hall of Fame में नाम डाल देंगे" वाला हिस्सा खास तौर पर ध्यान खींचता है। जबकि वास्तव में यह 15B से अधिक market cap वाली विशाल कंपनी है।
    • तंज़ में किसी ने sarcasm.com सुझाया।
  • onboard Wi‑Fi काम नहीं कर रहा था, इसलिए USB external Wi‑Fi इस्तेमाल किया, लेकिन DriverHub की वजह से उसका भी कोई फ़ायदा नहीं हुआ। इसे solution कहा गया था, पर निराशा ही मिली।
    • blog post खुद पढ़ने में दिलचस्प लगी।
    • नया Wi‑Fi driver काम नहीं कर रहा था, इसलिए पुराना version इस्तेमाल करना पड़ा।
  • ASUS 15 अरब डॉलर market cap वाली बड़ी कंपनी है, फिर भी न ठीक से reward देती है और न customers व researchers की मेहनत की कद्र करती है। ऐसा बर्ताव देखकर समझ आता है कि researchers को कितना अन्याय महसूस होता होगा। निष्कर्ष यही है कि ASUS के उत्पाद न खरीदना ही सबसे अच्छा है।
  • bug report submit करते समय PoC file को Amazon CloudFront ने malicious request मान लिया, इसलिए submission ही block हो गया। इस तरह का WAF (Web Application Firewall) उल्टा एक खराब pattern या case study जैसा है।
  • onboard Wi‑Fi समस्या वाली शिकायत से सहमत हूँ। सच कहें तो chipset model देखकर station-drivers जैसी जगह से अलग से download कर लें, तो कुछ ही सेकंड लगते हैं। ऐसी असुविधाओं की वजह से मुझे ASUS पसंद नहीं है। BIOS options जो operating system के साथ सीधे interact करते हैं, वे तो खास तौर पर नापसंद हैं।
  • मुझे ASUS के उत्पाद पसंद हैं, लेकिन UEFI में preinstalled support apps को मैं हमेशा disable कर देता हूँ। पहले पूरा ROG Armoury Crate install हो जाता था और उसे हटाना झंझट भरा था। ASUS ने Intel से NUC business लेने के बाद भी BIOS updates जारी रखे, लेकिन MyASUS जैसे install apps डिफ़ॉल्ट रूप से जोड़ दिए गए। अच्छी बात यह है कि disable करने का option है, और अगर Intel NUC BIOS से update किया गया हो, तो लगता है यह डिफ़ॉल्ट रूप से बंद रहता है।