غالبًا ما تكون بيانات الشركة سرًا تجاريًا. قد يؤدي تسريبها إلى توجيه ضربة إلى السمعة أو الخسائر المالية أو حتى الإفلاس. لذلك ، يجب أن تكون متطلبات الأمان لمنتج B2B عالية جدًا. عند إنشاء منتج جديد - Corporate Mail.ru - أولينا اهتمامًا خاصًا لمسألة أمانه.
بريد الشركة Mail.ru هو إصدار محلي من بريد B2C المعروف Mail.ru. مقارنةً به ، يحتوي على عدد من التعديلات للعمل في بيئة جديدة - دائرة العملاء.
لجعل عملائنا واثقين من سلامتهم ، قررنا الخضوع لعملية تدقيق في شركة تابعة لجهة خارجية وإصلاح جميع أوجه القصور التي وجدناها قبل عرض المنتج في السوق. للقيام بذلك ، لجأوا إلى واحدة من أكثر الشركات شهرة في مجال أمن المعلومات - الأمن الرقمي.
نتائج التدقيق تحت الخفض.
تنفيذ التعليمات البرمجية عن بعد في uWSGI
هناك أطر عمل مختلفة لبناء تطبيقات ويب Python. عادةً ما يتم استخدام واجهة بوابة خادم الويب Python (WSGI) للتواصل بين تطبيق الويب وخادم الويب. بالإضافة إلى ذلك ، يتيح لك استخدام WSGI تنفيذ مكونات البرامج الوسيطة.
لتوحيد الاتصال بين تطبيق ويب Python وخادم ويب مثل Apache أو Nginx ، تم تطوير PEP 0333 ، متبوعًا بـ PEP 3333 ، الذي يصف واجهة WSGI. لن نتطرق إلى كيفية عمل WSGI ، لكننا سنخبرك عن خادم شائع يدعم واجهة WSGI - uWSGI.
يمكن لخادم uWSGI العمل في وضع خادم الويب العادي وفي "وضع WSGI" ، وتبادل البيانات مع خادم ويب آخر ، مثل Nginx. في نفس الوقت ، يستخدم Nginx البروتوكول الثنائي الذي يحمل نفس الاسمuwsgi ، وهو أمر مثير للاهتمام لمجرمي الإنترنت بسبب وظائفه الغنية. عند تحليل "الأجزاء الداخلية" للحل ، تم العثور على خادم uWSGI ، والذي يمكن لجميع المكونات الداخلية للمنتج الوصول إليه.
كانت المشكلة أنه في بروتوكول uwsgi ، يمكنك استخدام ما يسمى بالمتغيرات السحرية التي تتيح لك تكوين خادم uWSGI ديناميكيًا. من بين هذه المتغيرات هناك متغير
UWSGI_FILEيسمح لك بتحميل تطبيق ديناميكي جديد إذا قمت بتحديد المسار إلى الملف في المتغير. كما اتضح فيما بعد، يمكن التعامل مع uWSGI خادم دوائر مختلفة في هذا السبيل، على سبيل المثال section، fd، call، أو الأكثر إثارة للاهتمام - exec. وبالتالي ، يمكنك تمرير المتغير كقيمةexec://<cmmand>لتنفيذ أمر bash تعسفي. لتحليل هذه المشكلة ، تمت كتابة استغلال ، متاح على جيثب .
مثال على استعلام يقوم بتنفيذ أمر.
لا يمكن استغلال هذه الثغرة الأمنية إلا إذا كان المهاجم:
- موجود بالفعل على الشبكة الداخلية للمنتج ، على سبيل المثال ، تم اختراق أحد المكونات. قد يسمح له ذلك باختطاف مكون جديد والوصول إلى بيانات جديدة ومواصلة الهجوم.
- لديه SSRF مع القدرة على إرسال بيانات عشوائية عبر TCP (على سبيل المثال استخدام
gopher://). في هذا السيناريو ، يمكن للمهاجم الوصول إلى داخل المنتج.
من الجدير بالذكر أن تطبيقات واجهات CGI للغات أو أطر البرمجة الأخرى يمكن أن تكون عرضة للخطر أيضًا ، على سبيل المثال ، استغلال من نفس مستودع FastCGI. هذا لا يعني أن هذه ثغرة أمنية بالمعنى المعتاد ، بل هي سمة من سمات خوادم CGI ، لذلك تحتاج إلى تقييد الوصول إلى هذه الخوادم قدر الإمكان.
تجاوز حماية CSRF
مع إدخال آليات الأمان المختلفة في المتصفحات ، تختفي الهجمات من جانب العميل على الويب الحديث تدريجيًا. ينطبق هذا أيضًا على CSRF: لقد نفذت المتصفحات بالفعل دعمًا لملف تعريف ارتباط SameSite ، على الرغم من أنه إذا تم تكوينه بشكل غير صحيح ، فقد لا تزال هناك ثغرات. بالإضافة إلى ذلك ، تسمح العديد من الأطر الشائعة للمطورين بتكوين حماية CSRF بسهولة ، ولكن بعض الأخطاء أو الثغرات غير الحرجة يمكن أن تتحول إلى هجوم CSRF محتمل. تم العثور على مثل هذه الأخطاء في تطبيق التقويم المتضمن مع منتجنا.
يحتوي التطبيق على واجهة برمجة تطبيقات تتيح لك تنفيذ إجراءات على أحداث وتقويمات المستخدم ، على سبيل المثال: تعديلها أو عرضها أو حذفها. للإشارة إلى الكائن ، يتم تمرير معلمة UID في مسار URL ، وهو المسؤول عن معرف التقويم أو الحدث. تبدو هكذا:
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
بشكل افتراضي ، يتم إنشاء UID بشكل عشوائي ولا يمكن أن يتأثر به المستخدم. ولكن في التطبيق ، تم العثور على مكانين يمكن للمستخدم من خلالهما تغيير UID.
الأول هو استيراد الملفات بتنسيق ICS (تنسيق خاص للتقويمات والأحداث) ، فهي تحتوي على حقل UID خاص يتحكم فيه المستخدم عند الاستيراد. في هذه الحالة ، بعد استيراد الأحداث ، ستبقى معرّفات UID الخاصة بها كما تم نقلها في الملف. أيضًا ، لا يوجد تصفية لهذه المعلمة. وبالتالي ، يمكن للمستخدم إنشاء حدث مع UID تعسفي.
والثاني هو القدرة على تغيير تقويم UID عند تحريره. يمكن القيام بذلك عن طريق اعتراض طلب تحرير التقويم وتغيير حقل UID ببساطة. لم يكن هناك تصفية هنا أيضًا.
ميزة أخرى مهمة: تنفذ واجهة برمجة التطبيقات حماية CSRF ؛ لهذا ، يتم تمرير معلمة خاصة في معلمات GET ، والتي تلعب دور كل من مفتاح API ورمز CSRF. يتم إضافته عبر JavaScript لجميع طلبات API. يعد تمرير رموز CSRF في معلمات GET ممارسة سيئة ، وفي هذه الحالة ، قد تتسرب الرموز المميزة من خلال المرجع أو سجلات التطبيق أو سجل المتصفح.
ضع كل شيء معا. يمكن للمهاجم التحكم في معرّفات UID للكائن في تطبيق ومشاركة الوصول إلى كل من الأحداث والتقويمات مع مستخدمين آخرين. في هذه الحالة ، سيرى المستخدمون نفس UID ، وعندما يبدأون في العمل مع مثل هذا الكائن ، سيتم تنفيذ الطلبات باستخدام UID الذي يتحكم فيه المهاجم. باستخدام هذا ، يمكن للمهاجم إنشاء كائن بمعرف UID مثل هذا:
../../../AnyPathTo?anyparam=value&
الآن ، عندما يقوم المستخدم بتنفيذ إجراء على الكائن ، سيتم إنشاء طلب:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
ثم سيتم أيضًا إضافة رمز مميز إليها ، حيث تلعب دور رمز CSRF المميز:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
وأخيرًا ، عند إجراء الطلب ، يقوم المتصفح بتطبيع التسلسل "
../" ، ونتيجة لذلك ، سيتم إرسال الطلب إلى
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
الآن يمكن للمهاجم إجبار المستخدم على إرسال طلب إلى التطبيق عبر مسار عشوائي مع معلمات عشوائية ورمز CSRF صحيح. يبقى أن نفهم ما هي طرق الطلب التي يمكننا تنفيذها.
اتضح أنه بسيط: عند التحرير ، يتم إرسال PUT ، عند الحذف ، الحذف ، وعند المشاهدة ، GET (يتم استخدام POST للإنشاء ، ولا يمكننا إجبار الضحية على استخدامه). باستخدام DELETE ، يمكن للمهاجم إجبار متصفح المستخدم على تنفيذ طلب لحذف كائن من المستخدم. مكافأة منفصلة للمهاجم هي أنه عندما يقوم المستخدم بتحرير كائن ، يتم إرسال طلب PUT مع نص الطلب. عند تحرير التقويم ، سيحتوي نص الطلب على JSON ، والذي يحتوي على جميع معلمات التقويم الحالي. أي أن المهاجم الذي أنشأ التقويم "الضار" يتحكم في هذه المعلمات. إذا نجح المهاجم في إعادة توجيه طلب تحرير من التقويم الضار إلى التقويم الخاص للمستخدم ، فسيتم تطبيق جميع خصائص التقويم الضار على خصائص تقويم الضحية.يمكن أن يؤدي ذلك إلى الكتابة فوق الوصول إلى التقويم لأنه أحد خصائص التقويم المحددة في JSON.
القدرة على الهجوم MITM
يعد اختراق متسلل للشبكة الداخلية للشركة وضعًا خطيرًا محفوفًا بالعواقب الوخيمة. لذلك ، أثناء تدقيق المنتج ، كانت إحدى مهامنا هي العثور على عيوب في بنية النظام يمكن أن تساعد متطفلًا على التحرك عبر المجال أو تحسين الهجمات الخارجية.
إحدى الميزات الرئيسية للمنتج هي التكامل مع Active Directory. يتم تنفيذه للمصادقة عبر LDAP وجمع الرسائل من خادم Exchange ، في هذا المثال سنركز على ActiveSync. بالنسبة للمهاجم ، يعد هذا هدفًا مثيرًا للاهتمام لأنه يتم تمرير حسابات المستخدمين وكلمات المرور بين المنتج و Active Directory أثناء الاتصال. من خلال الوصول إلى الاتصالات ، سيتمكن المهاجم من سرقة الحسابات وسيكون على بعد خطوة واحدة من اختراق المجال.
في الحلول الداخلية وعلى خوادم الشركات ، غالبًا ما تكون هناك مشكلة في الاستخدام غير الصحيح لـ TLS أو عدم وجودها على الإطلاق ، بينما ليس من الصعب تنفيذ TLS لخدمة ما. عادة ما يكون هذا نتيجة لحقيقة أن الشبكة الداخلية للشركة تعتبر أكثر أمانًا ، ولا يضيع مسؤولو الشركة الوقت في إنشاء البنية التحتية للمفاتيح العمومية الصحيحة وإصدار الشهادات لجميع الخوادم.
الهجوم الأكثر شيوعًا داخل شبكات الشركات هو MITM. غالبًا ما يسمح هذا النوع من الهجوم بالوصول داخل الدليل النشط للشركة. في الوقت نفسه ، ليس من الممكن دائمًا للمهاجم أن يهاجم التفاعل من خادم إلى خادم داخل شبكة الشركة ؛ في أغلب الأحيان ، أثناء اختبارات الاختراق ، يقع هو أو نموذجه في شريحة شبكة مستخدم لا يوجد فيها خادم Exchange أو وحدة تحكم مجال. بالإضافة إلى ذلك ، في حالتنا ، لا يستخدم المنتج بروتوكولات تحليل اسم البث مثل NBNS و LLMNR و mDNS ، لذا فإن انتحال هذه البروتوكولات لن يسمح بتنفيذ MITM. وبالتالي ، من أجل نجاح MITM بين الحل والخوادم الأخرى ، من الضروري للمهاجم الوصول إلى الشبكة حيث تم تثبيت أحد هذه المكونات. من الممكن أحيانًا تحقيق هذا الهدف - هناك أجهزة توجيه أو خوادم ضعيفة ،والتي تسمح لك في النهاية بالوصول إلى شبكة معينة.
في حالتنا ، أثناء التحليل ، اتضح أن التكامل مع Active Directory عرضة لهجمات MITM.
عندما يقوم المستخدم بإدخال اسم مستخدم وكلمة مرور ، يرسل النظام طلبي LDAP إلى وحدة تحكم المجال. يقوم الطلب الأول بإرجاع قائمة عناوين البريد ، وإذا كان تسجيل دخول المستخدم موجودًا في هذه القائمة ، فسيتم إرسال الطلب الثاني ، وهو مصادقة LDAP البسيطة. يتم إرسال البيانات بنص واضح دون استخدام SSL / TLS ، أو بالأحرى ، لا يتم استخدام LDAPS (LDAP عبر SSL). يسمح هذا للمهاجم ، حتى في حالة هجوم MITM السلبي ، بالحصول على حسابات المستخدمين المصرح بها حاليًا في المنتج.
المشكلة الثانية: عند الاتصال بخادم Exchange باستخدام بروتوكول ActiveSync لتجميع الرسائل الواردة ، لم يقم النظام بمصادقة شهادة TLS للخادم. في هذه الحالة ، يمكن للمهاجم تنفيذ هجوم MITM نشط ، عند تلقي اتصال ، يمكنه تقديم شهادة موقعة ذاتيًا ، وإنشاء اتصال وتوكيل البيانات إلى خادم Exchange ؛ عندئذٍ ستكون MITM غير مرئية ، ويمكن للمهاجم الحصول على بيانات اعتماد المستخدم ، والتي يتم إرسالها في بروتوكول ActiveSync.
من خلال استغلال هذه الثغرات الأمنية ، يمكن للمهاجم نظريًا الحصول على حسابات مستخدمين ثم استخدامها في هجوم على مجال Active Directory. بشكل منفصل ، تجدر الإشارة إلى أن الاستخدام الصحيح لـ TLS هو مهمة ضرورية للشركة التي تنفذ الحل.
نتيجة
نواجه باستمرار هجمات القراصنة واكتسبنا خبرة قوية في كيفية محاربتها. نعتقد أن المنتجات التي نضعها في محيط العميل يجب أن تكون آمنة قدر الإمكان ، بما في ذلك بناءً على نتائج الفحوصات المستقلة. Mail.ru للشركات هو مجرد منتج من هذا القبيل.
لقد واجهتنا مهمة شاقة: نقل قاعدة رمز كبيرة مع العديد من الخدمات الصغيرة إلى البنية التحتية للعميل ، بحيث يعمل البريد بمفرده في معظم الأوقات ، دون إخفاقات وتدخلات المشرف.
لقد طلبنا من المراجعين إيلاء أكبر قدر من الاهتمام لتغيير التفويض (يستخدم بريد الشركة إعلان العميل) وواجهة برمجة تطبيقات البريد الرئيسية - تم تحليل الكود المصدري لهذه المكونات بالتفصيل. نتيجة لذلك ، كانت أوجه القصور التي تم العثور عليها مرتبطة بشكل أساسي بطوبولوجيا الشبكة المتغيرة والتعديلات الخاصة بالحل الداخلي.
بالنسبة لبقية المكونات (التقويم ، Mail.ru لواجهة إدارة الأعمال) ، تم استخدام نموذج المربع الرمادي: تفاعل المدققون مع الخدمة بامتيازات المستخدمين العاديين ، ولكن يمكنهم الاتصال بالحاوية مع التطبيق قيد التشغيل ، ويمتلكون جزئيًا كود مصدر API ويمكنهم توضيح التفاصيل مع المطورين.
كان التدقيق مفيدًا جدًا بالنسبة لنا. لقد وجدنا عددًا من أوجه القصور في بعض المكونات ، والتي قمنا بتصحيحها على الفور لتقديم منتج آمن إلى السوق. في نفس الوقت ، كنا مقتنعين بمستوى الحماية العالي لمعظم المكونات الأخرى. نحن نخطط لإجراء مثل هذه المراجعات على أساس منتظم - نريد أن يكون منتجنا دائمًا في مقدمة الحلول المحلية الأكثر أمانًا ، ليس فقط في رأينا ، ولكن أيضًا في رأي المراجعين المستقلين.
أمان بريد الشركة هو مزيج من أمان المنتج نفسه والبنية التحتية للعميل. أي أن مسؤولية أمان بيانات الشركة تقع على عاتقنا وعلى المطور والعميل نفسه. بالإضافة إلى ذلك ، قمنا بصياغة توصيات بشأن الممارسات التي أثبتت جدواها لحماية البنية التحتية من العيوب وتقديم المشورة للعملاء دائمًا أثناء تثبيت منتجنا.