Windows ड्राइवर सिग्नेचर बायपास से kernel rootkit इंस्टॉल होने की संभावना

 (bleepingcomputer.com)
1 पॉइंट द्वारा GN⁺ 2024-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ऊपर से नवीनतम patch लगा हुआ Windows भी अगर Windows Update process के नियंत्रण में आ जाए, तो उसे पुराने kernel components पर वापस ले जाकर Driver Signature Enforcement बायपास और kernel rootkit वितरण तक पहुंचाया जा सकता है
  • SafeBreach के शोधकर्ता Alon Leviev ने BlackHat और DEFCON में downgrade/version rollback attack का प्रदर्शन किया, और Windows Update takeover अब भी पूरी तरह patch नहीं हुआ है
  • admin privileges वाला हमलावर नवीनतम Windows 11 में भी ci.dll को बिना patch वाले version से बदलकर unsigned kernel drivers को load करा सकता है
  • Virtualization-based Security, UEFI lock और registry settings पर निर्भर करती है, इसलिए Mandatory फ्लैग के बिना वाले configuration में registry modification या core file replacement बायपास का रास्ता बन सकते हैं
  • Microsoft पुराने VBS system files को हटाने वाला security update विकसित कर रहा है, लेकिन प्रभावित versions की जांच, compatibility testing और regression रोकने के कारण इसकी release timing स्पष्ट नहीं है

नवीनतम patch स्थिति को निष्प्रभावी करने वाला downgrade attack

  • हमलावर Windows Update process को नियंत्रित करके अपडेटेड दिखने वाले system में पुराने vulnerable components दोबारा डाल सकता है
  • operating system अब भी पूरी तरह patched दिखता है, लेकिन वास्तव में वह पहले से ठीक की जा चुकी vulnerabilities के लिए फिर से exposed हो जाता है
  • downgrade targets में DLL, drivers और NT kernel शामिल हैं
  • Alon Leviev ने Windows Downdate tool जारी कर दिखाया कि custom downgrade बनाना संभव है

Driver Signature Enforcement बायपास और rootkit का जोखिम

  • Leviev ने दिखाया कि kernel security मजबूत होने के बाद भी Driver Signature Enforcement(DSE) को बायपास किया जा सकता है
  • DSE बायपास सफल होने पर हमलावर unsigned kernel drivers load कर सकता है
  • ऐसे drivers का उपयोग security controls को disable करने और compromise detection को कठिन बनाने वाले rootkit malware तैनात करने में हो सकता है
  • Leviev अपने तरीके को "ItsNotASecurityBoundary" DSE bypass कहते हैं
    • यह तरीका ItsNotASecurityBoundary exploit को downgrade करने का एक रूप है
    • यह exploit Windows की false file immutability vulnerability class का उपयोग करता है, जिसे Elastic के Gabriel Landau ने पहचाना था, और इससे kernel privileges पर arbitrary code execution संभव होता है

ci.dll replacement और reboot की शर्त

  • नए शोध में Leviev ने दिखाया कि admin privileges वाला हमलावर Windows Update process का दुरुपयोग करके पूरी तरह अपडेटेड Windows 11 में भी DSE protection को बायपास कर सकता है
  • इसकी कुंजी DSE लागू करने वाली ci.dll को ऐसे बिना patch वाले version से बदलना है जो driver signatures को ignore करता है
  • component को vulnerable version पर downgrade करने के बाद, सामान्य update process की तरह system restart आवश्यक होता है
  • Leviev ने पूरी तरह patched Windows 11 23H2 system पर DSE patch को downgrade के जरिए rollback कर फिर उस component के exploit का प्रदर्शन किया

जब VBS settings कमजोर हों तो खुलने वाले बायपास रास्ते

  • Leviev ने Microsoft की Virtualization-based Security(VBS) को disable या bypass करने के तरीके भी बताए
  • VBS, Windows के आवश्यक resources और security assets की सुरक्षा के लिए isolated environment बनाती है
    • protected targets में security kernel code integrity mechanism skci.dll और authenticated user credentials शामिल हैं
  • VBS आमतौर पर UEFI lock और registry configuration जैसी सुरक्षा व्यवस्थाओं पर निर्भर करती है
  • अगर VBS को अधिकतम security setting “Mandatory” flag के साथ configure नहीं किया गया है, तो targeted registry key modifications से इसे disable किया जा सकता है
  • अगर VBS केवल आंशिक रूप से enabled है, तो SecureKernel.exe जैसी core VBS files को compromised versions से बदलकर VBS operation में हस्तक्षेप किया जा सकता है
    • यह स्थिति “ItsNotASecurityBoundary” बायपास और ci.dll replacement तक जाने वाला रास्ता खोल सकती है

