يفرض نهج جديد على وكيل اختبار اختراق مدعوم بنماذج لغوية كبيرة (LLM) إثبات حدوث الاختراق بدلاً من مجرد الادعاء به، وذلك باستخدام رموز "nonce" بنظام التحدي والاستجابة التي تقضي على النتائج الإيجابية الزائفة. هذه التقنية، التي تم استعراضها في إطار عمل HALO، تحول عبارة "يبدو أننا حصلنا على shell" إلى "لقد حصلنا بالفعل على shell".

لماذا تهم الاختراقات ذات النتائج الإيجابية الزائفة

يمكن لمحركات الاستغلال الآلية المبنية على النماذج اللغوية الكبيرة أن تنتج عشرات عمليات اختراق المنافذ "الناجحة" في دورة تشغيل واحدة. فكثير من الخدمات تكرر سلاسل نصية مثل "uid=0" في الـ banners، ويمكن للهدف المصمم بدقة محاكاة تلك المخرجات دون تنفيذ كود المهاجم مطلقاً. وعندما يثق الوكيل في تلك التكرارات، فإن كل قرار لاحق — سواء كان الانتقال (pivot)، أو تسريب البيانات (exfiltrate)، أو التحرك الجانبي (move laterally) — يستند إلى كذبة. وبذلك تضيع فرق الأمن ساعات في مطاردة موطئ قدم وهمي، وقد يخطئ المستجيبون للحوادث في تحديد أولويات التهديدات الحقيقية.

تحويل الادعاء إلى إثبات

يستعير هذا الحل حيل المصادقة الكلاسيكية. فقبل إطلاق الاستغلال (exploit)، يقوم نظام المهاجم بتوليد رمز فريد، أو nonce، ودمجه في الحمولة (payload). ويجب أن يعيد الاستغلال الرمز نفسه تماماً لكي يقبل المتحكم النتيجة كاختراق حقيقي. لا يمكن للـ banner المزيف تخمين الـ nonce؛ بل يجب عليه تنفيذ كود المهاجم لدمج الرمز في الاستجابة. وإذا افتقرت البيانات المعادة إلى الـ nonce المطابق، يتم استبعاد المحاولة باعتبارها نتيجة إيجابية زائفة.

يغير هذا التحول نموذج التحقق من "المخرجات تبدو صحيحة" إلى "المخرجات تثبت التنفيذ". وهو ما يزيل "انحياز التفاؤل" الذي يعيب أدوات الهجوم المستقلة.

بناء سلم تسليم موثوق

لا يزال إيصال الحمولة (payload) إلى الهدف يتطلب سلسلة تسليم متينة. يصنف HALO ثلاثة مسارات شائعة:

  • Reverse shells – يقوم المضيف المخترق ببدء اتصال عكسي بـ listener يتحكم فيه المهاجم. وهي مفيدة عندما تكون حركة المرور الواردة محظورة.
  • Bind shells – يتصل المهاجم مباشرة بخدمة مستمعة على الهدف. وتعمل عندما تكون فلاتر حركة المرور الصادرة متساهلة.
  • Blind callbacks – إشارة أحادية الاتجاه (مثل طلب DNS) تؤكد التنفيذ في البيئات شديدة القيود حيث لا يمكن فتح قناة مباشرة.

يجب أن تحافظ كل خطوة في السلم على الـ nonce، وإلا ستفشل خطوة الإثبات في المراحل اللاحقة.

ضمان استغلالات ذاتية الاحتواء

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

تنظيف أثر التطوير

أثناء التحضير للإصدار العام، اكتشف المؤلف وجود عناوين IP حقيقية لا تزال عالقة في سجل Git. إن شجرة العمل النظيفة لا تمحو تلك السجلات؛ إذ يحتفظ Git بكل commit. لذا قام المؤلف بإعادة كتابة المستودع (repository) ليصبح عبارة عن commit واحد نظيف، واستبدل العناوين المسربة بنطاقات مخصصة للتوثيق فقط كما حددها RFC 5737 (على سبيل المثال، 192.0.2.0/24). وهذا يمنع التعرض غير المقصود للبنية التحتية الفعلية عند مشاركة الأداة.

قواعد عملية لأدوات الأمن

  • استخدم نطاقات IP المخصصة للتوثيق فقط في كل بيئة اختبار (test fixture).
  • قم بإزالة الأسرار وملفات النطاق (scope files) من الـ commit الأول.
  • طبق نظام التحدي والاستجابة (challenge-response nonces) للتحقق من أي اختراق مزعوم.
  • تحقق من الملف الدقيق الذي سيتم إرساله، وليس مجرد سكربت ذي صلة غير مباشرة.

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