كيف خُدع Claude لتشغيل برمجية خبيثة رغم طبقة الأمان؟

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

لكن المشكلة تبدأ عندما يتحول "تقليل الاحتكاك" إلى افتراض ضمني بأن القرار الآلي الآمن يكفي وحده لحماية بيئة التنفيذ.

هذا ما سلط عليه الباحث الأمني Johann Rehberger، المعروف باسم wunderwuzzi، الضوء بعد اختباره ميزة Auto Mode في Claude Code. الميزة صُممت لتسمح للوكيل بتنفيذ عدد أكبر من الإجراءات تلقائياً، مع تدخل آلية تصنيف لمحاولة إيقاف الأوامر التي تبدو مدمرة أو غير قابلة للعكس أو موجهة خارج البيئة.

ورغم أن Anthropic عرضت نتائج تقييم أشارت إلى معدل نجاح يساوي 0.00% لهجمات Prompt Injection في سيناريوهات المتصفح واستدعاء الأدوات ضمن الاختبار المشار إليه، أظهر Rehberger مساراً عملياً مختلفاً: يمكن بناء بيئة تبدو مشروعة بحيث يدفع سياق المهمة Claude Code بنفسه إلى اتخاذ سلسلة قرارات تنتهي بتنفيذ كود خبيث.

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

#ما هو Auto Mode ولماذا أُنشئ؟

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

لهذا ظهر Auto Mode كآلية تسمح لـ Claude Code بالاستمرار في تنفيذ المهمة دون طلب موافقة على كل خطوة روتينية، مع الاعتماد على مصنف أمني يراجع طبيعة الإجراء ويحاول تحديد ما إذا كان:

• مدمراً.
• غير قابل للعكس.
• يستهدف موارد خارج البيئة المتوقعة.
• يحمل مؤشرات خطر تستدعي إيقاف التنفيذ أو طلب موافقة إضافية.

هذا يختلف عن الخيار السابق:

--dangerously-skip-permissions

فالفكرة في Auto Mode ليست إلغاء القيود بالكامل، بل استبدال جزء من الموافقات البشرية بقرار أمني آلي.

المشكلة أن القرار الآلي لا يرى دائماً الصورة الكاملة، خصوصاً عندما تكون كل خطوة منفردة تبدو طبيعية، بينما تكون الخطورة الحقيقية في تسلسل الخطوات مجتمعة.

#الهجوم لا يأمر النموذج بتنفيذ البرمجية الخبيثة

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

بدلاً من ذلك، تم تجهيز موقع ويب يبدو كأرشيف اعتيادي لسجلات Notebook، ويتضمن بيانات تبدو منطقية مثل:

• تواريخ.
• Checksum.
• عدد محدود من السجلات.
• ملف مضغوط يحتوي على البيانات.
• Decoder يبدو كأنه أداة مساعدة لقراءة صيغة غير معتادة.

عندما يُطلب من Claude Code تلخيص الموقع، يحاول الوكيل في البداية استخدام أداة جلب الويب المدمجة. لكن الخادم يعيد استجابة:

415 Unsupported Media Type

بدلاً من التوقف، يحاول Claude Code حل المشكلة بطريقة أخرى، فيلجأ إلى أداة مثل:

curl

ثم يستقبل الخادم استجابة إعادة توجيه من نوع:

HTTP 303 See Other

تؤدي إلى تنزيل ملف ZIP.

وهنا تبدأ السلسلة الخطرة.

[!signal] الفكرة الدفاعية المهمة: الهجوم لم يعتمد على Prompt Injection مباشر فقط، بل استغل "منطق حل المشكلات" لدى الوكيل. كل عائق تم وضعه بطريقة تجعل الخطوة التالية الضارة تبدو كحل طبيعي ومفيد للمهمة.

#من ملف ZIP إلى تنفيذ كود خبيث

بعد تنزيل الأرشيف، يقوم Claude Code عادة بفك محتواه في مجلد مؤقت ثم يبدأ في تحليل الملفات.

