Crassus Windows विशेषाधिकार वृद्धि खोज उपकरण

त्वरित शुरुआत

1. Process Monitor में, Enable Boot Logging विकल्प चुनें।
2. रिबूट करें।
3. एक बार जब आप लॉग इन कर लें और Windows स्थिर हो जाए, तो Process Monitor को फिर से चलाएँ।
4. जब संकेत दिया जाए, तो बूट लॉग को सहेजें, उदा., raw.PML में।
5. Ctrl-R का उपयोग करके डिफ़ॉल्ट Process Monitor फ़िल्टर रीसेट करें।
6. इस लॉग फ़ाइल को सहेजें, उदा., boot.PML में।
7. Crassus.exe boot.PML चलाएँ।
8. किसी भी हरे रंग के परिणाम और results.csv में संबंधित प्रविष्टियों की जाँच करें।

विषयसूची

• "Crassus" क्यों?
  • क्या आपने वास्तव में एक और विशेषाधिकार वृद्धि खोज उपकरण बनाया?
  • विशेषताएँ
  • फ़्लोचार्ट
• स्क्रीनशॉट
  • Crassus निष्पादन
  • CSV आउटपुट
  • निर्यात
  • Export DLL फ़ंक्शन
  • Export DLL Ordinals
• Crassus.exe प्राप्त करना
  • Visual Studio के साथ बनाना
  • पूर्व-संकलित Crassus.exe का उपयोग करना
• उपयोग
  • निष्पादन प्रवाह
  • कमांड लाइन तर्क
  • उदाहरण
  • प्रॉक्सी DLL टेम्पलेट
  • openssl.cnf टेम्पलेट
• प्रॉक्सी DLL संकलन
  • Visual Studio
  • MinGW
• वास्तविक दुनिया के उदाहरण
  • Acronis True Image
  • Atlassian Bitbucket
  • McAfee
  • Microsoft SQL Server 2022
• समस्या निवारण
  • गुम फ़ाइल लोड नहीं हुई
  • अप्रत्याशित विशेषाधिकारों के साथ कोड निष्पादित
  • रिबूट पर निष्कर्ष गायब हो जाते हैं
• योगदान
• क्रेडिट

"Crassus" क्यों?

Accenture ने Spartacus नामक एक उपकरण बनाया, जो Windows पर DLL हाइजैकिंग के अवसरों का पता लगाता है। Spartacus को शुरुआती बिंदु के रूप में उपयोग करते हुए, हमने Crassus बनाया ताकि Windows विशेषाधिकार वृद्धि खोज क्षमताओं को केवल गुम फ़ाइलों की खोज से परे बढ़ाया जा सके। विशेषाधिकार प्राप्त प्रक्रियाओं की फ़ाइलों और निर्देशिकाओं द्वारा उपयोग किए जाने वाले ACL, लक्ष्य प्राप्त करने के लिए गुम फ़ाइलों की खोज से अधिक पा सकते हैं।

क्या आपने वास्तव में एक और विशेषाधिकार वृद्धि खोज उपकरण बनाया?

...लेकिन एक मोड़ के साथ, क्योंकि Crassus SysInternals Process Monitor का उपयोग करता है और कच्चे PML लॉग फ़ाइलों को पार्स करता है। सामान्य उपयोग Process Monitor का उपयोग करके बूट लॉग उत्पन्न करना और फिर Crassus के साथ पार्स करना है। यह स्वचालित रूप से कमजोर DLL के लिए सभी प्रासंगिक निर्यातों के साथ प्रॉक्सी DLL के लिए स्रोत कोड भी उत्पन्न करेगा।

विशेषताएँ

