SkyShip Dusk بواسطة SeerLightبناء أي خدمة يشمل بالضرورة العمل المستمر على الأمن. الأمان هو عملية مستمرة تتضمن تحليلًا مستمرًا وتحسينًا لأمان المنتج ومراقبة الأخبار المتعلقة بمواطن الضعف وأشياء أخرى كثيرة. بما في ذلك - مراجعة الحسابات. يتم إجراء عمليات التدقيق على حد سواء من قبل خبراء خارجيين ويمكنهم المساعدة بشكل كبير في مجال الأمن ، حيث إنهم لا ينغمسون في المشروع ولديهم رؤية واضحة.
يدور المقال حول هذه النظرة التي لا تحظى بشعبية كبيرة للخبراء الخارجيين الذين ساعدوا فريق Mail.ru Cloud Solutions (MCS) في اختبار الخدمة السحابية وحول ما وجدوه. باسم "القوى الخارجية" ، اختارت MCS الأمن الرقمي ، المعروف بخبرته العالية في مجتمع الأمن. وفي هذه المقالة ، سنقوم بتحليل بعض نقاط الضعف المثيرة للاهتمام التي تم العثور عليها كجزء من التدقيق الخارجي - بحيث تحصل على نفس المشكلة عندما تقوم بإجراء الخدمة السحابية الخاصة بك.
وصف المنتج
Mail.ru Cloud Solutions (MCS) هي عبارة عن منصة لبناء البنية التحتية الافتراضية في السحابة. ويشمل IaaSs ، PaaSs ، سوق صور التطبيق الجاهزة للمطورين. بالنظر إلى بنية MCS ، كان من الضروري التحقق من سلامة المنتج في المجالات التالية:
- حماية البنية التحتية للبيئة الافتراضية: برامج Hypervisor ، التوجيه ، جدران الحماية ؛
- حماية البنية التحتية الافتراضية للعملاء: العزلة عن بعضها البعض ، بما في ذلك الشبكات والشبكات الخاصة في SDN ؛
- OpenStack ومكوناته المفتوحة ؛
- S3 التنمية الخاصة ؛
- IAM: مشاريع متعددة المستأجرين مع نموذج يحتذى به ؛
- الرؤية (رؤية الآلة): واجهة برمجة التطبيقات ونقاط الضعف عند العمل مع الصور ؛
- واجهة الويب والهجمات على شبكة الإنترنت الكلاسيكية.
- نقاط الضعف في مكونات PaaS ؛
- API لجميع المكونات.
ربما ، كل ما هو ضروري للتاريخ اللاحق هو كل شيء.
ما نوع العمل الذي تم تنفيذه ولماذا يحتاجون إليه؟
يهدف التدقيق الأمني إلى تحديد الثغرات الأمنية وأخطاء التكوين التي يمكن أن تؤدي إلى تسرب البيانات الشخصية أو تعديل المعلومات الحساسة أو إلى انتهاك توفر الخدمات.
أثناء العمل ، الذي يستمر 1-2 أشهر في المتوسط ، يكرر المراجعون إجراءات المهاجمين المحتملين ويبحثون عن نقاط الضعف في أجزاء العميل والخادم بالخدمة المحددة. في سياق التدقيق في منصة MCS السحابية ، تم تحديد الأهداف التالية:
- تحليل المصادقة في الخدمة. من شأن نقاط الضعف في هذا المكون أن تساعد على الفور في الوصول إلى حسابات الآخرين.
- دراسة نموذج الدور والتحكم في الوصول بين الحسابات المختلفة. بالنسبة للمهاجمين ، تعد القدرة على الوصول إلى الجهاز الافتراضي لشخص آخر هدفًا مرحبًا به.
- نقاط ضعف العميل. XSS / CSRF / CRLF / إلخ. ربما من الممكن مهاجمة مستخدمين آخرين من خلال الروابط الخبيثة؟
- نقاط الضعف في جانب الخادم: RCE وجميع أنواع الحقن (SQL / XXE / SSRF وهلم جرا). غالبًا ما يكون من الصعب العثور على الثغرات الموجودة في الخادم ، ولكنها تؤدي إلى تسوية العديد من المستخدمين في وقت واحد.
- تحليل عزل قطاع الشبكة لشرائح المستخدمين. بالنسبة للمهاجمين ، يؤدي عدم وجود العزل إلى زيادة كبيرة في سطح الهجوم على المستخدمين الآخرين.
- تحليل منطق الأعمال. هل من الممكن خداع شركة وإنشاء أجهزة افتراضية مجانًا؟
في هذا المشروع ، تم تنفيذ العمل وفقًا لنموذج Gray-box: تفاعل المراجعون مع الخدمة بامتيازات المستخدمين العاديين ، لكن امتلكوا جزئيًا شفرة المصدر لواجهة برمجة التطبيقات وأتيحت لهم الفرصة لتوضيح التفاصيل مع المطورين. عادة ما يكون هذا هو الأنسب ، وفي الوقت نفسه نموذج عمل واقعي تمامًا: لا يزال من الممكن جمع المعلومات الداخلية من قبل المهاجمين ، إنها مسألة وقت فقط.
نقاط الضعف التي تم العثور عليها
قبل أن يبدأ المدقق في إرسال حمولات متعددة (الحمولة ، التي تُستخدم للهجوم) إلى أماكن عشوائية ، تحتاج إلى فهم كيفية عملها ، وما هي الوظيفة المعروضة. قد يبدو هذا تمرينًا غير مجدي ، لأنه في معظم الأماكن التي تتم دراستها لن تكون هناك نقاط ضعف. ولكن فقط فهم بنية التطبيق ومنطق تشغيله سيجعل من الممكن العثور على متجهات الهجوم الأكثر تعقيدًا.
من المهم العثور على أماكن تبدو مشبوهة أو شيء مختلف تمامًا عن الآخرين. تم العثور على أول ثغرة أمنية خطيرة بهذه الطريقة.
IDOR
تعد الثغرات الأمنية لـ IDOR (مرجع الكائن المباشر غير الآمن والارتباطات المباشرة غير الآمنة للكائنات) واحدة من أكثر الثغرات شيوعًا في منطق الأعمال التي تسمح بطريقة أو بأخرى بالوصول إلى الكائنات التي لا يسمح الوصول إليها فعليًا. إنشاء ثغرات IDOR إمكانية الحصول على معلومات المستخدم بدرجات متفاوتة من الأهمية.
أحد خيارات IDOR هو تنفيذ إجراءات مع كائنات النظام (المستخدمين ، والحسابات المصرفية ، والبضائع في السلة) عن طريق معالجة معرفات الوصول لهذه الكائنات. هذا يؤدي إلى عواقب لا يمكن التنبؤ بها. على سبيل المثال ، إمكانية استبدال حساب المرسل ، نظرًا لأنه يمكنك سرقته من مستخدمين آخرين.
في حالة MCS ، اكتشف المراجعون للتو ثغرة أمنية IDOR المرتبطة بمعرفات غير النظام. في حساب المستخدم الشخصي ، للوصول إلى أي كائنات ، تم استخدام UUIDs ، والذي بدا ، كما يقول رجال الأمن ، غير مثير للإعجاب بشكل مثير للإعجاب (أي ، محمي من هجوم القوة الوحشية). ولكن بالنسبة لبعض الكيانات ، تم اكتشاف أن الأرقام العادية المتوقعة يمكن استخدامها للحصول على معلومات حول مستخدمي التطبيق. أعتقد أنك تدرك أنه كان من الممكن تغيير معرف المستخدم من جانب واحد ، وإرسال الطلب مرة أخرى وبالتالي الحصول على معلومات تتجاوز قائمة التحكم في الوصول (ACL (قائمة التحكم في الوصول ، وقواعد الوصول إلى البيانات للعمليات والمستخدمين).
طلب جانب الخادم التزوير (SSRF)
تعتبر منتجات OpenSource جيدة لأنها تحتوي على عدد كبير من المنتديات التي تحتوي على وصف تقني مفصل للمشاكل التي تنشأ ، وإذا كنت محظوظًا ، مع وصف للحل. لكن هذه العملة لها جانب انعكاس: نقاط الضعف المعروفة أيضًا مفصلة. على سبيل المثال ، يحتوي منتدى OpenStack على وصف رائع لنقاط الضعف
[XSS] و
[SSRF] ، والتي لسبب ما لا يتعجل أحد إصلاحه.
تتمثل وظيفة التطبيق المتكرر في قدرة المستخدم على إرسال رابط إلى الخادم الذي ينقر عليه الخادم (على سبيل المثال ، لتنزيل صورة من مصدر محدد). مع عدم كفاية تصفية الأمان للارتباطات أو الاستجابات التي يتم إرجاعها من الخادم إلى المستخدمين ، يتم استخدام هذه الوظيفة بسهولة بواسطة المهاجمين.
نقاط الضعف SSRF يمكن أن تقدم إلى حد كبير تطوير الهجوم. يمكن للمهاجم الحصول على:
- محدودية الوصول إلى الشبكة المحلية التي تمت مهاجمتها ، على سبيل المثال ، فقط على قطاعات شبكة معينة وعلى بروتوكول معين ؛
- الوصول الكامل إلى الشبكة المحلية ، إذا كان تقليل مستوى ممكن من مستوى التطبيق إلى مستوى النقل ، ونتيجة لذلك ، إدارة كاملة للحمل على مستوى التطبيق ؛
- الوصول إلى قراءة الملفات المحلية على الخادم (إذا كان الملف: /// schem معتمد) ؛
- وأكثر من ذلك بكثير.
يُعرف OpenStack منذ فترة طويلة بضعف SSRF "الأعمى": عند الوصول إلى الخادم ، لن تحصل على استجابة منه ، لكنك تحصل على أنواع مختلفة من الأخطاء / التأخير ، اعتمادًا على نتيجة الطلب. بناءً على ذلك ، يمكنك فحص المنافذ على الأجهزة المضيفة على الشبكة الداخلية ، مع كل العواقب المترتبة عليها ، والتي لا ينبغي الاستهانة بها. على سبيل المثال ، قد يكون للمنتج واجهة برمجة تطبيقات للمكتب الخلفي ، وهي متاحة فقط من شبكة الشركة. حيازة الوثائق (لا تنسى المطلعين) ، يمكن للمهاجم استخدام الطرق الداخلية باستخدام SSRF. على سبيل المثال ، إذا تمكنت من الحصول بطريقة أو بأخرى على قائمة تقريبية لعناوين URL المفيدة ، فعندئذٍ يمكنك استخدام SSRF من خلالهما وتنفيذ طلب - بالمعنى المنطقي أو تحويل الأموال من حساب إلى حساب أو تغيير الحدود.
ليست هذه هي الحالة الأولى للكشف عن ثغرات SSRF في OpenStack. في الماضي ، كان من الممكن تنزيل صور VM ISO عبر رابط مباشر ، مما أدى أيضًا إلى عواقب مماثلة. تتم إزالة هذه الميزة حاليًا من OpenStack. على ما يبدو ، اعتبر المجتمع هذا الحل الأسهل والأكثر موثوقية للمشكلة.
وفي
هذا التقرير المتاح للعموم من خدمة HackerOne (h1) ، يؤدي استغلال SSRF غير الأعمى مع القدرة على قراءة بيانات التعريف الأولية إلى وصول Root إلى البنية التحتية Shopify بأكملها.
في MCS ، في مكانين لهما وظائف مماثلة ، تم اكتشاف ثغرات SSRF ، لكن كان من المستحيل تقريبًا استغلالها بسبب جدران الحماية وغيرها من أشكال الحماية. بطريقة أو بأخرى ، قام فريق MCS بإصلاح هذه المشكلة على أي حال ، دون انتظار المجتمع.
XSS بدلا من تحميل قذائف
على الرغم من مئات الدراسات المكتوبة ، من عام إلى آخر ، لا يزال XSS (هجوم البرمجة النصية عبر المواقع) هو أكثر نقاط ضعف الويب
شيوعًا (أو
الهجوم ؟).
يعد تنزيل الملفات مكانًا مفضلاً لأي باحث أمن. غالبًا ما يتبين أنه يمكنك تحميل برنامج نصي تعسفي (asp / jsp / php) وتنفيذ أوامر OS ، في مصطلحات pentesters - "load shell". لكن شعبية هذه الثغرات الأمنية تعمل في كلا الاتجاهين: يتم تذكرها وتطوير أدوات ضدها ، لذا فإن احتمال "تحميل القشرة" تميل مؤخرًا إلى الصفر.
كان الفريق المهاجم (يمثله الأمن الرقمي) محظوظًا. حسنًا ، في MCS ، على جانب الخادم ، تم فحص محتويات الملفات التي تم تنزيلها ، ولم يُسمح سوى بالصور. لكن SVG هي أيضا صورة. وما يمكن أن يكون صور SVG خطيرة؟ لأنه يمكنك تضمين أجزاء JavaScript فيها!
اتضح أن الملفات التي تم تنزيلها متاحة لجميع مستخدمي خدمة MCS - مما يعني أنه يمكنك مهاجمة مستخدمين آخرين من السحابة ، أي المسؤولين.
مثال على استخدام نموذج تسجيل دخول للتصيد الاحتيالي باستخدام هجوم XSSأمثلة على استغلال هجوم XSS:
- لماذا تحاول سرقة جلسة (خاصةً منذ الآن في كل مكان ، ملفات تعريف الارتباط HTTP فقط محمية من السرقة باستخدام برامج js النصية) إذا كان النص الذي تم تنزيله يمكنه الوصول إلى واجهة برمجة تطبيقات الموارد على الفور؟ في هذه الحالة ، يمكن أن الحمولة النافعة تغيير تكوين الخادم من خلال طلبات XHR ، على سبيل المثال ، إضافة مفتاح SSH العام للمهاجم والحصول على وصول SSH إلى الخادم.
- إذا كانت سياسة CSP (سياسة حماية المحتوى) تحظر تنفيذ JavaScript ، فيمكن للمهاجم الاستغناء عنها. بتنسيق HTML الخالص ، قم بتكوين نموذج تسجيل دخول مزيف للموقع وسرقة كلمة مرور المسؤول من خلال مثل هذا التصيد المتقدم: صفحة التصيّد للمستخدم بنفس عنوان URL ، ويصعب على المستخدم اكتشافها.
- أخيرًا ، يمكن للمهاجم ترتيب عميل DoS - تعيين ملفات تعريف الارتباط أكبر من 4 كيلوبايت. يكفي أن يفتح المستخدم الرابط مرة واحدة ويصبح الوصول إلى الموقع بأكمله غير متوقع حتى تنظف المتصفح بشكل خاص: في الغالبية العظمى من الحالات سيرفض خادم الويب قبول مثل هذا العميل.
دعونا نلقي نظرة على مثال لنظام XSS آخر تم كشفه ، هذه المرة مع تشغيل أكثر صعوبة. تتيح لك خدمة MCS دمج إعدادات جدار الحماية في مجموعات. تم اكتشاف XSS في اسم المجموعة. كانت خصوصيته أن المتجه لا يعمل على الفور ، وليس عند عرض قائمة القواعد ، ولكن عندما تم حذف المجموعة:
بمعنى ، كان السيناريو كما يلي: يقوم المهاجم بإنشاء قاعدة جدار حماية مع "تحميل" في الاسم ، ويلاحظ المسؤول ذلك بعد فترة من الوقت ، ويبدأ عملية الحذف. وهنا تفي JS الخبيثة أيضًا.
لمطوري MCS ، للحماية من XSS في صور SVG القابلة للتنزيل (إذا لم يكن من الممكن التخلي عنها) ، أوصى فريق Digital Security:
- استضافة الملفات التي تم تحميلها من قبل المستخدمين على مجال منفصل لا علاقة له بـ "ملف تعريف الارتباط". سيتم تنفيذ البرنامج النصي في سياق مجال آخر ولن يشكل تهديدًا لـ MCS.
- في استجابة HTTP للخادم ، أعط العنوان "التصرف في المحتوى: مرفق". بعد ذلك سيتم تنزيل الملفات بواسطة المتصفح ولن يتم تنفيذها.
بالإضافة إلى ذلك ، هناك الآن العديد من الطرق المتاحة للمطورين لتخفيف مخاطر تشغيل XSS:
- باستخدام علامة "HTTP فقط" ، يمكنك جعل رؤوس جلسات ملفات تعريف الارتباط غير قابلة للوصول إلى JavaScript ضار ؛
- تؤدي سياسة CSP المطبقة بشكل صحيح إلى تعقيد تشغيل XSS بشكل كبير للمهاجمين ؛
- تقوم محركات القوالب الحديثة ، مثل Angular أو React ، بمسح بيانات المستخدم تلقائيًا قبل عرضها في متصفح المستخدم.
نقاط الضعف المصادقة اثنين عامل
لزيادة أمان الحساب ، يُنصح المستخدمون دائمًا بتمكين 2FA (المصادقة ثنائية العوامل). في الواقع ، هذه طريقة فعالة لمنع المهاجم من الوصول إلى الخدمة إذا تم اختراق بيانات اعتماد المستخدم.
ولكن هل يضمن استخدام عامل التوثيق الثاني دائمًا سلامة الحساب؟ في تطبيق 2FA ، توجد مشكلات أمنية مثل:
- البحث الخام من رمز OTP (رموز لمرة واحدة). على الرغم من بساطة العملية ، فإن أخطاء كبيرة مثل عدم وجود حماية ضد OTP الغاشمة تصادفها أيضًا الشركات الكبرى: قضية Slack ، وحالة Facebook .
- خوارزمية توليد ضعيفة ، على سبيل المثال ، القدرة على التنبؤ بالكود التالي.
- الأخطاء المنطقية ، على سبيل المثال ، القدرة على طلب OTP لشخص آخر على هاتفك ، كما كان الحال مع Shopify.
في حالة MCS ، يتم تطبيق 2FA على Google Authenticator و
Duo . لقد تم بالفعل اختبار البروتوكول نفسه بمرور الوقت ، لكن تطبيق التحقق من الكود على جانب التطبيق يستحق التدقيق.
يتم استخدام MCS 2FA في عدة أماكن:
- عند مصادقة المستخدم. يوجد هنا حماية ضد القوة الغاشمة: المستخدم لديه فقط بضع محاولات لإدخال كلمة مرور لمرة واحدة ، ثم يتم حظر الإدخال لفترة من الوقت. هذا يمنع القدرة على أداء خرق OTP.
- عند إنشاء رموز النسخ الاحتياطي دون اتصال لتشغيل 2FA ، وكذلك إيقاف تشغيله. هنا ، لم يتم تطبيق الحماية ضد القوة الغاشمة ، مما جعل من الممكن تجديد رموز النسخ الاحتياطي أو تعطيل 2FA بشكل كامل إذا كان هناك كلمة مرور للحساب وجلسة نشطة.
بالنظر إلى أن رموز النسخ الاحتياطي كانت موجودة في نفس نطاق قيم الأسطر كتلك التي تم إنشاؤها بواسطة تطبيق OTP ، كانت فرصة التقاط الرمز في وقت قصير أعلى بكثير.
عملية اختيار OTP لتعطيل 2FA باستخدام أداة Burp: Intruderيؤدي
بشكل عام ، تبين أن MCS كمنتج آمن. أثناء التدقيق ، لم يتمكن فريق Pentester من الوصول إلى VMs للعميل وبياناته ، وتم إصلاح الثغرات الموجودة بسرعة بواسطة فريق MCS.
لكن من المهم هنا ملاحظة أن الأمن عمل مستمر. الخدمات ليست ثابتة ، فهي تتطور باستمرار. وتطوير منتج بالكامل دون نقاط ضعف أمر مستحيل. ولكن يمكنك العثور عليها في الوقت المناسب وتقليل فرصة تكرارها.
الآن تم إصلاح جميع الثغرات المذكورة في MCS بالفعل. ومن أجل تقليل عدد الأشخاص الجدد وتقصير عمرهم ، يواصل فريق المنصة القيام بذلك: