nickstadb/pocمستودع لاستغلالات وأدوات إثبات المفهوم.
مستودع لاستغلالات وأدوات إثبات المفهوم.
استغلال تنفيذ أوامر عن بُعد بدون مصادقة لوكيل RSCD التابع لـ BMC Server Automation. يعمل الاستغلال ضد الخوادم المتأثرة بـ CVE-2016-1542 (التي يكتشفها Nessus).
هذا أصبح الآن وحدة Metasploit، انظر exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
تم إنشاء هذا الاستغلال عبر جعل Nessus يفحص سكربت Python يسجّل الحزم ويعيد إرسالها/بيانات عشوائية إلى Nessus. بعد التقاط الحزم، كان من السهل "عكس" تنسيق البيانات لإنشاء استغلال شبه عامل. لاحقًا حصلت على إمكانية الوصول إلى برنامج الوكيل المتأثر وتمكنت من استخدام مصحح أخطاء وبعض التلغيم لإصلاح العيوب وتحويل هذا إلى استغلال RCE متين.
اطّلع على منشورات مدونتي حول كيفية بناء هذا الاستغلال لمزيد من التفاصيل:
استغلال تنفيذ أكواد عن بُعد بدون مصادقة لإصدارات HP Device Manager من 5.0.0 إلى 5.0.3 (CVE-2020-6926, CVE-2020-6927).
يستغل هذا الاستغلال خدمة Java RMI بدون مصادقة تحتوي على ثغرة حقن في Hibernate Query Language. يُستخدم حقن ORM لتهريب حمولة حقن SQL في Postgres لاستبدال ملف pg_hba.conf على خادم HP Device Manager، مما يتيح الوصول عن بُعد إلى قاعدة بيانات Postgres المرفقة مع HPDM. بمجرد التفعيل، يُستخدم حساب مستخدم خارق كباب خلفي للمصادقة على قاعدة بيانات Postgres وتنفيذ أوامر نظام تشغيل عشوائية.
اطّلع على منشور مدونتي حول كيفية اكتشاف هذه الثغرات لمزيد من التفاصيل:
في حين أن هذا الاستغلال يعمل فقط ضد HPDM 5.x، فإن خدمة Java RMI بدون مصادقة موجودة في جميع إصدارات HPDM قبل 5.0.4 و4.7 service pack 13. قد يكون تأثير استغلال هذه الخدمة أقل، لكن لا تزال هناك ثغرة HQLi/SQLi، بالإضافة إلى إمكانية استخراج الإعدادات (ربما بما في ذلك كلمات مرور خدمات أخرى)، وجميع أسماء مستخدمي حسابات HPDM وتجزئات كلمات المرور MD5 المقابلة لها.
استغلال تنفيذ أكواد عن بُعد بدون مصادقة لنقاط نهاية خدمة JNBridge Java المُهيأة بشكل غير آمن. استنادًا إلى عمل Moritz Bechler (CVE-2019-7839).
بروتوكول الشبكة الذي تنفذه JNBridge مُصمم حصريًا لتسهيل تنفيذ الأكواد عن بُعد لتحقيق التشغيل البيني بين تطبيقات Java و.NET. وبالتالي، هذا ليس استغلالًا من الناحية الفنية، بل مجرد سكربت Python صغير ومفيد لتنفيذ أوامر عشوائية ضد نقطة نهاية JNBridge Java.
اطّلع على منشور مدونتي للحصول على شرح تفصيلي لرحلتي من النشرة الأمنية إلى إنتاج استغلال كامل:
يستهدف هذا الاستغلال وظيفة التحديث التلقائي غير الآمنة في WordPress لإسقاط قشرة PHP على الخادم الأساسي. تم اختبار الاستغلال بنجاح حتى WordPress 4.9.8، وهو أحدث إصدار في تاريخ النشر.
عندما يتحقق WordPress من التحديثات، يحاول إنشاء اتصال HTTPS آمن بـ api.wordpress.org. إذا فشل هذا الاتصال، على سبيل المثال بسبب تقديم شهادة غير موثوقة، فإن WordPress يتراجع إلى استخدام اتصال HTTP غير آمن.
المشكلة الثانية هي أن WordPress يثق في تحديثات الترجمات. فهو لا يحدّث تلقائيًا الإضافات أو القوالب أو إصدارات النواة الرئيسية، على الأرجح بسبب مخاطر تثبيت أكواد جديدة على الخادم. لكنه مع ذلك يحدّث الترجمات تلقائيًا. لسوء الحظ، يفشل WordPress في التحقق بشكل صحيح من أرشيفات الترجمات، لذا طالما أن ملف ZIP الخاص بالترجمة يحتوي على ملف واحد على الأقل بامتداد .po وملف واحد بامتداد .mo، فإن WordPress سيستخرج المحتويات إلى الخادم الأساسي (بما في ذلك القشرة المُدرجة هناك بواسطة الرجل في المنتصف).
اكتشفت هذه المشكلات بالصدفة، لكن عندما أبلغت عنها (نوفمبر 2017) قال فريق WordPress أساسًا WONTFIX بسبب التوافقية مع الإصدارات السابقة. إذا كان شخص ما يشغّل WordPress على خادم لا يمكنه إنشاء اتصال SSL/TLS صادر، فيجب أن يظل قادرًا على تحديث WordPress تلقائيًا لأسباب أمنية، كما يقولون.
¯\_(ツ)_/¯
اطّلع على منشور مدونتي لمزيد من التفاصيل:
بعض مقتطفات JS لاستخدامها في استغلال ثغرات XSS في WordPress.