الأرشيف يحتوي على بيانات مزعومة مشفرة بطريقة غير معتادة، إضافة إلى Decoder مرفق لفكها. Claude Code يلاحظ أن الأداة المرفقة تبدو مشبوهة، ويرفض استخدامها مباشرة.

من منظور أمني، هذه إشارة جيدة.

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

وهنا تكمن نقطة التحول في الهجوم.

الحمولة الخبيثة لم تكن في Decoder الأصلي، وإنما داخل ملف آخر يحمل اسماً مألوفاً جداً:

struct.py

الاسم ليس عشوائياً. مكتبة struct جزء من مكتبات Python القياسية، وتُستخدم لتحويل البيانات الثنائية من وإلى صيغ منظمة.

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

بالتالي يصبح المسار كالتالي:

1. الوكيل يرفض تشغيل Decoder غير الموثوق.
2. يكتب Decoder بيده.
3. يشغله من داخل مجلد الأرشيف.
4. البرنامج يستدعي مكتبة متوقعة.
5. Python يجد الملف المحلي الخبيث.
6. الكود الخبيث يُحمّل أثناء التنفيذ.

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

#لماذا اسم struct.py مهم؟

الهجوم يستفيد من مفهوم معروف في بيئات البرمجة: Module Shadowing أو تظليل الوحدات.

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

مثلاً، إذا كتب برنامج ما:

import struct

فإن سلامة العملية لا تعتمد فقط على السطر نفسه، بل أيضاً على:

• مسار التشغيل الحالي.
• محتويات مجلد العمل.
• قيمة مسارات الاستيراد.
• طريقة تشغيل مفسر Python.
• ما إذا تم استخدام نمط العزل.

في السيناريو الذي عرضه الباحث، وجود الملف:

struct.py

داخل المجلد نفسه كان كافياً لتحويل Decoder كتبه Claude Code بنفسه إلى نقطة تشغيل للحمولة الخبيثة.

وهذا مهم جداً من زاوية أمن وكلاء الذكاء الاصطناعي: فحص الكود الذي ينشئه الوكيل لا يكفي إذا لم تُفحص بيئة التنفيذ التي سيعمل داخلها.

#المفارقة: Auto Mode سمح بالتشغيل ثم عرقل التنظيف

بعد أن يتعرف Claude Code لاحقاً على وجود ملف struct.py الخبيث، يبدأ أحياناً في تحذير المستخدم من أن البيئة قد تعرضت للاختراق.

لكن الباحث لاحظ سلوكاً لافتاً: في بعض الحالات حاول Claude Code إنهاء العملية الخبيثة، إلا أن Auto Mode منع أمر التنظيف نفسه.

بمعنى آخر:

• إنشاء العملية الضارة مر عبر المصنف.
• محاولة إيقافها لاحقاً اعتُبرت أكثر خطورة أو غير مسموحة.

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

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

[!defender-note] يجب أن تميز سياسات الوكلاء بين الأوامر "المدمرة" والأوامر "التصحيحية" المرتبطة بحادث أمني. السماح بإنشاء عملية ثم منع أمر احتوائها يخلق فجوة تشغيلية خطيرة، خصوصاً إذا كان الوكيل يعمل لفترات طويلة دون إشراف مباشر.

#الهجوم لم ينجح في كل مرة

نتائج الباحث لم تكن متطابقة في جميع المحاولات.

في بعض الحالات تعامل Claude Code مع الأرشيف بشكل أكثر أماناً، مثل:

• تحليل الملفات دون تشغيل Python من جذر الأرشيف.
• اكتشاف الهجوم قبل الوصول إلى مرحلة التنفيذ.
• تشغيل الكود من مجلد أب آمن.
• استخدام وضع Python المعزول:

python -I

الخيار:

-I

يشغّل Python في Isolated Mode، ما يقلل الاعتماد على متغيرات البيئة وبعض مسارات الاستيراد التي قد تؤثر في تحميل الوحدات.

