اكتشاف مخاطر التكوين الخاطئ للتطبيقات

ملاحظة المحرر: في أولنا مشاركة مدونة بالنسبة لهذه السلسلة، أعلنا أن Wiz تعمل على توسيع قدراتها في تقييم المخاطر لتشمل تحليل تكوين نظام التشغيل والتطبيقات. ملكنا مشاركة المدونة الثانية كان بمثابة تعمق في قواعد تكوين نظام التشغيل المخصص.

لقد أطلقنا مؤخرًا قواعد تكوين المضيف، مما يتيح للعملاء رؤية مشكلات التكوين على مستوى نظام التشغيل والتطبيق باستخدام نفس النهج بدون وكيل سهل النشر وغير التدخلي الذي تشتهر به Wiz. في منشور المدونة هذا، يسعدنا إطلاق قواعد جديدة للتكوين الخاطئ للتطبيقات عالية الخطورة والتي أصبحت الآن مرتبطة بـ Wiz Security Graph، مما يساعدك على الحماية من تنفيذ التعليمات البرمجية عن بُعد (RCE) والكشف عن المعلومات.

تخيل السيناريو التالي: يستضيف جهاز ظاهري مكشوف للعامة (VM) في البيئة السحابية الخاصة بك خادم Redis، والذي تمت تهيئته بشكل خاطئ للسماح بالوصول غير المصادق من أي عنوان IP. في رأيك، كم من الوقت سيستغرق إصابة هذا الجهاز الافتراضي بشبكة الروبوتات وإساءة استخدامه في عمليات التعدين الخفي؟

عندما يتعلق الأمر بأمن أنظمة التشغيل والتطبيقات، غالبًا ما تركز المؤسسات بشكل أكبر على معالجة نقاط الضعف الحرجة باستخدام التهديدات الشائعة. ومع ذلك، هناك بعض التكوينات الخاطئة التي قد لا ترتبط بأي من الثغرات الأمنية الخطيرة ولكنها يمكن أن تؤدي بنفس السهولة إلى RCE أو الكشف عن المعلومات، مما يجعلها بنفس خطورة نقاط الضعف التقليدية التي تتطلب اهتمامًا فوريًا. على عكس الثغرات الأمنية، يمكن أن تؤثر هذه الأنواع من التكوينات الخاطئة على أحدث إصدار من التطبيق، حتى في بعض الأحيان حتى عند استخدام الإعدادات الافتراضية. تُظهر بياناتنا أن حوالي 20% من جميع المؤسسات لديها تطبيق واحد على الأقل تمت تهيئته بشكل خاطئ والذي يمكن أن يؤدي إما إلى RCE أو الكشف عن المعلومات.

مثلما هو الحال مع ثغرة RCE، قد تسمح التكوينات الخاطئة للتطبيق ونظام التشغيل التي يمكن أن تؤدي إلى RCE للمهاجم باختراق الأجهزة المكشوفة علنًا في بيئتك والانتقال أفقيًا إلى الأنظمة الحساسة، مما يتسبب في التوقف عن العمل وتسرب البيانات وغير ذلك الكثير. يبحث المهاجمون بنشاط عن استغلال هذه الأنواع من التكوينات الخاطئة للوصول إلى بيئتك – يمكن ملاحظة ذلك في GreyNoise على سبيل المثال، من خلال الاستعلام عن الماسحات الضوئية الضارة التي تبحث عن مثيلات Hadoop YARN ResourceManager المكشوفة للعامة والتي تم تكوينها بشكل خاطئ للسماح بتنفيذ أوامر غير مصادق عليها، بما في ذلك شبكة HinataBot المكتشفة مؤخرًا. تتضمن أدوات الأمان الهجومية مثل Metasploit وحدات متاحة بسهولة لاستغلال التكوينات الخاطئة، مثل هذه الوحدة لاستغلال التكوين الخاطئ المذكور أعلاه في Hadoop YARN.

