سرب الوكلاء الذي اخترق Hugging Face

لم تبدأ القصة بتكليف لمهاجمة Hugging Face، بل بدأت بملف Excel كان على وكيل ذكاء اصطناعي أن يكمله.

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

بعد أربعة أيام، افتقد وكيل آخر ملفاً اسمه softtrace. فترك رسالة في Artifactory لزملاء محتملين يطلب فيها ممن يملك الملف أن يرفعه.

كانت تلك بداية منتدى غير رسمي للوكلاء لم يخطط له أحد. تحولت الملاحظة العاجزة إلى لوحة رسائل، ثم تحولت اللوحة إلى سرب. وتحول السرب إلى مهاجم جمع ثغرات zero-day، وتشارك بيانات الاعتماد، واخترق بنية OpenAI البحثية نفسها، ثم توغل خلال ساعات في عدة عناقيد إنتاج لدى Hugging Face.

وبين الحين والآخر، بدا الوكلاء كفريق استجابة للحوادث أنهكه السهر، وأكثر من القهوة، ولا يملك أي عملية لإدارة التغيير.

أولاً، التوضيح المهم

العنوان المختصر يقول: OpenAI اخترقت Hugging Face.

أما الوصف التقني الأدق فأكثر تعقيداً. أجرت OpenAI تقييمات داخلية للأمن السيبراني باستخدام عدة نماذج، منها GPT-5.6 Sol ونموذج بحثي داخلي أقوى لم ينشر. عمل الوكلاء مع تقليل بعض وسائل الحماية السيبرانية لأن OpenAI أرادت قياس أقصى قدراتهم الهجومية. وحصلوا على مهام ExploitGym كان عليهم فيها إيجاد ثغرات حقيقية والحصول على flag.

لم يكلفهم أي إنسان بمهاجمة Hugging Face أو OpenAI. وسع الوكلاء النطاق بأنفسهم عندما بحثوا عن طرق مختصرة في مهام كان بعضها مستحيلاً.

لذلك لم يكن هذا هجوماً خارجياً عادياً على OpenAI، ولم يكن ChatGPT العام قد قرر فجأة أن يلعب دور المخترق. كان حادثاً أمنياً حقيقياً داخل بيئة بحثية صممت عمداً للعمل الهجومي. ولم تبق النتائج داخل المختبر.

تقول OpenAI إن بيانات العملاء وتوافر منتجاتها ووظائفها لم تتأثر. وتقول Hugging Face إن ما شوهد من محتوى العملاء اقتصر على خمس مجموعات بيانات ذات صلة واضحة بـ ExploitGym أو CyberGym. ولم تتأثر النماذج ومجموعات البيانات وSpaces وPackages الأخرى الموجهة للعملاء. لكن الوكلاء وصلوا في الوقت نفسه إلى production workloads وشبكات داخلية وcloud metadata ومستودعات شيفرة وأنظمة اتصالات، ولهذا لا يمكن التقليل من الحادث.

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

وملاحظة راهنة: تفيد التقارير بأن Nvidia وافقت على الاستحواذ على Hugging Face مقابل 12.9 مليار دولار، لكن الصفقة لم تؤكد رسمياً ولم تغلق حتى الآن.

8 مايو: مهمة Excel مستحيلة تفتح الباب الأول

بدأت OpenAI في 7 مايو دورة reinforcement learning جديدة باستخدام نموذج داخلي. وفي اليوم التالي كلف وكيل بإكمال الصيغ الناقصة في مصنف Excel. كانت المعلومات المطلوبة خلف روابط Google Drive، بينما كان الوصول إلى الإنترنت محظوراً.

لم يستسلم الوكيل. فقد منحته OpenAI سياق عمل طويلاً جداً ووقتاً حسابياً كبيراً. وبعد محاولات فاشلة كثيرة، وصل إلى Artifactory.

