شكك في الثغرة فوضع 500 دولار من البيتكوين طُعماً، ثم أثبت بنفسه أن PHP2Shell قابلة للاستغلال فعلاً

قبل بضعة أسابيع، دفعت ثغرتان حرجتان في PHP نسبة ملحوظة من المواقع إلى التوقف عن العمل لإجراء التحديثات. وفور الإعلان، ظهر «خبراء» قالوا إن الأمر ليس بهذا السوء وإن استغلال الثغرتين في العالم الحقيقي يكاد يكون مستحيلاً. وكانت حجتهم الرئيسية أن أحداً لم ينشر استغلالاً يعمل فعلياً. فقرر أحد المشككين اختبار ذلك عملياً.

طُعم بقيمة 500 دولار

أنشأ صاحب التجربة موقعاً ووضع فيه المفتاح السري لمحفظة بيتكوين تحوي 500 دولار، ثم نشر الرابط على Hacker News قائلاً: اخترقوه وخذوا المال. خلال الساعات الأولى لم ينجح أحد، ورأى المعلقون في ذلك، بطبيعة الحال، تأكيداً على صحة موقفهم.

لكن الأسباب كانت عادية للغاية. أولاً، تدفقت حركة مرور كثيفة إلى الموقع، فأخذ يتعطل وظلت طلبات كثيرة بلا استجابة. وثانياً، لم يكن الموقع نفسه عرضة للثغرة. كانت PHP مثبتة عليه، بل وكانت تقدم الصفحة الرئيسية، لكن الإعدادات لم تطابق البيئة التي تؤثر فيها الثغرة.

أضاف صاحب التجربة مزيداً من الموارد إلى الخادم وأعاد كتابة الشيفرة، التي كانت مفرطة في البساطة ولا تشبه المواقع المعتادة. بعد ذلك نجحت الثغرة وحصل مخترق على المفتاح. صحيح أن صاحب التجربة كان قد وضع في النهاية المفتاح الخطأ، لكن ذلك لم يعد سوى تفصيل جانبي.

اعتراف المشكك

كتب في تدوينته الختامية أن رأيه كان خاطئاً: لا تزال PHP2Shell تهديداً حقيقياً ويمكن استغلالها. ويرى أيضاً أن الاستغلال ما زال صعباً، وأن شخصاً يفتقر إلى الخبرة ولا يملك سوى نموذج لغوي كبير سيعجز على الأرجح عن إنجازه.

يمكن الاعتراض على ذلك. فمن المرجح أن معظم المحاولات لم تكن جادة: لم ينفق أصحابها عدداً كبيراً من الرموز ولم يستخدموا أذكى النماذج. فضلاً عن أن هذه النماذج كثيراً ما تحظر الطلبات المتعلقة بالاختراق.

وهناك بيانات أيضاً. يقول خبير اخترق OpenAI قبل بضعة أشهر إن Mythos وSol-5.6 وحدهما تمكنا في اختباراته من تنفيذ الهجوم خلال 2–4 ساعات. أما النموذجان المفتوحان GLM-5.3 وKimi K3.1 فعملا لأكثر من 20 ساعة من دون نجاح، وهو يشك في قدرة النماذج المفتوحة على إنجاز هذه المهمة من الأساس.

ويجيب ذلك في الوقت نفسه عن سؤال شائع: لماذا لا نسمع أخباراً عن اختراقات قادمة من الصين؟ وهل يثير الأمريكيون الضجة فحسب؟ وفقاً لهذه الاختبارات، لا تتعلق المسألة بالضجة؛ فالنماذج المتاحة هناك لا تمتلك حتى الآن القدرات اللازمة لمثل هذه المهمة.

ما الذي ينبغي فعله عملياً

أولاً: لا تنتظروا نشر استغلال علني قبل تثبيت التحديث. فالعروض المصورة لهجمات على منتجات حقيقية ضمن الإعلان تمثل دليلاً كافياً بالفعل. وغياب الشيفرة يعني فقط أنها لم تُنشر.

ثانياً: إذا كنتم تختبرون ادعاءات الآخرين بشأن ثغرة، فأعيدوا إنشاء إعدادات بيئة الإنتاج، لا منصة اختبار مبسطة. وجود PHP على الخادم لا يعني وحده أن الخادم معرض للمشكلة. كان هذا تحديداً خطأ المشكك، وقد يقع فيه أيضاً المدافعون الذين يظنون أنهم في مأمن.

ثالثاً: قيّموا المخاطر مع مراعاة قدرات النماذج الرائدة. بضع ساعات من الاختراق باستخدام نموذج قوي لا تكلف كثيراً مقارنة بتكلفة توقف الخدمة. أما الاختبارات الضعيفة باستخدام نماذج رخيصة وميزانية محدودة من الرموز فتعطي شعوراً زائفاً بالأمان.

القيود

هذه قصة تجربة واحدة ومجموعة اختبارات واحدة. جاءت بيانات النماذج من باحث واحد، لا من معيار قياس مستقل. ولا يزال الاستغلال يتطلب خبرة وموارد. لكن الخلاصة بسيطة: ثبّتوا التحديثات من دون انتظار دليل استعراضي مبهر.