LAB 9-CVE-2018-7600

I. सिस्टम विश्लेषण

हमला सतह की पहचान करें

चल रहे कंटेनरों को सूचीबद्ध करके शुरू करें:

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 की पहचान करने के लिए एक मजबूत सबूत है। मैं इस प्रकार तर्क करता हूँ:

1. docker ps दिखाता है कि लैब पोर्ट 8011 के माध्यम से HTTP सेवा को एक्सपोज़ करता है।
2. curl -i Apache/PHP से एक मान्य HTTP प्रतिक्रिया लौटाता है।
3. प्रतिक्रिया /core/install.php पर रीडायरेक्ट करती है।
4. वेब इंटरफ़ेस स्पष्ट रूप से Drupal 8.5.0 प्रदर्शित करता है।
5. Drupal सलाहकार पुष्टि करता है कि Drupal >=8.5.0 <8.5.1 CVE-2018-7600 से प्रभावित है।
6. लक्ष्य ठीक Drupal 8.5.0 चला रहा है, जो इसे CVE-2018-7600 का परीक्षण करने के लिए संस्करण मानदंडों के तहत पात्र बनाता है।

लक्ष्य Apache/PHP पर चलने वाला Drupal 8.5.0 है। यह संस्करण Drupal के आधिकारिक सलाहकार के अनुसार CVE-2018-7600 से प्रभावित सीमा के अंतर्गत आता है। अगला कदम वास्तविक शोषण स्थितियों की जाँच करना है ताकि यह सत्यापित किया जा सके कि लक्ष्य RCE के अधीन किया जा सकता है।

Drupal संस्करण के आधार पर CVE-2018-7600 सत्यापित करें

पिछले फिंगरप्रिंटिंग चरण से, लक्ष्य स्पष्ट रूप से प्रदर्शित करता है: 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 इंस्टॉलर के हमला सतह का आकलन

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 के लिए शोषण की स्थितियाँ

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 पर रीडायरेक्ट होते हैं ⇒ अभी तक संतुष्ट नहीं

Drupal Form API + Render Array इंजन पूरी तरह से बूटस्ट्रैप होना चाहिए

कमज़ोरी Form API की AJAX प्रोसेसिंग पाइपलाइन के भीतर होती है: FormBuilder → RenderArray → #post_render callback निष्पादन। यह पाइपलाइन तभी काम करती है जब Drupal सभी आवश्यक उप-प्रणालियों (रूटिंग, फॉर्म स्थिति, रेंडर इंजन) को बूटस्ट्रैप करता है।