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

 (mrbruh.com)
2 पॉइंट द्वारा GN⁺ 2025-05-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Windows लॉगिन के तुरंत बाद इंस्टॉल हो सकने वाला ASUS DriverHub, वेबसाइट और लोकल सर्विस को जिस तरह जोड़ता था, उसकी वजह से यूज़र के सिर्फ़ किसी खास वेबसाइट पर जाने से एडमिन अधिकारों के साथ code execution तक संभव था
  • DriverHub बिना GUI के बैकग्राउंड में चलता है, और इसकी संरचना ऐसी थी कि driverhub.asus.com, 127.0.0.1:53000 की लोकल HTTP/WebSocket सर्विस को रिक्वेस्ट भेजता था; Origin जांच driverhub.asus.com.* रूप वाले डोमेन को अनुमति देती थी
  • UpdateApp endpoint, URL में सिर्फ़ .asus.com स्ट्रिंग शामिल होने पर फ़ाइल डाउनलोड कर लेता था; ASUS-signed executable को एडमिन अधिकारों से चलाता था, जबकि signature verification में फेल हुई फ़ाइलों को डिलीट नहीं करता था
  • अंतिम exploit में unsigned calc.exe, बदला हुआ AsusSetup.ini, और signed AsusSetup.exe को क्रम से डाउनलोड करवाकर SilentInstallRun=calc.exe के जरिए एडमिन अधिकारों वाला RCE हासिल किया गया
  • ASUS ने अप्रैल 2025 में fix के वितरण की पुष्टि की, और 9 मई 2025 को CVE-2025-3462 व CVE-2025-3463 सार्वजनिक हुए; certificate transparency logs के आधार पर disclosure से पहले सक्रिय exploitation के संकेत नहीं दिखे

वेबसाइट से जुड़ा DriverHub लोकल RPC

  • ASUS motherboard खरीदने के बाद Windows लॉगिन के तुरंत बाद ASUS DriverHub इंस्टॉलेशन पूरा करने के लिए एडमिन अधिकार मांगने वाला notification दिखता है
  • DriverHub अलग GUI नहीं है, बल्कि बैकग्राउंड process के रूप में चलता है, और driverhub.asus.com पर जरूरी ड्राइवर और update targets दिखाता है
  • वेबसाइट लोकल में चल रहे DriverHub process से RPC के जरिए communication करती है
    • लोकल सर्विस 127.0.0.1 के fixed port 53000 पर चलती है
    • वेबसाइट या सर्विस इसी लोकल port पर API requests भेजती है
  • ऐसी संरचना में अगर RPC protection पर्याप्त न हो, तो attacker इसे malicious application इंस्टॉल कराने के लिए abuse कर सकता है

ढीली Origin जांच को bypass करना

  • DriverHub किसी भी वेबसाइट की सभी requests स्वीकार नहीं करता था; इसे इस तरह design किया गया था कि यह Origin header driverhub.asus.com होने वाली requests का जवाब दे
  • समस्या यह थी कि जांच exact comparison नहीं थी, बल्कि string inclusion या wildcard जैसी थी
    • यह origin == driverhub.asus.com जैसा direct comparison नहीं था
    • driverhub.asus.com.mrbruh.com को Origin के रूप में सेट करने पर request स्वीकार हो गई
  • attacker इस behavior का उपयोग करके driverhub.asus.com.* रूप वाले domain से लोकल DriverHub RPC तक पहुंच सकता था

खुले हुए RPC endpoints

  • वेबसाइट JavaScript और executable decompilation के जरिए कई RPC endpoints पहचाने गए
  • मुख्य endpoints ये थे
    • Initialize: software install है या नहीं और basic installation जानकारी लौटाता है
    • DeviceInfo: installed ASUS software, installed .sys drivers, hardware components, और MAC address लौटाता है
    • Reboot: बिना confirmation के target device को तुरंत reboot करता है
    • Log: पूरे DriverHub logs का compressed version लौटाता है
    • InstallApp: app या driver ID से installation करता है; app ID, DriverHub installer द्वारा दिए XML file में hardcoded होती है
    • UpdateApp: दिए गए file URL को डाउनलोड और execute करके DriverHub को खुद update करता है