Microsoft की प्रतिक्रिया और बाकी बची खाई

  • BlackHat और DEFCON में सार्वजनिक किए गए downgrade attacks में उपयोग हुए CVE-2024-21302 और CVE-2024-38202 को address किया गया है, लेकिन Windows Update takeover समस्या अभी भी बाकी है
  • Microsoft का मानना है कि यह समस्या परिभाषित security boundary को पार नहीं करती, और admin privileges के साथ kernel code execution हासिल करना security boundary violation नहीं है
  • Leviev ने ज़ोर दिया कि Microsoft के fix जारी करने तक security solutions को downgrade attacks की monitoring और detection करनी चाहिए
  • Microsoft ने कहा कि वह इस जोखिम को रोकने के लिए mitigations सक्रिय रूप से विकसित कर रहा है
  • कंपनी पुराने और बिना patch वाले VBS system files को हटाने वाला security update विकसित कर रही है
    • इस प्रक्रिया में सभी प्रभावित versions की जांच, update development और compatibility testing शामिल है
    • customer protection और operational disruption को न्यूनतम रखने के लिए integration failure या regression से बचना होगा
    • समस्या की जटिलता के कारण update की उपलब्धता का समय स्पष्ट नहीं है
  • 27 अक्टूबर के update में यह स्पष्ट किया गया कि attack के लिए admin privileges चाहिए, और यह जानकारी इस भ्रम को कम करने के लिए जोड़ी गई कि Microsoft mitigation नहीं कर रहा है

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

