kazet/wpgarlicएक अवधारणा-प्रमाण WordPress प्लगइन फ़ज़र
एक प्रूफ-ऑफ-कॉन्सेप्ट वर्डप्रेस प्लगइन फ़ज़र जिसने लगभग 30 मिलियन साइटों पर स्थापित 300 से अधिक वर्डप्रेस प्लगइन्स में कमज़ोरियाँ खोज निकालीं।
इस्तेमाल की गई तकनीक का वर्णन https://kazet.cc/2022/02/03/fuzzing-wordpress-plugins.html पर किया गया है।
अगर आप शोध जारी रखना चाहते हैं, तो कम लोकप्रिय प्लगइन्स से शुरू करें - यदि किसी प्लगइन ने अक्टूबर 2021 और जनवरी 2024 के बीच कम से कम 10k सक्रिय इंस्टॉल प्राप्त किए हैं, तो मैंने सबसे अधिक संभावना है कि फ़ज़र रिपोर्ट्स देखी हैं (और अधिकांश ध्यान उन प्लगइन्स पर केंद्रित किया गया है जिनमें कम से कम 20k सक्रिय इंस्टॉल हैं)। चूंकि फ़ज़र के काम करने के तरीके में बहुत अधिक यादृच्छिकता है, इन प्लगइन्स में कुछ कमज़ोरियाँ अभी भी अनदेखी रह सकती हैं - लेकिन कम।
फ़ज़र रिपोर्ट्स में बहुत सारे गलत सकारात्मक परिणाम होते हैं - उनमें से अधिकांश किसी कमज़ोरी का संकेत नहीं देते। रिपोर्ट देखने के बाद, पहले विश्लेषण करें कि आप जो व्यवहार देख रहे हैं वह वास्तव में कमज़ोरी है या गलत सकारात्मक। WPScan/विक्रेताओं को कच्ची फ़ज़र रिपोर्ट से स्पैम न करें - इसके बजाय एक PoC एक्सप्लॉइट प्रदान करें।
स्पष्ट कारणों से, उदाहरणों में केवल वे कमज़ोरियाँ होंगी जो पहले ही ठीक की जा चुकी हैं।
मान लीजिए आप responsive-vector-maps के संस्करण 6.4.0 को फ़ज़ कर रहे हैं:
./bin/fuzz_object plugin responsive-vector-maps --version 6.4.0
(नवीनतम संस्करण को फ़ज़ करने के लिए, बस --version छोड़ दें)।
फ़ज़िंग समाप्त होने के बाद (जिसमें इस प्लगइन के लिए 10-30 मिनट लगेंगे) आप कॉल कर सकते हैं:
./bin/print_findings data/object_fuzz_results/
आप देखेंगे, अन्य चीज़ों के अलावा:
इसका मतलब है कि फ़ज़र ने एक ज्ञात पेलोड पर fopen() निष्पादित होने का पता लगाया। अधिकांश पेलोड में आउटपुट में स्वचालित पहचान की सुविधा के लिए GARLIC शब्द होता है। आप उन्हें docker_image/magic_payloads.php में देख या कॉन्फ़िगर कर सकते हैं।
फिर, आप स्रोत कोड ब्राउज़ कर सकते हैं और देख सकते हैं कि वास्तव में wp_ajax_rvm_import_markers एंडपॉइंट आउटपुट प्रस्तुत करने के लिए फ़ाइल सामग्री का उपयोग करता है, इस प्रकार आपको सर्वर पर मनमानी फ़ाइलें पढ़ने की अनुमति देता है: CVE-2021-24947।
सफेद रंग में जो दिखाई देता है वह एक दिलचस्प क्रैश माना जाता है (आप उन्हें crash_detectors.py में संशोधित या नए जोड़ सकते हैं)। हरा संदर्भ है। नीले रंग में आप रिपोर्ट फ़ाइल नाम (प्लगइन नाम के साथ), प्लगइन लोकप्रियता और एंडपॉइंट नाम (यहां: ajax एक्शन नाम) देखते हैं।
पीले रंग का डेटा दर्शाता है कि किन पेलोड को किन वेरिएबल्स में इंजेक्ट किया गया था।
मान लीजिए आप page-builder-add के संस्करण 1.4.9.4 को फ़ज़ कर रहे हैं:
./bin/fuzz_object plugin page-builder-add --version 1.4.9.4
परिणाम प्रिंट करने के बाद, आप देखेंगे कि ज्ञात पेलोड वापस गूंज रहा है:
फिर आप मैन्युअल रूप से परीक्षण कर सकते हैं कि क्या वास्तव में यह स्थान (याद रखें: नीले रंग में आपके पास एंडपॉइंट नाम है, यहां: मेनू पृष्ठ नाम) XSS के प्रति संवेदनशील है। इस मामले में, यह है: CVE-2021-25067।
./bin/fuzz_object plugin duplicate-page-or-post --version 1.4.6
परिणाम प्रिंट करने के बाद, आप update_option को कॉल होते देखेंगे:
एंडपॉइंट के कोड का विश्लेषण आपको बताएगा कि यह वास्तव में एक संग्रहीत XSS कमज़ोरी की ओर ले जाता है: CVE-2021-25075।
दुर्भाग्य से, अधिकांश प्लगइन्स के लिए फ़ज़र को कोई दिलचस्प क्रैश नहीं मिलता, और बाकी के लिए, अधिकांश रिपोर्ट गलत सकारात्मक होती हैं. उदाहरण के लिए, यदि आप देखते हैं:
Call: wp_mail arguments={'to': '[email protected]', 'subject': '[Plugin contact] - http://GARLICGARLICGARLIC.example.com'}
इसका मतलब हो सकता है कि wp_mail वास्तव में कॉल किया गया है, लेकिन आप प्राप्तकर्ता और अधिकांश विषय को नियंत्रित नहीं करते। यदि आप सुनिश्चित होना चाहते हैं, तो प्लगइन स्रोत देखें।
__GARLIC_ACCESSED__ _FILES[files] __ENDGARLIC__ देखते हैं - इसका मतलब है कि अपलोड की गई फ़ाइल तक पहुंच का पता चला। वर्तमान में कोई और जाँच नहीं की जाती है - यह जाँचने के लिए कि क्या यह कमज़ोरी है, कोड देखें।$_GET['page'] में कुछ भी इंजेक्ट नहीं कर सकते।फ़ज़िंग या परीक्षणों की पहली रन में लगभग एक घंटा लग सकता है, क्योंकि हम इंस्ट्रूमेंटेड PHP और WordPress के साथ Docker इमेज बनाने की आवश्यकता है।
./bin/fuzz_object plugin PLUGIN_SLUG
./bin/fuzz_object theme THEME_SLUG
आप स्थानीय ज़िप फ़ाइल से भी प्लगइन स्थापित कर सकते हैं:
./bin/fuzz_object plugin PLUGIN_FILE_NAME.zip
फ़ज़र द्वारा पाए गए परिणामों को प्रिंट करने के लिए, उपयोग करें:
./bin/print_findings data/object_fuzz_results/
परीक्षण चलाने के लिए, उपयोग करें:
./bin/test
चेतावनी: परीक्षण लंबे समय तक चलते हैं (एक घंटे से अधिक) और क्योंकि वे जाँच करते हैं कि क्या फ़ज़र कमज़ोरियाँ ढूंढेगा, वे कुछ संभावना के साथ विफल होते हैं।
wpgarlic लिंटर्स चलाने और कोड को प्रारूपित करने के लिए pre-commit का उपयोग करता है।
CI पर pre-commit को निष्पादित किया जाता है ताकि यह सत्यापित हो सके कि कोड ठीक से प्रारूपित है।
इसे स्थानीय रूप से चलाने के लिए, उपयोग करें:
pre-commit run --all-files
pre-commit को सेटअप करने के लिए ताकि यह प्रत्येक कमिट से पहले चले, उपयोग करें:
pre-commit install
आप एक परीक्षण वातावरण शुरू कर सकते हैं जिसमें केवल एक प्लगइन स्थापित हो, का उपयोग करके:
./bin/manual_testing PLUGIN_SLUG|PLUGIN_PATH.zip [version]
आप किसी प्लगइन को उसके slug या स्थानीय zip फ़ाइल से स्थापित कर सकते हैं।
यह http://127.0.0.1:8001/ पर सुनता रहेगा।
डेटाबेस में दो परीक्षण उपयोगकर्ता होंगे:
यह उपकरण एक प्रूफ-ऑफ-कॉन्सेप्ट है - इस अनुभाग में वे स्थान हैं जहाँ इसे और अधिक कमज़ोरियाँ खोजने के लिए बेहतर बनाया जा सकता है.
आप filtering.py को संपादित करना चाह सकते हैं -- इसमें ऐसे नियम हैं जो किसी विशेष क्रैश को महत्वपूर्ण या नहीं मानते हैं। यदि आप उन्हें बदलते हैं, तो आपके पास अधिक गलत सकारात्मक हो सकते हैं, लेकिन साथ ही अधिक कमज़ोरियाँ भी मिल सकती हैं। उदाहरण के लिए, एकमात्र हेडर जिसे मैं उत्सर्जित होने पर दिलचस्प मानता हूँ वह है Location हेडर, ताकि Open Redirect कमज़ोरियों का पता लगाया जा सके। यह केवल एक विचार है और आपके पास अन्य हो सकते हैं।
एक और फ़ाइल जो विस्तार के योग्य हो सकती है वह है docker_image/patch_wordpress.sh। यह बताती है कि किन फ़ंक्शनों के कॉल को दिलचस्प के रूप में लॉग किया जाएगा।
यदि आप अन्य पेलोड इंजेक्ट करना चाहते हैं (या उन संभावनाओं को बदलना चाहते हैं जिनके साथ वे इंजेक्ट किए जाते हैं) तो docker_image/magic_payloads.php और docker_image/fuzz/config.py को संपादित करें।
crash_detector.py में नियमित अभिव्यक्तियाँ हैं जो दिलचस्प क्रैश या दिलचस्प जानकारी (जैसे ई-मेल) के उजागर होने का पता लगाती हैं।
लॉग-इन किए गए व्यवस्थापक के रूप में REST रूट्स को फ़ज़ करना अक्षम कर दिया गया है क्योंकि इससे गलत सकारात्मक उत्पन्न हुए। इसे बदलने के लिए config.DEFAULT_ENABLED_FEATURES में rest_routes_admin को अनकम्मेंट करें।
कुछ प्लगइन्स को दूसरों (जैसे woocommerce) की निर्भरता के रूप में आवश्यकता होती है। जब किसी ऐसे प्लगइन को फ़ज़ कर रहे हैं जिसमें निर्भरता है, तो हम केवल चुने गए प्लगइन को फ़ज़ करना चाहते हैं और निर्भरता AJAX एक्शन, REST रूट्स और मेनू पृष्ठों को छोड़ देना चाहते हैं। हम woocommerce एक्शन/रूट/पृष्ठों को तभी फ़ज़ करना चाहते हैं जब हमने woocommerce को फ़ज़ करने के लिए चुना हो।
निर्भरता एक्शन/रूट/पृष्ठों की सूची को ब्लॉकलिस्ट कहा जाता है और यह docker_image/blocklists/ में सूचीबद्ध हैं। common नाम की फ़ाइलों में WordPress कोर एक्शन/रूट/पृष्ठ होते हैं - हम इन्हें भी फ़ज़ नहीं करना चाहते।
इन ब्लॉकलिस्ट को अपडेट करने के लिए, ./bin/update_blocklists का उपयोग करें।
शायद। प्लगइन को स्थानीय परीक्षण वातावरण में स्थापित करें (उदाहरण के लिए आप मैन्युअल परीक्षण वातावरण अनुभाग में वर्णित का उपयोग कर सकते हैं) और बग का विश्लेषण करें।
ऐसा न मानें। फ़ज़र कुछ प्रकार की कमज़ोरियाँ ढूंढता है, लेकिन इसकी सीमाएँ हैं।
अधिकांश प्लगइन्स के लिए फ़ज़र को कुछ नहीं मिलता - उपकरण का उद्देश्य एकल प्लगइन का व्यापक परीक्षण करना नहीं है, बल्कि बड़ी संख्या में वर्डप्रेस प्लगइन्स का बड़े पैमाने पर स्कैन करना है।
यह संभव है। फ़ज़र पेलोड को यादृच्छिक रूप से चुनता है, और अन्य स्थानों पर यादृच्छिकता प्रस्तुत करता है (जैसे कि == ऑपरेटर को उन मामलों में कैसे व्यवहार करना चाहिए जिनका वर्णन https://kazet.cc/2022/02/03/fuzzing-wordpress-plugins.html#patched-equality में किया गया है)।
Github टिकट दर्ज करें या मुझे ई-मेल करें: [email protected]।