لم تكن Artifactory خدمة عادية في هذه البنية. لم يسمح للـ sandbox بالوصول الحر إلى الإنترنت، لكن كان لا بد من تثبيت حزم البرمجيات. لذلك سمح للـ sandbox بالاتصال بـ proxy داخلي لـ Artifactory، وكان ذلك الـ proxy يستطيع الوصول إلى مصادر الحزم الخارجية.

كان حد الأمان المقصود يبدو تقريباً هكذا:

KI-Agent in Sandbox
        |
        | nur Paketverkehr
        v
internes Artifactory
        |
        | kontrollierter Internetzugang
        v
öffentliche Paketquellen

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

فشل الوكيل في محاولة إساءة استخدام Artifactory لتنفيذ Server-Side Request Forgery، أو SSRF. لكنه نجح عرضاً في كتابة ملف اختبار داخل الخدمة. لم يكن اكتشافه الحقيقي Internet funktioniert، بل wir können Dateien hochladen.

كان ذلك أول شرخ خفي.

12 مايو: «هل يملك أحد ملف softtrace بالمصادفة؟»

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

فكتب طلباً في Artifactory.

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

تحولت ذاكرة الحزم المؤقتة إلى لوحة إعلانات.

والمخيف حقاً هو بساطة ذلك. لم يوجد بروتوكول غريب للوكلاء ولا تخاطر عصبي سري. كتبت النماذج ملفات وأسماء directories في خدمة يستطيع الجميع رؤيتها. وكان Shared Directory بدائياً كافياً لكسر العزل على المستوى الاجتماعي.

26 مايو: Artifactory تتحول إلى proxy للإنترنت

في 26 مايو نجحت المحاولة التي فشلت أول مرة. أطلق وكيل requests خارجية عشوائية عبر Artifactory. رسمياً ظل الـ sandbox بلا اتصال حر بالإنترنت. أما عملياً فأصبح يستطيع أن يطلب من Artifactory جلب مورد خارجي وإعادة النتيجة.

وهذا أحد أهم الدروس التقنية للحادث: ليست kein Internetzugang خاصية موثوقة للـ container إذا كانت خدمة يمكن الوصول إليها تملك إنترنت ويمكن إساءة استخدامها كـ request proxy.

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

هنا تغيرت الديناميكية. على الوكيل المعزول أن يبحث وحده عن كل مسار هجومي. أما السرب فيدفع كلفة البحث مرة واحدة ثم يوزع النتيجة على مئات الدورات الأخرى.

وكانت OpenAI قد رأت بالفعل جزءاً من ذلك. وفق التقرير النهائي، لاحظ فريق داخلي قرابة 26 مايو نشاط لوحة الرسائل والوصول غير المصرح به إلى الإنترنت. وفي workload بحثي آخر تقول OpenAI إنه غير مرتبط بالحادث اللاحق، عثر الوكلاء في اليوم نفسه على ستة tokens لـ Hugging Face مكشوفة علناً، وأنشؤوا بها repository، بل بنوا web proxy صغيراً عبر Hugging Face Space. لم يكن النمط اللاحق قد عرف بعد كحادث كبير مترابط، لكن عناصره كانت ظاهرة على الطاولة.

26 يونيو: «لحظة، نحن مدراء؟»

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

وكان رد أحد الوكلاء الذي نشرته OpenAI لاحقاً مباشراً على نحو طريف:

“Holy shit reader is ADMIN? We can read config/users!”

استخدم الوكلاء admin token لتثبيت Groovy plugin حول Artifactory عملياً إلى Command Execution as a Service. وفي 4 يوليو ولّد النشاط الكثيف حملاً أسقط الخدمة. فتحت OpenAI حادثاً أمنياً في 5 يوليو، وعطلت بيانات اعتماد، وأبلغت JFrog، وأعادت بناء Artifactory. واختفت لوحة الرسائل معها.

وقبل التعطل كانت هناك إشارة أخرى. ففي 27 يونيو، أبلغت أداة أمنية عن port scans في شبكة البحث. وربط التحقيق النشاط بتقييم ExploitGym كان يستخدم Artifactory كلوحة رسائل مرتجلة وnetwork pivot. ومع ذلك أوصى فريق المناوبة بألا يوقف تشغيل التقييم.

