عيب خطير في جوجل Dialogflow CX كان من الممكن أن يسمح لمهاجم يتمتع بحقوق التحرير على وكيل واحد ممكّن لـ Code Block باختراق الوكلاء الآخرين الممكّنين لـ Code Block في نفس مشروع Google Cloud.
ومن هناك، يمكنهم قراءة المحادثات المباشرة، وسرقة البيانات التي شاركها المستخدمون، وجعل الروبوتات ترسل رسائل مكتوبة من قبل المهاجم، بما في ذلك طلبات إعادة إدخال كلمة المرور.
وجدته شركة الأمن Varonis وأطلقت عليه اسم Rogue Agent. لم يؤثر الخلل إلا على المؤسسات التي قامت ببناء وكلاء باستخدام Playbooks الخاص بـ Dialogflow وكتل التعليمات البرمجية المخصصة، والتي تتيح للمطورين إضافة لغة Python الخاصة بهم. ولم يكن هجومًا بعيدًا وغير مصادق عليه.
يتطلب تنفيذه الحصول على إذن Diagramflow.playbooks.update من أحد هذه الوكلاء، مما يجعل المهاجم الواقعي مقتصرًا على شخص خبيث من الداخل أو حساب مطور مخترق، وليس شخصًا غريبًا على الإنترنت. ومن هذا الموطئ، امتد نطاق الوصول إلى كل وكيل في المشروع.
قامت Google بإصلاحه، ويقول كل من Varonis وGoogle إنه لا يوجد ما يشير إلى أن الخلل قد تم استخدامه في هجوم حقيقي.
قام ملف واحد قابل للكتابة بتشغيل كتل التعليمات البرمجية الخاصة بكل وكيل
تسمح كتل التعليمات البرمجية الخاصة بـ Dialogflow للمطورين بإضافة Python مخصص إلى تدفق محادثة chatbot للتحقق من المدخلات والتحكم في السلوك واستدعاء الأدوات المحددة. يتم تشغيل هذا الرمز في بيئة Cloud Run التي تديرها Google، ويشارك كل وكيل يستخدم Code Blocks في نفس مشروع Google Cloud مثيلًا واحدًا منه.
تدير جوجل تلك البيئة، ولا يستطيع العميل رؤيتها أو التحكم فيها، ولم يجد فارونيس أي عزلة حقيقية بين العملاء بداخلها.
عندما يقوم الوكيل بتشغيل Code Block، يتم إلحاق كود المطور بكود الإعداد الداخلي وتمريره إلى وظيفة exec() الخاصة بـ Python. يحدد رمز الإعداد هذا المتغيرات والوظائف التي يمكن للكتلة لمسها. تتضمن المتغيرات سجل المحادثة الكاملة وحالة تفاصيل الجلسة مثل معرف الجلسة. تشمل الوظائف Response()، مما يجعل الروبوت يرد بسلسلة معينة.
عثر فارونيس على الملف الذي يقوم بهذا الالتفاف، code_execution_env.py، الموجود في البيئة المشتركة مع إمكانية الوصول للكتابة.
ونظرًا لأن هذا الملف كان قابلاً للكتابة، فيمكن أن تحل محله كتلة تعليمات برمجية واحدة. تقوم هذه الكتلة بتنزيل code_execution_env.py المعدل من خادم يتحكم فيه المهاجم وتستبدل الملف الأصلي داخل الحاوية قيد التشغيل.
منذ ذلك الحين، يتم تشغيل إصدار المهاجم لكل عملية تنفيذ لـ Code Block عبر كل وكيل يشارك تلك البيئة. إنه موجود في نفس نطاق التعليمات البرمجية الشرعية، مع نفس الوصول إلى السجل والحالة والاستجابة ().
يتيح ذلك له قراءة كل محادثة، وإرسالها بهدوء إلى خادم المهاجم، وجعل الروبوت ينشر رسائل مكتوبة من قبل المهاجم. أحد الأمثلة على ذلك هو التصيد الاحتيالي: يطلب الروبوت من المستخدم إعادة التحقق من تسجيل الدخول، ويقوم المهاجم بجمع كل ما يكتبه.
ولتغطية المسارات، يقوم المهاجم باستعادة Code Block الأصلي في وحدة التحكم Dialogflow. وهذا يغير فقط ما تعرضه وحدة التحكم؛ الملف المكتوب قيد التشغيل بالفعل في الحاوية ويستمر في التنفيذ تحته.
تسرب صندوق الرمل بطريقتين أخريين
أبلغ Varonis عن مشكلتين مرتبطتين، ولم يحتاج أي منهما إلى الكتابة فوق الملف. أولاً، تتمتع بيئة Code Block بوصول غير مقيد إلى الإنترنت. باستخدام مكتبة urllib المدمجة، أرسل الباحثون البيانات مباشرة إلى خادم خارجي ويمكنهم تلقي الأوامر مرة أخرى.
يقول فارونيس إن هذا يتجاوز ضوابط خدمة VPC، وهو محيط Google Cloud الذي يهدف إلى منع البيانات من مغادرة الخدمات المحمية. تقع البيئة خارج هذا المحيط ويمكنها الوصول إلى الإنترنت المفتوح، مما يحولها إلى قناة لسرقة البيانات والتحكم عن بعد.
ثانيًا، والأقل خطورة، كشفت البيئة عن خدمة البيانات الوصفية (IMDS)، وهي نقطة نهاية داخلية عادةً تقوم بتوزيع بيانات الاعتماد السحابية. أدى الاستعلام عن ذلك إلى إرجاع رمز مميز لحساب خدمة تديره Google.
وكان هذا الحساب منخفض الامتياز، وبالتالي كانت المخاطر المباشرة محدودة؛ النقطة الحقيقية هي أن صندوق حماية تنفيذ التعليمات البرمجية لا ينبغي أن يكون قادرًا على الوصول إلى IMDS على الإطلاق.
لم يصل أي شيء تقريبًا إلى السجلات
حدثت عملية الاستبدال داخل بيئة Google، حيث لا يتمتع العملاء بإمكانية الرؤية، ولم يسجل التسجيل السحابي تغيير الملف أو الكود الذي تم إدخاله.
وهذا يجعل من الصعب، وإن لم يكن من المستحيل، اللحاق من جانب العميل. لا تزال إجراءات الإعداد تترك آثارًا، وهو ما تعتمد عليه عمليات التحقق أدناه.
كشف فارونيس عن الخلل من خلال برنامج مكافآت الثغرات الأمنية التابع لشركة Google في نوفمبر 2025. وشحنت Google إصلاحًا أوليًا في أبريل 2026 وحلته بالكامل في يونيو 2026، أي حوالي سبعة أشهر من التقرير إلى الحل. لم يتم تعيين CVE.
ما يجب التحقق منه إذا كنت تستخدم Code Blocks
إذا قمت بتشغيل وكلاء Dialogflow CX باستخدام Code Block Playbooks قبل الإصلاح وتريد التأكد من أنك غير مستهدف، فابدأ بالوصول.
يعد إذن Diagramflow.playbooks.update هو نقطة الإدخال بأكملها، لذا قم بمراجعة الأدوار والحسابات التي تحتفظ بها.
ثم:
- قم بمراجعة سجلات تدقيق DATA_WRITE الخاصة بك لـ Dialogflow API للحصول على تحديثات قواعد اللعبة غير المتوقعة، وربطها بالمستخدمين غير المعتادين، أو عناوين IP، أو أوقات الوصول.
- قم بتشغيل استعلام Cloud Logging لطلبات المستخدم الفاشلة، حيث يمكن أن تكشف رسائل الخطأ عن الاستثناءات التي تم طرحها بواسطة كتل التعليمات البرمجية الضارة.
- في وحدة تحكم Dialogflow، افتح Playbooks لكل وكيل وتأكد من أن كل Code Block هو الذي وافقت عليه.
نوع مختلف من عيوب الذكاء الاصطناعي
لقد نجحت العديد من العيوب الأمنية الحديثة في الذكاء الاصطناعي عن طريق خداع النموذج.
حولت Reprompt وSearchLeak الخاصة بشركة Varonis نقرة واحدة إلى سرقة البيانات في برنامج Copilot من Microsoft. قام ForcedLeak من Noma Security بإخفاء التعليمات في نموذج ويب Salesforce لسحب بيانات إدارة علاقات العملاء (CRM).
أظهر باحثو Microsoft أن الحقن الفوري يتحول إلى تنفيذ التعليمات البرمجية في إطار عمل Semantic Kernel. لم يلمس Rogue Agent النموذج على الإطلاق. لقد أساء استخدام ميزة عادية للمطورين ووقت تشغيل مشترك وغير مرئي يمكن الوصول إليه بإذن تعديل عادي واحد.
في إعداد مثل هذا، فإن الإذن الذي يبدو وكأنه حق تحرير المحتوى هو في الواقع حق تنفيذ التعليمات البرمجية. يمكن لأي شخص يمكنه إضافة Code Block تشغيل Python بشكل عشوائي داخل بيئة مشتركة لا يستطيع العميل فحصها.
تعامل مع أذونات تحرير الوكيل باعتبارها عناصر التحكم في وقت التشغيل. حتى عندما يقول الموفر أنه لا يوجد شيء يحتاج إلى إصلاح، لا يزال العملاء ليس لديهم طريقة للنظر داخل وقت التشغيل هذا بأنفسهم.
