
CVE-2024-38473 के प्रति संवेदनशील Apache सर्वरों का पता लगाने के लिए Nuclei टेम्पलेट

Nuclei टेम्पलेट CVE-2024-38473 के प्रति संवेदनशील Apache सर्वरों का पता लगाने के लिए डिज़ाइन किया गया है। यह पहले Apache < 2.4.60 चलाने वाले सर्वरों को डिफ़ॉल्ट PHP-FPM सेटिंग्स के साथ पहचानता है। फिर, यह ACL द्वारा संरक्षित संभावित PHP फ़ाइलों को फ़ज़ करता है जो इस कमजोरी के कारण बाइपास हो सकती हैं।
इस Nuclei टेम्पलेट का उपयोग करने के लिए, आपको रिपॉजिटरी को क्लोन करना होगा। आप निम्नलिखित कमांड चलाकर ऐसा कर सकते हैं:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
क्लोन की गई रिपॉजिटरी निर्देशिका पर जाएँ:
cd CVE-2024-38473-Nuclei-Template
एकल होस्ट में nuclei टेम्पलेट चलाएँ:
nuclei -t CVE-2024-38473.yaml -u http://example.com
होस्टों की सूची के विरुद्ध nuclei टेम्पलेट चलाएँ:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
एकल होस्ट में एक मान्य .html या .php फ़ाइल निर्दिष्ट करते हुए nuclei टेम्पलेट चलाएँ:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
इस तरह Nuclei चलाने से उच्च पहचान दर मिल सकती है। आप होस्ट फ़ाइल में इस प्रारूप में URLs भी शामिल कर सकते हैं ताकि उस सूची के विरुद्ध टेम्पलेट चलाया जा सके।
CVE-2024-38473 कमजोरी का आसानी से परीक्षण करने के लिए, आप Docker का उपयोग करके एक कमजोर वातावरण सेट कर सकते हैं। Nuclei टेम्पलेट की प्रभावशीलता को शीघ्रता से सत्यापित करने के लिए इन चरणों का पालन करें:
सुनिश्चित करें कि Docker Daemon चल रहा है: सुनिश्चित करें कि आपके सिस्टम पर Docker daemon चल रहा है। यदि यह पहले से नहीं चल रहा है तो आप इसे निम्नलिखित कमांड से शुरू कर सकते हैं:
sudo systemctl start docker
Docker कंटेनर चलाएँ: रिपॉजिटरी निर्देशिका के अंदर, एक कमजोर Apache और PHP-FPM सेटअप के साथ कंटेनर शुरू करने के लिए निम्नलिखित Docker कमांड का उपयोग करें:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
कमजोरी का परीक्षण करें:
मैन्युअल रूप से: अपना वेब ब्राउज़र खोलें और Docker कंटेनर में चल रहे Apache सर्वर से इंटरैक्ट करने के लिए http://localhost:8787 पर जाएँ। कमजोरी का परीक्षण करने के लिए http://localhost:8787/info.php तक पहुँचें। यह फ़ाइल ACL द्वारा संरक्षित है, और यदि ACL बाइपास सफल होता है, तो आप phpinfo() का आउटपुट देखेंगे:

Nuclei टेम्पलेट का उपयोग करके: सर्वर का टेम्पलेट से परीक्षण करने के लिए निम्नलिखित Nuclei कमांड चलाएँ:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
8 अगस्त 2024 को, सुरक्षा शोधकर्ता Orange Tsai ने Black Hat USA 2024 में एक प्रस्तुति दी जिसका शीर्षक था: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!। इस प्रस्तुति में, उन्होंने Apache HTTP Server को प्रभावित करने वाली कई कमजोरियों की सूचना दी। उन्होंने समझाया कि Apache में एक अत्यधिक मॉड्यूलर आर्किटेक्चर है, जो सैकड़ों मॉड्यूल से बना है, प्रत्येक अपना कार्य करता है और request_rec नामक एक साझा संरचना को पढ़ता और लिखता है, जिसमें लगभग 100 फ़ील्ड होते हैं।
सुरक्षा शोधकर्ता द्वारा रिपोर्ट की गई कमजोरियों का मूल कारण इस असंगति में निहित है कि विभिन्न Apache मॉड्यूल साझा संरचना के विभिन्न फ़ील्ड को कैसे संभालते हैं। उदाहरण के लिए, mod_authz_core फ़ील्ड r->filename को एक फ़ाइल के रूप में मानता है, जबकि mod_proxy इसे URL के रूप में मानता है, जिससे विसंगतियाँ उत्पन्न होती हैं जिनके परिणामस्वरूप कई प्रकार की कमजोरियाँ होती हैं।
अपनी प्रस्तुति में, Orange Tsai ने "Filename Confusion" नामक एक प्रकार के हमले को परिभाषित किया है। हालांकि इस हमले का एक विविध हमला सतह है, CVE-2024-38473, जिसे हम इस टेम्पलेट में कवर करते हैं, यह संदर्भित करता है कि हम Apache ACLs को बाइपास करने और प्रतिबंधित फ़ाइलों तक पहुँच प्राप्त करने के लिए "Filename Confusion" हमले को कैसे लागू कर सकते हैं।
समस्या तब उत्पन्न होती है जब Apache का प्रमाणीकरण मॉड्यूल, mod_authz_core, r->filename विशेषता को एक फ़ाइल के रूप में मानता है, जबकि mod_proxy इसे URL के रूप में मानता है। इसके कारण, डिफ़ॉल्ट कॉन्फ़िगरेशन में PHP-FPM वाली Apache स्थापनाएँ इस कमजोरी से प्रभावित होती हैं। कल्पना करें कि Apache और PHP-FPM चलाने वाले एक सर्वर में admin.php फ़ाइल तक पहुँच को क्रेडेंशियल्स के साथ सुरक्षित करने के लिए इस प्रकार ACL कॉन्फ़िगर किया गया है:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
कमजोरी के कारण, एक व्यक्तिगत फ़ाइल की सुरक्षा करने वाले उपरोक्त जैसे ACLs को बाइपास करना संभव है। वास्तव में, यह निम्नलिखित अनुरोध भेजने जितना आसान है: http://server/admin.php%3fooo.php।
इसे गहराई से समझने के लिए, यह विचार करना महत्वपूर्ण है कि जब Apache उपरोक्त जैसे अनुरोध को संसाधित करता है, तो mod_authz_core मॉड्यूल साझा संरचना के r->filename फ़ील्ड से admin.php?fooo.php मान पढ़ता है। यह इस मान को अनुरोधित फ़ाइल का नाम मानता है, और जब यह इसकी तुलना ACL से करता है, तो यह मेल नहीं खाता क्योंकि admin.php?fooo.php, admin.php से अलग है।
फिर, चूँकि admin.php?fooo.php .php में समाप्त होता है, अनुरोध PHP-FPM द्वारा संभाला जाता है। PHP-FPM Apache से प्राप्त फ़ाइलनाम में ? के बाद आने वाली हर चीज़ को हटा देता है, इसे फ़ाइल के बजाय URL मानकर। परिणामस्वरूप, PHP-FPM सीधे admin.php को प्रोसेस करेगा। चूँकि ACL जाँच पहले पारित हो चुकी थी, हमलावर प्रमाणीकरण के बिना admin.php तक पहुँच सकता है।
वर्तमान Nuclei टेम्पलेट का उद्देश्य न केवल ब्रूट फोर्स द्वारा संरक्षित फ़ाइलों की खोज करना है, बल्कि इसमें यह पहचानने की तर्कशक्ति भी शामिल है कि कब किसी सर्वर में PHP-FPM के साथ कमजोर Apache < 2.4.60 कॉन्फ़िगरेशन है, भले ही ACLs द्वारा संरक्षित फ़ाइलों के मामलों का पता न लगा हो। मूल प्रवाह में, यह पहले यह पहचानने की कोशिश करता है कि सर्वर में कमजोर कॉन्फ़िगरेशन है या नहीं, और फिर, यदि सकारात्मक है, तो यह सामान्य फ़ाइलों की पहचान करने का प्रयास करता है जो ACLs द्वारा संरक्षित हो सकती हैं।
Apache < 2.4.60 और PHP-FPM के साथ कमजोर कॉन्फ़िगरेशन का पता लगाने के पीछे का विचार दो बुनियादी आधारों पर आधारित है:
एक कमजोर कॉन्फ़िगरेशन में, यदि सर्वर पर file.php मौजूद है, तो http://server/file.php%3fooo.php का अनुरोध उसी 200 स्थिति कोड और उसी बॉडी लंबाई के साथ वापस आएगा जैसा कि http://server/file.php के अनुरोध में है (क्योंकि PHP-FPM द्वारा %3fooo.php को हटाने के बाद, अनुरोधित फ़ाइल समान होगी)।
एक कमजोर कॉन्फ़िगरेशन में, यदि सर्वर पर file.html मौजूद है, तो http://server/file.html%3fooo.php का अनुरोध 403 Access Denied लौटाएगा। ऐसा इसलिए है क्योंकि PHP-FPM .php के बजाय .html एक्सटेंशन वाली फ़ाइल लोड करने का प्रयास करेगा, जो डिफ़ॉल्ट रूप से अनुमत नहीं है।
टेम्पलेट प्रवाह में अनुरोधों के 7 समूह होते हैं। उन्हें क्रम में निष्पादित करने की आवश्यकता होती है और अनुरोधों के अगले समूह में आगे बढ़ने के लिए उन्हें संबंधित मिलान शर्तों को पूरा करना होता है। इससे उन अनुरोधों की संख्या को कम करने में मदद मिलती है जो व्यर्थ भेजे जाते हैं जब शर्तें पहले से ही असंतुष्ट मानी जाती हैं।
टेम्पलेट एक गैर-मौजूद फ़ाइल index.phpooo.php%3fooo.php के लिए एक अनुरोध भेजता है। विचार उन मामलों में झूठी सकारात्मकता को फ़िल्टर करना है जहाँ index.php%3fooo.php 200 स्थिति कोड और index.php के समान बॉडी लौटाता है, भले ही PHP-FPM कॉन्फ़िगर न किया गया हो। यह तब हो सकता है, उदाहरण के लिए, जब ऐसे नियम हों जो किसी भी अनुरोधित फ़ाइल या "index" से शुरू होने वाली फ़ाइलों को index.php में पुनर्लेखित करते हैं, जैसे:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]