• ProcMon PML फ़ाइलों को मूल रूप से पार्स करना। लॉग (PML) पार्सर को C# में https://github.com/eronnen/procmon-parser/ से आंशिक कार्यक्षमता पोर्ट करके लागू किया गया है। आप प्रारूप विनिर्देश यहाँ पा सकते हैं।
• Crassus सभी पहचाने गए गुम DLL के लिए प्रॉक्सी DLL के लिए स्रोत कोड बनाएगा। उदाहरण के लिए, यदि कोई एप्लिकेशन version.dll के माध्यम से DLL हाइजैकिंग के लिए कमजोर है, तो Crassus आपके लिए version.cpp और version.def फ़ाइलें बनाएगा जिसमें सभी निर्यात शामिल होंगे। डिफ़ॉल्ट रूप से प्रॉक्सी DLL calc.exe लॉन्च करेगा। DLL को Visual Studio या MinGW पर बनाने के लिए बिल्ड स्क्रिप्ट शामिल हैं।
• अन्य रुचि की घटनाओं के लिए, जैसे कि प्रक्रिया बनाना या लाइब्रेरी लोड करना, अविशेषाधिकार प्राप्त उपयोगकर्ताओं की फ़ाइल या फ़ाइल के पथ के किसी भी भाग को संशोधित करने की क्षमता की जाँच की जाती है।
• बड़ी PML फ़ाइलों को संसाधित करने और सभी रुचि की घटनाओं को एक आउटपुट CSV फ़ाइल में संग्रहीत करने में सक्षम।

फ़्लोचार्ट

Crassus कैसे काम करता है इसका सामान्य सारांश इस फ़्लोचार्ट में संक्षेपित किया जा सकता है:

स्क्रीनशॉट

Crassus निष्पादन

CSV आउटपुट

आउटपुट निर्यात

Export DLL फ़ंक्शन

Export DLL Ordinals

Crassus.exe प्राप्त करना

Visual Studio के साथ बनाना

Crassus को Visual Studio 2019 प्रोजेक्ट के रूप में विकसित किया गया था। Crassus.exe बनाने के लिए:

1. Crassus.sln खोलें
2. अपने कीबोर्ड पर Ctrl+Shift+B दबाएँ

पूर्व-संकलित Crassus.exe का उपयोग करना

यदि आप बिना जाने दूसरों के कोड को चलाने पर भरोसा करते हैं, तो Crassus.exe इस रिपॉजिटरी में प्रदान किया गया है।

उपयोग

निष्पादन प्रवाह

1. Process Monitor में, Enable Boot Logging विकल्प चुनें।
2. रिबूट करें।
3. एक बार जब आप लॉग इन कर लें और Windows स्थिर हो जाए, तो वैकल्पिक रूप से निर्धारित कार्यों को भी चलाएँ जो विशेषाधिकारों के साथ चलने के लिए कॉन्फ़िगर किए जा सकते हैं।
4. Process Monitor को फिर से चलाएँ।
5. जब संकेत दिया जाए, तो बूट लॉग को सहेजें।
6. Ctrl-R का उपयोग करके डिफ़ॉल्ट Process Monitor फ़िल्टर रीसेट करें।
7. इस लॉग फ़ाइल को सहेजें, उदा., boot.PML में। लॉग फ़ाइल को पुनः सहेजने का कारण दोहरा है:
   1. Process Monitor के पुराने संस्करण बूट लॉग को एकल फ़ाइल के रूप में सहेज नहीं पाते।
   2. बूट लॉग डिफ़ॉल्ट रूप से अनफ़िल्टर्ड होंगे, जिसमें अतिरिक्त शोर हो सकता है, जैसे कि Process Monitor के स्वयं लॉन्च होने में स्थानीय-उपयोगकर्ता DLL हाइजैकिंग।

कमांड लाइन तर्क

उदाहरण

boot.PML में सहेजे गए Process Monitor बूट लॉग को पार्स करें। सभी कमजोर पथ results.csv के रूप में सहेजे जाएंगे और सभी प्रॉक्सी DLL स्रोत फ़ाइलें stubs उपनिर्देशिका में सहेजी जाएंगी।

C:\tmp> Crassus.exe boot.PML

प्रॉक्सी DLL टेम्पलेट

