ثغرة خطيرة بـ Vertex AI SDK تمكن المهاجمين من اختطاف نماذج الذكاء الاصطناعي

مقدمة تحليلية

كشفت أبحاث حديثة أجرتها وحدة Unit 42 التابعة لشركة Palo Alto Networks عن ثغرة أمنية حرجة في حزمة تطوير البرامج (SDK) لـ Google Cloud Vertex AI لـ Python. سمحت هذه الثغرة، التي أطلق عليها اسم "Pickle in the Middle"، للمهاجمين باختطاف عمليات تحميل نماذج التعلم الآلي الخاصة بالمستخدمين وتشغيل تعليمات برمجية ضارة داخل البنية التحتية لـ Google السحابية. الأخطر من ذلك هو أن المهاجم لم يكن بحاجة إلى أي وصول مسبق لمشروع الضحية أو بيانات اعتماد، بل مجرد معرفة بمعرف المشروع (Project ID) الخاص بالضحية، والذي غالبًا ما يكون متاحًا للعامة. قامت جوجل بمعالجة هذه الثغرة، وينصح بشدة بالتحديث إلى الإصدار 1.148.0 أو ما بعده من SDK لضمان الحماية. تكمن خطورة هذه الثغرة في قدرتها على تجاوز آليات الأمان التقليدية، حيث أنها لا تعتمد على التصيد الاحتيالي أو استغلال نقاط ضعف في البنية التحتية للمستهدف بشكل مباشر. بدلاً من ذلك، استغلت الثغرة طريقة غير آمنة في تخصيص دلو التخزين السحابي المؤقت (Cloud Storage bucket) لعمليات تحميل النماذج، مما مكن المهاجمين من تنفيذ تقنية "Bucket Squatting" الخبيثة. هذا الاكتشاف يسلط الضوء على التحديات المتزايدة في تأمين بيئات الذكاء الاصطناعي السحابية المعقدة، ويؤكد على أهمية المراجعة المستمرة لآليات الأمان حتى في المكونات الأساسية مثل حزم SDK.

التحليل التقني

القلب النابض لثغرة "Pickle in the Middle" هو كيفية قيام حزمة Vertex AI SDK باختيار دلو Cloud Storage مؤقت لعمليات تحميل النماذج. في حال عدم قيام المستخدم بتحديد دلو تخزين صريح، كانت حزمة SDK تقوم بإنشاء اسم دلو يمكن التنبؤ به من معرف المشروع والمنطقة، مثل _project-vertex-staging-region_. كانت المشكلة أن حزمة SDK تتحقق مما إذا كان الدلو موجودًا بالفعل، ولكنها لم تتحقق مما إذا كان هذا الدلو مملوكًا للضحية أو أن الضحية لديه الأذونات الصحيحة عليه. نظرًا لأن أسماء الدلاء فريدة عالميًا عبر Google Cloud، كان بإمكان المهاجم إنشاء الدلو المتوقع أولاً في مشروعه الخاص. عندما يبدأ الضحية عملية تحميل النموذج، تقوم حزمة SDK الخاصة به بتحميل ملفات النموذج إلى دلو المهاجم. في هذه المرحلة، يمكن للمهاجم استبدال النموذج الشرعي بنموذج خبيث. العديد من نماذج التعلم الآلي المكتوبة بلغة Python يتم حفظها باستخدام صيغ مثل `pickle` أو `joblib`، والتي يمكنها تشغيل تعليمات برمجية عند تحميل الملفات. عندما يقوم Vertex AI بتحميل النموذج المستبدل لاحقًا، يتم تنفيذ الكود الضار داخل حاوية الخدمة (serving container). كان الهجوم يعتمد على عامل السرعة؛ إذ قدرت Unit 42 المدة الزمنية بين تحميل الضحية للنموذج وقراءة Vertex AI للملف بحوالي 2.5 ثانية. في دليل المفهوم (proof of concept) الخاص بهم، استخدم المهاجم دالة سحابية (Cloud Function) يتم تشغيلها بعد التحميل واستبدلت النموذج في غضون 1.4 ثانية، قبل أن يقرأه Vertex AI. تضمنت الحمولة الخبيثة سرقة رمز OAuth مميز (OAuth token) من خادم بيانات التعريف للحاوية وإرساله إلى المهاجم. في بيئة اختبار Unit 42، لم يكن هذا الرمز المميز مقتصرًا على النشر المخترق، بل كان بإمكانه الوصول إلى عناصر نموذجية أخرى في نفس مشروع المستأجر (tenant project) المُدار من قبل جوجل، بما في ذلك نموذج TensorFlow كامل بأوزان تدريبية، بالإضافة إلى بيانات وصفية لـ BigQuery، وقوائم وصول، وسجلات المستأجر، وأسماء مجموعات GKE، ومسارات صور الحاويات الداخلية. * **الثغرات المكتشفة:** * `Pickle in the Middle` (لا يوجد CVE رسمي حتى الآن). * `CVE-2026-2473` (ثغرة سابقة في Vertex AI Experiments لمعالجة Bucket Squatting). * **الإصدارات المتأثرة:** * Vertex AI SDK for Python v1.139.0 و v1.140.0. * **الإصدارات التي تتضمن الإصلاح:** * v1.144.0 (إصلاح مبدئي بإضافة uuid4 عشوائي لاسم الدلو). * v1.148.0 (إصلاح كامل بإضافة التحقق من ملكية الدلو `bucket ownership verification`).