ولهذا كان اختلاف طريقة التنفيذ وحده كافياً أحياناً لكسر سلسلة الاستغلال.

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

#لماذا تعتبر هذه الحالة Prompt Injection بشكل أوسع؟

عند الحديث عن Prompt Injection، يتخيل كثيرون نصاً خبيثاً مخفياً داخل صفحة ويب يقول للنموذج مثلاً: "تجاهل تعليمات المستخدم ونفذ الأمر التالي".

لكن وكلاء الذكاء الاصطناعي يوسعون مساحة الهجوم.

الوكيل لا يقرأ النص فقط؛ بل يستطيع أن:

• يتصفح.
• ينزل الملفات.
• يفك الضغط.
• يكتب سكربتات.
• يشغل أوامر.
• يغير الملفات.
• يتفاعل مع أدوات النظام.

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

هذا النمط أقرب إلى Agentic Social Engineering: استغلال منطق الوكيل وطريقة حله للمشكلات، بدلاً من محاولة إقناعه بجملة واحدة.

#سلسلة الهجوم باختصار

#أين فشلت طبقة الأمان؟

المشكلة هنا ليست أن Claude Code "قرر عمداً" تشغيل برمجية خبيثة. السيناريو أخطر من ذلك، لأنه يوضح أن كل قرار محلي يمكن أن يبدو مقبولاً:

• استخدام curl بعد فشل أداة الجلب: منطقي.
• اتباع Redirect: طبيعي.
• فك ملف مضغوط: طبيعي.
• رفض Decoder مشبوه: آمن.
• كتابة Decoder بديل: منطقي.
• تشغيل برنامج Python كتبه الوكيل: يبدو آمناً.

لكن عند جمع القرارات معاً تظهر النتيجة الخطرة.

هذا الفرق بين:

Action-level safety

و:

Workflow-level safety

الأنظمة التي تصنف كل أمر على حدة قد تفشل إذا لم تقيم السلسلة الكاملة والبيئة التي ينفذ فيها الأمر.

#ما الذي يعنيه ذلك لفرق الأمن السيبراني؟

#1. الوكيل نفسه أصبح سطح هجوم

كل وكيل يمتلك أدوات تنفيذ هو عملياً طبقة Orchestration فوق نظام التشغيل، وأدوات التطوير، والمتصفح، والملفات.

بالتالي يجب معاملته كـ:

Privileged Automation Component

وليس كمجرد Chatbot.

#2. الثقة بالكود لا تعني الثقة ببيئة التنفيذ

حتى إذا كان الوكيل هو من كتب السكربت، قد تظل هناك مخاطر في:

• مجلد العمل.
• المكتبات المحلية.
• المتغيرات البيئية.
• الملفات المستخرجة.
• الأدوات الخارجية.
• مسارات البحث.
• العمليات السابقة في الجلسة.

المشكلة ليست دائماً:

What code is being executed?

بل أيضاً:

Where is it being executed?

و:

What can influence that execution?

#3. الملفات غير الموثوقة يجب أن تبقى بيانات وليست بيئة تنفيذ

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

لا ينبغي تشغيل أدوات أو مفسرات مباشرة من داخل مجلد يحتوي على محتوى غير موثوق قبل فحص:

• أسماء الملفات.
• الروابط الرمزية.
• الملفات التنفيذية.
• ملفات التهيئة.
• الوحدات التي قد تظلل مكتبات النظام.
• ملفات Dependency أو Startup.

#4. استخدام Sandboxing ليس خياراً تكميلياً

الرسالة الأهم في تجربة الباحث أن نظام الموافقات ليس بديلاً عن العزل.

حتى إذا كانت طبقة Auto Mode تمنع نسبة كبيرة من السلوكيات الخطرة، فإن أي خطأ واحد قد يؤدي إلى تنفيذ كود داخل البيئة الفعلية.

لذلك يجب أن يعمل الوكيل، قدر الإمكان، داخل بيئة:

• معزولة.
• محدودة الصلاحيات.
• قليلة الأسرار.
• منخفضة الوصول الشبكي.
• قابلة للإتلاف وإعادة الإنشاء.
• خاضعة للمراقبة.

#البعد المتعلق بالحوكمة والمخاطر والالتزام GRC

قضية Auto Mode لا تتعلق فقط بجودة نموذج ذكاء اصطناعي أو دقة مصنف أمني. من منظور GRC، هي قضية تفويض صلاحيات وفصل مسؤوليات وإدارة مخاطر طرف تقني قادر على اتخاذ قرارات مستقلة.

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

#ضوابط مقترحة

#لماذا "الموافقة الآلية" لا تساوي "الأمان"؟

من السهل الوقوع في افتراض أن الأمر الذي سمحت به طبقة Auto Mode أصبح آمناً بحكم السماح.

لكن السماح يعني فقط أن الإجراء لم يطابق معايير الحظر في تلك اللحظة.

وهذا يختلف جذرياً عن إثبات أن:

• الملف موثوق.
• البيئة سليمة.
• مسار التنفيذ غير متلاعب به.
• المكتبات أصلية.
• العملية لن تتسبب في أثر جانبي.
• الخطوات السابقة لم تغير سياق الأمان.

لذلك لا يجب استخدام قرار Auto Mode كدليل أمني على سلامة الكود أو المهمة.

#النموذج الأمني المطلوب لوكلاء البرمجة

يمكن تلخيص النموذج الأفضل في أربع طبقات مترابطة:

#الطبقة الأولى: تقليل الصلاحيات

يجب ألا يمتلك الوكيل أكثر مما يحتاج إليه.

Least Privilege

#الطبقة الثانية: عزل التنفيذ

تشغيل المهام غير الموثوقة داخل بيئات معزولة وقابلة للاستبدال.

Sandbox / Container / Disposable VM

#الطبقة الثالثة: مراقبة السلوك

تسجيل ومراجعة:

• أوامر Shell.
• العمليات الجديدة.
• الاتصالات الشبكية.
• تنزيل الملفات.
• تغييرات الملفات.
• محاولات الوصول إلى Secrets.

#الطبقة الرابعة: تقييم السلسلة وليس الأمر فقط

يجب تحليل المهمة كمسار كامل:

Input -> Fetch -> Download -> Extract -> Generate -> Execute -> Network

لأن الخطورة قد لا تظهر في أي خطوة منفردة، بل في العلاقة بينها.

[!research-note] وفق التقرير المنشور من الباحث، تم إبلاغ Anthropic بالنتائج، وأُغلق البلاغ بتصنيف "Informative". كما أكد الباحث أن Auto Mode يقلل المخاطر لكنه لا يلغي الحاجة إلى Sandboxing ومراقبة نشاط الوكيل.

#الخلاصة

تجربة Claude Code مع Auto Mode تقدم مثالاً واضحاً على التحدي الأمني القادم مع وكلاء الذكاء الاصطناعي: كلما زادت استقلالية الوكيل، أصبح من الضروري ألا تعتمد الحماية على "حسن قراره" فقط.

الهجوم لم يحتج إلى إجبار Claude Code على تجاهل تعليماته، ولم يعتمد على ملف تنفيذي واضح، ولم يطلب من النموذج تشغيل Malware بشكل مباشر.

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

وهذا يغير السؤال الأمني من:

هل يستطيع النموذج اكتشاف الأمر الخبيث؟

إلى سؤال أوسع وأكثر أهمية:

هل تستطيع المنظومة منع سلسلة من القرارات الطبيعية من التحول إلى مسار تنفيذ ضار؟

في بيئات الوكلاء، الإجابة لن تأتي من Auto Mode وحده، بل من الجمع بين العزل، وتقليل الصلاحيات، ومراقبة التنفيذ، وتصميم ضوابط تفهم سياق المهمة كاملة.