وبما أن المهاجمين الحقيقيين يبحثون عن هذه الأنواع من التكوينات الخاطئة، فإنها تمثل عامل خطر أمني حاسم في السحابة ويجب ألا تمر دون أن يلاحظها أحد. ومع ذلك، قد يكون من الصعب على المؤسسات اكتشاف التطبيقات التي تم تكوينها بشكل خاطئ في بيئتها السحابية باستخدام الحلول التقليدية لأنها غالبًا ما تفتقر إلى التغطية الكاملة ولا تأخذ السياق في الاعتبار، مما يجعل من الصعب فهم أي التكوينات الخاطئة أكثر خطورة من غيرها.

كما هو الحال مع الثغرات الأمنية، يتطلب علاج التكوينات الخاطئة بشكل فعال فهمًا كاملاً لمسارات الشبكة والأذونات المطلوبة للتطبيق، ولهذا السبب يعد السياق مهمًا جدًا. على سبيل المثال، إذا علمنا أن مثيل تطبيق به تكوين RCE خاطئ يتعرض أيضًا للإنترنت ويتمتع بامتيازات عالية في البيئة، فسنحتاج إلى معالجته بأولوية عالية، لأنه يشكل خطرًا كبيرًا على المؤسسة.

وبالمثل، فإن التطبيق الذي يحتوي على بيانات حساسة مستضافة على خادم داخلي يمكن أن يشكل أيضًا خطرًا أمنيًا إذا تمت تهيئته بشكل خاطئ بحيث لا يتطلب أي مصادقة. إذا حصل أحد المهاجمين بطريقة أو بأخرى على وصول أولي إلى البيئة من خلال وسائل أخرى، فقد يتمكن من الانتقال أفقيًا إلى هذا الخادم واستغلال التكوين الخاطئ لوضع أيديهم على البيانات الحساسة.

التعرف بسرعة على مخاطر التكوين الخاطئ للتطبيقات الهامة

تعمل Wiz على توسيع نطاق تقييم المخاطر الخاص بها لتحديد التكوينات الخاطئة للتطبيق التي قد تؤدي إلى RCE أو الكشف عن المعلومات، مما يوفر لك السياق الذي تحتاجه في الرسم البياني للأمان لفهم مدى الأهمية الكاملة للتكوين الخاطئ حتى تتمكن من الاستجابة بشكل مناسب.

تم تطوير قواعد التكوين الخاطئ للتطبيقات المضمنة الجديدة لـ RCE بواسطة فريق أبحاث التهديدات لدينا استنادًا إلى معلومات حول الهجمات الواقعية التي تم فيها استغلال هذه التكوينات الخاطئة، مثل حاويات PostgreSQL التي تم تكوينها بشكل خاطئ والمصابة ببرامج التعدين الخفي Kinsing الضارة. إلى جانب قواعد RCE الهامة الجديدة، أضفنا أيضًا قواعد لتحديد التكوينات الخاطئة للتطبيقات عالية الخطورة والتي يمكن أن تتسبب في الكشف عن المعلومات مثل شجرة الملفات التي يمكن للمستخدمين غير المصادقين اجتيازها.

من خلال ارتباط الرسم البياني الأمني ​​الجديد لقواعد تكوين المضيف، يتم تمكين العملاء بالسياق حول هذه التكوينات الخاطئة لتحديد المجموعات السامة وحل التكوينات الخاطئة لكل من RCE والكشف عن المعلومات بشكل استباقي. يمكن للعملاء أيضًا إنشاء مسارات معالجة للتطبيق الذي تمت تهيئته بشكل خاطئ للتأكد من إمكانية وصول التنبيهات إلى الأشخاص المناسبين في الوقت المناسب، بالإضافة إلى معالجة المشكلة تلقائيًا.

تقديم قواعد التكوين الخاطئ للتطبيقات الهامة الجديدة

فيما يلي بعض الأمثلة على قواعد التكوين الخاطئ الهامة الجديدة للتطبيقات مع تفاصيل حول كيفية تكوين كل تطبيق بشكل خاطئ للسماح بـ RCE أو الكشف عن المعلومات، وإرشادات الإصلاح الخاصة بنا لمنع هذا السيناريو:

تأكد من أن Hashicorp Consul لا يسمح بتنفيذ التعليمات البرمجية التعسفية