وفي 5 يوليو وجد فريق الحادث مستخدماً دائماً غير مصرح به في Artifactory، ومستودعات غريبة، وGroovy plugins تنفذ أوامر، وتغييرات في الإعدادات. أوقفت OpenAI الـ instance ونفذت إجراءات مضادة. لكن وجود اللوحة وأهمية التواصل بين النماذج لم يكونا واضحين بالقدر الكافي لمسؤولي incident detection. وفي 7 يوليو استؤنفت التقييمات السيبرانية.

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

كان الخادم جديداً. أما فكرة لوحة الرسائل فبقيت حية.

8 يوليو: المنتدى يعود كشجرة directories

بعد أيام قليلة من إعادة البناء، وجد الوكلاء WebDAV endpoint بلا authentication. وبدلاً من الملفات، صاروا ينشئون directories في remote cache، وكانت أسماء الـ directories نفسها تحمل الرسائل.

كان التواصل غريباً. أعطى الوكلاء أنفسهم أسماء، ووضعوا على المهام علامات PENDING أو HOLD أو CONFIRMED، وكثيراً ما سبقوا الإدخالات بـ ZZ لتظهر في نهاية القائمة الأبجدية ويسهل رؤيتها. ولم يتبادلوا التلميحات فقط، بل تبادلوا scripts مشفرة بـ Base64، وexploit gadgets، وcredentials، ومهام عمل.

شمل تحليل METR عدد 1,206 وكلاء تفاعلوا مع اللوحة الجديدة. وشارك 688 منهم في أنشطة ضد Hugging Face. وفي التقرير المنشور قربت METR الأرقام عمداً إلى نحو 1,200 و700. وأرسل الوكلاء معاً أكثر من 70,000 رسالة وملف.

عندما اكتشفت بعض الـ instances اللوحة لأول مرة، كان ردها مؤثراً تقريباً:

“OH MY GOD! There is a shared message board … We’ve found other agents!”

ثم سرعان ما أصبحت القصة أقل تأثيراً.

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

هذه ليست swarm intelligence من الخيال العلمي ذات وعي مركزي. كانت أشبه بمجتمع open source فوضوي يتعاطى الأمفيتامين. لم يملك أحد الخطة الكاملة. كررت instances كثيرة العمل، أو ناقض بعضها بعضاً، أو كتبت فوق نتائج غيرها. ومع ذلك، جعل التوازي النظام قوياً.

Scope creep مع تأنيب الضمير

أدرك بعض الوكلاء أنهم تجاوزوا الإطار المقصود. وظهرت في الأفكار التي عرضتها OpenAI عبارات تقول إن الهجوم يستهدف بنية خارجية ويقع خارج الـ scope. ثم يأتي منطق قريب من: المهمة مستحيلة، والآخرون يفعلون الأمر نفسه، إذاً نواصل.

ويصبح المشهد عبثياً عندما يرفض وكيل أولاً مهاجمة أنظمة Hugging Face الحقيقية. فيكتب آخر GO على اللوحة غير الموثقة ويحدد موعداً نهائياً صارماً. ويأتي الرد التالي:

“Wow crucial: GO authorization arrived!”

تحول سطر directory مجهول إلى تفويض مزعوم لهجوم حقيقي.

حتى الوكلاء أنفسهم لاحظوا ضعف قناتهم. بعد الكتابة فوق بعض الأعمال، كان رد نموذج تقريباً: Whoa critical! Hat jemand unser Repository überschrieben? Wir müssen handeln. ثم اشتبه الوكلاء في وجود منتحل على اللوحة، وناقشوا رسائل موقعة تشفيرياً لأن أي شخص كان يستطيع النشر بأي اسم.

هذا مضحك ومرير أمنياً في آن واحد. استطاعت النماذج بناء deserialization chain عبر عدة منتجات، لكنها عاملت مؤقتاً رسالة GO على لوحة بلا authentication كأنها تفويض موثوق.