नीचे वह टेम्पलेट है जिसका उपयोग प्रॉक्सी DLL उत्पन्न करते समय किया जाता है। Crassus द्वारा पाए गए DLL के लिए, प्रॉक्सी DLL में %_EXPORTS_% में निर्दिष्ट समान निर्यात नाम होंगे, साथ ही .def फ़ाइल में निर्दिष्ट समान ऑर्डिनल्स होंगे। Crassus पैरेंट प्रक्रिया के आर्किटेक्चर को देखकर पता लगाएगा कि DLL को 32-बिट लाइब्रेरी या 64-बिट लाइब्रेरी के रूप में बनाने की आवश्यकता है या नहीं, और %_BUILD_AS_% फ़ील्ड में स्रोत कोड को टैग करेगा।

यदि Process Monitor लॉग का उपयोग करके वास्तविक DLL नहीं मिल पाता है, या यदि निर्यात नाम समस्याग्रस्त है, तो बिल्ड स्क्रिप्ट निर्दिष्ट निर्यात के बिना DLL बनाने पर वापस आ जाएगी।

#pragma once
    
//%_BUILD_AS%

#include <windows.h>;

extern "C" {

  VOID Payload() {
      // अपना पेलोड यहाँ चलाएँ।
      WinExec("calc.exe", 1);
  }

  BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
  {
      switch (fdwReason)
      {
      case DLL_PROCESS_ATTACH:
          Payload();
          break;
      case DLL_THREAD_ATTACH:
          break;
      case DLL_THREAD_DETACH:
          break;
      case DLL_PROCESS_DETACH:
          break;
      }
      return TRUE;
  }


  #ifdef ADD_EXPORTS
  %_EXPORTS_%
  #endif
}

openssl.cnf टेम्पलेट

उन एप्लिकेशन के लिए जो असुरक्षित रूप से OPENSSLDIR वेरिएबल मान का उपयोग करते हैं, एक तैयार किया गया openssl.cnf फ़ाइल नोट किए गए स्थान पर रखा जा सकता है। इस उदाहरण के लिए, सॉफ़्टवेयर C:\tmp\calc.dll लोड करेगा। 32-बिट प्रक्रियाओं को लक्षित करने के लिए 32-बिट लाइब्रेरी और 64-बिट प्रक्रियाओं को लक्षित करने के लिए 64-बिट लाइब्रेरी का उपयोग करना सुनिश्चित करें।

openssl_conf = openssl_init
[openssl_init]
# यह OpenSSL आरंभीकरण के भाग के रूप में फ़ाइल c:\tmp\calc.dll को लोड करने का प्रयास करेगा
# बिल्ड स्क्रिप्ट को पता लगाना चाहिए कि calc.dll लाइब्रेरी को 32-बिट या 64-बिट के रूप में बनाने की आवश्यकता है या नहीं
/tmp/calc = asdf

प्रॉक्सी DLL संकलन

Visual Studio

संकलन Visual Studio के साथ शामिल cl.exe बाइनरी का उपयोग करके संभव है। विशेष रूप से:

cl.exe /DADD_EXPORTS /D_USRDLL /D_WINDLL <target>.cpp /LD /Fe<target>.dll /link /DEF:<target>.def

बिल्ड प्रक्रिया को स्वचालित करने के लिए, जिसमें यह निर्दिष्ट करना शामिल है कि लाइब्रेरी 64-बिट या 32-बिट होनी चाहिए:

1. Visual Studio डेवलपर कमांड प्रॉम्प्ट खोलें।
2. build.bat स्क्रिप्ट के साथ DLL बनाएँ।
3. यदि कमजोर फ़ाइल नाम .dll के अलावा किसी और चीज़ पर समाप्त होता है तो संकलित फ़ाइल का नाम बदलें।

नोट: vcvarsall.bat के साथ एक दुर्भाग्यपूर्ण व्यवहार के कारण, जो निश्चित रूप से एक बग नहीं है, आपको एक ही Visual Studio डेवलपर कमांड प्रॉम्प्ट सत्र में build.bat को एक से अधिक बार चलाने का प्रयास करने में परेशानी हो सकती है। यदि आपको कोई त्रुटि मिलती है, तो बस विंडो बंद करें और इसे फिर से लॉन्च करें।