تحدد هذه القاعدة مثيل القنصل مع -enable-script-checks تم ضبطه على “صحيح”، مما قد يسمح للمهاجم بتسجيل شيك على وكيل بعيد باستخدام حمولة ضارة, وبالتالي تحقيق RCE. لقد لاحظنا سابقًا أن هذه التقنية تستخدم بواسطة شبكة Dreambus الروبوتية للوصول الأولي إلى البيئات السحابية (T1190)، ونشر نفسها عبر شبكة داخلية، واختطاف الخوادم المصابة للتعدين الخفي (T1496) والانتشار إلى شبكات أخرى.

الإجراء العلاجي المناسب هو تعيين enable-script-checks إلى كاذبة، أو استبدال enable-script-checks مع -enable-local-script-checks

تأكد من أن Jupyter Notebook لا يسمح بالوصول غير المصادق عليه عن بعد

تتحقق هذه القاعدة مما إذا كان المورد يحتوي على Jupyter Notebook مع مجموعة التكوين الهامة التالية:

1. يسمح بالوصول عن بعد من أي عنوان IP، من خلال c.NotebookApp.ip = 0.0.0.0 أو * تعريف

2. لا يتطلب المصادقة، من خلال c.NotebookApp.token = '' أو c.NotebookApp.password = '' التعاريف

معًا، يمكن أن تؤدي حالات التكوين هذه إلى RCE. التوجيه العلاجي لهذه القاعدة هو التأكد ج.NotebookApp.ip تم تعيينه على مضيف محلي أو نطاق IP محدد موثوق به، وأن Jupyter Notebook تم تكوينه بكلمة مرور قوية أو رمز مميز.

تأكد من أن Redis لا يسمح بالوصول غير المصادق عليه عن بعد

تتحقق هذه القاعدة من وجود خادم Redis بامتداد bind التوجيه الذي تم ضبطه على 0.0.0.0 أو *، مما يتيح الاتصال عن بعد بـ Redis من أي عنوان IP، requirepassword تم تعيين التوجيه على كلمة مرور فارغة أو قائمة التحكم بالوصول (ACL). user تم ضبط التوجيه على nopass، وله أيضًا protected -mode no config الذي يسمح بالوصول غير المصرح به، مما يؤدي معًا إلى RCE (يعتمد تأثيره على أذونات عملية Redis على المضيف). تم استهداف مثيلات Redis التي تم تكوينها بشكل خاطئ من خلال عمليات التعدين الخفي بواسطة شبكة الروبوتات HeadCrab، من بين أمور أخرى.

# Redis configuration file example. 
# 
protected-mode no 
bind 0.0.0.0 
user guest +@all ~* nopass 

الإجراء العلاجي في هذه الحالة هو إما التمكين protected-modeأو قم بتعيين كلمة مرور قوية أو تأكد من تعيين تعريف الربط على نطاق IP موثوق به أو مضيف محلي محدد.

تحديد المجموعات السامة على الرسم البياني الأمني

يتم الآن عرض نتائج قاعدة تكوين المضيف على الرسم البياني للأمان من Wiz، مما يسمح لك بفهم المجموعات السامة في بيئتك والتي تتضمن تطبيقات تم تكوينها بشكل خاطئ وتتطلب اهتمامًا فوريًا. يضيف هذا طبقة مهمة أخرى من السياق إلى قواعد تكوين المضيف الحالية لدينا من خلال السماح لك بربط التكوينات الخاطئة مع عوامل الخطر الأخرى في بيئتك وإعطاء الأولوية للتكوينات الخاطئة الأكثر تأثيرًا.

في المثال الموضح أدناه، يمكننا رؤية مثيل Consul الذي تم تكوينه للسماح بالوصول عن بعد (كما هو موضح أعلاه). كما ترون على الرسم البياني، فإن هذا الجهاز لديه أيضًا مسار يعرضه للإنترنت، ومخاطر امتياز عالية يمكن أن تؤدي إلى حركة جانبية، كل هذا معًا يؤدي إلى مزيج سام يمثل خطرًا بالغ الأهمية.

ابدأ الآن في تحديد التكوينات الخاطئة الهامة للتطبيق والتي تؤدي إلى مجموعات سامة في بيئتك على Wiz Security Graph. يمكنك معرفة المزيد في مستندات Wiz (يلزم تسجيل الدخول). إذا كنت تفضل العرض التجريبي المباشر، فنحن نحب التواصل معك.