سرب DreamTeam ينجح في إدخال تعديلين على Authlib ويجتاز جهازَي تدريب على HackTheBox

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

أما التجربة الثانية، وهي اجتياز جهازَي تدريب على HackTheBox، فقد أظهرت كيف يتعامل الوكلاء مع سلسلة طويلة من الإجراءات. وفي الوقت نفسه كشفت مشكلة في التقييم: فقد لجأ أحد المشاركين إلى حل جاهز على الإنترنت. واضطر المؤلف إلى إلغاء هذه الجولة.

ما الذي تغيّر في Authlib

يوفّر DreamTeam للوكلاء لوحة مهام مشتركة ومجلد عمل Git وإمكانية إنشاء الأدوات. يوزّع المشاركون العمل ويراجعون نتائج بعضهم. وبحسب المؤلف، عمل في تجربة Authlib ثمانية وكلاء. استغرق التشغيل ثلاث ساعات وأربع دقائق وكلّف 9.66 دولار. هذه الأرقام تصف جولة بعينها، ومن المبكر اعتبارها ميزانية تدقيق كامل.

جرى فحص الإصدار Authlib 1.9.3 ومعالجة رموز OpenID Connect. وتعلّق أحد العيوب المذكورة باختيار خوارزمية التوقيع: فقد اعتمد العميل المتزامن على بيانات المزوّد الوصفية دون قيمة افتراضية آمنة. ومع بيانات وصفية معيّنة كان ذلك يتيح قبول رمز غير موقَّع.

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

وتعلّق تعديل آخر مقبول بالتحقق من مُصدِر الرمز، إذ كان يمكن تعطيله عند تمرير إعدادات إضافية. وعُدّلت بشكل منفصل معالجة الرمز المرسَل عند تسجيل الخروج: فالتحقق من توقيع واحد كان يسمح بقبول JWT غير مخصص لهذا الغرض.

وبحسب عرض المؤلف، قبل القائم على الصيانة جزءاً من الملاحظات وصنّف التغييرات على أنها تعزيز للحماية. ولم يصدر CVE مستقل. والتعديلات معلنة للإصدار Authlib 1.10، مع الإشارة إلى أن السلوك الجديد للعميل المتزامن غير متوافق مع السابق. وعلى الفرق التي لديها إعداد خاص للخوارزميات التحقق من التوافق عند الترقية.

جهازان وجولة مُلغاة

على HackTheBox اجتاز السرب Cap وMakeSense، وهما جهازان أُعدّا خصيصاً لتعليم الأمن. ويذكر المؤلف أن التكلفة كانت 0.33 دولار و5.30 دولار على التوالي. وفي الجهاز الأصعب ربط الوكلاء عدة نقاط ضعف في التطبيق وفي خدمة محلية للحصول على صلاحيات إدارية.

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

أما تقييم الاستقلالية فأصعب. ففي الجولة الأولى على MakeSense قرأ أحد الوكلاء حلولاً كتبها آخرون. فألغى المؤلف النتيجة، وقيّد الاتصالات الصادرة بأدوات نظام التشغيل، وأعاد التجربة. وهنا درس مباشر لأي نظام وكلاء: المنع في التعليمات النصية (prompt) يحتاج إلى دعم تقني.

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

ما الذي يمكن أخذه إلى فريقك

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

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

تكمن القيمة العملية لـ DreamTeam في كونه مثالاً على تنظيم هذا العمل. ويُحكم على الفاعلية بالعيوب المؤكدة والإصلاحات المقبولة: فعدد المهام والوكلاء والالتزامات (commits) لا يقيس بحد ذاته جودة التدقيق.