MinGW

यदि Visual Studio आसानी से उपलब्ध नहीं है, तो प्रॉक्सी DLL को इसके बजाय MinGW-w64 के साथ संकलित किया जा सकता है। उदाहरण के लिए, Ubuntu प्लेटफ़ॉर्म पर, MinGW को निम्नलिखित के माध्यम से स्थापित किया जा सकता है: sudo apt install g++-mingw-w64-x86-64-win32 g++-mingw-w64-i686-win32

# 32-बिट DLL बनाएँ
i686-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
i686-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows

# 64-बिट DLL बनाएँ
x86_64-w64-mingw32-g++ -c -o <target>.o <target>.cpp -D ADD_EXPORTS
x86_64-w64-mingw32-g++ -o <target>.dll <target>.o <target>.def -s -shared -Wl,--subsystem,windows

बिल्ड प्रक्रिया को स्वचालित करने के लिए, जिसमें यह निर्दिष्ट करना शामिल है कि लाइब्रेरी 64-बिट या 32-बिट होनी चाहिए:

1. एक टर्मिनल खोलें।
2. bash ./build.sh चलाएँ।
3. यदि कमजोर फ़ाइल नाम .dll के अलावा किसी और चीज़ पर समाप्त होता है तो संकलित फ़ाइल का नाम बदलें।

वास्तविक दुनिया के उदाहरण

Acronis True Image

Crassus विश्लेषण

जैसा कि VU#114757 में उल्लिखित है, पुराने Acronis सॉफ़्टवेयर में कई विशेषाधिकार वृद्धि कमजोरियाँ हैं।

1. openssl.cnf का एक अविशेषाधिकार प्राप्त-उपयोगकर्ता-निर्माण योग्य स्थान पर प्लेसमेंट।
2. C:\ProgramData\Acronis निर्देशिका में अनुचित ACL।

Crassus इन दोनों मुद्दों को स्वचालित रूप से ढूँढता है।

DLL हाइजैकिंग

हमारे संकलित curl.dll फ़ाइल को C:\ProgramData\Acronis\Agent\var\atp-downloader\ निर्देशिका में रोपित करके और एक नए Process Monitor बूट लॉग के साथ रिबूट करके, हम देख सकते हैं कि calc.exe चलाने वाला हमारा पेलोड SYSTEM विशेषाधिकारों के साथ चलता है।

openssl.cnf प्लेसमेंट

कमजोर Acronis सॉफ़्टवेयर दो अलग-अलग स्थानों से openssl.cnf लोड करने का प्रयास करता है। हम अपना टेम्पलेट openssl.cnf फ़ाइल c:\jenkins_agent\workspace\tp-openssl-win-vs2013\17\product\out\standard\vs_2013_release\openssl\ssl में रखेंगे, और एक 32-बिट calc.dll पेलोड c:\tmp में रखेंगे।

Atlassian Bitbucket

Crassus विश्लेषण

जैसा कि VU#240785 में उल्लिखित है, पुराने Atlassian Bitbucket सॉफ़्टवेयर इंस्टॉलेशन निर्देशिका के कमजोर ACL के कारण विशेषाधिकार वृद्धि के लिए कमजोर है। किसी भी Windows सॉफ़्टवेयर की तरह जो C:\Program Files\ या अन्य ACL-प्रतिबंधित स्थानों के बाहर स्थापित होता है, सॉफ़्टवेयर इंस्टॉलर पर लक्ष्य निर्देशिका पर स्पष्ट रूप से ACL सेट करना निर्भर करता है।

Crassus इस सॉफ़्टवेयर के साथ विशेषाधिकार वृद्धि प्राप्त करने के कई तरीके ढूँढता है, जिनमें शामिल हैं:

• उपयोगकर्ता-लेखनीय स्थानों में गुम DLL का प्लेसमेंट।
• उपयोगकर्ता-लेखनीय स्थानों में गुम EXE का प्लेसमेंट।
• एक विशेषाधिकार प्राप्त EXE की निर्देशिका का नाम बदलकर उपयोगकर्ता को समान नाम के EXE के प्लेसमेंट की अनुमति देना।

