hackedrishi/ctf_writeups-tryhackme-cve-2021-41773-CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
CTF_WRITEUPS/TryHackMe /CVE-2021-41773/
تاريخ مختصر
في الخامس من أكتوبر 2021، تم نشر ثغرة (CVE) تفصّل هجوم تجاوز المسار على خادم Apache HTTP Server الإصدار v2.4.49. حُملت الرقم CVE-2021-41773، ونُشرت بالوصف التالي:
تم العثور على خلل في تغيير تم إجراؤه على تسوية المسار (path normalization) في Apache HTTP Server 2.4.49. يمكن للمهاجم استخدام هجوم تجاوز المسار لربط عناوين URL بملفات خارج جذر المستندات المتوقع. إذا كانت الملفات خارج جذر المستندات غير محمية بواسطة "require all denied"، يمكن لهذه الطلبات أن تنجح. بالإضافة إلى ذلك (كما ورد)، يمكن لهذا الخلل تسريب مصدر الملفات المفسّرة مثل نصوص CGI. من المعروف أن هذه المشكلة استُغلت في البرية. تؤثر هذه المشكلة فقط على Apache 2.4.49 وليس الإصدارات الأقدم.
دعنا نقسّم هذا لنرى ما يعنيه ذلك فعليًا بالنسبة لنا:
الكثير من الإصلاحات لاحقًا...
بالتالي، أصلحت Apache هذا الخلل وأصدرت الإصدار v2.4.50. نهاية القصة، أليس كذلك؟ حسنًا، ليس تمامًا. بعد يومين فقط، في السابع من أكتوبر، تم نشر ثغرة CVE جديدة تستند إلى السابقة. تذكر هذه الثغرة أن إصلاح هجوم تجاوز المسار السابق كان غير مكتمل، وأنه لا يزال بإمكاننا تجاوز المسار إذا كان المسار المعني يستخدم توجيه alias لربط عناوين URL بنظام الملفات. حُملت الثغرة الرقم CVE-2021-42013، بالوصف التالي:
تبين أن إصلاح CVE-2021-41773 في Apache HTTP Server 2.4.50 كان غير كافٍ. يمكن للمهاجم استخدام هجوم تجاوز المسار لربط عناوين URL بملفات خارج الدلائل التي تم تكوينها بواسطة توجيهات شبيهة بـ Alias. إذا كانت الملفات خارج هذه الدلائل غير محمية بالتكوين الافتراضي المعتاد "require all denied"، يمكن لهذه الطلبات أن تنجح. إذا تم أيضًا تمكين نصوص CGI لهذه المسارات المستعارة (كما ورد)، فقد يسمح ذلك بتنفيذ التعليمات البرمجية عن بُعد. تؤثر هذه المشكلة فقط على Apache 2.4.49 وApache 2.4.50 وليس الإصدارات الأقدم.
كما في السابق، يمكننا تعلم بعض الأشياء هنا:
بينما نستوعب هذا الجنون، سننظر في التكوين المطلوب في المهمة التالية.
أجب عن الأسئلة أدناه
القليل من النظرية
استغلال تجاوز المسار (Path Traversal) هو هجوم يهدف إلى الوصول إلى موارد يتعذر الوصول إليها عادةً عبر إساءة استغلال العيوب في تحليل المسار و/أو تسويته. عادةً ما نستغل هذا النوع من الهجمات بالانتقال (المعروف أيضًا بالتجاوز) إلى الخلف إلى ما وراء الجذر المفترض باستخدام صيغة ...
التسوية؟ ماذا؟
عادةً، عند توفير مسار لبعض التعليمات البرمجية للعثور على ملف، يكون المسار المطلق ضروريًا. دعنا نسمي هذا المسار القانوني (canonical path). عندما يتم إعطاء مسار نسبي بدلاً من ذلك، يجب تسويته إلى صيغة قانونية حتى تتمكن مكتبات نظام التشغيل التي تستخدم هذا المسار من العثور على المورد المعني. هذا تبسيط مفرط، بالطبع، لكن الجوهر يبقى.
بشكل عام، توجد مكتبات منصة تقوم بهذه التسوية نيابةً عنا، لكن في C/C++ عادةً ما يتعين علينا فعل كل شيء بأنفسنا. في حين أن هذا يمكن أن يوفر بعض المرونة، فإنه يمكن أيضًا أن يُدخل عيوبًا بسهولة إذا لم يكن تنفيذنا مثاليًا.
تسوية عناوين URL
يجب على خادم HTTP ترجمة عنوان URL إلى مسار قانوني على نظام الملفات للعثور على الملف الصحيح لتقديمه. بينما توجد بالتأكيد بعض عوامل التصفية لتجنب القدرة على تجاوز جذر المستندات، قد يتم تفويت بعض حالات الاستخدام بسهولة. في هذه الحالة، يستغل الهجوم ليس فقط ترميز URL (سنصل إليه بعد قليل) ولكن أيضًا خللًا في تسوية المسار لوحدة Alias (كما يُزعم)
استطراد حول ترميز URL
المعرف في RFC 3986 القسم 2، ترميز URL هو مخطط يُستخدم لتشفير الأحرف الخاصة أو المحجوزة داخل عنوان URL. على سبيل المثال، يتم ترميز المسافات في عنوان URL كحرف + (خاصة في معاملات الاستعلام). إذا أردنا ترميز علامة زائد فعلية، فيجب علينا ترميزها باستخدام ما يُعرف بـ "الترميز المئوي" (percent-encoding). يتضمن ذلك ببساطة إضافة رمز % إلى الكود السداسي العشري US-ASCII الخاص بالحرف. في مثالنا، يمكن ترميز الرمز + كـ %2B.
يمكن ترميز أي حرف بتشفير URL، وعناوين URL المرمزة بالكامل مكافئة وظيفيًا للنسخة غير المرمزة. من RFC: إذا اختلف عنوانا URI فقط في حالة الأحرف السداسية العشرية المستخدمة في الثمانيات المرمزة بالمئة، فإنهما متكافئان.
إذًا ماذا حدث مع Apache؟
تغيير حديث في وحدة تسوية المسار في خادم Apache سمح لعنوان URL مُصمم خصيصًا بتجاوز عوامل التصفية والتجاوز إلى ما وراء جذر المستندات، مما سمح بقراءة ملفات عشوائية على النظام إذا كان التكوين يسمح بذلك. علاوةً على ذلك، إذا تم تمكين وحدة CGI، فمن الممكن أيضًا تنفيذ ملفات عشوائيًا!
أجب عن الأسئلة أدناه
A) Include arbitrary remote files to be processed on the server. B) Include arbitrary local files to be processed on the server. C) Allow arbitrary files to be exposed by the server. D) None of the above.
اختراق Apache للمتعة
إذًا والآن بعد أن انتهت النظرية، دعنا ننتقل إلى استغلال هذه الثغرة. أولاً، نحتاج إلى إصدار ضعيف من Apache. لحسن الحظ لدينا docker لهذا الغرض :)```
user@machine$ docker pull httpd:2.4.49
2.4.49: Pulling from library/httpd
07aded7c29c6: Already exists
05bb40c8f148: Already exists
0827b74117da: Already exists
35a526fdcc7d: Pull complete
59fed288cd32: Pull complete
Digest: sha256:dcba0d12e2362fb0c50ec524ae8aa1cca4a4ba7216617a57e7bbca20767e79cc
Status: Downloaded newer image for httpd:2.4.49
docker.io/library/httpd:2.4.49
**التهيئة**
لكي يعمل هذا الاستغلال، نحتاج إلى تهيئة Apache للسماح بالوصول إلى الملفات خارج جذر المستندات. يمكننا أن نكون دقيقين ونحدد دليلاً معيناً، أو يمكننا اتباع نهج YOLO ومنح الوصول إلى كل شيء. لأغراضنا، الوصول إلى كل شيء سيكون مناسباً تماماً. للبدء، لنشغّل الحاوية ونفحص التهيئة. لاحظ أن هذه التعديلات تعمل مع كلا الإصدارين المعرّضين للخطر من Apache.```
user@machine$ docker run --name vuln-httpd -p 8080:80 -d httpd:2.4.49
a4dfc0376d93dc62183982a527b0bef62543e7a91178116bb0480a42ecc0c8dd
user@machine$ docker cp vuln-httpd:/usr/local/apache2/conf/httpd.conf .
user@machine$ grep -C4 -n "Require all denied" httpd.conf
246-# <Directory> blocks below.
247-#
248-<Directory />
249- AllowOverride none
250: Require all denied
251-</Directory>
252-
253-#
254-# Note that from this point forward you must specifically allow
--
303-# The following lines prevent .htaccess and .htpasswd files from being
304-# viewed by Web clients.
305-#
306-<Files ".ht*">
307: Require all denied
308-</Files>
309-
310-#
311-# ErrorLog: The location of the error log file.
user@machine$ sed "250s/denied/granted/" httpd.conf > httpd.new.conf
user@machine$ docker cp http.new.conf vuln-httpd:/usr/local/apache2/conf/httpd.conf
user@machine docker container restart vuln-httpd
vuln-httpd