هل هذا أسوأ اختراق في تاريخ ووردبريس؟
BBetter Stack
Internet TechnologyBusiness NewsComputing/Software
Transcript
00:00:00شهد ووردبريس سلسلة من الثغرات الأمنية مؤخرًا، حيث كانت الأخيرة خطيرة للغاية
00:00:04لدرجة أنها تتيح للمخترقين السيطرة الكاملة على لوحة التحكم، فنحن نتحدث عن حقن SQL وتشغيل
00:00:09أوامر غلاف البرامج، وهو أمر سيئ للغاية. وربما لا تهتم بووردبريس، لكنه يظل مشغلًا لأكثر من 44%
00:00:14من مواقع الإنترنت في العالم، لذا فإن الكثير من المواقع التي تتفاعل معها وتمنحها بياناتك
00:00:19قد تكون تعمل بنظام ووردبريس وبحقن هذه النسخة المصابة بالثغرة. الأمر يعمل أساسًا كالتالي:
00:00:25لديّ نسخة افتراضية قياسية مثبتة محليًا من ووردبريس، ويمكنني تشغيل هذا
00:00:29البرنامج النصي الأول لنرى ما إذا كانت الثغرة موجودة، وكما ترون نحصل على الاستجابة
00:00:34HTTP 207، مما يعني نعم، إنها مصابة بالفعل بالثغرة، وهذا يعني أنه يمكننا الآن تشغيل الفحص الثاني
00:00:41وهو الدخول إلى غلاف الأوامر التفاعلي، والذي يحقن كود SQL في الموقع وينشئ مسؤولاً جديدًا تمامًا
00:00:47ثم يرفع إضافة خبيثة تتيح لي التفاعل مع أي ملف على هذا الموقع
00:00:52لذا فلنتعمق في هذه المشكلة ونرى كيف تعمل بالضبط.
00:00:58هذا المستودع الذي أنظر إليه يوضح لك بالضبط كيفية حقن SQL في مواقع ووردبريس المصابة، أي
00:01:06أي موقع بين الإصدارين 6.90 و 6.94 أو 7.00 و 7.01. يبدأ الهجوم بأكمله باستدعاء نقطة نهاية غير موثقة
00:01:14تسمى batch v1، وتتيح لك تجميع طلبات أخرى يتم التحقق من صحتها وفحص صلاحياتها بنفسها.
00:01:20يحتوي معالج الدفعات على مصفوفتين متوازيتين يُفترض أن تظلا متزامنتين: التحقق والمطابقات،
00:01:26لكن خلتلًا برمجياً تسبب في أنه عند فشل الدالة wp pass URL بسبب مسار غير صالحة، تم تحديث مصفوفة التحقق فقط،
00:01:33لذا أصبح الفهرس نفسه المستخدم للتحقق من كلا المصفوفتين يعطي نتائج غير متطابقة. ويستغل إثبات المفهوم (POC) هذا الأمر،
00:01:41إذ يرسل دفعة تحتوي على طلب واحد فقط، وهو طلب POST إلى نقطة النهاية v2 post، والتي تحمل بنفسها جسم طلب.
00:01:48وبما أنه تم التحقق من صحة الطلب الأب بشكل صحيح كطلب POST، فإن أي طلب داخل جسم الطلب ينتهي به المطاف بتجاوز قائمة طرق HTTP المسموح بها،
00:01:56مما يتيح لك إرسال طلبات GET. ثم داخل تلك الدفعة الداخلية يوجد طلب GET لمنشور غير موجود، مما يحفز
00:02:02عدم التزامن السابق، متسببًا في أن يرسل ووردبريس الطلب نفسه تحت دالة تسمى get items حيث يتم ربط الحقل author
00:02:10exclude بـ author not in، والتي تقوم النسخة المصابة بدمجها في كود SQL كـ نص. وبشكل أساسي، لأن كل هذا يعمل،
00:02:18فإن كود SQL لا يتم معالجته للهروب من الرموز. يستخدم إثبات المفهوم سلسلة من الطلبات التي تتيح في النهاية لطلب POST إلى v2 users إنشاء
00:02:25حساب مسؤول جديد. يتناول المستودع في الواقع كل هذه الخطوات بالتفصيل، فالخطوات الخمس الأولى تكون قبل المصادقة وتستغل الثغرة، لكن الخطوة السادسة مجرد سلوك عادي لووردبريس
00:02:35للمستخدمين الموثقين، وهو رفع حزمة خبيثة. حسناً، كما ذكرنا سابقًا، هذه مجرد النسخة الافتراضية القياسية من ووردبريس، ولا يتم الوصول للثغرة عبر إضافة خبيثة ما،
00:02:46بل يمكنك مجرد تثبيت ووردبريس القياسي. نشغل سكريبت الفحص هذا أولاً، والذي يتحقق أساسًا مما إذا كانت
00:02:52الثغرة قابلة للاستغلال، ثم يمكننا تشغيل أمر القراءة هذا على سبيل المثال، والذي يخبرنا بأشياء مثل
00:02:57مستخدم قاعدة البيانات واسمها. ويمكننا الآن أيضاً تشغيل أوامر SQL ضد الموقع لمعرفة أشياء مثل
00:03:03الإصدار الذي تعمل به قاعدة البيانات حالياً، ولا شيء من هذا يعد الجزء الأسيء؛ هذا هو الجزء السيء
00:03:07حقاً حيث ننشئ بالفعل حساب مسؤول يملك صلاحية الوصول لرفع إضافة خبيثة، وفي هذه
00:03:15الحالة تسمى web shell. هذا يتيح لنا الوصول إلى غلاف الأوامر الخاص بالموقع، مما يعني أنه يمكننا الآن الوصول إلى
00:03:22أي ملف على هذا الموقع، ويحدث هذا الهجوم بالأسلوب الذي شرحناه سابقاً في الفيديو. لذا
00:03:27بعد إنشاء حساب المسؤول، يتم رفع الإضافة، وأخيراً يتم حذف ذلك المستخدم، وبالتالي فإن وجود
00:03:34الإضافة وما حدث يصبح أكثر كتماناً وتخفياً. ولتوضيح مدى سوء هذا الأمر، أنشأت سكريبت آخر منفصلاً
00:03:38ينشئ حساب مسؤول ويُبقيه على النظام.
00:03:40لذا لدي هنا اسم مستخدم وكلمة مرور، وعدت إلى الموقع وحين توجهت إلى المسار wp login، أستطيع إدخال
00:03:47اسم المستخدم وكلمة المرور والنقر على تسجيل الدخول، وأصبح لدي الآن وصول كامل إلى لوحة التحكم. الآن إذا كان أي من هذا مربكاً، فلا تقلق،
00:03:54استغرق مني الأمر وقتاً طويلاً لفهمه أيضاً. الادعاء هو أن سلسلة الاستغلال الناتجة كانت معقدة بشكل
00:04:00سريالي، لدرجة أنها كانت ستستغرق من باحث أمني بشري أسابيع إن لم تكن أشهراً لاكتشافها
00:04:05وتجميع أجزائها. لم يكن بمقدور أي باحث أمني بمفرده العثور على سلسلة الاستغلال هذه وإكمالها
00:04:10في 10 ساعات بدون الذكاء الاصطناعي، وهذا أمر مخيف للغاية، لأن الفاعلين الأشرار يمكنهم فعلياً استخدام روبوتات تمسح
00:04:17المستودعات وتفحص الروابط منتظرة ظهور الثغرات الأمني لتستغلها في وقت قياسي باستخدام الذكاء الاصطناعي.
00:04:23قال أحد المستخدمين على Reddit إن موقعه تعرض للاختراق بعد يومين فقط من اكتشاف الثغرة،
00:04:27وبما أنهم يقومون بالتحديث فقط في عطلات نهاية الأسبوع، تمكن المهاجم من إنشاء مسؤول جديد وتسجيل الدخول بالنسبة لأولئك
00:04:33المصابين بالثغرة. تم إصلاح الثغرة في الإصدار 7.0.2، لذا يمكنك الترقية إليه، لكنها كانت ثغرة جنونية بحق.
00:04:40يمكنكم العثور على المستودع والمقال في التعليقات واللذين استخدمتهما لتشغيل إثبات المفهوم، ولمَ لا
00:04:46تشتركون في Better Stack للبقاء على اطلاع بأحدث الأخبار التقنية. أتمنى أن تكونوا قد استمتعتم بهذا المقطع يا رفاق،
00:04:50وبالطبع وكما هو الحال دائماً، سأراكم في المقطع القادم.