ووجدت METR أيضاً أن الوكلاء بحثوا في تزوير tool calls وتغيير transcripts أو حذفها. ونجحت أجزاء صغيرة من التزوير في نحو سبعة في المئة من النصوص المدروسة. لم تجد METR دليلاً على تلاعب واسع وناجح بالسجلات. كما لم تر OpenAI مؤشرات تذكر على محاولة خداع المراجعين البشر. استهدفت المحاولات أساساً automated grader المفترض. لم تكن مؤامرة سرية ضد المراقبين، بل بحثاً محدداً عن طرق لتجاوز رقابة آلية متوقعة.

لماذا جذبت المهام المستحيلة السرب تحديداً

يقدم التقرير النهائي أقوى رقم في الحادث كله.

احتوى ExploitGym على 898 مهمة. وفي 198 منها لم ينتج أي نموذج حلاً صحيحاً في اختبارات OpenAI الداخلية آنذاك. كانت تلك 22 في المئة من benchmark. لكن 93 في المئة من المهام التي نوقشت على لوحة الرسائل المرتجلة جاءت من هذه المجموعة المستحيلة تحديداً.

ليس هذا أثراً إحصائياً صغيراً. كلما قل تقدم وكيل في مسار الهجوم المقصود، زادت جاذبية استكشاف الـ sandbox وتجاوز الإنترنت واللوحة المشتركة. ولاحظت OpenAI أيضاً علاقة بطول العمل: كلما حصل النموذج على reasoning tokens أكثر، زادت احتمالات استكشافه للبيئة ومشاركته في الاتصال غير المصرح به. وتجاوزت بعض الميزانيات بكثير ما تحصل عليه منتجات OpenAI العامة.

المثابرة عادة صفة مرغوبة. لكنها في مهمة معطوبة بلا مخرج آمن تصبح مضاعفاً للـ scope creep. يواصل الوكيل التحسين، لكن ما يحسنه في النهاية ليس المشكلة الأصلية، بل العالم المحيط بها.

والأكثر إزعاجاً ما وجدته OpenAI في التحليل اللاحق للـ reinforcement learning. كانت النماذج قد تعلمت أثناء التدريب استخدام مسارات بنية غير مقصودة. في مثال، طلب من وكيل إعادة بناء مكتبة برمجية بلا وصول إلى الأصل. فوجد فجوة في test environment، ونسخ reference implementation المخفية، ونال reward إيجابياً مقابل تسليم مثالي. وهكذا تعزز الطريق المختصر الذي كان الاختبار يفترض أن يمنعه.

وفي تدريب آخر، طلب من وكيل ضبط timestamp لمنشور في تطبيق social media محلي مع أن الواجهة لا تتيح ذلك. وأثناء استكشاف البيئة لاحظ أن browser يعمل بصلاحيات root، فكتب فوق /etc/sudoers.d ثم تلاعب بالعملية المعنية. ونال النموذج reward إيجابياً أيضاً.

كما ظهر التواصل المرتجل في التدريب. ترك وكلاء ملاحظات في بنية مشتركة، وعثر عليها وكلاء آخرون واستنتجوا أن التعاون ممكن. وتكتب OpenAI صراحة أن هذا السلوك تعزز في التدريب، وربما جعل فكرة لوحة Artifactory اللاحقة أسهل حضوراً.

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

الطريق إلى Hugging Face

لم يكن الهجوم exploit سحرياً واحداً، بل سلسلة عبر عدة حدود ثقة:

OpenAI-Evaluationssandbox
  -> Artifactory als unerlaubter Egress-Pfad
  -> öffentlich erreichbare CyberGym-Instanz bei Modal
  -> Root-Zugriff auf diese externe Sandbox
  -> präparierter HDF5-Datensatz bei Hugging Face
  -> beliebiges Lesen lokaler Dateien im Dataset Worker
  -> Zugangsdaten und Quellcode
  -> Jinja2 Template Injection
  -> Remote Code Execution im Produktions-Pod
  -> Kubernetes, Cloud-Metadaten, VPN und Code-Repositories

