Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CACredDecoder — C-Ark क्रेडेंशियल डिकोडर #CVE-2021-31796 के लिए | Kitploit
उपकरण/GitHubGitHub/unmanarc/cacreddecoder
पासवर्ड क्रैकिंगएन्क्रिप्शन/डिक्रिप्शन उपकरणभेद्यता विश्लेषणशोषणक्रिप्टोग्राफीपेनिट्रेशन टेस्टिंग
GitHubunmanarc/cacreddecoder

CACredDecoder

C-Ark क्रेडेंशियल डिकोडर #CVE-2021-31796 के लिए

रिपॉजिटरी देखें
114 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

C-Ark क्रेडेंशियल डिकोडर

CVE-2021-31796 के लिए शोषण उपकरण
C-Ark क्रेडेंशियल फ़ाइलों को डिकोड करने के लिए एक उपकरण

द्वारा: Aaron Mizrachi        - https://twitter.com/unmanarc/
      Enrique Vaamonde - https://twitter.com/_ejvm
पहला रिलीज़: 2/सितंबर/2019
प्रकटीकरण: 11/अक्टूबर/2021

संदर्भ

  • https://packetstormsecurity.com/files/164023/CyberArk-Credential-File-Insufficient-Effective-Key-Space.html
  • https://vuldb.com/?id.181904

जिम्मेदार प्रकटीकरण:

यह भेद्यता सितंबर/2019 से रिलीज़ के लिए लंबित थी।

और... यहाँ समयरेखा है:

  • 2019-08-1x कुछ अभ्यास के दौरान, हमारी टीम ने स्थानीय विक्रेता प्रतिनिधि को उपयोग की जाने वाली कुछ क्रेडेंशियल भंडारण विधियों में एक संभावित क्रिप्टो कमजोरी की सूचना दी और रिपोर्ट की।
  • 2019-08-30 इस तिथि तक, हमारे पास केवल अपने स्वयं के टूल का उपयोग करके एक "ollydbg" मेमोरी-में प्रूफ ऑफ कॉन्सेप्ट था। हम यह बिंदु साबित करने की कोशिश कर रहे थे कि यह कुछ विशिष्ट स्थितियों के लिए हमले का वेक्टर कैसे बन सकता है, लेकिन हम बिंदु साबित करने में असफल रहे। इसलिए हमने इस प्रूफ ऑफ कॉन्सेप्ट को कोड करना शुरू करने का निर्णय लिया ताकि अधिक स्पष्ट तर्क हो।
  • 2019-09-02 हमने सफलतापूर्वक हैशिंग और क्रिप्टो एल्गोरिथम को अपने स्वयं के प्रूफ ऑफ कॉन्सेप्ट में लागू किया (उत्पाद से पूरी तरह अलग)।
  • 2019-09-03 हमने विक्रेता को अपने निष्कर्षों और इसे सार्वजनिक रूप से उपलब्ध कराने में अपनी रुचि की घोषणा की।
  • 2019-09-20 हमें विक्रेता से अनुरोध प्राप्त हुआ कि जब तक समस्या ठीक नहीं हो जाती, तब तक सार्वजनिक रिलीज़ में देरी करें।
  • 2020-05 हमने उनसे फिर से संपर्क किया ताकि टूल जारी करने की अनुमति मिल सके और कुछ ईमेल का आदान-प्रदान किया जिसमें उन्होंने कहा कि वे तैयार नहीं हैं।
  • 2021-09/2021-10 हमने पाया कि अन्य असंबंधित शोधकर्ताओं ने भी हाल ही में इसी भेद्यता को सार्वजनिक रूप से खोजा और प्रकट किया है, और इसे देखते हुए... अंततः (2 वर्षों के बाद!) हमें विक्रेता द्वारा CreateCredFile क्रिप्टो-कमजोरी के शोषण के लिए अपने निष्कर्षों और प्रूफ ऑफ कॉन्सेप्ट टूल को आपके साथ साझा करने की मंजूरी मिल गई है।

संभावित उपयोग:

पेनटेस्ट के दौरान, यदि कोई व्यक्ति इतना स्मार्ट है कि PSM तक पहुँच सकता है और गलती से CredFile तक पहुँच प्राप्त कर लेता है, तो वह व्यक्ति संभावित रूप से इस फ़ाइल का उपयोग Vault से कनेक्शन स्थापित करने और पूरा साम्राज्य प्राप्त करने के लिए कर सकता है...

प्रतिउपाय के रूप में, अधिकांश क्रेडेंशियल फ़ाइलें पासवर्ड को किसी भिन्न वातावरण/कंप्यूटर (जैसे हैकर का अपना PSM) में उपयोग होने से रोकने के लिए कुछ "प्रतिबंध" रखती हैं।

हालाँकि, यदि आप रिवर्स करते हैं और कच्ची कुंजी भाग प्राप्त करते हैं तो उन प्रतिबंधों को संशोधित किया जा सकता है। इस डिक्रिप्ट की गई कुंजी भाग का उपयोग अन्य "सुरक्षा" पैरामीटर (जैसे कोई अन्य होस्ट, कोई अन्य एप्लिकेशन, कोई अन्य OS उपयोगकर्ता) के साथ एक और फ़ाइल बनाने के लिए किया जा सकता है।

संचालन मोड

AES-256 (32 बाइट्स) की कच्ची डिक्रिप्शन कुंजी उत्पन्न करने के लिए, हम "AdditionalInformation" क्रेडेंशियल फ़ील्ड से प्रत्येक हैश के लिए "0x00000000" और "0x00000001" जोड़कर SHA1SUM की एक जोड़ी लेते हैं; पहला हैश कुंजी के पहले 20 बाइट प्रदान करता है, और दूसरा केवल अंतिम 12 बाइट प्रदान करता है।

यदि कोई पर्यावरणीय प्रतिबंध (जैसे IP/Host/exepath/...) हैं, तो हम दोनों SHA1SUM लेने से पहले प्रत्येक प्लेनटेक्स्ट मान को AdditionalInformation में जोड़ते हैं।

यह उल्लेख करना महत्वपूर्ण है कि "ClientApp" फ़ील्ड को "AdditionalInformation" में जोड़ने और दोनों SHA1SUM उत्पन्न करने से पहले BASE64(SHA1SUM(strlower(ClientApp))) में रूपांतरित किया जाता है।

डिक्रिप्शन AES-256-CBC OpenSSL फ़ंक्शन का उपयोग करके किया जाता है जिसमें Password या NewPassword फ़ील्ड का उपयोग किया जाता है। (https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

हम यह पता लगाने के लिए (verificationflags-16) का उपयोग कर रहे हैं कि कौन सा सत्यापन/प्रतिबंध लागू है:

root@kitploit:~
usingClientApp      = ((uVerificationsFlag&0x1) != 0);
usingAppPath        = ((uVerificationsFlag&0x2) != 0);
usingClientIP       = ((uVerificationsFlag&0x4) != 0);
usingOSUser         = ((uVerificationsFlag&0x8) != 0);
usingClientHostname = ((uVerificationsFlag&0x20) != 0);

और यदि आउटपुट क्रेडेंशियल फ़ाइल में कुछ प्रतिबंध प्रदर्शित नहीं होते हैं, तो आप उन्हें हमेशा हाथ से दर्ज कर सकते हैं। मुझे लगता है कि हम दोनों इस बात से सहमत हो सकते हैं कि न तो "app path" और न ही "client IP" वास्तव में यादृच्छिक मान हैं।

शमन:

HSM का उपयोग करें \o/, डिक्रिप्शन कुंजी को क्रेड फ़ाइल में संग्रहीत न करें।

निर्माण विधि:

root@kitploit:~
qmake . 
make -j8
टूल डाउनलोड करें