وفقًا لبحث جديد، كان من الممكن أن يستغل أحد المهاجمين ثغرة أمنية مرتبطة بخدمة توجيه حركة المرور في Amazon Web Service والمعروفة باسم Application Load Balancer لتجاوز عناصر التحكم في الوصول واختراق تطبيقات الويب. ينبع الخلل من مشكلة في تنفيذ العميل، مما يعني أنه ليس ناتجًا عن خلل في البرنامج. بدلاً من ذلك، تم تقديم التعرض من خلال الطريقة التي يقوم بها مستخدمو AWS بإعداد المصادقة باستخدام Application Load Balancer.
تشكل مشكلات التنفيذ عنصرًا بالغ الأهمية في أمن السحابة بنفس الطريقة التي لا يتم بها حماية محتويات الخزنة المدرعة إذا تُرك الباب مفتوحًا. باحثون من شركة الأمن Miggo وجد أنه بناءً على كيفية إعداد مصادقة موازن تحميل التطبيق، قد يتمكن المهاجم من التلاعب بعملية التسليم إلى خدمة مصادقة مؤسسية تابعة لجهة خارجية للوصول إلى تطبيق الويب المستهدف وعرض البيانات أو استخراجها.
يقول الباحثون إنهم من خلال النظر في تطبيقات الويب التي يمكن الوصول إليها علنًا، حددوا أكثر من 15000 تطبيق يبدو أنها تحتوي على تكوينات ضعيفة. ومع ذلك، تعارض AWS هذا التقدير، وتقول إن “جزءًا صغيرًا من النسبة المئوية لعملاء AWS لديهم تطبيقات قد تم تكوينها بشكل خاطئ بهذه الطريقة، وهو أقل بكثير من تقدير الباحثين”. وتقول الشركة أيضًا إنها اتصلت بكل عميل في قائمتها الأقصر لتوصية بتنفيذ أكثر أمانًا. ومع ذلك، لا تتمتع AWS بإمكانية الوصول إلى بيئات السحابة الخاصة بعملائها أو رؤيتها، لذا فإن أي رقم دقيق هو مجرد تقدير.
يقول باحثو ميجو إنهم واجهوا المشكلة أثناء العمل مع أحد العملاء. ويقول دانييل شيختر الرئيس التنفيذي لشركة ميجو: “تم اكتشاف هذه المشكلة في بيئات الإنتاج الحقيقية. لقد لاحظنا سلوكًا غريبًا في نظام العملاء – بدا الأمر كما لو كانت عملية التحقق تتم جزئيًا فقط، كما لو كان هناك شيء مفقود. وهذا يوضح حقًا مدى عمق الترابط بين العميل والبائع”.
لاستغلال مشكلة التنفيذ، يقوم المهاجم بإعداد حساب AWS وموازن تحميل التطبيق، ثم يقوم بتوقيع رمز المصادقة الخاص به كالمعتاد. بعد ذلك، يقوم المهاجم بإجراء تغييرات في التكوين بحيث يبدو أن خدمة المصادقة الخاصة بالهدف أصدرت الرمز. بعد ذلك، يقوم المهاجم بتوقيع AWS على الرمز كما لو كان صادرًا بشكل شرعي من نظام الهدف واستخدامه للوصول إلى تطبيق الهدف. يجب أن يستهدف الهجوم على وجه التحديد تطبيقًا تم تكوينه بشكل غير صحيح ويمكن الوصول إليه علنًا أو يمكن للمهاجم الوصول إليه بالفعل، ولكنه يسمح له بتصعيد امتيازاته في النظام.
تقول شركة Amazon Web Services إن الشركة لا تنظر إلى تزوير الرمز باعتباره ثغرة أمنية في Application Load Balancer لأنه في الأساس نتيجة متوقعة لاختيار تكوين المصادقة بطريقة معينة. ولكن بعد أن كشف باحثو Miggo لأول مرة عن نتائجهم لشركة AWS في بداية شهر أبريل، أعلنت الشركة أنها لن تتدخل في هذا الأمر. تم إجراء تغييرين في الوثائق تهدف إلى تحديث توصيات التنفيذ الخاصة بمصادقة موازن تحميل التطبيق. تضمنت إحدى التوصيات، اعتبارًا من الأول من مايو، إرشادات حول إضافة التحقق قبل أن يقوم Application Load Balancer بتوقيع الرموز. وفي 19 يوليو، أضافت الشركة أيضًا توصية صريحة للمستخدمين بتعيين أنظمتهم لتلقي حركة المرور من Application Load Balancer الخاص بهم فقط باستخدام ميزة تسمى “مجموعات الأمان”.
صرح المتحدث باسم AWS، باتريك نيغورن، لموقع WIRED في بيان: “من غير الصحيح أن نطلق على هذا تجاوزًا للمصادقة والترخيص لـ AWS Application Load Balancer (ALB) أو أي خدمة أخرى من خدمات AWS لأن هذه التقنية تعتمد على جهة فاعلة سيئة لديها بالفعل اتصال مباشر بتطبيق عميل تم تكوينه بشكل غير صحيح ولا يقوم بمصادقة الطلبات. نوصي العملاء بتكوين تطبيقاتهم لقبول الطلبات من ALB فقط باستخدام مجموعات الأمان واتباع التعليمات التالية:أفضل ممارسات أمن ALB“.”
وبالنظر إلى التغييرات التي أجرتها AWS معًا، فإنها تعالج بفعالية مسار الهجوم الذي اقترحه باحثو Miggo. ولكن نظرًا لأنها تتضمن تغيير الطريقة التي أنشأ بها عملاء AWS أنظمتهم الخاصة، فإن الإصلاحات ليست مثل تصحيح البرامج الذي يمكن للمطورين إرساله إلى جميع المستخدمين. بدلاً من ذلك، يجب على مستخدمي AWS الذين لديهم تكوينات معرضة للخطر سماع الإرشادات المحدثة، وإدراك أنها ذات صلة بتكويناتهم، وإجراء التغييرات بأنفسهم.
تحت ما يعرف بـ نموذج المسؤولية المشتركةغالبًا ما تقع مثل هذه المواقف في المنطقة الرمادية بين ما يجب على مزود منصة السحابة معالجته لعملائه وما يحتاج المستخدمون إلى تحمل مسؤولية إدارة أنفسهم. وفي حين أن هذا لقد كان الغموض موجودًا لسنواتهناك بعض الحالات التي لا يوجد فيها حل واحد واضح للتأكد من أن كل عميل سحابي لديه إعداد الأمان الدقيق الذي يحتاجه وينوي القيام به.