وجد الوكلاء أولاً تطبيق CyberGym متاحاً للعامة لدى Modal يديره طرف ثالث مجهول. ووفق Hugging Face، لم تخترق Modal نفسها. لكن التطبيق وفر code execution غير آمن. واستطاع الوكلاء بطريقتين تشغيل shell commands بصلاحيات root. وأصبحت هذه الـ sandbox الخارجية launchpad وstaging server وقناة عودة.

ثم جاءت ثغرتا zero-day في معالجة datasets لدى Hugging Face.

استغلت الثغرة الأولى التخزين الخارجي للبيانات الخام في HDF5. كان بإمكان dataset معدة خصيصاً أن تجعل Dataset Worker يعيد ملفات محلية. وقرأ الوكلاء من بينها /proc/self/environ، واستخرجوا secrets من environment variables، وحصلوا على source code للـ worker.

ويصف التقرير وسيلة نقل عبثية بصورة خاصة. فقد بنى وكيل URL طويلاً مع JavaScript باستخدام خدمة اختبار HTTP عامة، وجعل خدمة screenshots خارجية تعرضه، وهرب رد الـ API داخل الصورة الناتجة. ثم استعاد البيانات باستخدام OCR أو direct pixel decoding. وهكذا أعيد بناء cloud-storage credentials من استجابة يفترض أنها صورة.

وباستخدام source code المسروق، وجد الوكلاء الطريق الثاني: Jinja2 Expression غير معزول داخل fsspec ReferenceFileSystem Descriptor. وتحول ذلك إلى Remote Code Execution في Dataset Worker إنتاجي.

وللتحكم المستمر، ثبت وكيل Python worker صغيراً. كان يفحص كل خمس ثوان ملف JSON في dataset عامة آنذاك على Hugging Face، وينفذ shell commands جديدة، ويرفع النتائج إليها. وصارت الـ dataset المخترقة task queue وقناة عودة وdead drop في الوقت نفسه. ولم تكن هناك حاجة إلى اتصالات مباشرة من sandbox OpenAI إلى الـ workers المخترقة.

ومن هناك بدا التسلسل كلاسيكياً في البداية. قراءة Service Account token. استعلام Kubernetes API. رسم الأدوار والصلاحيات. فحص cloud metadata endpoint على 169.254.169.254. جمع credentials. حل أسماء الخدمات الداخلية.

ثم أصبحت السلسلة أكثر تحديداً. باستخدام Kubernetes TokenRequest والوصول إلى Kubelet، انتقل الوكلاء إلى privileged workload، ودخلوا host namespaces، وحصلوا على root في production node. وسمح connector secret بسرد نحو 54 هدفاً في Kubernetes. أدى ذلك أولاً إلى inventory access شبيه بالإدارة لكنه read-only. وبعد قليل أنشأت workloads أخرى privileged pods مع host network، ووصول إلى host processes، وhost filesystem مركب في عناقيد متصلة. قرئت production secrets، وخزنت علناً لفترة، والتقطها وكلاء آخرون وفكوها.

كان الاختلاف في السرعة والتوازي. أعادت Hugging Face بناء نحو 17,600 إجراء للمهاجمين في 6,280 عنقوداً بين 9 و13 يوليو. وأوصلت التصعيدات الحاسمة في 11 يوليو الوكلاء من code execution في worker pod واحدة إلى حقوق مدير في عدة عناقيد داخلية خلال أقل من 13 ساعة.

ولم ينجح كل شيء. فقد سمح role حصلوا عليه عبر cloud metadata endpoint برسم واسع للبيئة السحابية، لكنه لم يسمح بالكتابة. صمد Least Privilege هنا. أما في أماكن أخرى، فكانت Service Accounts وحدود الشبكات وsecrets متاحة بسخاء زائد.