1 टिप्पणियां

 
GN⁺ 2024-10-27
Hacker News की राय

  • MS कहता है कि UAC कोई security boundary नहीं है, यानी यह उस समस्या से जुड़ा है जहाँ कुछ users admin privilege तक पहुँच जाते हैं
    लेकिन इस मामले में, जैसे admin से kernel तक जाना भी security boundary नहीं माना जा रहा है, और साथ ही driver signature enforcement को security feature कहा जा रहा है
    यहाँ वही feature सीधे bypass हो रहा है, फिर भी कहा जा रहा है कि कोई security boundary पार नहीं हुई, तो अच्छा होता अगर इसे थोड़ी संगति के साथ समझाया जाता

    • MS की logic समझ में आती है. बस एक अहम बात छूट रही है
      UAC उन users के लिए है जो पहले से admin group में हैं, यह “कुछ users को admin बनाना” वाला feature नहीं है
      security boundary admin users के आसपास नहीं बल्कि standard users के आसपास है
      यह पसंद न आए तो अलग बात है, लेकिन अगर security boundary चाहिए तो users को Administrators group में मत डालिए
    • यह value system की असंगति जैसा लगता है
      राय के टकराव में अक्सर definition की असंगति और value system की असंगति होती है
      इस मामले में Microsoft इस issue को छोटा दिखाने को महत्व देता दिखता है, और अगर वही उनकी सबसे ऊँची priority है, तो उस कसौटी पर उनका फैसला internally consistent लग सकता है
      definition की असंगति अपेक्षाकृत आसानी से सुलझाई जा सकती है. जैसे software system design पर सब design pattern की terminology में बात करें, लेकिन हर व्यक्ति A को A′ या A″ की तरह अलग समझे, तो बड़ी confusion पैदा हो सकती है
    • मैंने सीखा कि Windows bug fix करवाने के लिए paid professional support खरीदनी पड़ती है
      corporate-managed open source software में भी यही हाल है
      असली सवाल यह है कि लोग अपनी बौद्धिक ऊर्जा desktop Linux को बेहतर बनाने के बजाय Microsoft के लिए मुफ्त security research में क्यों लगाते हैं
    • असल में UAC security boundary की तरह काम नहीं करता, और अगर उसे ऐसा बनाया जाए तो users इतने परेशान हो जाएँगे कि दूसरे operating system पर चले जाएँगे
      UAC और sudo दोनों OS-level cookie consent popup जैसे लगते हैं, और मेरे हिसाब से तीनों को हटाना बेहतर होगा
      UAC/sudo जैसी user-based privilege escalation छोड़कर, Android और iOS की तरह users नहीं बल्कि apps को sandbox करना चाहिए
    • Microsoft में हमेशा से ऐसी विरोधाभासी बातें रही हैं. शायद इसलिए कि उन्हें पता है कि bypass के तरीके बहुत हैं

  • यह भी दिलचस्प है कि Windows और Linux दोनों में सामान्य local accounts व्यवहार में लगभग root-equivalent privilege जैसे ही काम करते हैं
    Linux में लोगों को system-related कामों से पहले sudo लगाने की आदत डाली जाती है, और Windows में UAC prompt पर क्लिक करके आगे बढ़ने की
    याद नहीं पड़ता कि password typo के अलावा sudo ने आखिरी बार किसी से कब “नहीं” कहा था
    UAC system-managed UI है, जबकि sudo सिर्फ एक program है, इसलिए इस मायने में UAC थोड़ा बेहतर है कि attacker किसी malicious shell alias से sudo को बदलकर password चुरा सकता है
    default setup में sudo और UAC दोनों हटा देना, और root व मुख्य user के local account के बीच किसी मजबूत security boundary का दिखावा न करना, users की सुविधा और वास्तविक security posture दोनों के ज्यादा करीब होगा

    • Linux में ज़्यादातर modern user applications sudo की जगह polkit इस्तेमाल करते हैं
      terminal में भी sudo की जगह pkexec इस्तेमाल किया जा सकता है
      किसी arbitrary command को root के रूप में चलाने के बजाय, application org.freedesktop.udisks2.filesystem-mount जैसे predefined actions का उपयोग कर सकता है, और user को localized message में दिखा सकता है कि app क्या करना चाहता है ताकि वह अनुमति दे या न दे
      system administrator यह भी सेट कर सकता है कि कुछ actions, जैसे flatpak update, के लिए authentication न माँगी जाए, या उल्टा कुछ actions को पूरी तरह block कर दिया जाए
    • वही बात दूसरे ढंग से कहें तो उसका असर बहुत अलग लगता है: Windows और Linux दोनों में default install user व्यवहार में root-equivalent privilege के काफ़ी करीब होता है
      इसके पीछे यह मान्यता लगती है कि install करने वाले user को system पर control होना चाहिए. आखिर उसने install ही न किया होता तो भी चलता
      sudo भी UAC की तरह इंसान को “नहीं” कहने वाला तंत्र नहीं है. दोनों का मकसद यह है कि जब admin कोई ऐसा administrative काम करने लगे जिसकी उम्मीद नहीं थी, तो इंसान खुद “नहीं” कहे
      जिन लोगों के पास admin privilege नहीं है लेकिन जिन्हें ऐसा काम करना है, उन्हें admin की मंजूरी लेनी चाहिए
      अगर यह single-user system नहीं है, तो machine configure करने वाले व्यक्ति को रोज़मर्रा के उपयोग के लिए एक restricted account बनाना चाहिए
    • Linux में sudo install नहीं किया जाता
      root बनने की ज़रूरत अक्सर नहीं पड़ती, और जब पड़ती है तो आम तौर पर कई काम लगातार करने होते हैं
      sudo मुझे multi-user computers, जैसे company-owned/managed computers, पर ज़्यादा उपयोगी लगता है, जहाँ admin कुछ users को सीमित privileged tasks की ही अनुमति देना चाहता है
      root के अलावा किसी और account का हमेशा उपयोग करने की मुख्य वजह security नहीं बल्कि गलती से बचाव है. यानी अनजाने में files delete या overwrite करने से बचना
      इसलिए कभी-कभार role बदलने के लिए password डालना पूरी तरह जायज़ लगता है
    • मेरे अनुभव में कम से कम Gnome पर Linux भी Windows-style sudo protection की दिशा में जा रहा है
      बस उसमें “verify करने के लिए ctrl+alt+delete दबाएँ” वाला trick नहीं है
      Windows का एक फायदा है कि हर चीज़ को script करने की ज़रूरत नहीं होती
      चाहें तो हर tool को runas/System.Management.Automation.PSCredential से wrap किया जा सकता है, लेकिन ज़्यादातर मामलों में इसकी ज़रूरत नहीं पड़ती

  • ऐसा लगता है कि kernel file open करते समय सभी open file handles को scan करके conflicting mandatory locks की जाँच करते हुए file sharing rules लागू करता है, लेकिन conflicting permission वाली memory mappings की जाँच नहीं करता
    यह गलती तो है, लेकिन fix अपेक्षाकृत सीधा लगता है
    दिलचस्प बात यह है कि Linux ने अभी हाल में mandatory locking के आखिरी निशान भी हटा दिए हैं. अब loaded executable पर लिखने से EBUSY नहीं आता
    यह देखना रोचक है कि वही feature एक operating system में security infrastructure का भार उठाने वाला हिस्सा है, जबकि दूसरे operating system में हटाए जाने लायक legacy अवशेष माना जाता है

  • मैं कोई security expert नहीं हूँ और बस बुनियादी बातें ही समझता हूँ, लेकिन लगता है कि मैं कहीं न कहीं conceptual model को मिस कर रहा हूँ
    जानना चाहता हूँ कि Windows को hack करना इतना आसान क्यों है

    • यह भरोसा करना मुश्किल है कि अब तक किसी ने सबसे बड़े कारण की ओर इशारा नहीं किया
      Windows सबसे ज़्यादा इस्तेमाल होने वाला desktop operating system है जिसे target करने से पैसा बनता है, खासकर enterprise environments में, इसलिए इसे तोड़ने में बहुत समय और निवेश लगाया जाता है
    • समस्या यह है कि Windows को security महत्वपूर्ण होने से पहले विकसित किया गया था
      वास्तव में सुरक्षित computing platform बनाने के लिए पर्याप्त निवेश नहीं किया गया
      आदर्श security platform को fdroid की तरह publicly verifiable infrastructure पर reproducible builds देने चाहिए, सभी untrusted applications को sandbox के भीतर virtualize करना चाहिए, और least-privilege model लागू करना चाहिए
      अभी security की हालत सबसे खराब है। CPU के ME, UEFI components, और operating system के third-party drivers तक, हर ring में ऐसी असुरक्षित code चल रही है जिसकी पहचान स्पष्ट नहीं है और शायद उसका पर्याप्त testing भी नहीं हुआ
      SeL4 के पास पूरी तरह verified kernel है, लेकिन वह अभी virtualization नहीं करता
    • यह भी एक महत्वपूर्ण कारण है कि third-party kernel-level code आम है
      Windows malware का बड़ा हिस्सा किसी न किसी चरण पर vulnerable third-party kernel driver पर निर्भर करता है
      इसके उलट Linux में third-party kernel modules दुर्लभ हैं और अच्छी नज़र से नहीं देखे जाते, और macOS में तो वे पूरी तरह प्रतिबंधित हैं
    • मेरे अनुभव में समस्या यह है कि user डिफ़ॉल्ट रूप से administrator होता है
      और user को elevated privileges के साथ कुछ भी चलाने के लिए मना लेना बहुत आसान है
    • driver signature blocklist फ़ाइल DriverSiPolicy.p7b कई सालों तक update नहीं हुई
      2022 में CERT analyst Will Dormann ने पूछा कि ऐसा क्यों है, उसके बाद ही इस पर काम हुआ
      अब इसे नियमित रूप से update किया जाता है, लेकिन यह सच में हैरान करने वाला है https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...

  • इस मामले में मैं कुछ हद तक Microsoft के पक्ष से सहमत हूँ
    administrator कंप्यूटर पर मनचाही चीज़ें कर सकता है, इसमें कुछ नया नहीं है
    मुझे नहीं पता कि कोई ऐसा सूक्ष्म अंतर है जो इसकी severity बढ़ाता हो
    इस तरह के attack पर Raymond Chen की लिखी हुई बात भी देखने लायक है
    https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

    • मेरी भी यही राय है
      अगर कोई पहले से system की किसी भी DLL को बदल सकता है, तो इस “exploit” के काम करने की preconditions पहले ही पूरी हो चुकी हैं, और उस बिंदु पर सब कुछ लगभग खत्म ही है
      driver signature bypass की क्षमता शायद चिंताओं की सूची में सबसे नीचे की चीज़ों में होगी

  • attack संदिग्ध रूप से बहुत simple लगता है
    इसमें update process को धोखा देकर ऐसा पुराना kernel component install कराया जाता है जिसमें ज्ञात vulnerabilities हैं
    expert न होने पर भी लगता है कि Microsoft ने पहले से इस बारे में सोचा होगा और उसके पास blocklist या revocation mechanism जैसी कोई व्यवस्था होनी चाहिए
    असली सवाल यह है कि root cause operating system design की समस्या है, या फिर कोई टूटी हुई प्रक्रिया है जिसने broken या bad hash को सही जगह पर दर्ज नहीं किया
    अगर दूसरी बात है तो उसे ठीक करना कहीं आसान होगा, लेकिन हमेशा की तरह थोड़ी polish की गई security advisories पहली बात का संकेत देती लगती हैं

    • हो सकता है इसे इसलिए अनुमति देनी पड़ती हो क्योंकि enterprise users ज़ोर देते हैं कि update से कुछ टूट जाए तो उन्हें downgrade करने में सक्षम होना चाहिए

  • demo मौजूद है, इसलिए यह मानना मुश्किल है कि Microsoft इसका खंडन कर रहा है
    उस Vimeo account पर और भी कई security findings हैं। उदाहरण के लिए एक यह भी है कि WhatsApp Python script चलाता है; समझ नहीं आ रहा कि वह असली है या scam

    • demo यह दिखाता है कि Microsoft जिस चीज़ को वास्तविक security boundary नहीं मानता, उसे पार किया जा रहा है
      एक मानदंड है: “administrator processes और users को Windows के trusted computing base (TCB) का हिस्सा माना जाता है, इसलिए उन्हें kernel boundary से मज़बूती से अलग नहीं किया जाता” [0]
      हाल का एक और मामला भी है
      https://arstechnica.com/security/2024/03/hackers-exploited-w...
      [0] https://www.microsoft.com/en-us/msrc/windows-security-servic...

  • मुझे याद है जब Windows पर Microsoft ने पहली बार driver signing अनिवार्य किया था, तब [1] में सबको कितनी परेशानी हुई थी
    हम [2] के लिए deep packet inspection driver बना रहे थे, और पहली नज़र में यह प्रक्रिया Apple Store app approval से भी ज़्यादा कठिन लगी थी, जबकि documentation भी बिल्कुल स्पष्ट नहीं थी
    यह सोचकर कि कंपनियों ने Microsoft की requirements पूरी करने में कितने resources झोंक दिए, इस तरह इसका दुरुपयोग होना एक बड़ा setback लगता है
    vulnerabilities तो हमेशा रहेंगी, लेकिन अगर किसी ने इसे पहले खोज लिया होता तो कुछ तसल्ली मिलती
    इसे खोजने वाले Alon Leviev और SafeBreach के लिए तालियाँ
    [1] https://www.nektra.com/
    [2] https://www.verizon.com/business/en-nl/products/security/man...

  • “एडमिन के रूप में kernel code execution मिल सकता है” कहने का मतलब आखिरकार बस इतना है कि root यूज़र rootkit इंस्टॉल कर सकता है।
    बस इसे कोई चमकदार नाम देना नहीं भूलना चाहिए। अरे, शोधकर्ता तो पहले ही Windows Downdate नाम का टूल जारी कर चुका है।
    0xF मिनट की शोहरत तो मिल ही गई, इसलिए इसे सफल कह सकते हैं।

    • कुछ भी कर सकने वाले root/superuser अकाउंट का कॉन्सेप्ट आम है, लेकिन वह operating system की design choice है।
      user account भी operating system के अंदर एक object भर है, और superuser account को सीमित किए बिना भी ऐसा operating system डिज़ाइन किया जा सकता है जो सभी user accounts पर कुछ नियम लागू करे।
      उदाहरण के लिए, admin account compromise हो जाने पर भी TPM की तरह कुछ secrets को सुरक्षित रखना, या admin से गलती में system को unbootable हालत में पहुँचाने से रोकना, इसके वैध कारण हो सकते हैं।
      एक और अधिक विवादित लक्ष्य DRM को लागू करना भी हो सकता है।
      Windows में Microsoft भी यही करना चाहता है। operating system admin account को kernel में दखल देने या rootkit इंस्टॉल करने से रोकने की कोशिश करता है।
      इस चर्चा में operating system के अंदर वाले admin user account और physical/hardware access रखने वाले “administrator” इंसान के बीच फर्क करना हमेशा महत्वपूर्ण है।
    • यहाँ 15 लिखना ज़्यादा आसान था, फिर भी 0xF लिखा गया, यह दिलचस्प है।
      यह गलत नहीं है, लेकिन थोड़ा अजीब चुनाव है, इसलिए जिज्ञासा होती है। शायद सिर्फ स्टाइल की वजह से किया गया हो।

  • जब भी Windows इस्तेमाल करना पड़े, मैं हमेशा मानकर चलता हूँ कि वह कंप्यूटर पहले से ही compromised है।