iTop-CVEs-exploit

يحتوي هذا المستودع على استغلالات لثغرات iTOP CVE-2024-52002 و52000 و31998 و31448 التي تتضمن سلسلة هجمات CSRF+XSS للحصول على صلاحيات إدارية على البرنامج.

الإعداد

1. قم بتنزيل نسخة iTOP الضعيفة من docker

sudo docker run -d -p 8090:80 --name=my-itop2 vbkunin/itop:3.1.1 

2. انتقل إلى localhost:8090 وقم بالتثبيت القياسي
3. استخدم الأمر أدناه للحصول على كلمة المرور

sudo docker logs my-itop2 | grep -A7 -B1 "Your MySQL user 'admin' has password"

يجب أن يبدو شيئًا مثل هذا

4. الآن تابع خطوات التثبيت القياسية
5. سيؤدي هذا إلى إنهاء مرحلة الإعداد والآن يمكنك الدخول إلى iTOP

الاستغلال

لا تتردد في استكشاف برنامج iTOP.

كالمهاجم، أكثر شيء قيّم هو الوصول إلى البرنامج عن بُعد عبر تسجيل دخول المسؤول الموجود على http://localhost:8090/pages/UI.php?c%5Bmenu%5D=UserAccountsMenu

XSS

لنبدأ باختبار استغلال XSS، يمكنك استخدام xss.csv في مستودع github هذا لاختبار ذلك.

1. انتقل إلى http://localhost:8090/pages/csvimport.php?c%5Bmenu%5D=CSVImport
2. انقر على Select a File وارفع ملف xss.csv
3. تابع مع الخيارات القياسية حتى الخطوة 3
4. في الخطوة 3 حدد الخيار Person كنوع الاستيراد
5. بالنقر على Simulate the import يمكننا رؤية XSS
6. هذا يثبت وجود XSS.
7. هذا وحده ليس له قيمة كبيرة، وسنعود إلى هذا.

CSRF

دعنا نستكشف CSRF حيث تخبرنا صفحات CVE بوجود CSRF على صفحات متعددة. كل من CSRF وXSS منفردين لا يعطياننا الكثير، لكن معًا يمكننا فعل شيء لإنشاء حساب إداري في النهاية.

1. لنقم باختبار بسيط، بالنظر إلى burpsuite لجميع المعاملات، سننشئ ملف html اختباري بسيط ونستضيفه على خادم python. (first_step_import_data.html) python3 -m http.server 9001
2. يستغل هذا الملف CSRF وXSS من الأعلى لعرض رمز CSRF المطلوب لإكمال مهمة الاستيراد في تنبيه لنا.
3. اكتشفنا أن هذا الرمز غير مرتبط بأي إجراء، لذلك عندما نستلم هذا الرمز، يمكننا جعل المستخدم يكمل عملية أخرى عن طريق الحصول على الرمز من صفحة XSS الضعيفة.
4. عندما تستضيف ملف html أعلاه وتنقر عليه كمستخدم مسجل دخول، سترى أن الرمز يُعرض في تنبيه في المتصفح.
5. سنقوم الآن بتعديل هذا الاستغلال لاستدعاء خادمنا بالرمز الذي سيتم ربطه بعد ذلك بالجزء الآخر من الاستغلال حيث سيُستخدم لإنشاء مستخدم. first_step_add_user.html و last_step_add_user.html

يمكننا أن نرى أنه عندما ينقر المستخدم على الرابط first_step_add_user.html فإنه يستخدم أولاً CSRF+XSS للحصول على رمز الإجراء ثم يستخدم ذلك لإنشاء المستخدم عن طريق الربط. في الأساس يصبح CSRF+XSS+CSRF

يمكن إرسال الرابط الضعيف إلى المستخدم باستخدام نموذج بريد إلكتروني للتصيد الاحتيالي مضاف في مستودع github.

المراجع

• https://nvd.nist.gov/vuln/detail/cve-2024-52002
• https://nvd.nist.gov/vuln/detail/cve-2024-52000
• https://nvd.nist.gov/vuln/detail/CVE-2024-31998
• https://nvd.nist.gov/vuln/detail/CVE-2024-31448
• https://owasp.org/www-community/HttpOnly
• https://bugbase.ai/blog/how-to-bypass-csrf-protection
• https://medium.com/sessionstack-blog/how-javascript-works-5-types-of-xss-attacks-tips-on-preventing-them-e6e28327748a
• https://www.sitepoint.com/get-url-parameters-with-javascript/
• https://portswigger.net/web-security/csrf#how-to-construct-a-csrf-attack
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS