هذه هي الحلقة الرابعة في سلسلة من الوظائف حول المكونات الضارة، حيث نقدم زيجيني نهج للتعامل مع هذا التهديد، كجزء من تغطيتنا ل Open Source Security.
لقد رأينا أن الثقة الزائدة في مكونات المصدر المفتوح ذات المصدر غير المؤكد يتم استغلالها من قبل مرتكبي الأخطاء من جميع الأنواع لتقديم سلوك غير متوقع يتم تشغيله إما في أجهزة المطورين، CI/CD الأنظمة، أو مُدمجة في برامج المؤسسة الضحية، بحيث يتم تمريرها إلى عملاء المؤسسة. لقد قمنا بتحليلها الحلقة 2 الهجمات التي تستخدم السجلات العامة لتوصيل البرامج الضارة وما تعلمناه بعد مشاهدة كيفية عمل الجهات الفاعلة السيئة، وفي السابق الحلقة 3 تم فحص الضوابط التي تعمل (وتلك التي تفشل) ضد هذا التهديد.
والآن حان الوقت للنظر في نهجنا تجاه المشكلة. في هذه الحلقة، نعرض الإستراتيجية التي نتبعها في Xygeni من أجلنا الإنذار المبكر بالبرامج الضارة نظام (MEW). كيف يعمل هذا النظام متعدد المراحل في الوقت الفعلي عندما يتم إصدار إصدار حزمة جديد، وكيف يتم التقاط الأدلة من مصادر مختلفة، وكيف يتم الفرز، وما هي معايير التصنيف التي نتبعها، ولماذا لا تزال هناك حاجة إلى بعض التحليل اليدوي لتأكيد الطبيعة من مرشح حزمة ضارة. سنشرح أيضًا كيف نساعد NPM وGitHub وPyPI وغيرها من البنى التحتية الرئيسية في الأنظمة البيئية مفتوحة المصدر لتقليل وقت بقاء البرامج الضارة.
استخدم pipeline
يقوم Xygeni Malware Early Warning (MEW) بمعالجة المكونات بشكل مستمر، إما حزم tarballs للمكتبات والأطر لأنظمة البرمجة المدعومة مثل JavaScript/Node أو Python، أو صور حاويات Docker/OCI، أو الملحقات والمكونات الإضافية للأدوات مثل IDEs أو CI/CD الأنظمة. يتم نشر هذه المكونات في سجلات عامة بمستويات مختلفة من فحص المستخدمين.
فيما يلي عرض تخطيطي لكيفية عمل النظام:
استخدم مكتشف تحصل العملية على خلاصة أحداث النشر. حدث النشر هو إنشاء إصدار جديد لمكون جديد أو موجود. نظرًا لأن السجلات الشائعة لا توفر آلية نشر فرعية للمستهلكين المهتمين، فغالبًا ما يتم ذلك عن طريق استطلاع السجل للأحداث الأخيرة. مشروع ممتاز من OSSF، خلاصات الحزمة، دعم السجلات الشائعة مثل PyPI أو Maven Central، وتوفر واجهة موحدة قائمة على الخلاصة. في MEW أضفنا بعض التطبيقات المحددة التي تقلل من وقت الانتظار، على سبيل المثال مع نسخة طبق الأصل من قاعدة بيانات CouchDB التي يستخدمها NPM والتي تتزامن مع قاعدة بيانات التسجيل العامة.
في Xygeni، لدينا مخزون[1] لجميع المكونات (بشكل مباشر أو غير مباشر) التي تستخدمها برامج عملائنا. يتم تغذية إحداثيات مكونات العملاء بانتظام إلى وزارة الكهرباء والمياه لتحديد أولويات التحليلات: تتم معالجة المكونات المستخدمة من قبل عملائنا في وقت سابق. تعتمد الأولوية أيضًا على سمعة الناشر ومدى أهمية المكون، لذلك يتم أيضًا إعطاء الأولوية للمكونات القادمة من الناشرين ذوي السمعة المنخفضة.
استخدم تحليل ثم تستهلك المكونات المعلقة في قائمة انتظار الأولوية. عند تحديد إصدار مكون للتحليل، يتم تنزيل القطران الخاص به من السجل. لاحظ أنه يتم تحليل المكون الثنائي المعبأ: تأتي معظم المكونات مفتوحة المصدر عادة من مستودع مفتوح المصدر، غالبًا على github.com، والذي يستخدم للسياق فقط، ويتم البحث دائمًا عن البرامج الضارة في tarball المكون لأن الجهات الفاعلة في التهديد بشكل منهجي تكذب بشأن المصادر التي يزعمون أنهم استخدموها في بناء مادة القطران المكونة التي أطلقوها.
من وجهة نظر المستخدم
أسمعك تفكر: كيف يمكنني الاستفادة من معرفة إصدار الحزمة الضارة مبكرًا؟ في الحلقة "تشريح الحزم الضارة: ما هي الاتجاهات؟" لقد رأينا أن إجمالي وقت المكوث في نطاق الأيام، في حين أن الإخطار الأول من وزارة الكهرباء والمياه إلى العملاء الذين يستخدمون المكون المتأثر يقع في نطاق الدقائق. مع حاجز حماية بسيط[2] يمكنك حظر الإنشاء (هناك مستويان للتنبيه، أحدهما آلي بالكامل عندما يستنتج المحرك وجود برامج ضارة محتملة وإشعار لاحق عندما يؤكد فريق الأمان لدينا عن طريق الفحص اليدوي وجود برامج ضارة). عادةً ما يكون الانتظار حتى يؤكد السجل وجود البرامج الضارة وإزالتها من السجل متأخرًا جدًا بسبب فترة التعرض الطويلة.
قد تستخدم المؤسسة حاجز حماية يتحقق مما إذا كان هناك مكون يحتوي على برامج ضارة محتملة (في أي من مستويي التنبيه) أو، عبر واجهة برمجة التطبيقات، تعرف بسرعة ما إذا كانت أي من التبعيات المباشرة أو غير المباشرة في مشروع البرنامج تستخدم مكونًا ضارًا.
كيف تعمل وزارة الكهرباء والمياه: التفاصيل الداخلية
جوهر: محرك الكشف عن البرامج الضارة
يستخدم المحلل أجهزة كشف مختلفة لالتقاط الأدلة على ارتكاب المخالفات. تجمع أجهزة الكشف بين التحليل الثابت وتحليل القدرات وتحليل السياق[3]، كما هو موضح في المنشور السابق من هذه السلسلة.
في Xygeni، لدينا فريق هندسي يتمتع بخبرة طويلة في التحليل الثابت، وهذا هو الفرق الرئيسي مع حلول مكافحة البرامج الضارة الأخرى. لاحظ أنه بالنسبة لبعض الأنظمة البيئية، تحتوي حزمة القطران إما على كود المصدر (مثل JavaScript أو كود TypeScript لحزم NPM، أو مصادر Python لحزم PyPI)، أو كود مجمع قريب بدرجة كافية من كود المصدر للتحليل الثابت (على سبيل المثال، كود بايت في ملفات JAR لـ Maven) . بالنسبة للآخرين، مثل صور الحاويات، تعد الملفات التنفيذية الثنائية شائعة، لذا فإن استنتاج القدرات هو التقنية المستخدمة، إلى جانب الكشف عن البرامج الضارة التقليدية استنادًا إلى قواعد YARA وتوقيعات البرامج الضارة.
يرجى ملاحظة أن التقنيات البسيطة مثل التعبيرات العادية أو التوقيعات ليست مناسبة لاكتشاف السلوك الضار. تخيل اكتشاف قطارة أو برنامج تنزيل: يوجد بعض التعليمات البرمجية أو البرنامج الثنائي في الحزمة أو تم تنزيله من مجال خارجي، وليس مرتبطًا بالمكون (يمكن أن يكون واحدًا من ملف قائمة كبيرة من النطاقات التي اشتراها ممثل التهديد[4]، أو المجال الشرعي لتجنب الكشف). يتم بعد ذلك تنفيذ هذا الرمز باستخدام إحدى الوظائف المخصصة لذلك. يمكن تحويل الكود لإخفاء عنوان URL للتنزيل أو الوظيفة المستخدمة لتشغيل الكود الذي تم تنزيله. هناك حاجة إلى تحليل كامل لتدفق البيانات لاكتشافه، باستخدام الآلية الكاملة للتحليل الثابت، أو تنفيذ وضع الحماية (إذا تم استيفاء شروط تشغيل السلوك الضار بالفعل) يمكن اكتشاف ذلك في الحالة العامة.
يتبع ممثلو التهديد نفس التقنيات وتم تصميم وتنفيذ أجهزة الكشف عنهم. هناك أيضًا بعض خطوات المعالجة المسبقة، على سبيل المثال لإزالة التشويش، والتي غالبًا ما تكون مطلوبة للكشف عن السلوك المخفي.
إضافة السياق
تستخدم بعض أجهزة الكشف معلومات السياق. على سبيل المثال، يشكل عدم التطابق بين الإصدار الموجود في سجل المكونات والعلامة/الإصدار في مستودع GitHub المرتبط دليلًا قويًا على أنه ربما حصل ممثل سيء على بيانات اعتماد النشر للسجل ولكن ليس لمستودع GitHub. هجمات مثل تلك التي تؤثر على بائع محفظة العملات المشفرة دفتر الحسابات يمكن اكتشافه بسهولة من خلال عدم التطابق هذا.
A درجة الخبث يتم حساب (MS) من نتائج تشغيل أجهزة الكشف، بناءً على قوة الأدلة التي تم التقاطها. ليست كل النتائج متماثلة، وترتيب التنفيذ ذو صلة.
سمعة المستخدم والمكونات
لم يتم إنشاء جميع مطوري البرامج مفتوحة المصدر على قدم المساواة!
قد يتم اختراق حساب NPM الخاص بمطور حسن السمعة (يحدث هذا حتى مع الأشخاص المهتمين بالأمان)، ويتم نشر البرامج الضارة باستخدام هذا الحساب. من الواضح أن السمعة يجب أن تنهار فجأة، ولن تستعيد مجدها السابق إلا عندما يتم استرداد الحساب المختطف ويقوم المطور بإصلاح الظروف التي أدت إلى الاستيلاء على الحساب. من الصعب اكتساب السمعة ولكن من الممكن أن تضيع في لحظة.
قمنا في وزارة الكهرباء والمياه بتطبيق نظام شامل لإدارة السمعة لمكافأة السلوك الإيجابي ومعاقبة الأنشطة المشبوهة. يبدأ هذا النظام بالمستخدمين الجدد في موقف محايد ويقوم بتعديل سمعتهم بناءً على أنشطتهم المستمرة.
تتحسن سمعة المستخدم من خلال الإجراءات الإيجابية مثل الحفاظ على حسابات وسائل التواصل الاجتماعي النشطة، وتمكين المصادقة متعددة العوامل، والمساهمة بانتظام في المشاريع، والتوقيع commitمع مفاتيح يمكن التحقق منها. على العكس من ذلك، تتدهور السمعة بسبب الإجراءات العدائية مثل نشر البرامج الضارة، واستخدام عناوين البريد الإلكتروني التي يمكن التخلص منها، وعدم التوقيع commitق، أو عرض أنماط غير عادية في المساهمات.
الهدف الأساسي لنظامنا هو ضمان بيئة آمنة وجديرة بالثقة. ويحقق ذلك من خلال تعديل سمعة المستخدم ديناميكيًا استنادًا إلى عوامل مختلفة، مع احترام مخاوف الخصوصية والقيود المفروضة على السجلات المختلفة.
يتم حساب درجة السمعة الداخلية للمستخدم (الانضمام إلى السجل وحساب github عندما يكون ذلك ممكنًا)، جنبًا إلى جنب مع درجة الضرر المستخدمة أثناء تصنيف المكون قيد التحليل، ولتأهيل الأشخاص الخاضعين لمنشور المكون بشكل أفضل.
تم العثور على أدلة على السلوك الضار. وماذا في ذلك؟ عملية المراجعة اليدوية
يقوم المصنف الحالي بتعيين إصدار المكون الذي تم تحليله في إحدى الفئات "الضارة المؤكدة" أو "ربما تكون ضارة" أو "عالية المخاطر" أو "منخفضة المخاطر" أو "غير ضارة" استنادًا إلى الحدود القصوى للنتائج التي تكثف النتائج وسمعة المستخدم/المكون. يؤدي التصنيف إلى فئات "عالية الخطورة" أو "من المحتمل أن تكون ضارة" إلى تشغيل المراجعة اليدوية والإخطار الأول. يتم تعيين فئة "البرامج الضارة المؤكدة" بعد المراجعة اليدوية أو عندما يتطابق الدليل مع نفس الدليل الخاص بإصدار سابق تم التأكد من أنه ضار.
عند وجود أدلة كافية على السلوك الضار المحتمل، يتم إرسال التنبيه الأول (تنبيه العزل) إلى المؤسسات المتضررة. كما ذكرنا من قبل، قد يؤدي ذلك إلى منع تثبيت أو إنشاء البرنامج الذي يعتمد على المكون المعزول.
وهذا يخلق مشكلة في وزارة الكهرباء والمياه الداخلية dashboard لذلك يمكن لمحللي الأمان بدء عملية المراجعة اليدوية للمكون. يمتلك الفريق أدوات متخصصة (وضع الحماية، وأدوات إزالة التشويش، والتوزيع لأبحاث البرامج الضارة، وأدوات الإبلاغ عن البرامج الضارة) لإجراء تقييم سريع لطبيعة إصدار المكون قيد التحقيق. تتم مراجعة معظم البرامج الضارة ("الأنشوجة" أو المكونات الضارة غير المعقدة).
تنتهي نتيجة المراجعة في أي منهما خزنة، لذلك وجد محرك التحليل التلقائي نتيجة إيجابية كاذبة يتم استخدامها كملاحظات لمصنف التعلم الآلي لتعلم النمط؛ أو مؤكدة الخبيثة، لذلك يتم الكشف عن المكون بشكل مسؤول باعتباره ضارًا للسجل العام، بعد عملية الإبلاغ. ويتم إرسال إشعار ثانٍ إلى المنظمات المتضررة، والتي بدورها قد تقوم بذلك إلغاء عزل المكون، أو حظره بالتأكيد من عملية ترقية الإصدار أو جدار حماية المكون المستخدم في السجل الداخلي الخاص بهم.
يتيح لنا هذا الإعداد تحليل عشرات الآلاف من الإصدارات الجديدة يوميًا وتحديد العشرات التي من المحتمل أن تكون ضارة، والتي نقوم بعد ذلك بمراجعتها يدويًا. تذكر من الحلقة السابقة أن واحدًا من كل عشرة آلاف هو معدل المكونات الضارة التي نراها حاليًا في البرية.
تقديم التقارير إلى السجل
لقد وجدنا أن معظم السجلات العامة، وهي أحد الركائز الأساسية للبنية التحتية مفتوحة المصدر، توفر آليات محدودة إلى حد ما للإبلاغ عن المشكلات الأمنية، والمكونات الضارة على وجه الخصوص. إننا نكافح من أجل تحسين التنظيم الأساسي لعملية إعداد التقارير. عادةً ما نتلقى على الأكثر رسالة بالبريد الإلكتروني من فريق الأمان في السجل تؤكد إزالة المكون من السجل.
في بعض الأحيان يتم إساءة استخدام السجل، مما يؤدي إلى انتهاك شروط الاستخدام الخاصة به، ولكن دون التسبب في سلوك ضار في البرنامج الذي تم تسليمه. يتم أيضًا إبلاغ السجل بذلك، ولكن لا يتم إخطار المؤسسات به للحد من الضوضاء.
العمل المستقبلي
توجد حاليًا العديد من التحسينات على خريطة الطريق. أولا وقبل كل شيء، أ البوابة العامة لصحة مكونات نظام التشغيل، ولا سيما فيما يتعلق بالأدلة التي تم العثور عليها عن الضرر المحتمل، وهو قيد التطوير حاليًا. يهدف هذا إلى تقديم مساهمة متواضعة لمجتمع المصادر المفتوحة. ابقوا متابعين.
تطور مستمر آخر هو تحسين مصنف التعلم الآليسيتعلم MEW من التصنيفات السابقة. يُستخدم متجه النتائج من كاشفات المحرك، بالإضافة إلى درجة الخبث المُشتقة ودرجة السمعة لكلٍّ من المكون والناشر ("الدليل الموجود") كمدخلات لنظام تعلُّم آلي يُحدِّث نموذج التصنيف. يكون متغير الإخراج ببساطة إذا أكد السجل ما إذا كان المكون خبيثًا. يُطلق على هذا الاسم الرمزي "أوراكل"، وسيساعد في تحديد أفضل.cisمؤهل، مصمم ليكون سليمًا (تذكرًا عاليًا أي لا يفوت المكونات الضارة) ولكن مع عدد أقل من الإيجابيات الخاطئة (لا يبلغ عن المكونات الآمنة على أنها ضارة).
A درجة الأهمية ستتم إضافتها لمعايير تحديد الأولويات، إلى جانب الانتماء إلى مجموعة تبعيات العملاء، والسمعة المنخفضة للناشر. ومن الواضح أنه ينبغي النظر في المشاريع ذات التأثير والأهمية الأكبر في وقت مبكر لتحليلها. لن نقوم بإعادة اختراع العجلة هنا، ونتبع درجة أهمية المشروع مفتوح المصدر.
دعم النظم البيئية الإضافية قيد التطوير. توجد تقنيات وأدوات واسعة النطاق مثل مكونات PHP أو Jenkins الإضافية في خريطة الطريق.
نحن نستكشف أيضًا ما إذا كان من الممكن مساعدة عملية المراجعة اليدوية باستخدام الذكاء الاصطناعي لتبسيط التحليل للمكونات الضارة القليلة الأكثر تعقيدًا.
في الجزء التالي والأخير من هذه السلسلة، "استغلال المصدر المفتوح: ما يمكن توقعه من الأشرار"، سنركز على أحدث الطرق التي يستخدمها الخصوم لجعل الهجمات أكثر سرية، ويصعب اكتشافها، وأكثر استهدافًا لصناعات محددة، وأكثر ربحية. هل سيتم تنفيذ هجمات برامج الفدية باستخدام هذه السيارة؟ كيف يستفيد الأشرار من أدوات الذكاء الاصطناعي لتقديم برامج ضارة أكثر تعقيدًا؟ هل المشاريع الشعبية الكبرى معرضة للخطر؟ وذلك لإعطاء القراء فكرة عن سباق التسلح هذا، وما يمكن توقعه على المدى القصير (النصف الثاني من عام 2024) وعلى المدى المتوسط (2025).
سنختتم ببعض الأفكار حول الخطوات الصغيرة التي يمكن للمجتمع اتخاذها دون تغيير الكثير من انفتاح عالم المصادر المفتوحة. على سبيل المثال، فإن وجود آلية أكثر كفاءة للإبلاغ عن البرامج الضارة إلى السجلات العامة، ومشاركة الأدلة على المكونات الضارة المحتملة مع السجلات والمجتمع سيكون بمثابة خطوة صغيرة في الاتجاه الصحيح نحو هدف إغلاق الأبواب أمام الجهات الفاعلة في مجال التهديد.
لا ينبغي للبرامج الضارة الموجودة في المكونات مفتوحة المصدر أن تعطل الفوائد الهائلة التي جلبها مجتمع المصادر المفتوحة لمجتمعنا.
- [1] يكتشف الماسح الضوئي الخاص بنا المكونات مفتوحة المصدر التي تشير إليها مشاريع البرامج التي تم تحليلها، وبالتالي فإن الرسم البياني للتبعية المحدث بالكامل معروف، على الأقل بالنسبة للمشاريع التي يتم فحصها بانتظام. يكشف Xygeni OSS عن واجهة برمجة التطبيقات (API) التي قد يستخدمها العملاء أيضًا أثناء إدراج أحد المكونات محل الاهتمام في القائمة البيضاء، بما في ذلك المعلومات الخاصة بنقاط الضعف والأدلة الضارة.
- [2] قد يؤدي حاجز الحماية إلى كسر البناء إذا تم اكتشاف حالة مطابقة لمشكلات أمنية. يمكن اعتبار النتائج الأمنية، مثل وجود ثغرة أمنية حرجة ويمكن الوصول إليها أو استخدام مكون معزول، خطيرة بما يكفي لكسر إنشاء البرنامج المتأثر.
- [3]يقوم محللو الأمان لدينا بتشغيل المكون أو البرامج النصية لتثبيته في بيئة معزولة عند الضرورة. ومع ذلك، لا تقوم وزارة الكهرباء والمياه بإجراء تحليل ديناميكي، وذلك في المقام الأول لأن السلوك الخبيث لا يتم تنفيذه دائمًا في الهجمات المستهدفة وبسبب منطق التهرب الذي تستخدمه الجهات الفاعلة في التهديد للتهرب من التحليل الديناميكي.
- [4] تم تسمية هذه التقنية باسم، خوارزميات إنشاء النطاق المسجل أو RDGA، والجهات الفاعلة الجديدة في مجال التهديد مثل ما يسمى الأرنب المسدس استثمر ما يصل إلى مليون دولار في 1 ألف نطاق، مما يوضح مدى ربحية صناعة الجرائم الإلكترونية.
