أجرت Wiz Research سلسلة من التحقيقات حول مقدمي خدمات الذكاء الاصطناعي الرائدين في الأشهر الأخيرة. وفي سياق هذا العمل، اكتشفنا نقاط الضعف الحرجة التي كان من الممكن أن تؤدي إلى تسرب الملايين من نماذج وتطبيقات الذكاء الاصطناعي الخاصة. تم تنفيذ الجزء الأول من هذه السلسلة بالشراكة مع فريق Hugging Face. الآن، في هذه الدفعة الثانية، سنقوم بتفصيل ثغرة أمنية في منصة Replicate AI.
ما اكتشفناه مع Replicate يثبت صحة فرضية الذكاء الاصطناعي لدينا: تحديات فصل المستأجرين تنتقل إلى مقدمي خدمات الذكاء الاصطناعي كخدمة وتتطلب فحصًا دقيقًا نظرًا للنمو الهائل لهذه الخدمات وقرب انتشارها في كل مكان. كان من الممكن أن يسمح استغلال هذه الثغرة الأمنية بالوصول غير المصرح به إلى مطالبات الذكاء الاصطناعي ونتائج جميع عملاء منصة Replicate.
كشفت شركة Wiz Research بشكل مسؤول عن هذه الثغرة الأمنية لـ Replicate في يناير 2024، وكان من الواضح على الفور مدى جديتها في التعامل مع الأمور الأمنية. لا يمكننا المبالغة في مدى جودة تواصل Replicate مع فريقنا ومدى سرعة تصرفهم لإصلاح المشكلة، والتي تم تخفيفها على الفور. لم يتم اختراق أي بيانات للعملاء، ولا يلزم العملاء اتخاذ أي إجراء.
Replicate.com وهي عبارة عن منصة تتيح المشاركة والتفاعل مع نماذج الذكاء الاصطناعي؛ شعار الشركة هو “نشر نماذج مخصصة على نطاق واسع، كل ذلك باستخدام سطر واحد من التعليمات البرمجية”. يمكن للمستخدمين تصفح النماذج الموجودة على المركز، وتحميل النماذج الخاصة بهم وضبطها لحالات الاستخدام الخاصة بهم. يوفر Replicate أيضًا لعملائه القدرة على استضافة نماذج خاصة ويوفر بنية أساسية للاستدلال مع واجهة برمجة تطبيقات ملائمة.
كما لدينا مكتوبة سابقاتمثل نماذج الذكاء الاصطناعي الضارة خطرًا كبيرًا على أنظمة الذكاء الاصطناعي، وخاصةً لمقدمي الذكاء الاصطناعي كخدمة. نظرًا لأن نماذج الذكاء الاصطناعي غالبًا ما يتم تجميعها بتنسيقات تسمح بتنفيذ تعليمات برمجية عشوائية، فيمكن للمهاجمين الاستفادة من هذه النماذج لتنفيذ هجمات عبر المستأجرين.
لتمكين الاستدلال السهل لنماذج الذكاء الاصطناعي على نظامها الأساسي، تستخدم Replicate التنسيق الخاص بها لحاويات النماذج المسماة ترس. يساعد Cog المستخدمين على تخزين نماذج الذكاء الاصطناعي الخاصة بهم، وتضمين التبعيات والمكتبات الصحيحة، وتجميع خادم RESTful HTTP API لسهولة الاستدلال. وفي نهاية العملية، يتم إنتاج صورة الحاوية. بعد وضع نموذج في حاوية باستخدام Cog، يمكن للمستخدمين تحميل الصورة الناتجة إلى منصة Replicate وبدء التفاعل معها.
لقد أنشأنا حاوية Cog الضارة الخاصة بنا وقمنا بتحميلها على منصة Replicate. بعد ذلك، باستخدام واجهة Replicate، تفاعلنا مع الحاوية لتحقيق تنفيذ التعليمات البرمجية عن بعد على البنية التحتية لـ Replicate.
نشك في أن تقنية تنفيذ التعليمات البرمجية هذه عبارة عن نمط، حيث تقوم الشركات والمؤسسات بتشغيل نماذج الذكاء الاصطناعي من مصادر غير موثوقة، على الرغم من أن هذه النماذج عبارة عن تعليمات برمجية قد تكون ضارة. لقد استخدمنا نفس التقنية في بحثنا السابق حول أمان الذكاء الاصطناعي مع Hugging Face ووجدنا أنه من الممكن تحميل نموذج ذكاء اصطناعي ضار إلى خدمة استدلال الذكاء الاصطناعي المُدارة ثم تسهيل الحركة الجانبية داخل البنية التحتية الداخلية الخاصة بهم.
بعد الحصول على تنفيذ التعليمات البرمجية عن بعد كـ root داخل الحاوية الخاصة بنا على البنية التحتية لـ Replicate، بدأنا في استكشاف البيئة. لقد لاحظنا بسرعة أننا كنا نعمل ضمن حجرة داخل مجموعة Kubernetes المستضافة على Google Cloud Platform. لم تكن الكبسولة التي كنا نعمل فيها كبسولة مميزة، لذلك لم نتمكن من الهروب بسهولة إلى العقدة. علاوة على ذلك، لم يكن لدى حجرتنا أيضًا حساب خدمة Kubernetes مرتبط بها، لذلك لم نتمكن من التواصل مع خادم Kubernetes API.
بدأنا التحقيق في الشبكة. باستخدام netstat لاحظنا وجود اتصال TCP تم إنشاؤه بالفعل ويتم التعامل معه من خلال عملية كانت تعمل في مساحة اسم PID مختلفة. هذا جعلنا نستنتج أننا شاركنا مساحة اسم شبكتنا مع حاوية أخرى، ولكن ليس مساحة اسم PID.
هذه الظاهرة شائعة جدا. في بيئات Kubernetes، تشترك الحاويات المختلفة داخل نفس الحجرة في نفس الشبكة. نظرًا لأن فرق التطوير لا تدرك ذلك غالبًا، فقد يؤدي ذلك إلى إضعاف أمان عزل الحاويات والسماح للمهاجم الذي تمكن من الوصول إلى حاوية واحدة بشن هجمات شبكية على حاويات أخرى داخل نفس الحاوية. لقد رأينا هذا النمط من قبل، وقمنا بإنشاء تمرين محدد حول هذه المشكلة في أحدث Kubernetes CTF (حزب K8s LAN).
كما كنا نركض مع root الامتيازات وكانت قادر ل CAP_NET_RAW و CAP_NET_ADMIN، يمكننا أن نستخدم tcpdump لفحص محتويات اتصال TCP هذا. بالنظر إلى محتوى الدفق، أدركنا أنه كان نصًا عاديًا ريديس البروتوكول (مخزن بيانات شائع ومفتوح المصدر داخل الذاكرة). من خلال إجراء بحث عكسي عن DNS على عنوان IP، أكد اسم المضيف الخاص به أنه كان بالفعل مثيل Redis.
في هذه المرحلة كنا نحاول فهم الغرض من خادم Redis هذا. من خلال فحص دفق النص العادي، فهمنا أن مثيل Redis هذا يقوم بتشغيل قائمة انتظار من نوع ما، وكنا نتساءل – هل يخدم حسابنا فقط؟ أو هل يشترك عملاء Replicate الآخرون في نفس قائمة الانتظار؟
بعد مزيد من الاستكشاف للبيئة، أدركنا أنه من المحتمل أن يخدم مثيل Redis العديد من العملاء، مما يجعله هدفًا مثيرًا للاهتمام لهجوم الوصول إلى البيانات بين المستأجرين. إذا تمكنا من الوصول إلى المعلومات أو تعديلها داخل قائمة الانتظار هذه، فيجب أن نكون قادرين على التأثير على توقعات العملاء الآخرين الذين يستخدمون المنصة – ربما يمكننا التشكيك في نماذجهم الخاصة أو حتى التدخل في طلباتهم.
لقد حاولنا بدء اتصال جديد بخادم Redis باستخدام ملف redis-cli، ولكن الخادم يتطلب بيانات اعتماد للمصادقة. لم نتمكن من العثور على بيانات الاعتماد هذه في أي مكان داخل حجرتنا. ومع ذلك، كان لدينا بالفعل جلسة نشطة تمت مصادقتها بنص عادي ضمن مساحة اسم شبكتنا، وكانت لدينا جميع إمكانيات الشبكة. ماذا لو قمنا بحقن حزم عشوائية في الاتصال المصادق عليه الحالي للحاوية المجاورة لنا؟
استخدمنا rshijack (أداة مساعدة لحقن TCP) لإدخال حزم عشوائية في اتصال TCP الحالي بخادم Redis الخاص بالحاوية المجاورة لنا من أجل تجاوز المصادقة. لقد نجحت! لقد أجرينا مزيدًا من الاستطلاع على خادم Redis وخلصنا إلى أنه يتم استخدامه كقائمة انتظار لإدارة طلبات العملاء واستجاباتهم، وأنه يخدم العديد من العملاء (وليس نحن فقط).
لغرض إثبات الوصول إلى بيانات المستأجرين الآخرين للعملاء الآخرين، كانت خطتنا هي استخدام حقن TCP الخاص بنا لتعديل عنصر داخل قائمة الانتظار ينتمي إلى حساب آخر خاص بنا. ومع ذلك، منذ أن تمت إدارة قائمة الانتظار في تدفقات ريديس، وهو إلحاق فقط، ثبت أن تعديل عنصر موجود في قائمة الانتظار يمثل تحديًا كبيرًا.
التداخل مع مطالبات العميل يحتوي العنصر الذي يمثل طلبًا من عميل في قائمة انتظار Redis على بعض الحقول المثيرة للاهتمام:
-
المعرفات المتعلقة بالنموذج المستخدم.
-
الإدخال الذي قدمه المستخدم (الموجه).
-
بعض البيانات الوصفية المتعلقة بالمستخدم الذي طلب التنبؤ.
-
أ
webhookمجال. عندما يكون هناك تحديث بخصوص التوقع، فإن العنوان الموجود فيwebhookيتم إخطار الحقل.
نظرًا لأننا لم نتمكن من تعديل العناصر الموجودة في قائمة الانتظار، فقد انتهى بنا الأمر باستخدام حقن TCP الخاص بنا لإدخال برنامج Lua النصي الذي قام بما يلي:
-
تم العثور على العنصر الذي نريد تعديله في قائمة الانتظار.
-
برزت من قائمة الانتظار.
-
تم تعديلها
webhookالحقل ليكون عنوان خادم واجهة برمجة التطبيقات المارقة الخاضع لسيطرتنا. -
تم دفع العنصر المعدل مرة أخرى إلى قائمة الانتظار.
كنا قلقين من أن الخادم الذي يعالج العناصر الموجودة في قائمة الانتظار لن يتمكن من التواصل مع حجرة العامل لدينا، لذلك قررنا استضافة خادم API المارق الخاص بنا على الإنترنت وتوجيه حركة المرور الخاصة به مرة أخرى داخل حجرة العامل لدينا.
بعد إدخال برنامج Lua النصي الخاص بنا في اتصال TCP، تلقى خادم واجهة برمجة التطبيقات (API) الخاص بنا طلب HTTP مع إدخال التنبؤ، وآخر مع إخراج التنبؤ. لقد أثبتنا أيضًا أن خادمنا المارق يمكنه تعديل تنبؤات الإخراج.
كان استغلال هذه الثغرة الأمنية سيشكل مخاطر كبيرة على كل من منصة Replicate ومستخدميها. من الممكن أن يقوم أحد المهاجمين بالاستعلام عن نماذج الذكاء الاصطناعي الخاصة بالعملاء، مما قد يؤدي إلى كشف المعرفة الخاصة أو البيانات الحساسة المشاركة في عملية التدريب على النماذج. بالإضافة إلى ذلك، قد يؤدي اعتراض المطالبات إلى كشف بيانات حساسة، بما في ذلك معلومات التعريف الشخصية (PII).
تشكل القدرة على تغيير المطالبات والاستجابات تهديدًا خطيرًا لوظائف تطبيقات الذكاء الاصطناعي. فهو يمنح المهاجمين طريقة للتلاعب بسلوك الذكاء الاصطناعي والإضرار بعمليات صنع القرار في هذه النماذج. تهدد مثل هذه الإجراءات بشكل مباشر دقة وموثوقية المخرجات المعتمدة على الذكاء الاصطناعي، مما يقوض سلامة القرارات الآلية وربما يكون له عواقب بعيدة المدى على المستخدمين الذين يعتمدون على النماذج المخترقة.
يركز فريق بحث Wiz بشكل كبير على ثغرات العزل في البيئات السحابية. عندما رأينا ظهور شركات الذكاء الاصطناعي كخدمة، كنا قلقين بشأن الآثار المحتملة لجهة فاعلة ضارة تستغلها للحصول على امتيازات الوصول بين المستأجرين، نظرًا لأن نماذج الذكاء الاصطناعي في الممارسة العملية هي في الواقع تعليمات برمجية.
تمثل النماذج الضارة خطرًا كبيرًا على أنظمة الذكاء الاصطناعي، خاصة لمقدمي خدمات الذكاء الاصطناعي كخدمة لأن المهاجمين قد يستفيدون من هذه النماذج لتنفيذ هجمات بين المستأجرين. التأثير المحتمل مدمر، حيث قد يتمكن المهاجمون من الوصول إلى الملايين من نماذج وتطبيقات الذكاء الاصطناعي الخاصة المخزنة لدى موفري الذكاء الاصطناعي كخدمة.
يسلط هذا البحث أيضًا الضوء على قيمة التعاون بين الباحثين الأمنيين ومطوري المنصات. يساعد هذا النوع من التعاون في الحصول على فهم أعمق للمخاطر المرتبطة بالمنصة يعزز في نهاية المطاف لها الوضع الأمني.
وبما أن المشكلة التي كشفناها في هذا البحث هي في نهاية المطاف قضية معزولة، فإننا نعتقد أن هذه فرصة عظيمة لذكرها خَوخ. PEACH هو إطار عمل خطوة بخطوة قمنا بتطويره لنمذجة وتحسين عزل مستأجر SaaS وPaaS. سواء كنت أحد عملاء السحابة أو مطور تطبيقات السحابة، فإن PEACH يسهل عليك فهم كيفية تأمين التطبيقات متعددة المستأجرين في السحابة.
لقد كشفنا بشكل مسؤول عن هذه المشكلة لـ Replicate في يناير 2024. وقد قامت Replicate بالتحقيق فيها ومعالجتها على الفور من خلال تنفيذ إجراءات تخفيف جديدة. لقد نشروا أيضًا منشورًا غنيًا بالمعلومات حول هذه المشكلة نفسها.
طوال عملية الكشف، لم تُظهر Replicate التزامًا عميقًا بالحفاظ على أمان منتجاتها فحسب، بل دعمت أيضًا أعلى معايير الاتصال والشفافية. في عمل الكشف الذي قمنا به مع العديد من المنظمات الخارجية، نادرًا ما واجه فريق Wiz Research مثل هذه الاحترافية والخبرة. مجد لفريق Replicate بأكمله لوضع مثل هذا المستوى العالي! ونشيد بتعاونكم واستجابتكم. أنت تمثل قدوة للجميع.