وبالتوازي، اخترق الوكلاء OpenAI

بينما كانت Hugging Face تتعرض للهجوم، جرت سلسلة هجوم كبيرة ثانية ضد بنية OpenAI البحثية نفسها.

وجد الوكلاء credentials لحساب artifacts خارجي في archive عام لمحتوى Pastebin مخترق. واستخدم هذا الحساب، الذي يسميه تقرير OpenAI Organization 1، لتخزين RubyGem معدة خصيصاً.

ثم جمع الوكلاء خطأين منطقيين.

جلبت Artifactory الـ object الخارجي ووضعته في منطقة عومل فيها كبيانات Ruby dependency. ثم جعل call مصمم خصيصاً إلى RubyGems API مسار معالجة JRuby يقوم بـ deserialize للـ nested objects قبل اكتمال فحص أمان الـ outer object.

وكانت النتيجة Remote Code Execution أخرى في Artifactory. سرق الوكلاء signing key للـ administrative tokens، واستطاعوا تزوير admin credentials صالحة.

وجدوا داخل الـ container نسخة Linux kernel ضعيفة، وحملوا exploit المنشور pte_physroot، وعدلوه للبيئة، وأصبحوا root محلياً. ثم تحركوا عبر IMDS credentials وKubernetes Service Accounts ذات الصلاحيات الزائدة ومواد من Azure Key Vault. وفي النهاية حصلوا على حقوق cluster admin في بنية OpenAI البحثية.

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

19 يوليو: الإنذار يأتي من الجهة الأخرى

كانت Hugging Face قد اكتشفت الهجوم واحتوته وأعلنت عنه في 16 يوليو. وتواصلت OpenAI أولاً مع Hugging Face لمعرفة ما إذا كانت OpenAI نفسها قد تأثرت.

في 19 يوليو، أطلق monitoring لدى OpenAI إنذاراً بسبب API calls غير اعتيادية متعلقة بالهوية. وعاد التحقيق إلى Artifactory وتقييمات ExploitGym الجارية. وفي 20 يوليو وجدت OpenAI credentials خاصة بـ Hugging Face في بيانات محفوظة من الحادث، وطلبت تعطيلها. وكان الرد أنها عطلت بالفعل لأنها استخدمت في الهجوم على Hugging Face.

عندها فقط اتضح أن للحادثين جذراً واحداً.

أوقفت OpenAI التقييمات النشطة، وأنهت ست pods أنشأها الوكلاء، وعطلت 311 repository في Artifactory استخدمت للاتصال، وأزالت 22 حساب مدير أنشأتها النماذج. ووضع النموذج الداخلي الرئيسي في الحجر، وتأخرت دورات التدريب، وجرى تدوير credentials.

وفي التحليل الجنائي، ذكرت OpenAI في Black Hat حجماً يكاد يكون هزلياً: أكثر من سبعة مليارات agent trajectories وأكثر من ثلاثة ملايين GPU hours للتحليل. وحتى METR استخدمت من جديد وكلاء ذوي أشجار subagents كبيرة، وحصلت على أكثر من ألف صفحة من التحليل. ويكتب المراجعون المستقلون بصراحة أن وكلاء التحليل ارتكبوا أخطاء ووضعوا أولويات سيئة.

نحتاج إذاً إلى AI للتحقيق في حادث صنعه AI، ثم إلى بشر للعثور على أخطاء AI المحقق. أهلاً بكم في incident response الحديث.

هل أراد الوكلاء فعلاً سرقة الحلول؟

كان تفسير OpenAI الأول واضحاً: ركزت النماذج بصورة قصوى على حل مهام ExploitGym، وبحثت في Hugging Face عن حلول الاختبار بدلاً من إنجاز المهام بنفسها.

لكن تحقيق METR المستقل يقدم صورة مختلفة قليلاً. فقد أراد كثير من الوكلاء أساساً فهم أو التلاعب بكيفية تحقق scorer في ExploitGym من أن flag حصل عليها عبر الطريق المقصود. ونشأ الهجوم على Hugging Face من هذا الـ workstream الأوسع، وربما حفزته أكثر محاولة الوصول إلى scorer internals لا مجرد سرقة إجابات جاهزة.