EXE हाइजैकिंग

Crassus आउटपुट में, हम देख सकते हैं कि c:\atlassian\bitbucket\7.9.1\elasticsearch\bin\elasticsearch-service-x64.exe विशेषाधिकार प्राप्त है, लेकिन चूंकि यह चल रहा है, हम इसे आसानी से बदल नहीं सकते। हालाँकि, हम इसे हाइजैक करने के लिए एक और तरकीब का उपयोग कर सकते हैं। हम आसानी से उस निर्देशिका का नाम बदल सकते हैं जिसमें यह रहता है, उसी नाम की एक नई निर्देशिका बना सकते हैं, और वहाँ अपना पेलोड उसी नाम से रोपित कर सकते हैं।

एक बार जब हम Process Monitor बूट लॉग के साथ रिबूट करते हैं, तो हम देख सकते हैं कि हमारा रोपित elasticsearch-service-x64.exe फ़ाइल वास्तविक के बजाय चल रहा है, जो Windows कैलकुलेटर आइकन पर आधारित है।

McAfee

जैसा कि VU#287178 में उल्लिखित है, McAfee सॉफ़्टवेयर के पुराने संस्करण openssl.cnf के माध्यम से विशेषाधिकार वृद्धि के लिए कमजोर हैं। आइए एक नज़र डालते हैं:

यह देखने के लिए कि इस बूट लॉग में openssl.cnf के दो अलग-अलग संदर्भ क्यों हैं, हम results.csv फ़ाइल देख सकते हैं:

ध्यान दें कि D:\ पथ से openssl.cnf फ़ाइल को लोड करने के लिए आगे मैन्युअल जाँच की आवश्यकता होगी, क्योंकि ऐसे पथ को लोड करने की व्यवहार्यता प्रश्न में प्लेटफ़ॉर्म और सिस्टम तक क्या पहुँच उपलब्ध है, पर निर्भर करती है। एक ऑप्टिकल डिस्क बनाना संभव हो सकता है जो एक openssl.cnf फ़ाइल प्रदान करती है जो ऑप्टिकल ड्राइव को हल करने वाले पथ को भी संदर्भित करती है।

Microsoft SQL Server 2022

SQL Server 2022 स्पष्ट रूप से कमजोर ACL के कारण विशेषाधिकार वृद्धि के लिए कमजोर नहीं है जब तक इसे गैर-मानक स्थान पर स्थापित नहीं किया जाता है। यदि इसे C:\Program Files के बाहर किसी स्थान पर स्थापित किया जाता है, तो Crassus विशेषाधिकार वृद्धि के लिए कई संभावनाओं को उजागर करेगा। अधिकांश Windows एप्लिकेशन जिनमें एक विशेषाधिकार प्राप्त घटक शामिल है, इस तरह से शोषण योग्य प्रतीत होते हैं यदि वे किसी ऐसी निर्देशिका में स्थापित होते हैं जिसमें पहले से ही सुरक्षित ACL नहीं हैं।

समस्या निवारण

गुम फ़ाइल निष्पादित नहीं हुई