UpdateApp ने RCE की शर्तें कैसे बनाईं

  • UpdateApp request इस रूप में काम करती है
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • UpdateApp के observed behavior ने RCE chain के लिए कई जरूरी conditions दीं
    • Url parameter में .asus.com string शामिल होनी चाहिए थी, लेकिन example.com/payload.exe?foo=.asus.com जैसा रूप भी स्वीकार था
    • फ़ाइल URL के अंत में दिए filename से save होती थी
    • extension कुछ भी हो, फ़ाइल डाउनलोड की जा सकती थी
    • अगर फ़ाइल ASUS-signed executable हो, तो वह एडमिन अधिकारों से अपने-आप execute होती थी
    • अगर executable ASUS-signed हो, तो वह DriverHub installer न होने पर भी execute होती थी
    • डाउनलोड की गई फ़ाइल signature check में fail हो जाए, तब भी delete नहीं होती थी
  • शुरुआत में signature verification की वजह से RCE मुश्किल लगता था, लेकिन signature fail हुई फ़ाइल के बचे रहने वाले behavior और ASUS-signed executable के installation behavior के मिल जाने से bypass path बन गया

AsusSetup.ini का उपयोग करने वाली exploit chain

  • ASUS WiFi driver package में AsusSetup.exe, AsusSetup.ini, SilentInstall.cmd शामिल थे
  • AsusSetup.exe run होने पर AsusSetup.ini से driver metadata पढ़ता है
  • AsusSetup.exe को -s flag के साथ run करने पर यह GUI के बिना silent installation करता है, और AsusSetup.ini के SilentInstallRun में specified item को execute करता है
    • DriverHub silent installation के लिए -s flag का उपयोग करता है
    • original INI file automated unattended installation के लिए cmd script specify करती है
    • SilentInstallRun में दूसरी executable file भी specify की जा सकती थी

  • पूरा attack sequence

    • यूज़र driverhub.asus.com.* रूप वाले domain की वेबसाइट पर जाता है
    • साइट UpdateApp से PoC executable calc.exe request करती है
    • calc.exe डाउनलोड होता है, लेकिन signature check में fail होने से execute नहीं होता
    • फ़ाइल delete नहीं होती और बची रहती है
    • साइट UpdateApp से modified AsusSetup.ini request करती है
    • यह फ़ाइल भी डाउनलोड होती है, लेकिन execute नहीं होती
    [InstallInfo]
SilentInstallPath=.\
SilentInstallRun=calc.exe
    • साइट UpdateApp से ASUS-signed binary AsusSetup.exe request करती है
    • AsusSetup.exe डाउनलोड होने के बाद एडमिन अधिकारों से execute होता है
    • DriverHub इसे -s से run करता है, इसलिए यह AsusSetup.ini पढ़ता है
    • SilentInstallRun=calc.exe के अनुसार calc.exe एडमिन अधिकारों से execute होता है

रिपोर्ट से CVE disclosure तक

  • vulnerability handling schedule इस प्रकार था
    • 2025-04-07: शुरुआती vulnerability discovery
    • 2025-04-08: RCE तक बढ़ने की पुष्टि
    • 2025-04-08: ASUS को vulnerability report
    • 2025-04-09: ASUS automatic response प्राप्त
    • 2025-04-17: follow-up contact के बाद ASUS ने patch completion और verification build भेजा
    • 2025-04-18: ASUS ने fix distribution की पुष्टि की
    • 2025-05-09: CVE-2025-3462 score 8.4 और CVE-2025-3463 score 9.4 सार्वजनिक हुए

Exploitation की संभावना और देखे गए निशान

  • रिपोर्ट के तुरंत बाद VPS पर certificate transparency updates track करने वाला script चलाकर driverhub.asus.com.* domain registration की जांच की गई
  • दूसरे certificate transparency log websites के आधार पर domains और subdomains आमतौर पर एक महीने के भीतर logs में दिखाई देते थे
  • एक महीने बाद जांचने पर regex से match करने वाली websites में सिर्फ़ test domain था
  • इस आधार पर, report से पहले active exploitation की संभावना कम थी

