CVE-2023-43804: مختبر إعادة إنتاج وتسريب ملفات تعريف الارتباط في urllib3 والمعالجة

يتضمن المستودع بيئة مختبرية كاملة من ثلاث طبقات ومعبأة بالكامل في حاويات، وهي مخصصة لعرض واستغلال والتحقق من الإصلاحات الخاصة بـ CVE-2023-43804 (تسريب ملفات تعريف الارتباط في urllib3 الذي يحدث أثناء عمليات إعادة التوجيه عبر الأصول المختلفة).

1. بيئة المختبر والبنية المعمارية

يتم تنسيق المختبر باستخدام Docker Compose ويتكون من ثلاث خدمات معزولة تتواصل عبر شبكة جسر داخلية:

• victim_client: حاوية مبنية على Python تنفذ سكريبت إعادة الإنتاج والاستغلال (exploit.py).
• target_app: تطبيق ويب مبني على Flask يحاكي خادم هدف مصاب بثغرة، مما يؤدي إلى إعادة توجيه HTTP 302 عبر الأصول المختلفة إلى أصل خارجي.
• attacker_app: خادم تسجيل مبني على Flask مصمم لالتقاط طلبات HTTP الواردة واستخراج الترويسات المسربة.

2. المتطلبات الأساسية ومتطلبات النظام

• Docker Desktop مثبت ويعمل.
• Docker Compose (الإصدار 2+).
• PowerShell أو أي واجهة سطر أوامر قياسية.

3. خطوات التثبيت والإعداد

1. استنسخ المستودع وانتقل إلى دليل المشروع:
   root@kitploit:~

   git clone [https://github.com/deepanshu-khurana/cve-2023-43804-lab.git](https://github.com/deepanshu-khurana/cve-2023-43804-lab.git)
   cd cve-2023-43804-lab
   
   
   
   

2. قم ببناء وتشغيل البنية التحتية للمختبر المعبأ في حاويات:

docker compose up -d --build

4. كيفية بدء وإيقاف المختبر

• بدء حاويات المختبر:

docker compose up -d

• إيقاف المختبر وتنظيف الموارد:

docker compose down --volumes

5. نظرة عامة على الثغرة (CVE-2023-43804)

• المكوّن المصاب: urllib3
• الإصدارات المصابة: < 1.26.17 أو < 2.0.5
• وصف الثغرة: فشل urllib3 في إزالة ترويسات المصادقة الحساسة (مثل Cookie) عند اتباع عمليات إعادة توجيه HTTP 302 عبر أصول مختلفة، مما سمح لنقاط إعادة التوجيه غير الموثوقة باعتراض رموز الجلسات الحساسة.

6. كيفية استغلال الثغرة (المرحلة 1)

1. تأكد من تثبيت الإصدار المصاب من urllib3 داخل حاوية العميل:

docker exec -it victim_client pip install urllib3==1.26.16

2. نفّذ سكريبت الاستغلال:

docker exec -it victim_client python3 -u /lab/exploit.py

3. النتيجة المتوقعة في الحالة المصابة:

• يعرض مخرجات العميل "status": "EXFILTRATED" إلى جانب رمز الجلسة المسرب.
• يعرض docker logs attacker_app ترويسة ملف تعريف الارتباط الحساسة التي تم التقاطها.

7. كيفية تشغيل آلية الكشف والتحقق (المرحلة 2)

للتحقق من التصحيح بعد ملاحظة الاستغلال:

1. قم بترقية urllib3 داخل حاوية العميل إلى الإصدار المصحح:

docker exec -it victim_client pip install urllib3==1.26.17

2. أعد تشغيل سكريبت الاستغلال:

docker exec -it victim_client python3 -u /lab/exploit.py

3. النتيجة المتوقعة في الحالة المصححة:

• يعرض مخرجات العميل "status": "SECURE", "stolen_cookie": "None / Stripped".
• تؤكد سجلات attacker_app أن الطلب الوارد يحتوي على Leaked Cookie Header: None.

8. المعالجة

• ترقية المكتبة: قم بتحديث التبعيات في requirements.txt لفرض الإصدارات الآمنة:

urllib3>=1.26.17

• الدفاع متعدد الطبقات: قم بتهيئة سياسات إدارة الترويسات بشكل صريح عبر remove_headers_on_redirect في تهيئات Retry المخصصة إذا كنت تحتفظ ببيئات تشغيل قديمة.

9. ملاحظات استكشاف الأخطاء وإصلاحها

• تسمية الحاويات: تأكد من استهداف أسماء الحاويات بدقة (victim_client، target_app، attacker_app) كما تم تعيينها بواسطة Docker Compose. استخدم docker ps للتحقق من أسماء الحاويات النشطة.
• توفر المنافذ: تأكد من أن المنافذ 5000 و 5001 غير مشغولة بخدمات محلية أخرى قبل تشغيل حزمة Docker.

10. عرض المختبر والنتائج

المرحلة 1: الحالة المصابة (تسريب ملفات تعريف الارتباط)

عند تشغيل المختبر على الإصدار المصاب urllib3==1.26.16، يتم اعتراض ملف تعريف الارتباط الحساس للمصادقة عبر عمليات إعادة التوجيه بين الأصول المختلفة ويتم تسجيله بنجاح بواسطة خادم المهاجم.

• مخرجات العميل والتقاط سجلات الخادم:
  • الشكل 1.1: يعرض exploit.py الحالة "status": "EXFILTRATED" إلى جانب رمز الجلسة المسرب، مؤكداً بمخرجات سجل attacker_app.

المرحلة 2: التحقق من التصحيح (الحالة الآمنة)

بعد ترقية urllib3 إلى الإصدار المصحح (1.26.17)، تقوم المكتبة تلقائياً بإزالة ترويسة Cookie الحساسة أثناء عمليات إعادة التوجيه بين الأصول المختلفة.

• ترقية الحزمة إلى الإصدار المصحح:

  • الشكل 2.1: ترقية urllib3 داخل victim_client عبر pip install urllib3==1.26.17.

• مخرجات العميل الآمنة والسجلات المُزالة:

  • الشكل 2.2: يعيد exploit.py الحالة "status": "SECURE" مع "stolen_cookie": "None / Stripped"، مؤكداً بسجل الخادم الذي يعرض Leaked Cookie Header: None.