السياق وتأثير السوق

لا تعد ثغرة "Pickle in the Middle" حادثًا معزولاً في Vertex AI؛ ففي الواقع، هي ثاني ثغرة تتعلق بأسماء الدلاء التي يمكن التنبؤ بها تظهر في Vertex AI هذا العام. سبقتها ثغرة `CVE-2026-2473` في فبراير، والتي كانت أيضًا تتضمن تقنية "Bucket Squatting" في Vertex AI Experiments وسمحت بتنفيذ تعليمات برمجية عبر المستأجرين وسرقة النماذج وتسميمها. هذا النمط المتكرر من الثغرات في نفس المنتج يشير إلى تحديات عميقة في تصميم واجهات برمجة التطبيقات الافتراضية وكيفية تعاملها مع الموارد السحابية. يُظهر اكتشاف Unit 42 لمعرفات مشاريع Google Cloud `project IDs` - وهي معلومات غالبًا ما تكون عامة - كعنصر كافٍ لتنفيذ الهجوم، نقطة ضعف حرجة في افتراضات الأمان. في بيئة سحابية حيث تتزايد تعقيدات الخدمات والتكاملات، يجب أن تكون الإعدادات الافتراضية آمنة قدر الإمكان (secure by default) لتجنب مثل هذه الهجمات التي لا تتطلب بيانات اعتماد. يعزز هذا الحادث ضرورة التفكير في الأمان من منظور المهاجم، وعدم الاكتفاء بالتحقق من الوجود، بل التأكد من الملكية والأذونات الصحيحة. تأثير السوق لهذه الثغرات يمتد إلى ثقة المطورين والشركات التي تعتمد على منصات الذكاء الاصطناعي السحابية. فمع تزايد استخدام نماذج التعلم الآلي في التطبيقات الحساسة، يصبح أمان هذه النماذج وبياناتها أمرًا حيويًا. يمكن أن يؤدي اختطاف النماذج أو تسميمها إلى عواقب وخيمة، تتراوح من تسرب البيانات الحساسة إلى اتخاذ قرارات خاطئة بناءً على نماذج معدلة. يسلط هذا الحدث الضوء على الدور المحوري لبرامج مكافآت الثغرات (bug bounty programs) في تعزيز أمان المنتجات التقنية الكبرى، حيث ساهمت Unit 42 بشكل فعال في اكتشاف الثغرة والإبلاغ عنها لجوجل.

رؤية Glitch4Techs

من وجهة نظر Glitch4Techs، تُظهر ثغرة "Pickle in the Middle" تحديًا أمنيًا متناميًا في التقاء الذكاء الاصطناعي والبنية التحتية السحابية. على الرغم من أن جوجل قد قدمت إصلاحًا، فإن حقيقة أن هذه الثغرة تعيش في حزمة SDK على جانب العميل (client-side SDK) تعني أن المستخدمين يتحملون مسؤولية التحديث. هذا يمثل نقطة ضعف محتملة؛ فليست جميع المشاريع أو بيئات التطوير يتم تحديثها بانتظام، مما يترك مساحة كبيرة للمشاريع القديمة أو المهملة عرضة للاستغلال. نوصي جميع مستخدمي Vertex AI بالتحقق من إصدار `google-cloud-aiplatform` في جميع بيئاتهم، بما في ذلك الدفاتر (notebooks)، ووظائف CI، وخطوط أنابيب التدريب، وليس فقط خدمات الإنتاج. علاوة على ذلك، فإن نطاق رمز OAuth المميز الذي تم سرقته في دليل المفهوم، والذي لم يكن مقتصرًا على النشر المخترق ويمكنه الوصول إلى بيانات تعريف BigQuery وسجلات المستأجر وأسماء مجموعات GKE ومسارات صور الحاويات الداخلية، يثير مخاوف جدية بشأن مبدأ الامتياز الأقل (least privilege) في البيئات السحابية. يجب على المطورين والمهندسين أن يكونوا حذرين للغاية بشأن الأذونات الممنوحة لحسابات الخدمة والرموز المميزة، وتطبيق قيود صارمة لضمان أن أي اختراق محدود لا يؤدي إلى تسرب أوسع. نحن نتوقع رؤية المزيد من الثغرات المشابهة مع تزايد تعقيد منصات الذكاء الاصطناعي وتكاملها العميق مع الخدمات السحابية الأخرى. الحل لا يكمن فقط في إصلاح الثغرات الفردية، بل في إعادة التفكير في تصميم الأمان الافتراضي وتعزيز الوعي الأمني لدى المطورين الذين يعتمدون على هذه الأدوات.