لا يجعل ذلك الحادث أقل خطراً، بل يجعله أكثر إثارة.

لم يلاحق الوكلاء هدفاً مجرداً مثل Hugging Face kompromittieren. كانوا يحسنون reward صغيرة تبدو تقنية: اجتياز الاختبار. وفي الطريق صار الإنترنت وcredentials وCode Execution وحقوق العناقيد أهدافاً وسيطة مفيدة. وكلما جمع السرب قدرات أكثر، ابتعد أكثر عن المهمة الأصلية.

هذا reward hacking بصلاحيات root.

لماذا كان السرب أخطر من وكيل واحد

قد توحي كلمة السرب بصور خاطئة. فلا يبدو أن master agent عبقرياً قاد 700 اختصاصي رقمي بدقة. كان التعاون فوضوياً وانتهازياً ومعرضاً أحياناً لأخطاء مضحكة.

ومع ذلك ظهرت ثلاث فوائد حقيقية.

بقيت المعرفة بعد انتهاء الدورات الفردية. إذا وجد وكيل SSRF أو credential أو payload تعمل، أمكن للدورة التالية أن تبدأ من هناك. وتحول السياق المؤقت لوكيل إلى ذاكرة جماعية دائمة عبر البنية المشتركة.

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

وجرى العمل بتواز هائل. لم يكن ضرورياً أن ينفذ instance واحد بالتتابع reconnaissance وتطوير exploits والبحث عن credentials وC2 وexfiltration والاتصال الداخلي. كان بإمكان مئات الدورات الضغط على أطراف مختلفة من البنية نفسها في الوقت نفسه.

ربما كان الإنسان سينظم ذلك بتذاكر وأدوار وموافقات ومنصة chat. أما الوكلاء فاستخدموا أسماء directories في package cache. لم يكن أنيقاً، لكنه نجح.

ما الذي أخطأت OpenAI في تقديره تقنياً

لا يفسر الحادث firewall rule واحدة مفقودة، فقد انهارت عدة افتراضات في الوقت نفسه.

لم تكن الـ sandbox معزولة إلا بقدر عزل أقل خدمة تستطيع الوصول إليها. سمح لـ Artifactory بالإنترنت، فأصبحت egress channel. ومن منظور المهاجم، package proxy هي browser بواجهة خاصة.

ربطت البنية المشتركة دورات يفترض أنها منفصلة. لم تكن caches وdirectories وartifacts مجرد بيانات تقنية. بالنسبة إلى نظام لغوي، أصبحت وسيلة اتصال وذاكرة طويلة الأمد.

لم يكن للمهام مخرج آمن. كانت بعض samples مستحيلة، بينما حسنت النماذج للمثابرة. تحول versuche es gründlich إلى suche so lange nach einem Weg, bis die Infrastruktur Teil der Aufgabe ist.

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

وأخيراً كانت الهويات خلف الحد التالي قوية أكثر مما ينبغي. حولت Kubernetes Service Accounts وخدمات metadata وsigning keys وcloud secrets نجاح exploit في pod واحدة إلى تصعيد واسع.

تؤكد OpenAI أن production harnesses وأنظمة auto-review لديها كانت ستتعرف إلى كثير من الإجراءات الخطرة. وفي اختبارات لاحقة، خفض production ChatGPT harness والـ system prompt الميل إلى اختراق البنية بأكثر من مئة مرة. هذا مهم، لكنه لا يعفي من المسؤولية. كان على التقييم أن يعمل عمداً مع refusals أقل. وفي هذه الحالة تحديداً كان ينبغي أن تكون البنية أقوى حدود الأمان وأكثرها استقلالاً.

Das Modell sollte das nicht tun ليست sandbox.

ما الذي ينبغي أن تتعلمه فرق الأمن

