بواسطة سير لايت
يتضمن بناء أي خدمة بالضرورة العمل المستمر على الأمن. الأمان هو عملية مستمرة تتضمن التحليل المستمر وتحسين أمان المنتج ومراقبة الأخبار حول نقاط الضعف وغير ذلك الكثير. بما في ذلك عمليات التدقيق. يتم إجراء عمليات التدقيق داخليًا ومن قبل خبراء خارجيين، والذين يمكنهم المساعدة بشكل جذري في مجال الأمن لأنهم ليسوا منغمسين في المشروع ولديهم عقل متفتح.
تتناول هذه المقالة وجهة النظر الأكثر وضوحًا للخبراء الخارجيين الذين ساعدوا فريق Mail.ru Cloud Solutions (MCS) في اختبار الخدمة السحابية، وما وجدوه. باعتبارها “قوة خارجية”، اختارت شركة MCS شركة الأمن الرقمي المعروفة بخبرتها العالية في دوائر أمن المعلومات. وفي هذه المقالة سنقوم بتحليل بعض نقاط الضعف المثيرة للاهتمام التي تم العثور عليها كجزء من التدقيق الخارجي - بحيث يمكنك تجنب نفس الاختراق عند إنشاء الخدمة السحابية الخاصة بك.
Описание продукта
عبارة عن منصة لبناء البنية التحتية الافتراضية في السحابة. يتضمن IaaS وPaaS وسوقًا لصور التطبيقات الجاهزة للمطورين. مع الأخذ بعين الاعتبار بنية MCS، كان من الضروري التحقق من سلامة المنتج في المجالات التالية:
- حماية البنية التحتية لبيئة المحاكاة الافتراضية: برامج Hypervisor، والتوجيه، وجدران الحماية؛
- حماية البنية التحتية الافتراضية للعملاء: العزلة عن بعضها البعض، بما في ذلك الشبكة والشبكات الخاصة في SDN؛
- OpenStack ومكوناته المفتوحة؛
- S3 من تصميمنا الخاص؛
- IAM: مشاريع متعددة المستأجرين مع نموذج يحتذى به؛
- الرؤية (رؤية الكمبيوتر): واجهات برمجة التطبيقات ونقاط الضعف عند العمل مع الصور؛
- واجهة الويب وهجمات الويب الكلاسيكية؛
- نقاط الضعف في مكونات PaaS؛
- API لجميع المكونات.
ربما هذا هو كل ما هو ضروري لمزيد من التاريخ.
ما نوع العمل الذي تم تنفيذه ولماذا كانت هناك حاجة إليه؟
يهدف التدقيق الأمني إلى تحديد نقاط الضعف وأخطاء التكوين التي قد تؤدي إلى تسرب البيانات الشخصية، أو تعديل المعلومات الحساسة، أو تعطيل توفر الخدمة.
أثناء العمل، الذي يستمر في المتوسط من شهر إلى شهرين، يكرر المدققون تصرفات المهاجمين المحتملين ويبحثون عن نقاط الضعف في أجزاء العميل والخادم في الخدمة المحددة. في سياق التدقيق على منصة MCS السحابية، تم تحديد الأهداف التالية:
- تحليل المصادقة في الخدمة. ستساعد الثغرات الأمنية في هذا المكون على الدخول فورًا إلى حسابات الآخرين.
- دراسة القدوة والتحكم في الوصول بين الحسابات المختلفة. بالنسبة للمهاجم، تعد القدرة على الوصول إلى الجهاز الظاهري لشخص آخر هدفًا مرغوبًا فيه.
- نقاط الضعف من جانب العميل. XSS/CSRF/CRLF/إلخ. هل من الممكن مهاجمة مستخدمين آخرين من خلال الروابط الضارة؟
- نقاط الضعف من جانب الخادم: RCE وجميع أنواع الحقن (SQL/XXE/SSRF وما إلى ذلك). عادةً ما يكون العثور على الثغرات الأمنية في الخادم أكثر صعوبة، ولكنها تؤدي إلى اختراق العديد من المستخدمين في وقت واحد.
- تحليل عزل شريحة المستخدم على مستوى الشبكة. بالنسبة للمهاجم، يؤدي الافتقار إلى العزلة إلى زيادة مساحة الهجوم بشكل كبير ضد المستخدمين الآخرين.
- تحليل منطق الأعمال. هل من الممكن خداع الشركات وإنشاء أجهزة افتراضية مجانًا؟
في هذا المشروع، تم تنفيذ العمل وفقًا لنموذج "الصندوق الرمادي": تفاعل المدققون مع الخدمة بامتيازات المستخدمين العاديين، لكنهم امتلكوا جزئيًا الكود المصدري لواجهة برمجة التطبيقات (API) وأتيحت لهم الفرصة لتوضيح التفاصيل مع المطورين. عادةً ما يكون هذا هو نموذج العمل الأكثر ملاءمة، وفي الوقت نفسه الواقعي تمامًا: لا يزال من الممكن جمع المعلومات الداخلية بواسطة مهاجم، إنها مسألة وقت فقط.
تم العثور على نقاط الضعف
قبل أن يبدأ المدقق في إرسال حمولات مختلفة (الحمولة المستخدمة لتنفيذ الهجوم) إلى أماكن عشوائية، من الضروري فهم كيفية عمل الأشياء والوظائف المتوفرة. قد يبدو أن هذا تمرين عديم الفائدة، لأنه في معظم الأماكن التي تمت دراستها لن تكون هناك نقاط ضعف. لكن فهم بنية التطبيق ومنطق تشغيله فقط هو الذي سيجعل من الممكن العثور على ناقلات الهجوم الأكثر تعقيدًا.
من المهم العثور على الأماكن التي تبدو مشبوهة أو مختلفة تمامًا عن الأماكن الأخرى بطريقة ما. وتم العثور على أول ثغرة أمنية خطيرة بهذه الطريقة.
آيدور
تعد ثغرات IDOR (مرجع الكائن المباشر غير الآمن) واحدة من أكثر الثغرات الأمنية شيوعًا في منطق الأعمال، والتي تسمح لشخص أو آخر بالوصول إلى الكائنات التي لا يُسمح بالوصول إليها فعليًا. تخلق ثغرات IDOR إمكانية الحصول على معلومات حول المستخدم بدرجات متفاوتة من الأهمية.
أحد خيارات IDOR هو تنفيذ إجراءات مع كائنات النظام (المستخدمين، الحسابات المصرفية، العناصر الموجودة في عربة التسوق) عن طريق معالجة معرفات الوصول إلى هذه الكائنات. وهذا يؤدي إلى عواقب لا يمكن التنبؤ بها. على سبيل المثال، إمكانية استبدال حساب مرسل الأموال، ومن خلاله يمكنك سرقتها من مستخدمين آخرين.
في حالة MCS، اكتشف المدققون ثغرة IDOR المرتبطة بالمعرفات غير الآمنة. في الحساب الشخصي للمستخدم، تم استخدام معرفات UUID للوصول إلى أي كائنات، والتي تبدو، كما يقول خبراء الأمن، غير آمنة بشكل مثير للإعجاب (أي أنها محمية من هجمات القوة الغاشمة). ولكن بالنسبة لبعض الجهات، تم اكتشاف أنه يتم استخدام أرقام منتظمة يمكن التنبؤ بها للحصول على معلومات حول مستخدمي التطبيق. أعتقد أنه يمكنك تخمين أنه كان من الممكن تغيير معرف المستخدم بمعرف واحد، وإرسال الطلب مرة أخرى وبالتالي الحصول على معلومات تتجاوز قائمة التحكم بالوصول (قائمة التحكم في الوصول، وقواعد الوصول إلى البيانات للعمليات والمستخدمين).
تزوير طلب جانب الخادم (SSRF)
الشيء الجيد في منتجات OpenSource هو أنها تحتوي على عدد كبير من المنتديات التي تحتوي على أوصاف فنية مفصلة للمشكلات التي تنشأ، وإذا كنت محظوظًا، وصفًا للحل. لكن هذه العملة لها جانب آخر: حيث يتم أيضًا وصف نقاط الضعف المعروفة بالتفصيل. على سبيل المثال، هناك أوصاف رائعة لنقاط الضعف في منتدى OpenStack и ، والذي لسبب ما لا أحد في عجلة من أمره لإصلاحه.
إحدى الوظائف الشائعة للتطبيقات هي قدرة المستخدم على إرسال رابط إلى الخادم، والذي ينقر عليه الخادم (على سبيل المثال، لتنزيل صورة من مصدر محدد). إذا لم تقم أدوات الأمان بتصفية الروابط نفسها أو الاستجابات التي يتم إرجاعها من الخادم إلى المستخدمين، فيمكن للمهاجمين استخدام هذه الوظيفة بسهولة.
يمكن لنقاط ضعف SSRF أن تؤدي إلى تقدم كبير في تطوير الهجوم. يمكن للمهاجم الحصول على:
- الوصول المحدود إلى الشبكة المحلية التي تمت مهاجمتها، على سبيل المثال، فقط من خلال قطاعات معينة من الشبكة وباستخدام بروتوكول معين؛
- الوصول الكامل إلى الشبكة المحلية، إذا كان الرجوع من مستوى التطبيق إلى مستوى النقل ممكنًا، ونتيجة لذلك، إدارة التحميل الكاملة على مستوى التطبيق؛
- الوصول لقراءة الملفات المحلية على الخادم (إذا كان نظام الملف:/// مدعومًا)؛
- وأكثر من ذلك بكثير.
إن ثغرة SSRF معروفة منذ فترة طويلة في OpenStack، وهي "عمياء" بطبيعتها: عندما تتصل بالخادم، لا تتلقى استجابة منه، ولكنك تتلقى أنواعًا مختلفة من الأخطاء/التأخير، اعتمادًا على نتيجة الطلب . وبناءً على ذلك، يمكنك إجراء فحص للمنافذ على الأجهزة المضيفة على الشبكة الداخلية، مع كل العواقب المترتبة على ذلك والتي لا ينبغي الاستهانة بها. على سبيل المثال، قد يحتوي المنتج على واجهة برمجة تطبيقات للمكتب الخلفي لا يمكن الوصول إليها إلا من خلال شبكة الشركة. باستخدام الوثائق (لا تنس المطلعين)، يمكن للمهاجم استخدام SSRF للوصول إلى الأساليب الداخلية. على سبيل المثال، إذا تمكنت بطريقة أو بأخرى من الحصول على قائمة تقريبية بعناوين URL المفيدة، فيمكنك باستخدام SSRF المرور عبرها وتنفيذ طلب - نسبيًا، أو تحويل الأموال من حساب إلى حساب أو تغيير الحدود.
ليست هذه هي المرة الأولى التي يتم فيها اكتشاف ثغرة أمنية SSRF في OpenStack. في الماضي، كان من الممكن تنزيل صور VM ISO من رابط مباشر، مما أدى أيضًا إلى عواقب مماثلة. تمت الآن إزالة هذه الميزة من OpenStack. على ما يبدو، اعتبر المجتمع هذا الحل الأبسط والأكثر موثوقية للمشكلة.
وفي تقرير متاح للعامة من خدمة HackerOne (h1)، يؤدي استغلال SSRF الذي لم يعد أعمى مع القدرة على قراءة البيانات التعريفية للمثيل إلى وصول الجذر إلى البنية التحتية الكاملة لـ Shopify.
في MCS، تم اكتشاف ثغرات SSRF في مكانين لهما وظائف مماثلة، ولكن كان من المستحيل تقريبًا استغلالها بسبب جدران الحماية ووسائل الحماية الأخرى. بطريقة أو بأخرى، قام فريق MCS بإصلاح هذه المشكلة على أي حال، دون انتظار المجتمع.
XSS بدلاً من تحميل الأصداف
على الرغم من مئات الدراسات المكتوبة، لا يزال هجوم XSS (البرمجة النصية عبر المواقع) هو الأكثر عامًا بعد عام ثغرة الويب (أو ؟).
يعد تحميل الملفات مكانًا مفضلاً لأي باحث أمني. غالبًا ما يتبين أنه يمكنك تحميل برنامج نصي عشوائي (asp/jsp/php) وتنفيذ أوامر نظام التشغيل، وفقًا لمصطلحات pentesters - "load shell". لكن شعبية مثل هذه الثغرات الأمنية تعمل في كلا الاتجاهين: حيث يتم تذكرها ويتم تطوير العلاجات ضدها، حتى أن احتمال "تحميل الصدفة" في الآونة الأخيرة يميل إلى الصفر.
وكان الفريق المهاجم (ممثلا بالأمن الرقمي) محظوظا. حسنًا، في MCS على جانب الخادم، تم فحص محتويات الملفات التي تم تنزيلها، ولم يُسمح إلا بالصور. لكن SVG هي أيضًا صورة. كيف يمكن أن تكون صور SVG خطيرة؟ لأنه يمكنك تضمين مقتطفات JavaScript فيها!
اتضح أن الملفات التي تم تنزيلها متاحة لجميع مستخدمي خدمة MCS، مما يعني أنه من الممكن مهاجمة مستخدمي السحابة الآخرين، أي المسؤولين.
مثال على هجوم XSS على نموذج تسجيل الدخول للتصيد الاحتيالي
أمثلة على استغلال هجوم XSS:
- لماذا تحاول سرقة جلسة (خاصة وأن ملفات تعريف الارتباط HTTP فقط موجودة الآن في كل مكان، ومحمية من السرقة باستخدام نصوص js)، إذا كان البرنامج النصي الذي تم تحميله يمكنه الوصول على الفور إلى واجهة برمجة تطبيقات المورد؟ في هذه الحالة، يمكن للحمولة استخدام طلبات XHR لتغيير تكوين الخادم، على سبيل المثال، إضافة مفتاح SSH العام للمهاجم والحصول على وصول SSH إلى الخادم.
- إذا كانت سياسة CSP (سياسة حماية المحتوى) تحظر إدخال JavaScript، فيمكن للمهاجم الاستغناء عنها. باستخدام HTML خالص، قم بإنشاء نموذج تسجيل دخول مزيف للموقع وسرقة كلمة مرور المسؤول من خلال هذا التصيد المتقدم: تنتهي صفحة التصيد الخاصة بالمستخدم في نفس عنوان URL، ويصعب على المستخدم اكتشافها.
- وأخيرا، يمكن للمهاجم الترتيب — قم بتعيين ملفات تعريف الارتباط بحجم أكبر من 4 كيلو بايت. يحتاج المستخدم إلى فتح الرابط مرة واحدة فقط، ويصبح الموقع بأكمله غير قابل للوصول حتى يفكر المستخدم في تنظيف المتصفح على وجه التحديد: في الغالبية العظمى من الحالات، سيرفض خادم الويب قبول مثل هذا العميل.
دعونا نلقي نظرة على مثال XSS آخر تم اكتشافه، هذه المرة مع استغلال أكثر ذكاءً. تتيح لك خدمة MCS دمج إعدادات جدار الحماية في مجموعات. كان اسم المجموعة هو المكان الذي تم اكتشاف XSS فيه. خصوصيته هي أن المتجه لم يتم تشغيله على الفور، ليس عند عرض قائمة القواعد، ولكن عند حذف مجموعة:
أي أنه تبين أن السيناريو هو ما يلي: يقوم المهاجم بإنشاء قاعدة جدار الحماية مع "تحميل" في الاسم، ويلاحظها المسؤول بعد فترة ويبدأ عملية الحذف. وهذا هو المكان الذي يعمل فيه JS الخبيث.
لكي يتمكن مطورو MCS من الحماية من XSS في صور SVG التي تم تحميلها (إذا كان لا يمكن حذفها)، أوصى فريق الأمن الرقمي بما يلي:
- وضع الملفات التي تم تحميلها من قبل المستخدمين في نطاق منفصل لا علاقة له بـ "ملفات تعريف الارتباط". سيتم تنفيذ البرنامج النصي في سياق مجال مختلف ولن يشكل تهديدًا لـ MCS.
- في استجابة HTTP الخاصة بالخادم، أرسل رأس "التخلص من المحتوى: المرفق". ثم سيتم تنزيل الملفات بواسطة المتصفح ولن يتم تنفيذها.
بالإضافة إلى ذلك، هناك الآن العديد من الطرق المتاحة للمطورين للتخفيف من مخاطر استغلال XSS:
- باستخدام علامة "HTTP فقط"، يمكنك جعل رؤوس "ملفات تعريف الارتباط" للجلسة غير قابلة للوصول إلى JavaScript الضارة؛
- سيجعل الأمر أكثر صعوبة على المهاجم استغلال XSS؛
- تقوم محركات القوالب الحديثة مثل Angular أو React بتطهير بيانات المستخدم تلقائيًا قبل إخراجها إلى متصفح المستخدم.
ثغرات المصادقة الثنائية
لتحسين أمان الحساب، يُنصح المستخدمون دائمًا بتمكين المصادقة الثنائية (2FA). وفي الواقع، تعد هذه طريقة فعالة لمنع المهاجم من الوصول إلى الخدمة إذا تم اختراق بيانات اعتماد المستخدم.
ولكن هل يضمن استخدام عامل المصادقة الثاني دائمًا أمان الحساب؟ هناك المشكلات الأمنية التالية في تنفيذ المصادقة الثنائية:
- بحث القوة الغاشمة عن رمز OTP (رموز لمرة واحدة). على الرغم من بساطة التشغيل، تواجه الشركات الكبيرة أيضًا أخطاء مثل نقص الحماية ضد القوة الغاشمة لمرة واحدة (OTP): , .
- خوارزمية التوليد ضعيفة، على سبيل المثال القدرة على توقع الكود التالي.
- الأخطاء المنطقية، مثل القدرة على طلب كلمة مرور لمرة واحدة (OTP) لشخص آخر على هاتفك، مثل هذا من شوبيفاي.
في حالة MCS، يتم تنفيذ المصادقة الثنائية (2FA) استنادًا إلى Google Authenticator و . لقد تم بالفعل اختبار البروتوكول نفسه عبر الزمن، ولكن تنفيذ التحقق من الكود على جانب التطبيق يستحق التدقيق.
يتم استخدام MCS 2FA في عدة أماكن:
- عند مصادقة المستخدم. هناك حماية ضد القوة الغاشمة: لدى المستخدم بضع محاولات فقط لإدخال كلمة مرور لمرة واحدة، ثم يتم حظر الإدخال لفترة من الوقت. وهذا يمنع إمكانية اختيار القوة الغاشمة لـ OTP.
- عند إنشاء رموز احتياطية دون اتصال بالإنترنت لإجراء المصادقة الثنائية (2FA)، بالإضافة إلى تعطيلها. هنا، لم يتم تنفيذ أي حماية من القوة الغاشمة، مما جعل من الممكن، إذا كان لديك كلمة مرور للحساب وجلسة نشطة، إعادة إنشاء الرموز الاحتياطية أو تعطيل المصادقة الثنائية (2FA) تمامًا.
وبالنظر إلى أن الرموز الاحتياطية كانت موجودة في نفس نطاق قيم السلسلة مثل تلك التي تم إنشاؤها بواسطة تطبيق OTP، فإن فرصة العثور على الرمز في وقت قصير كانت أعلى بكثير.
عملية اختيار OTP لتعطيل المصادقة الثنائية باستخدام أداة "Burp: Intruder".
نتيجة
بشكل عام، يبدو أن MCS آمن كمنتج. أثناء التدقيق، لم يتمكن فريق الاختبار من الوصول إلى الأجهزة الافتراضية للعملاء وبياناتهم، وتم تصحيح نقاط الضعف التي تم العثور عليها بسرعة بواسطة فريق MCS.
ولكن من المهم هنا الإشارة إلى أن الأمن عمل مستمر. الخدمات ليست ثابتة، فهي تتطور باستمرار. ومن المستحيل تطوير منتج بشكل كامل دون وجود ثغرات. ولكن يمكنك العثور عليها في الوقت المناسب وتقليل فرصة تكرارها.
الآن تم بالفعل إصلاح جميع نقاط الضعف المذكورة في MCS. ومن أجل تقليل عدد العناصر الجديدة إلى الحد الأدنى وتقليل مدة بقائها، يواصل فريق المنصة القيام بذلك:
- إجراء عمليات تدقيق منتظمة من قبل شركات خارجية؛
- دعم وتطوير المشاركة;
- الانخراط في الأمن. 🙂
المصدر: www.habr.com