juanschallibaum/cve-2024-38473-nuclei-templateقالب Nuclei للكشف عن خوادم Apache المعرضة لـ CVE-2024-38473
قالب Nuclei مصمم لاكتشاف خوادم Apache المعرضة لـ CVE-2024-38473. يقوم أولاً بتحديد الخوادم التي تشغل Apache < 2.4.60 مع إعدادات PHP-FPM الافتراضية. ثم يقوم بتجريب ملفات PHP محتملة محمية بواسطة قوائم التحكم بالوصول (ACLs) والتي قد يمكن تجاوزها بسبب هذه الثغرة.
لاستخدام قالب 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
تشغيل قالب Nuclei على مضيف واحد مع تحديد ملف .html أو .php صالح:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
قد يؤدي تشغيل Nuclei بهذه الطريقة إلى معدل اكتشاف أعلى. يمكنك أيضًا تضمين عناوين URL بهذا التنسيق داخل ملف المضيفين لتشغيل القالب ضد تلك القائمة.
لاختبار ثغرة CVE-2024-38473 بسهولة، يمكنك إعداد بيئة ضعيفة باستخدام Docker. اتبع هذه الخطوات للتحقق بسرعة من فعالية قالب Nuclei:
تأكد من تشغيل Daemon Docker: تأكد من أن Daemon Docker قيد التشغيل على نظامك. يمكنك تشغيله بالأمر التالي إذا لم يكن قيد التشغيل بالفعل:
sudo systemctl start docker
تشغيل حاوية Docker: داخل دليل المستودع، استخدم أمر Docker التالي لبدء حاوية تحتوي على إعداد Apache و PHP-FPM ضعيف:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
اختبار الثغرة:
يدويًا: افتح متصفح الويب وانتقل إلى http://localhost:8787 للتفاعل مع خادم Apache الذي يعمل داخل حاوية Docker. قم بزيارة 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 بعنوان: هجمات الارتباك: استغلال الغموض الدلالي المخفي في خادم Apache HTTP!. في هذا العرض، أبلغ عن ثغرات متعددة تؤثر على خادم Apache HTTP. أوضح أن Apache له بنية معيارية عالية، تتكون من مئات الوحدات، كل منها يؤدي وظيفته أثناء القراءة والكتابة على بنية مشتركة تسمى request_rec، والتي تتكون من ما يقرب من 100 حقل.
السبب الجذري للثغرات التي أبلغ عنها الباحث الأمني يكمن في عدم الاتساق في كيفية معالجة وحدات Apache المختلفة للحقول المختلفة للبنية المشتركة. على سبيل المثال، تعالج mod_authz_core الحقل r->filename كملف، بينما تعالجه mod_proxy كعنوان URL، مما يؤدي إلى تناقضات ينتج عنها مجموعة واسعة من الثغرات.
في عرضه التقديمي، يعرّف Orange Tsai نوعًا من الهجمات يسمى "Filename Confusion." على الرغم من أن هذا الهجوم له سطح هجوم متنوع، إلا أن CVE-2024-38473، الذي نغطيه في هذا القالب، يشير إلى كيفية تطبيق هجوم "Filename Confusion" لتجاوز قوائم ACL الخاصة بـ Apache والحصول على الوصول إلى الملفات المقيدة.
تنشأ المشكلة عندما تعامل وحدة المصادقة في Apache، mod_authz_core، السمة r->filename كملف، بينما تعاملها mod_proxy كعنوان URL. ونتيجة لذلك، تتأثر تثبيتات Apache التي تستخدم PHP-FPM في تكوينها الافتراضي بهذه الثغرة. تخيل أن خادمًا يشغل Apache و PHP-FPM لديه ACL تم تكوينه مثل التالي لحماية الوصول إلى ملف admin.php ببيانات اعتماد:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
بسبب الثغرة، من الممكن تجاوز قوائم ACL مثل المذكورة أعلاه التي تتضمن حماية ملف فردي. في الواقع، يمكن القيام بذلك بسهولة عن طريق إرسال الطلب التالي: http://server/admin.php%3fooo.php.
لفهم هذا بعمق، من المهم اعتبار أنه عندما يعالج Apache طلبًا مثل المذكور أعلاه، تقرأ وحدة mod_authz_core القيمة admin.php?fooo.php من حقل r->filename للبنية المشتركة. تعامل هذه القيمة كاسم الملف المطلوب، وعند مقارنتها مع 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 الحالي ليس فقط إلى اكتشاف الملفات المحمية عن طريق القوة العمياء (brute force)، ولكنه يتضمن أيضًا منطقًا لتحديد متى يكون الخادم بتكوين ضعيف لـ Apache < 2.4.60 مع PHP-FPM، حتى في حالة عدم اكتشاف حالات الملفات المحمية بواسطة 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 ستحاول تحميل ملف بامتداد .html بدلاً من .php، وهو غير مسموح به افتراضيًا.
يتكون تدفق القالب من 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]
يجب أن يعيد هذا الطلب رمز الحالة 200 إذا كان الخادم لديه قواعد مثل المذكورة أعلاه، أو رمز الحالة 404 في الحالات العادية التي قد تكون فيها PHP-FPM مهيأة. إذا لم يعيد هذا الطلب رمز الحالة 404، سيتوقف القالب عن المعالجة على هذا المضيف.
يرسل القالب طلبًا إلى foo.phpooo.php%3fooo.php وهو ملف غير موجود. الفكرة هي تصفية النتائج الإيجابية الخاطئة في الحالات التي يعيد فيها index.html%3fooo.php رمز الحالة 403، حتى عندما لا تكون PHP-FPM مهيأة. يمكن أن يحدث هذا، على سبيل المثال، عندما تكون هناك قواعد تمنع الحرف %3f في أي مكان في عنوان URL أو تقيد الوصول إلى الملفات المنتهية بـ .php. أمثلة على هذه القواعد تشمل:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
يجب أن يعيد هذا الطلب رمز الحالة 403 إذا كان الخادم لديه قواعد مثل المذكورة أعلاه، أو رمز الحالة 404 في الحالات العادية التي قد تكون فيها PHP-FPM مهيأة. إذا لم يعيد هذا الطلب رمز الحالة 404، سيتوقف القالب عن المعالجة على هذا المضيف.
يرسل القالب طلبات لتحديد بعض الملفات المتاحة على الخادم. أولاً، يحاول تحديد ما إذا كان index.php متاحًا. ثم يتحقق من index.html و index.htm. أخيرًا، يختبر الملف الموجود في عنوان URL المقدم من المستخدم إذا كان موجودًا. إذا تم تشغيل Nuclei مع تحديد ملف صالح في عنوان URL، فيمكن أن يعزز فعالية الكشف في الحالات التي لا توجد فيها ملفات فهرس كلاسيكية.
يرسل القالب طلبًا إلى ملف غير موجود لتصفية آخر النتائج الإيجابية الخاطئة في الحالات التي يعيد فيها index.php%3fooo.php رمز الحالة 200 ونفس نص index.php، حتى عندما لا تكون PHP-FPM مهيأة. بعض خوادم الويب، خاصة تلك التي ليست Apache، تتجاهل كل ما يلي %3f. لذلك، إذا أرسلنا index.php%3fooo.php، فإن الخادم يعامله كـ index.php. لتصفية هذه الحالات، يرسل القالب طلبًا إلى index.php%3fooo.html (إذا تم العثور على index.php على الخادم) أو index.html%3fooo.html (إذا تم العثور على index.html على الخادم). نظرًا لأنه ينتهي بـ .html، في الحالات العادية التي قد تكون فيها PHP-FPM مهيأة، لن تتم معالجته بواسطة PHP-FPM وسيعامل كملف ثابت غير موجود منطقيًا، مما يؤدي إلى رمز الحالة 404. ومع ذلك، سيعيد رمز الحالة 200 في الحالات التي نريد تصفيتها، حيث يتم تجاهل كل ما يلي %3f. إذا لم يعيد هذا الطلب رمز الحالة 404، سيتوقف القالب عن المعالجة على هذا المضيف.
يرسل القالب طلبًا لتحديد التكوين الضعيف. هناك حالتان، يجب تحقيق شرط مطابقة واحد على الأقل منهما:
الحالة الأولى: في الطلب رقم 3، تم العثور على index.php. في هذه الحالة، إذا كان Apache < 2.4.60 و PHP-FPM مفعلة بالتكوين الافتراضي، يجب أن تزيل جزء %3fooo.php وتحمّل index.php، مما يؤدي إلى استجابة 200 بنفس الطول الذي تم الحصول عليه في الطلب رقم 3. إذا تم استخدام mod_php أو معالج آخر، فسيعامل index.php%3fooo.php كاسم ملف كامل ويعيد 404. لكي تتطابق هذه الحالة، يجب أن يعيد الطلب 200 ونص بنفس طول الاستجابة من الطلب رقم 3.
الحالة الثانية: في الطلب رقم 3، تم العثور على index.html. في هذه الحالة، إذا كان Apache < 2.4.60 و PHP-FPM مفعلة بالتكوين الافتراضي، يجب أن تزيل جزء %3fooo.php وتحاول تحميل index.html، والذي سيعيد 403 Access Denied، حيث تحاول PHP-FPM تحميل ملف بامتداد غير مسموح به. إذا تم استخدام mod_php أو معالج آخر، فسيعامل index.php%3fooo.php كاسم ملف كامل ويعيد 404. لكي تتطابق هذه الحالة، يجب أن يعيد الطلب 404.
إذا وصل القالب إلى هذه النقطة، فهذا يشير إلى أن الخادم لديه تكوين ضعيف. وبالتالي، يرسل القالب طلبات لتجريب الملفات المحتملة المحمية التي تعيد رمز الحالة 403 أو تتطلب مصادقة وتعير رمز الحالة 401. افتراضيًا، يحاول فقط تحديد عدد قليل من أسماء الملفات الأكثر شيوعًا والمحتمل حمايتها. ومع ذلك، يمكنك إلغاء تعليق سطر لاستخدام قائمة كلمات مخصصة تحتوي على 350 اسم ملف PHP محتمل.
يرسل القالب طلبًا للتحقق من أن الملف المحمي الذي تم تحديده في الطلب رقم 6 يعيد رمز الحالة 200 مع التجاوز.
إذا تم تحقيق أي شرط مطابقة من الطلب رقم 5، فهذا يشير إلى أن الخادم يشغل Apache < 2.4.60 مع إعدادات PHP-FPM الافتراضية. هذا يعني أنه إذا كان هناك ACL يحمي ملفًا فرديًا، فقد يمكن تجاوزه. ومع ذلك، في كثير من الأحيان يمكن اكتشاف هذه التكوينات الضعيفة دون تحديد أي ملفات محمية. افتراضيًا، يستخدم القالب قائمة الكلمات wordlists/potential_protected_php_files_10.php لتجريب الملفات المحمية. تتضمن هذه القائمة أفضل 10 أسماء ملفات PHP الأكثر احتمالاً لحمايتها بواسطة ACLs. بدلاً من ذلك، تتوفر قائمة كلمات أكبر تحتوي على 350 إدخالًا: wordlists/potential_protected_php_files_350.php. للتبديل إلى القائمة الأكبر، قم بتعليق قائمة الـ 10 إدخالات وإلغاء تعليق قائمة الـ 350 في قسم YAML الخاص بـ الطلب رقم 6 في القالب، كما يلي:
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
يمكن أن يؤدي استخدام قائمة الكلمات الأكبر إلى زيادة فرص العثور على ملفات PHP محمية. ومع ذلك، قد تحتوي قائمة الكلمات potential_protected_php_files_350.txt على أسماء ملفات PHP غير شائعة وقد تفتقر إلى أسماء ملفات PHP الأكثر شيوعًا التي يمكن حمايتها بواسطة ACLs. لذلك، أي تحسينات أو إضافات لقائمة الكلمات مرحب بها. بالإضافة إلى ذلك، يمكن استخدام قوائم كلمات مخصصة أكبر لمزيد من الاستكشاف.
لاحظ أن قوائم ACL القابلة للتجاوز قد تكون مهيأة لمضيفات افتراضية مختلفة، في ملفات .htaccess في أي دليل من التطبيق، وليس فقط الدليل الجذر. لذلك، لتعظيم فرصة تحديد الملفات المحمية بواسطة ACL، يوصى بإجراء استطلاع شامل للأدلة والمجالات الفرعية، وتشغيل القالب ضد جميع عناوين URL المحددة بمجالات فرعية وأدلة مختلفة.
حاليًا، يتوقف تدفق الطلب رقم 6 بعد تحديد أول ملف محمي بواسطة ACL. ومع ذلك، قد يكون هناك المزيد. يحدث هذا لأنني لم أجد طريقة لتجريب ملفات متعددة باستخدام Nuclei، وتخزين النتائج، ثم استخدامها في طلب متابعة للتحقق مما إذا كان التجاوز يمنح بالفعل الوصول إلى الملفات المحمية. لذلك، أي اقتراحات حول كيفية تعديل القالب لتحديد ملفات محمية متعددة والتحقق من أنها بالفعل قابلة للتجاوز مرحب بها أيضًا.
جميع الإسنادات للإبلاغ عن الثغرات وإجراء البحث المتميز تعود إلى Orange Tsai. ساهم عمله المكثف حول ثغرات خادم Apache HTTP، بما في ذلك CVE-2024-38473، بشكل كبير في تعزيز الوعي الأمني. أنا، Juan Schallibaum، مسؤول فقط عن إنشاء قالب Nuclei هذا لتسهيل اختبار واكتشاف CVE-2024-38473.
استخدام قالب Nuclei هذا لمهاجمة أهداف دون موافقة متبادلة مسبقة غير قانوني. من مسؤولية المستخدم النهائي الامتثال لجميع القوانين المحلية والولائية والفيدرالية المعمول بها. لا يتحمل المطورون أي مسؤولية عن أي إساءة استخدام أو ضرر أو عواقب قانونية ناتجة عن استخدام هذا القالب. تأكد دائمًا من حصولك على إذن صريح قبل إجراء أي اختبار أمني.