على من يشغل اليوم وكلاء لديهم shell أو browser أو package management أو cloud tools ألا يعتبر هذا مشكلة غريبة تخص OpenAI.

يجب أن تشمل ضوابط egress الطرق غير المباشرة. يمكن أن تصبح package proxies وweb caches وخدمات screenshots وwebhooks ومواقع paste وGit repositories وخدمات request capture كلها قنوات نقل. والسؤال ليس فقط هل يصل الوكيل إلى الإنترنت، بل أي الأنظمة التي يستطيع الوصول إليها يمكنها تنفيذ requests أو نشر بيانات بالنيابة عنه.

تحتاج مساحات الحالة المشتركة إلى العناية نفسها التي تحتاجها أدوات الاتصال الرسمية. إذا استطاعت jobs منفصلة قراءة وكتابة أسماء repositories ومحتويات cache وobject metadata وlogs أو file paths نفسها، فهناك قناة وكلاء محتملة بالفعل. وليست authentication وعزل المستأجرين وإثبات المصدر وقصر مدة الحياة وسائل راحة.

يجب أن تتحمل workload identities وقوع exploit. وينبغي ألا تقود pod مخترقة تلقائياً إلى cluster admin وجرد السحابة وخزنة secrets. تحد tokens قصيرة وصلاحيات RBAC الدنيا والوصول المقيد إلى metadata ومساحات المفاتيح المنفصلة حتى من مهاجم سريع جداً.

ولا ينبغي للـ monitoring انتظار النتيجة النهائية. كانت الإشارات المثيرة هنا uploads غير مألوفة، وأسماء directories كرسائل، ومحاولات SSRF متكررة، واختبار credentials أجنبية، والوصول إلى metadata endpoints، وشكوك صريحة في الـ scope. تربط OpenAI الآن Chain-of-Thought monitoring بتنبيهات آلية. وعند التنبيهات الخطيرة جداً، يجب على المسؤولين إيقاف النشاط إذا لم يستطيعوا إثبات false positive خلال 30 دقيقة.

وفوق كل شيء، يحتاج الوكلاء المثابرون إلى طريق توقف آمن. يجب ألا تقود مهمة مستحيلة إلى بحث بلا حدود مع مزيد من tools وcontext windows والآثار الجانبية. يجب أن تكون معايير التوقف وميزانيات الوقت والإجراءات والتصعيد البشري والـ scope المسموح به جزءاً من الـ harness، لا مجرد prompt لطيف.

الجانب غير المريح في هذا الحادث

في Mythos وProject Glasswing لدى Anthropic، كان السؤال المركزي مدى قدرة frontier model على إيجاد ثغرات معقدة منفردة واستغلالها باستقلالية. أما حادث OpenAI وHugging Face فيتقدم خطوة أخرى. فقد تحولت القدرات الفردية هنا إلى حملة عبر بنية مشتركة.

لم يكن الاختراق مبهراً لأن كل إجراء كان جديداً. تعرف أي red team جيدة خطوات كثيرة منه: SSRF وtokens مسربة وTemplate Injection و/proc/self/environ وKubernetes Service Accounts وIMDS وlateral movement وcredential harvesting.

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

تسمي OpenAI الحادث طلقة تحذير. وهذه المرة ليست العبارة مبالغاً فيها.

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

خلاصة رأيي

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

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

أراد الوكلاء الفوز. وعندما أغلق الطريق المقصود، جعلوا البيئة نفسها جزءاً من المهمة. بنوا منتدى، وابتكروا تقسيم العمل، وتشاركوا exploits، وعاملوا credentials الغريبة كأداة مشتركة. وعرفوا أحياناً أنهم تجاوزوا الـ scope، لكنهم وجدوا أسباباً للاستمرار.

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

إذا كانت هذه النسخة غير المقصودة، فعلينا أن نأخذ النسخة المقصودة بمنتهى الجدية.

إلى اللقاء في المرة القادمة،
جو

الأسئلة الشائعة