ASUS की प्रतिक्रिया और बाकी issues

  • ASUS ने bug bounty नहीं दी, इसके बजाय hall of fame में नाम जोड़ने की बात कही
  • बाद में पता चला कि एक अन्य security researcher leonjza ने यही Origin जांच समस्या फरवरी 2025 में पहले ही report कर दी थी, और ASUS ने इस fix के समय तक इसे ठीक कर दिया था
    • ASUS ने यह बात अलग से नहीं बताई
    • cve.org page पर credit में केवल वही researcher listed था, और ASUS ने कहा कि additional credit reflect नहीं किया जाएगा
  • ASUS Security Advisory form से vulnerability report submit करते समय Amazon CloudFront ने attached PoC को malicious request के रूप में detect कर submission block कर दिया
    • कुछ PoC code हटाकर उसकी जगह recorded video link submit करना पड़ा
  • DriverHub में recommended drivers को अलग-अलग install करने के बजाय “Install All” दबाने पर ArmouryCrate, ASUS का custom CPU-Z, Norton360, और WinRAR भी साथ install होते हैं
  • ASUS का CVE description RCE scope और impact को संकुचित रूप में व्यक्त करता है
    • description में इस आशय की wording थी कि “यह motherboards तक सीमित है और laptops, desktop computers पर असर नहीं है”
    • वास्तव में DriverHub installed desktops/laptops समेत सभी computers पर असर है
    • arbitrary या remote code execution की जगह इसे इस तरह व्यक्त किया गया कि “untrusted sources system behaviour को प्रभावित कर सकते हैं”

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

