على مدار الأشهر الماضية، أجرينا في فريق أبحاث Wiz أبحاثًا موسعة لعزل المستأجرين على العديد من موفري خدمات الذكاء الاصطناعي. نعتقد أن هذه الخدمات أكثر عرضة لنقاط الضعف في عزل المستأجر، لأنها بحكم تعريفها تسمح للمستخدمين بتشغيل نماذج وتطبيقات الذكاء الاصطناعي – وهو ما يعادل تنفيذ تعليمات برمجية عشوائية. نظرًا لأن البنية التحتية للذكاء الاصطناعي أصبحت بسرعة عنصرًا أساسيًا في العديد من بيئات الأعمال، فإن الآثار المترتبة على هذه الهجمات أصبحت أكثر أهمية.
سنعرض النتائج التي توصلنا إليها من هذا المشروع البحثي في مؤتمر Black Hat القادم، في جلستنا “عزلة أم هلوسة؟ اختراق موفري البنية التحتية للذكاء الاصطناعي من أجل المتعة والأوزان“.
بالنسبة للجزء الأخير من هذا المشروع، قمنا بالبحث في عرض الذكاء الاصطناعي من SAP، والذي يحمل اسم “SAP AI Core”. هذا هو تقريرنا الثالث في السلسلة، بعد بحثنا حول تعانق الوجه و تكرار المنصات. سوف تستكشف هذه المدونة سلسلة الثغرات الأمنية وتفصل النتائج التي توصلنا إليها، والتي يطلق عليها اسم “SAPwned”، بينما تبحث أيضًا في التأثير المحتمل والوجبات السريعة الأوسع لتأمين منصات الذكاء الاصطناعي المُدارة.
تتطلب عملية التدريب على الذكاء الاصطناعي الوصول إلى كميات هائلة من بيانات العملاء الحساسة، مما يحول خدمات التدريب على الذكاء الاصطناعي إلى أهداف جذابة للمهاجمين. يوفر SAP AI Core عمليات تكامل مع HANA والخدمات السحابية الأخرى للوصول إلى البيانات الداخلية للعملاء عبر مفاتيح الوصول السحابية. تعتبر بيانات الاعتماد هذه حساسة للغاية، وكان هدف بحثنا هو تحديد ما إذا كان بإمكان الجهات الفاعلة الضارة المحتملة الوصول إلى أسرار العملاء هذه.
بدأ بحثنا في SAP AI Core من خلال تنفيذ إجراءات تدريب مشروعة على الذكاء الاصطناعي باستخدام البنية التحتية لـ SAP. ومن خلال تنفيذ تعليمات برمجية عشوائية، تمكنا من التحرك أفقيًا وتولي الخدمة – وتمكنا من الوصول إلى الملفات الخاصة للعملاء، إلى جانب بيانات الاعتماد للبيئات السحابية للعملاء: AWS، وAzure، وSAP HANA Cloud، والمزيد. من الممكن أن تكون الثغرات الأمنية التي وجدناها قد سمحت للمهاجمين بالوصول إلى بيانات العملاء وتلويث العناصر الداخلية – والانتشار إلى الخدمات ذات الصلة وبيئات العملاء الأخرى.
على وجه التحديد، سمح لنا الوصول الذي حصلنا عليه بما يلي:
-
قراءة وتعديل صور Docker في سجل الحاوية الداخلي لـ SAP
-
قم بقراءة وتعديل صور SAP’s Docker على Google Container Registry
-
قراءة وتعديل القطع الأثرية على خادم Artifactory الداخلي لـ SAP
-
احصل على امتيازات مسؤول المجموعة على مجموعة Kubernetes الخاصة بـ SAP AI Core
-
يمكنك الوصول إلى بيانات الاعتماد السحابية للعملاء وأدوات الذكاء الاصطناعي الخاصة
كان السبب الجذري لهذه المشكلات هو قدرة المهاجمين على تشغيل نماذج الذكاء الاصطناعي الضارة وإجراءات التدريب، والتي هي في الأساس تعليمات برمجية. بعد مراجعة العديد من خدمات الذكاء الاصطناعي الرائدة، نعتقد أنه يجب على الصناعة تحسين معايير العزل ووضع الحماية عند تشغيل نماذج الذكاء الاصطناعي.
تم الإبلاغ عن جميع نقاط الضعف إلى فريق الأمان في SAP وتم إصلاحها بواسطة SAP، كما تم الاعتراف بذلك على موقعهم على الانترنت. ونشكرهم على تعاونهم. لم يتم اختراق أي بيانات العملاء.
فيما يلي نظرة فنية على سلسلة نقاط الضعف والنتائج التي توصلنا إليها.
SAP AI Core هي خدمة تتيح للمستخدمين تطوير خدمات الذكاء الاصطناعي وتدريبها وتشغيلها بطريقة قابلة للتطوير وإدارتها، باستخدام الموارد السحابية الهائلة لشركة SAP. كما هو الحال مع موفري الخدمات السحابية الآخرين (وموفري البنية التحتية للذكاء الاصطناعي)، يتم تشغيل التعليمات البرمجية الخاصة بالعميل ضمن بيئة SAP المشتركة – مما يشكل خطر الوصول عبر المستأجرين.
بدأ بحثنا كعميل SAP، مع أذونات أساسية تسمح لنا بإنشاء مشاريع الذكاء الاصطناعي. لذلك، بدأنا بإنشاء تطبيق ذكاء اصطناعي عادي على SAP AI Core. لقد أتاحت لنا منصة SAP توفير ملف Argo Workflow، والذي أدى بدوره إلى إنتاج Kubernetes Pod جديد وفقًا للتكوين الذي قمنا به.
سمح لنا هذا بتشغيل التعليمات البرمجية التعسفية الخاصة بنا داخل Pod حسب التصميم – دون الحاجة إلى وجود ثغرة أمنية. ومع ذلك، كانت بيئتنا مقيدة تمامًا. لقد أدركنا بسرعة أن جهاز Pod الخاص بنا يتمتع بإمكانية وصول محدودة للغاية إلى الشبكة، كما تم فرضه بواسطة وكيل Istio الجانبي – لذلك لم يكن فحص الشبكة الداخلية خيارًا بالنسبة لنا. حتى الآن.
الخطأ رقم 1: تجاوز قيود الشبكة بقوة 1337
أول شيء حاولناه هو تهيئة الكبسولة الخاصة بنا بامتيازات “مثيرة للاهتمام”. ومع ذلك، قامت وحدة التحكم بالقبول في SAP بحظر جميع خيارات الأمان الخطيرة التي جربناها – على سبيل المثال، تشغيل الحاوية الخاصة بنا كـ root.
وعلى الرغم من ذلك، وجدنا تكوينين مثيرين للاهتمام فشلت وحدة التحكم في القبول في حظرهما.
الأول هو shareProcessNamespace، مما سمح لنا بمشاركة مساحة اسم العملية مع الحاوية الجانبية الخاصة بنا. نظرًا لأن الجهاز الجانبي الخاص بنا كان وكيل Istio، فقد تمكنا من الوصول إلى تكوين Istio، بما في ذلك رمز الوصول إلى خادم Istio المركزي للمجموعة.
والآخر هو runAsUser (و runAsGroup). على الرغم من أننا لم نتمكن من الوصول إلى الجذر، إلا أنه تم السماح بجميع معرفات UID الأخرى – بما في ذلك معرف Istio’s UID، والذي كان من المفارقة أن 1337 (نعم، حقا). لقد قمنا بتعيين UID الخاص بنا على 1337 وتم تشغيله بنجاح كمستخدم Istio. منذ Istio نفسها مستبعد من قواعد iptables الخاصة بـ Istio – كنا نركض الآن دون أي قيود على حركة المرور!
بعد أن تحررنا من أغلال حركة المرور، بدأنا في فحص الشبكة الداخلية لجهاز Pod الخاص بنا. باستخدام رمز Istio الخاص بنا، تمكنا من قراءة التكوينات من خادم Istiod والحصول على نظرة ثاقبة للبيئة الداخلية – مما قادنا إلى النتائج التالية.
الخطأ رقم 2: يقوم Loki بتسريب رموز AWS المميزة
لقد عثرنا على مثيل لـ Grafana Loki في المجموعة، لذلك طلبنا /config نقطة النهاية لعرض تكوين Loki. استجابت واجهة برمجة التطبيقات (API) بالتكوين الكامل، بما في ذلك أسرار AWS التي استخدمها Loki للوصول إلى S3:
منحت هذه الأسرار إمكانية الوصول إلى مجموعة Loki’s S3، التي تحتوي على مجموعة كبيرة من السجلات من خدمات AI Core (التي تقول SAP إنها ليست حساسة) ووحدات العملاء.
الخطأ رقم 3: مشاركات EFS غير المصادق عليها تكشف ملفات المستخدم
داخل الشبكة الداخلية، وجدنا 6 مثيلات لنظام AWS Elastic File System (EFS)، تستمع على المنفذ 2049. مشكلة شائعة مع مثيلات EFS هو تكوينها الافتراضي كعام – مما يعني أنه ليست هناك حاجة إلى بيانات الاعتماد لعرض الملفات أو تحريرها، طالما أن لديك وصولاً عبر الشبكة إلى منافذ NFS الخاصة بها. لم تكن هذه الحالات مختلفة، وباستخدام أدوات NFS البسيطة مفتوحة المصدر، تمكنا من الوصول بحرية إلى محتويات المشاركات.
كشفت قائمة الملفات المخزنة في مثيلات EFS عن كميات هائلة من بيانات الذكاء الاصطناعي، بما في ذلك مجموعات بيانات التعليمات البرمجية والتدريب، المصنفة حسب معرف العميل:
الخطأ رقم 4: خادم Helm غير المصادق يعرض للخطر سجل Docker الداخلي وArtifactory
كانت النتيجة الأكثر إثارة للاهتمام التي توصلنا إليها على الشبكة هي خدمة تسمى Tiller، وهي مكون الخادم لمدير حزم Helm (في الإصدار 2).
يتم الاتصال بـ Tiller عبر واجهة gRPC الخاصة به على المنفذ 44134، والتي يتم كشفها افتراضيًا دون أي مصادقة.
كشف الاستعلام عن هذا الخادم على شبكتنا الداخلية عن أسرار مميزة للغاية لسجل Docker الخاص بـ SAP بالإضافة إلى خادم Artifactory الخاص به:
باستخدام الوصول للقراءة لهذه الأسرار، يمكن للمهاجم المحتمل قراءة الصور والبنيات الداخلية، واستخراج الأسرار التجارية وربما بيانات العملاء.
باستخدام الوصول إلى الكتابة للأسرار، يمكن للمهاجم تسميم الصور والبنيات، والقيام بهجوم سلسلة التوريد على خدمات SAP AI Core.
الخطأ رقم 5: خادم Helm غير المصادق يخترق مجموعة K8s، ويكشف رموز الوصول إلى Google وأسرار العملاء
تعرض خادم Helm لكل من عمليات القراءة والكتابة. بينما كشف الوصول للقراءة عن أسرار حساسة (كما هو موضح أعلاه)، سمح الوصول للكتابة للخادم بالاستيلاء الكامل على المجموعة.
تيلر install يأخذ الأمر حزمة Helm وينشرها في مجموعة K8s. لقد أنشأنا حزمة Helm ضارة تولد حجرة جديدة بها cluster-admin الامتيازات، وقمت بتشغيل أمر التثبيت.
كنا نعمل الآن بامتيازات كاملة على المجموعة!
باستخدام مستوى الوصول هذا، يمكن للمهاجم الوصول مباشرة إلى المستودعات الخاصة بالعميل الآخر وسرقة البيانات الحساسة، مثل النماذج ومجموعات البيانات والتعليمات البرمجية. يسمح هذا الوصول أيضًا للمهاجمين بالتدخل في البودات الخاصة بالعميل، وتلويث بيانات الذكاء الاصطناعي والتلاعب باستدلال النماذج.
علاوة على ذلك، كان من الممكن أن يسمح لنا مستوى الوصول هذا بعرض أسرار العملاء الخاصة – حتى الأسرار التي تقع خارج نطاق SAP AI Core. على سبيل المثال، يحتوي حساب AI Core الخاص بنا على أسرار لحساب AWS الخاص بنا (للوصول إلى بيانات S3)، وحساب SAP HANA الخاص بنا (للوصول إلى Data Lake)، وحساب Docker Hub الخاص بنا (لسحب صورنا). باستخدام مستوى الوصول المكتشف حديثًا، استفسرنا عن هذه الأسرار، وتمكنا من الوصول إليها جميعًا بنص عادي:
كشف نفس الاستعلام أيضًا عن مفتاح وصول SAP إلى Google Container Registry، المسمى sap-docker-registry-secret. لقد أكدنا أن هذا المفتاح يمنح أذونات القراءة والكتابة – مما يزيد من توسيع نطاق الهجوم المحتمل على سلسلة التوريد.
يوضح بحثنا في SAP AI Core أهمية الدفاع بعمق. كانت العقبة الأمنية الرئيسية التي كنا نواجهها هي قيام Istio بمنع حركة المرور لدينا من الوصول إلى الشبكة الداخلية. وبمجرد أن تمكنا من تجاوز هذه العقبة، تمكنا من الوصول إلى العديد من الأصول الداخلية التي لم تتطلب أي مصادقة إضافية – مما يعني أن الشبكة الداخلية كان يُنظر إليها على أنها موثوقة. كان من الممكن أن يؤدي تشديد هذه الخدمات الداخلية إلى تقليل تأثير هذا الهجوم وخفض مستواه من الاستيلاء الكامل على الخدمة إلى حادث أمني بسيط.
تماشيًا مع الثغرات الأمنية السابقة المتعلقة بـ Kubernetes، يوضح هذا البحث أيضًا مخاطر عزل المستأجر عند استخدام K8s في الخدمات المُدارة. يتأثر الفصل الحاسم بين مستوى التحكم (منطق الخدمة) ومستوى البيانات (حساب العميل) ببنية K8s، التي تسمح بالاتصالات المنطقية بينهما من خلال واجهات برمجة التطبيقات والهويات والحوسبة المشتركة والشبكات المقسمة إلى برامج.
علاوة على ذلك، يوضح هذا البحث التحديات الفريدة التي تطرحها عملية البحث والتطوير في مجال الذكاء الاصطناعي. يتطلب تدريب الذكاء الاصطناعي تشغيل تعليمات برمجية عشوائية حسب التعريف؛ ولذلك، يجب وضع حواجز الحماية المناسبة لضمان فصل التعليمات البرمجية غير الموثوق بها بشكل صحيح عن الأصول الداخلية والمستأجرين الآخرين.
-
25 يناير 2024 – تقوم Wiz Research بإبلاغ نتائج الأمان إلى SAP
-
27 يناير 2024 – يرد SAP ويعين رقم الحالة
-
16 فبراير 2024 – يعمل SAP على إصلاح الثغرة الأمنية الأولى وتدوير الأسرار ذات الصلة
-
28 فبراير 2024 – يتجاوز Wiz Research التصحيح باستخدام اثنتين من نقاط الضعف الجديدة، ويتم تقديم التقارير إلى SAP
-
15 مايو 2024 – تنشر SAP إصلاحات لجميع الثغرات الأمنية التي تم الإبلاغ عنها
-
17 يوليو 2024 – الإفصاح العلني
أهلاً! نحن هيلاي بن ساسون (@hillai)، شير تماري (@shirtamari)، نير أوهفيلد (@ نيروهفيلد)، ساجي تصادق (@sagitz_) ورونين شوستين (@ronenshh) من فريق أبحاث Wiz. نحن مجموعة من المتسللين ذوي القبعة البيضاء المخضرمين بهدف واحد: جعل السحابة مكانًا أكثر أمانًا للجميع. نحن نركز بشكل أساسي على العثور على نواقل هجوم جديدة في السحابة والكشف عن مشكلات العزل لدى موردي السحابة.
نحن نحب أن نسمع منك! لا تتردد في الاتصال بنا على تويتر أو عبر البريد الإلكتروني:Research@wiz.io.