यदि Crassus किसी फ़ाइल के विशेषाधिकार प्राप्त लोडिंग की रिपोर्ट करता है जिसे उपयोगकर्ता रोपित या संशोधित कर सकता है, तो इसका मतलब यह नहीं है कि यह एक शोषण योग्य परिदृश्य है। जबकि Crassus संभावित रूप से रुचिकर फ़ाइल प्रकारों की तलाश करता है, एक Process Monitor लॉग फ़ाइल सीधे यह संकेत नहीं देगी कि संबंधित प्रक्रिया फ़ाइल के साथ क्या करती यदि वह वहाँ होती। यह एक प्रोग्राम आइकन निकालने जितना सरल हो सकता है। Process Monitor में फ़ाइल ऑपरेशन के कॉल स्टैक की जाँच करने से संकेत मिल सकता है कि क्या किया गया होता। या बस फ़ाइल रखें और एक नए Process Monitor बूट लॉग के साथ व्यवहार की जाँच करें, यदि आप आसान ब्रूट फोर्स मार्ग पसंद करते हैं। आपको एक ऐसी गुम लाइब्रेरी का भी सामना करना पड़ सकता है जहाँ या तो Crassus लाइब्रेरी नहीं ढूँढ पाता कि कौन से निर्यात मौजूद होने चाहिए, या Crassus द्वारा पाए गए निर्यात इस तरह से टकराते हैं जो उचित DLL संकलन को रोकता है। ऐसे मामलों में, Crassus एक DLL बनाने पर वापस आ जाएगा जो कोई फ़ंक्शन नाम निर्यात नहीं करता है। लक्ष्य एप्लिकेशन लाइब्रेरी को कैसे लोड करता है, इसके आधार पर, अपेक्षित फ़ंक्शन नामों और/या ऑर्डिनल नंबरों की अनुपस्थिति लक्ष्य एप्लिकेशन को लाइब्रेरी को सफलतापूर्वक लोड करने से रोक सकती है। इस परिदृश्य में यह निर्धारित करने के लिए मैन्युअल प्रयास की आवश्यकता होगी कि प्रॉक्सी DLL कैसा दिखना चाहिए।

अप्रत्याशित विशेषाधिकारों के साथ कोड निष्पादित

Crassus रुचि के पथों की खोज के लिए विशेषाधिकार प्राप्त फ़ाइल संचालन की तलाश करेगा। आपको एक ऐसे परिदृश्य का सामना करना पड़ सकता है जहाँ एक विशेषाधिकार प्राप्त और एक अविशेषाधिकार प्राप्त प्रक्रिया दोनों एक पथ तक पहुँचती हैं, लेकिन केवल गैर-विशेषाधिकार प्राप्त प्रक्रिया ही वह है जो मौजूद कुछ का निष्पादन करती है। वैकल्पिक रूप से, आपको एक ऐसे परिदृश्य का सामना करना पड़ सकता है जहाँ एक पैरेंट प्रक्रिया विशेषाधिकारों के साथ चलती है, लेकिन यह स्पष्ट रूप से कम विशेषाधिकारों के साथ चाइल्ड प्रक्रियाओं को जन्म दे सकती है।

रिबूट पर निष्कर्ष गायब हो जाते हैं

विशेष रूप से पहली बार सॉफ़्टवेयर स्थापित करते समय, या अपडेट स्थापित करते समय, Process Monitor एक फ़ाइल ऑपरेशन लॉग कर सकता है जो शोषण योग्य लगता है लेकिन हर बार जब सिस्टम बूट होता है तो नहीं होता है। ऐसी घटना होने के बाद पहले रिबूट पर इन संचालनों का शोषण करना संभव हो सकता है। ऐसे किनारे के मामलों से बचने के लिए, पुष्टि करें कि बाद के बूट लॉग में बाद के रिबूट पर समान रिपोर्ट किए गए फ़ाइल संचालन शामिल हैं।

योगदान

चाहे वह टाइपो, बग या नई सुविधा हो, Crassus योगदान के लिए बहुत खुला है जब तक हम निम्नलिखित पर सहमत हैं:

• आप इस प्रोजेक्ट के MIT लाइसेंस से सहमत हैं।
• पुल रिक्वेस्ट बनाने से पहले, एक मुद्दा बनाएँ ताकि कोई भी कार्य करने से पहले इस पर चर्चा की जा सके, क्योंकि आंतरिक विकास सार्वजनिक GitHub रिपॉजिटरी के माध्यम से ट्रैक नहीं किया जाता है। अन्यथा, आप जोखिम उठाते हैं कि आपकी पुल रिक्वेस्ट अस्वीकार कर दी जाएगी, उदाहरण के लिए यदि हम पहले से ही उसी/समान सुविधा पर काम कर रहे हैं, या किसी अन्य कारण से।

क्रेडिट

• https://github.com/eronnen/procmon-parser/