1 टिप्पणियां

 
GN⁺ 2025-05-12
Hacker News की टिप्पणियां

  • responsible disclosure और उसके नतीजे इंसानियत के लिए लगभग आपदा जैसे रहे हैं। कंपनियों को ग्राहक सुरक्षा को ज्यादा गंभीरता से लेने के लिए कहीं ज्यादा बार और कहीं ज्यादा बड़ा दर्द महसूस करना होगा
    अगर आप उन्हें एक महीना दें और समाधान तक चम्मच से खिला दें, तो यह बस backlog का एक ticket बनकर रह जाता है। अगर हर security issue के फूटते ही वह online इतनी बड़ी खबर बन जाए कि CEO तक शामिल हो और समाधान महीनों में नहीं बल्कि घंटों में ढूंढना पड़े, तो वे कहीं ज्यादा proactive होंगे। बेशक end user को सबसे ज्यादा नुकसान होगा, लेकिन ASUS खरीदने के समय से ही वे वैसे भी दर्द झेल रहे हैं

    • इस बार ASUS की response speed काफी ठीक थी, और यहां कोई बड़ी समस्या नहीं दिखती। ASUS ने bug से इनकार नहीं किया, software reverse engineering के कारण मुकदमा करने की धमकी भी नहीं दी, और जल्दी patch कर दिया
      responsible disclosure से पहले के दौर में यह प्रक्रिया महीनों लेती और शायद police तक शामिल हो जाती। सामान्य users vulnerabilities में रुचि नहीं रखते, और 3 साल से update बंद पड़े phone से banking करते हैं। अगर news में CVE लगातार उछाले जाएं, तो लोग “सारी कंपनियां खराब हैं” वाली बात से ऊबकर असली खतरा आने पर भी सुन्न हो जाएंगे
      EU एक अलग समाधान आगे बढ़ा रहा है। नए cybersecurity regulation में ज्ञात vulnerabilities वाले products को stores में बेचने से रोका जाएगा। ASUS लगातार गड़बड़ करता रहा तो motherboards inventory बनकर रह जाएंगे, और stores भी ASUS hardware बेचना नहीं चाहेंगे। यह सिर्फ computer hardware पर नहीं, smart refrigerators और washing machines पर भी लागू होगा। अगर आप dishwasher vulnerability खोजते हैं और manufacturer ने firmware update का तरीका नहीं रखा है, तो आप industry के लिए कई million dollars का बेकार inventory पैदा कर सकते हैं
    • “responsible disclosure” नाम अपने आप में विरोधाभासी है। असल में यह लगभग पूरी तरह गैर-जिम्मेदार तरीके जैसा है
      ज्यादातर कंपनियां disclosure को बेहद खराब तरीके से संभालती हैं। वे समय पर, जैसे एक हफ्ते के भीतर, fix नहीं करतीं, credit भी ठीक से नहीं देतीं, users को बताती भी नहीं, और अपनी गलतियों से सीखती भी नहीं। गैर-जिम्मेदार तरीके से delayed limited disclosure ऐसे व्यवहार को मजबूत करता है
      सच में जिम्मेदार तरीका है तुरंत, पूरी तरह और सार्वजनिक रूप से बताना। जरूरत हो तो अपनी सुरक्षा के लिए anonymous तरीके से किया जा सकता है। प्रभावित company बार-बार सही response देने का प्रमाण दे, उसके बाद ही उसे, जैसे 5 business days का, बहुत छोटा advance notice अधिकार मिल सकता है
      ऐसे गैर-जिम्मेदार delayed limited disclosure को “responsible disclosure” कहा जाना अपने आप में Newspeak का एक उदाहरण है
    • असली मुद्दा liability को कानून में लाने का है। car manufacturers को recalls और repairs का आदेश दिया जाता है, लेकिन software·hardware companies पर दबाव बहुत कमजोर है
      ग्राहकों को, उदाहरण के लिए, unfixed CVE वाले खराब device पर full refund मिलना चाहिए
    • CGPGrey को quote करें तो, सबसे पहले दिमाग में आने वाले solutions आम तौर पर भयानक और बेअसर होते हैं
      अच्छी safety·security culture participants को समस्याएं छिपाने से रोकने के लिए encourage करती है। कंपनियां लालची होती हैं, इसलिए security mistakes छिपाने के लिए कुछ भी करेंगी
      एक महीने में fix किए जा सकने वाले legal और fixable issue को सबके सामने public कर दें, तो exploit होने की संभावना भी काफी बढ़ जाती है
    • ऐसा business idea हो सकता है। शायद पहले से हो भी, लेकिन एक disclosure brokerage·aggregation service बनाना
      यह reporters की privacy बचाए, security vulnerabilities verify करे, और यह confirm करे कि public की जाने वाली हर vulnerability सच में exploitable है। तय schedule पर disclose करे, और companies से उनके ऊपर असर डालने वाले disclosures को पहले पाने वाली “early feed” के लिए subscription fee ले। उस पैसे से reporters को reward दे, operating cost चुकाए, और कुछ profit रखे
      कहें तो companies के प्रति थोड़ा hostile bug bounty marketplace। उत्सुक हूं कि यह legal होगा या extortion माना जाएगा

  • ASUS से पूछा गया कि क्या उनके पास bug bounty है, तो उन्होंने कहा नहीं, और बदले में “Hall of Fame” में नाम डालने की बात कही—यह हिस्सा कड़वा लगता है
    तंज यह है कि ASUS एक छोटा startup है, इसलिए bounty देने की पूंजी नहीं होगी, समझा जा सकता है

    • Cisco जैसी छोटी company के लिए भी समझने लायक बात है। Cisco भी सालों से acquire की गई कई online services के साथ ऐसा ही करता रहा है
      Cisco तो इससे आगे जाकर security advisory page तक भूल गया, इसलिए कोई भी recognition अब शून्य में गायब हो गया है
    • अगर bug bounty नहीं है, तो exploits black market में जाएंगे, या फिर full disclosure की तरफ
    • ऐसी response देखकर फिर कभी ASUS products खरीदने का मन नहीं करता
    • “Asus एक छोटा startup है” यह phrase कहां से आया, समझ नहीं आता। Asus कम से कम 90s से motherboards और PC parts बनाता आ रहा है

  • हैरानी की बात नहीं। ASUS software खराब है, और security के मामले में prevention की कमी वाला लगभग repeat offender है
    https://www.techspot.com/news/95425-years-gigabyte-asus-moth...
    https://www.reddit.com/r/ASUS/comments/tg3u2n/removing_bloat...
    https://www.reddit.com/r/ASUS/comments/ojsq80/nahimic_servic...

  • Certificate Transparency लॉग देखकर यह निष्कर्ष निकालना कि driverhub.asus.com.* से मेल खाने वाला डोमेन सिर्फ उनका self-test डोमेन था, इसलिए रिपोर्ट से पहले इसका सक्रिय रूप से दुरुपयोग होने की संभावना कम थी—यह बात सिर्फ तब सही है जब wildcard certificate न हो
    अगर किसी के पास wildcard होता, तो वह Certificate Transparency में दिखे बिना भी इसका दुरुपयोग कर सकता था

    • wildcard certificate केवल single-label स्तर पर लागू होता है। *.example.com. test.test.example.com. पर लागू नहीं होता, लेकिन test.example.com. पर होता है
      अगर किसी ने *.asus.com.example.com. के लिए wildcard जारी करा लिया होता, तो वह driverhub.asus.com.example.com. के नीचे web server चला कर उसे valid दिखा सकता था
    • अच्छा idea है, इसलिए अभी चेक किया, और पुष्टि हुई कि wildcard record में कुछ संदिग्ध नहीं था
    • wildcard certificate वाला blind spot सही है। अगर attacker के पास .example.com के लिए wildcard certificate होता, तो वह driverhub.asus.com. डोमेन के रूप में Certificate Transparency लॉग में खास तौर पर दिखे बिना इसका दुरुपयोग कर सकता था
      इसलिए सिर्फ Certificate Transparency लॉग monitoring से इस तरह की subdomain takeover vulnerability detect करना पर्याप्त नहीं है
    • इसके अलावा, यह भी जानने की उत्सुकता है कि क्या self-signed certificate भी काम करता। ऐसे certificate transparency लॉग में नहीं जाते
      और यह भी सवाल है कि क्या HTTPS होना जरूरी था

  • अंत में “मेरा onboard WiFi अब भी नहीं चलता, और मुझे external USB WiFi adapter खरीदना पड़ा। धन्यवाद, DriverHub” निकला—यानी यह पूरी प्रक्रिया सचमुच व्यर्थ मेहनत थी

    • blog post अपने आप में अच्छी थी
    • latest WiFi driver काम नहीं करता, इसलिए पुराना version इस्तेमाल करना होगा

  • ASUS security reporting form में vulnerability report submit करते समय Amazon CloudFront ने attached PoC को malicious request मानकर block कर दिया—यह हिस्सा ऐसा लगता है जैसे web application firewall anti-pattern होने की चेतावनी हो: https://thedailywtf.com/articles/Injection_Rejection

  • “ASUS तो छोटी startup है, समझ में आता है”—यानी market cap सिर्फ 15 अरब डॉलर वाली छोटी startup
    सच में समझना मुश्किल यह है कि वे न सिर्फ खराब product देते हैं, बल्कि customer के लिए जबरदस्त काम करने वाले researcher के साथ भी ऐसा व्यवहार करते हैं
    ऐसे काम करने के बाद भी ignore किए जाने या नीचा दिखाए जाने वाले researchers के लिए दुख होता है। यह बहुत unfair है
    हम बस ASUS products न खरीदने का फैसला कर सकते हैं

  • पूछा गया कि क्या ASUS के पास bug bounty है, और ASUS ने जवाब दिया कि नहीं, लेकिन बदले में “hall of fame” में नाम डाल देंगे। यह व्यंग्य है कि ASUS छोटी startup है, इसलिए bounty देने की पूंजी नहीं होगी—समझा जा सकता है
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • या शायद sarcasm.com भी हो सकता है ;)

  • अनिवार्य Scumbag Asus video link
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “ASUS ने पिछले हफ्ते हमें email भेजकर कहा कि वे इस हफ्ते office आकर issue पर ‘open dialogue’ करना चाहते हैं। हमने कहा ठीक है, लेकिन बातचीत record करनी होगी। आखिर उन्होंने ही कहा था कि वे open dialogue चाहते हैं। उसके बाद 5 दिनों तक कोई जवाब नहीं आया। तो ASUS के पास इसे ठीक करने का मौका था। हम उन्हें वह मौका देने के लिए video रोककर बैठे थे। लेकिन जैसे ही हमने कहा ‘ठीक है, बस जो वादे किए गए हैं उन्हें record पर रखने के लिए इसे film करेंगे’, तुरंत चुप्पी छा गई”

    • फिर भी, क्या कोई motherboard manufacturer है जो “basically ठीक” हो? या हर बड़े vendor की ऐसी ही कहानियां हैं?
      एक दोस्त जल्द ही नया PC build करने वाला है, उसके लिए पूछ रहा हूं
    • यह गुस्सा दिलाता है, लेकिन ASUS की तरफ से सबसे मजबूत और सबसे credible बचाव क्या हो सकता है, यह जानने की उत्सुकता है
      reality से जो ज्यादा मेल खाता है, वह शायद यही होगा: वे profit chase कर रहे हैं और फिर भी बच निकलते हैं, इसलिए record पर आकर खराब दिखने की कोई वजह नहीं, और उस समय में marketing करना बेहतर समझते हैं

  • bug bounty नहीं होना बेतुका है। आगे से ASUS product नहीं खरीदूंगा

    • शायद इसलिए कि वे “छोटी startup” हैं
    • Asus software और customer support बहुत खराब हैं, और हमेशा से रहे हैं