هذه هي الحلقة الأولى في سلسلة من المقالات حول النوع الأكثر شيوعًا من هجمات سلسلة توريد البرامج: تلك التي تستخدم سجلًا عامًا لمكونات البرامج، والمخصصة لـ مشاريع مفتوحة المصدر لتحميل العناصر التي يمكن مشاركتها مع مستخدمين آخرين. عندما ينشر الأشرار برامج ضارة هناك، باستخدام السجل كوسيلة لتوزيع البرامج الضارة، فإننا نتعرض لهجوم على سلسلة التوريد عندما تقوم المؤسسات الضحية بتثبيت مكون البرنامج المصاب أو تشغيله.
لتبسيط المناقشة سنتحدث عنها باقات البرامج المحوسبة: المكونات في شكل معبأ من إنتاج أطراف ثالثة. وهذا لا يشمل فقط المكونات التي يستخدمها مديرو الحزم مثل NPM أو Poetry، ولكن أيضًا مكونات نظام التشغيل بما في ذلك المكتبات والثنائيات القابلة للتنفيذ، صور الحاوية, والأجهزة الافتراضية، أو ملحقات الأداة لأدوات التطوير والبناء والنشر. لقد رأينا حزمًا ضارة في كل مكان. لا يمانع مجرمو الإنترنت: فهم مسرورون بالبدائل التي توفرها البنى التحتية للبرمجيات الحديثة ويستخدمون السجل والأداة التي تناسب أغراضهم على أفضل وجه. لذا، يرجى تذكر أن حزم البرامج هي اختصار لصور الحاويات، والحزم الثنائية، ومستودعات المصادر المفتوحة، والإضافات أو المكونات الإضافية من جميع الأنواع (بيئات التطوير المتكاملة، CI/CD الأنظمة، وأدوات البناء). جميعها تتعرض للهجوم بشكل روتيني.
المسلسل سيكون مكون من 5 حلقات:
- ما هي مشكلة الحزم مفتوحة المصدر؟ هذا هو موضوع هذا المنصب. لماذا يقوم المجرمون بجميع أنواعهم بنشر حزم ضارة؟ لماذا يجب أن أشعر بالقلق؟
- تشريح الحزم الضارة: ما هي الاتجاهات؟ في هذه الحلقة، نركز على التهديد الذي نراقبه من خلال نظام MEW الخاص بنا، يومًا بعد يوم. مع وجود ضجيج كبير في الخلفية بسبب وجود عدد كبير من الحزم الضارة التي تستخدم typosquatting أو ارتباك التبعية، تكون نسبة أقل من الهجمات أكثر غدرًا وتشكل خطرًا أكبر. كيف تغير سلوك الجهات الفاعلة السيئة فيما يتعلق بنظام التشغيل في الماضي القريب؟ ما هي الأرقام؟ ما هي التكتيكات والتقنيات والإجراءات المستخدمة، وما هي الإجراءات الضارة التي شوهدت؟
- الحماية من الحزم الضارة مفتوحة المصدر: ما الذي ينجح (لا) يعمللدى معظم المتخصصين في مجال الأمن أفكار حول كيفية التعامل مع هذا التهديد. وقد سمعنا مديري الأمن يقولون دون تردد: SCA تُخبرك الأدوات مُسبقًا متى يكون إصدار الحزمة برمجيًا ضارًا، أو أنها تعتمد على مكونات برمجية معروفة وخضعت لمراجعات دقيقة، حيث يتم اكتشاف أي برمجية خبيثة وإزالتها فورًا. كما أنها تستخدم إصدارات ثانوية/تصحيحات مفتوحة المصدر لإصلاح الثغرات الأمنية تلقائيًا، وهذه هي الطريقة الصحيحة والموصى بها لتقليل مخاطر تبعيات المصادر المفتوحة، باتباع مبدأ "التصحيح المبكر والتصحيح المتكرر". في هذه الحلقة، سنستعرض سبب خطأ هذه الأفكار، وكيف تُساهم هذه المفاهيم الخاطئة في شيوع آلية الهجوم هذه، وفي خطر جسيم تواجهه المؤسسات. سنختتم بالحديث عن ما يُجدي نفعًا، وما هو الجهد والموارد اللازمة.
- الحزم الخبيثة مفتوحة المصدر: نهج Xygeni. في هذه الحلقة، نعرض الإستراتيجية التي نتبعها في Xygeni لنظام الإنذار المبكر بالبرامج الضارة (MEW). كيف يعمل هذا النظام متعدد المراحل في الوقت الفعلي عند نشر إصدار جديد للحزمة، وكيف يتم التقاط الأدلة من مصادر مختلفة، وكيف يتم الفرز، وما هي معايير التصنيف التي نتبعها، ولماذا لا تزال هناك حاجة إلى بعض التحليل اليدوي للتأكيد طبيعة مرشح الحزمة الخبيثة؟ كيف تساعد التعليقات الواردة من فرقنا الداخلية وفرق التسجيل النظام على التعلم من الأدلة السابقة التي تم جمعها لتقليل النتائج الإيجابية الخاطئة إلى الحد الأدنى. سنشرح كيف نساعد NPM وGitHub وPyPI وغيرها من البنى التحتية الرئيسية في الأنظمة البيئية مفتوحة المصدر مفتوحة المصدر لتقليل وقت المكوث..
- استغلال المصدر المفتوح: ما يمكن توقعه من الأشرار. تنتهي السلسلة بالتركيز على أحدث الإجراءات التي يتبناها الخصوم لجعل الهجمات أكثر سرية، ويصعب اكتشافها، وأكثر استهدافًا لصناعات معينة، واستخلاص المزيد من الفوائد من هذه الفئة من الهجمات. هل سيتم تنفيذ هجمات برامج الفدية باستخدام هذه السيارة؟ كيف يستفيد الأشرار من أدوات الذكاء الاصطناعي لتقديم حزم ضارة أكثر تعقيدًا؟ هل المشاريع الشعبية الكبرى في خطر؟ وذلك لإعطاء القراء فكرة عن سباق التسلح هذا، وما يمكن توقعه على المدى القصير (النصف الثاني من عام 2024) وعلى المدى المتوسط (2025). وسوف نتعلم كيف يمكن لمثل هذه الهجمات الأخيرة XZ-Utils مستتر، أو الهجوم على العيش خارج الأرض منشئ الإلكترون في مارس/آذار 2024، تظهر أننا يجب أن نبقى يقظين بشأن كيفية تطور الخصوم.
دعونا نفتح المسرح بالحلقة الأولى: ما الذي يحدث مع الحزم الخبيثة مفتوحة المصدر؟
ما هي مشكلة الحزم مفتوحة المصدر؟
في السنوات الأخيرة، استخدم مرتكبو الجرائم من جميع الأنواع سجلات برمجيات مفتوحة المصدر لتقديم السلوك الضار. هذه الأنشطة قديمة قدم المصادر المفتوحة، لكن تواترها تزايد بشكل كبير في السنوات الثلاث الماضية.
نشر المكونات الضارة في السجلات العامة (الهجمات القائمة على التبعية) هي حرب عصابات غير متماثلة تستخدمها الجهات الفاعلة في مجال التهديد لتوزيع البرامج الضارة، مما يعزز الثقة التي تضعها المؤسسات في المكونات مفتوحة المصدر القادمة من مطورين غير معروفين (تذكر التبعية xkcd هزلية؟). نظرًا لأنك تثق في الحزم ولا تمانع في مراجعة محتويات الحزمة وتبعياتها يدويًا، فإن هذه الهجمات فعالة بشكل غير عادي. ويأتي عدم التماثل لأنه يمكن أن تكون آلية إلى حد كبير ولا يحتاج الأشرار إلى التفاعل مع الضحية مباشرة. إنهم ببساطة يقومون بتحميل الحزمة إلى السجل العام ويتركونها.
الحزم الخبيثة ارتفع بمقدار 6 أضعاف في عام 2022واستمرت في النمو بمقدار 2.5 مرة في عام 2023. وفي العام الماضي، شوهدت 245,000 حزمة ضارة، وهو رقم يزيد عن ضعف العدد الإجمالي عن السنوات السابقة مجتمعة. هذا هو النمو المتسارع! من عمليات إزالة الحزم باعتبارها برامج ضارة مؤكدة بالمئات خلال عام 2021 وبالآلاف خلال عام 2022، شهدنا المزيد من "الضجيج" في الخلفية خلال عام 2023، بوتيرة مماثلة لهذا العام. وفي ظل تلك الخلفية التي سببها مجرمو الإنترنت غير المتطورين الذين اتبعوا "الطريق الأقل مقاومة"، وصلت أقلية من الهجمات البارزة إلى عناوين الأخبار حتى في وسائل الإعلام العامة.
لماذا هذه مشكلة بهذا الحجم؟ هناك الثقة الزائدة في جميع أنحاء السلسلة. يتم توزيع البرامج مفتوحة المصدر مع كود المصدر الخاص بها، ويتم إصدارها بموجب ترخيص معين. نعم، يمكن لأي شخص فحص الكود المصدري؛ ولكن من يفعل ذلك بشكل عام؟ من يقوم ببناء البرنامج من المصادر بعد التأكد من خلو البرنامج من البرمجيات الخبيثة؟ من، قبل تمرير المكون المعبأ (المعروف أيضًا باسم a صفقة) إلى مدير الحزم أو أداة الإنشاء، للتأكد من أن الحزمة ليست مليئة بالبرامج الضارة وتتوافق مع كود المصدر المفترض الذي يجب أن تأتي منه؟
لماذا تسمح البنية التحتية بمثل هذه الهجمات السهلة؟
سجلات الحزمة مفتوحة، وغالبًا ما تتطلب الحد الأدنى من التحقق من هوية الناشر. "نرحب بأي شخص لنشر برامجه هنا!" لقد تم تعيين مستوى منخفض للمهاجمين: فهم يستخدمون عناوين بريد إلكتروني يمكن التخلص منها وحسابات GitHubgithub التي يمكن التخلص منها لإنشاء مئات من الحزم الضارة في حملات قصيرة تشبه التصيد الاحتيالي. فقط للمستهدفين هناك حاجة إلى مستوى أعلى من التطور: لقد رأينا حتى إنشاء مستودع مصادر GitHub موثوق به يضم العديد من النجوم و commitمن عدة مساهمين مزيفين ومقاييس أخرى للشعبية والصيانة. الحصول مراقبو النجوم والسمعة من المساهمات المزيفة ليس من الصعب أتمتة. لقد رأينا انتهاكات على البنى التحتية للبرمجيات المفتوحة بجميع أنواعها، وليس فقط البرامج الضارة، مثل حادثة بروتوكول الشاي.
تم تصميم مديري الحزم لسهولة الاستخدام وليس للأمان. يمكنهم تشغيل البرامج النصية لما بعد التثبيت قبل وبعد التثبيت (في بعض الأحيان يكون تجميع التعليمات البرمجية الأصلية للمكتبة ضروريًا). أيضًا، مديري الحزم تثبيت الحزم من مصادر متعددة، وفي بعض الأحيان يكون الإعداد الافتراضي هو استخدام السجلات العامة. ولم يتحققوا من عدم التطابق بين البيانات التعريفية في طلب النشر والبيانات التعريفية الموجودة في الحزمة نفسها.
التبعيات متداخلة وتشكل رسمًا بيانيًا. في بعض الأنظمة البيئية مثل Node (JavaScript)، تتراكم التبعيات الصغيرة بالمئات أو الآلاف. هناك شيء واحد يتمثل في فرض رقابة صارمة على التبعيات المباشرة التي تعلنها مشاريعي البرمجية، ولكن التبعيات متعدية يصعب السيطرة عليها. يتبع المصدر المفتوح عبارة "أصدقاء أصدقائي هم أصدقائي". الأخوة هي القاعدة في الشرق الأقصى البري! تعرف الجهات الفاعلة في مجال التهديد ذلك وتخفي بعمق السلوك الخبيث في التبعيات الغامضة التي غالبًا ما تكون غير معروفة. وكان هذا هو الحال مع تيار الحدث حادثة تستهدف محفظة Copay.
هذه هي الطريقة التي عملت بها البرمجيات مفتوحة المصدر منذ بدايتها. لن يتغير كثيرا. تتطلب بعض سجلات الحزم في أفضل الأحوال مصادقة ثنائية، وغالبًا ما تكون للحزم الأكثر شيوعًا فقط. توفر بعض السجلات النطاقات، وهي مساحة اسم مملوكة لمنظمة تم فحصها، ولكن بشكل مأساوي البعض الآخر لا يدعمه (PyPI) أو يجعله اختياريًا (NPM). ومن المثير للاهتمام أن نلاحظ أنه حتى أ مخطط فحص بسيط (استنادًا إلى التحكم في مستودع/مؤسسة DNS أو GitHub التي تطابق معرف المجموعة) والتصنيع توقيعات PGP إلزامية لجميع العناصر باستثناء المجاميع الاختبارية، يزيل معظم "الضجيج"، والحزم الضارة الشبيهة بـ typosquatting، ويحد من الكثير من ارتباك التبعية. الهجمات المتطورة ممكنة ولكنها أصعب بكثير، مع عدد قليل فقط مثل com.github.codingandcoding:maven-compiler-plugin معروف بـ Maven Central. وليس كل السجلات المخضرمة تتبع نفس الممارسات!
قد تشكل الضوابط الأمنية على مديري الحزم عبئًا ولكنها لا تعيق هجمات التبعية. تكمن مشكلة المصادقة متعددة العوامل في أنه بالنسبة للتشغيل الآلي، يتم إنشاء بيانات الاعتماد المشتقة مثل رموز الوصول أو مفاتيح APIapi للحسابات التي سيتم استخدامها في مكالمات APIapi التي يتم إجراؤها من البرامج النصية للأتمتة، مع عدم وجود مستخدم تفاعلي داعم يوفر عاملاً ثانيًا. يعد MFA مفيدًا لحماية حسابات المستخدمين من تسرب كلمات المرور، ولكن رموز الوصول التي تم إنشاؤها أو مفاتيح APIapi تحتاج إلى الحماية أثناء نشاطها، وإلا سيتم انتحال شخصية مالكها من قبل الخصوم. يبدأ جزء كبير من حملات سلسلة التوريد القائمة على الحزم بمفتاح/رمز مميز مسرب. فقط تذكر حوادث مثل دفتر الحسابات, 3CXوغيرها الكثير، حيث تم تسريب بيانات الاعتماد غير التفاعلية لأول مرة في عملية اقتحام أولية لبدء هجوم سلسلة التوريد.
لم تكن الاستجابة لهذا التهديد قوية بما يكفي. في الحلقة الثالثة، سنركز على ما نجح، وما فشل فشلاً ذريعاً. على القطاع أن يعمل بشكل جماعي على standardالإجراءات، والعمليات، والتعليم، والأدوات اللازمة للتخفيف من مخاطر سلاسل التوريد العالمية. هذه ليست مشكلةً تستطيع منظمةٌ واحدةٌ حلها بمفردها.
ولإنهاء هذا القسم، سوء الفهم الحاسم: نحن نتحدث عنه خبيث الحزم، لا الضعيفة تلك. تأتي نقاط الضعف من أخطاء في التصميم أو الترميز، والتي يتم إدخالها عن طريق الخطأ، دون نية سيئة. قد يتم استغلال نقاط الضعف، لكن الكثير منها لا يتم استغلاله. دائمًا ما تكون الحزم الضارة مقصودة، ويمكن استغلالها بنسبة 100% إذا تم تنفيذها. لا يوجد خطر مماثل! لذلك ومن المفارقة أن نرى عدد الجهود المبذولة لاكتشاف نقاط الضعف والتخفيف من آثارها، وعدم وجود تدابير مماثلة للمكونات الضارة.
"نحن نأخذ الأمن على محمل الجد"
دعونا نتخيل المعتاد شركة Acme. شركة Acme، المزود الرئيسي لموقع WileCoyote.com، تأتي معظم برامجها من أطراف ثالثة، وأكثر من 80% منها تأتي من مشاريع مفتوحة المصدر. إنهم ينتجون برامج للاستخدام الداخلي، لكنهم يقدمون أيضًا برامج لشركائهم ومقدمي الخدمات والعملاء/المستخدمين النهائيين. لدى Acme برامج مكتوبة بلغات Go وJavaScript وJava وC# وPython، وتقوم بتشغيل معظم برامجها على السحابة، ضمن مجموعات Kuberneteskubernetes. تقوم Acme ببناء صورها المخصصة من الصور الأساسية المأخوذة من Docker Hub والسجلات الأخرى. ويشاركون عددًا قليلًا من المكتبات والحزم وصور الحاويات في السجلات العامة أيضًا.
تأخذ شركة Acme الأمن على محمل الجد. إنهم يدركون جيدًا مشكلة open source security، والمخاطر التي يحملها. يستخدم جميع المطورين ومديري الأنظمة ومهندسي DevOpsdevops مفاتيح التشفير الصغيرة اللطيفة كعامل مصادقة ثانٍ. الجميع commitيتم توقيع مستودعات التعليمات البرمجية، ويتم تمكين حماية الفرع من خلال مراجعات التعليمات البرمجية الإلزامية، CI/CD مُقفلة، والأسرار مُخزَّنة في خزنة سرية، مع سجل داخلي يُحاكي جزئيًا السجلات الخارجية، حيث تُخزَّن فقط المكونات المسموح بها والمدرجة في القائمة البيضاء. يُشترط أن يأخذ البرنامج المُطوَّر بواسطة Acme تبعيات خارجية من هذا السجل.
ربما تتناسب معظم المنظمات مع هذا الملف الشخصي. عزيزي القارئ، من المؤكد أن ما تفضله يناسبك إذا كنت هنا، أليس كذلك؟
ثم في أحد الأيام المشؤومة، أصبح أحد مطوري الواجهة الأمامية المهمين ركض في Acme تثبيت npm acme-cute-lib، متناسين أن @acme/cute-lib كانت التبعية الصحيحة ذات النطاق. الخطأ الدقيق ليس مهمًا، فقد تسوء أشياء كثيرة حتى عندما يفترض المرء التحكم الكامل في دورة حياة البرنامج. لم يكن مطورنا يعلم أن مجموعة APT كانت تستهدف Acme ونشرت مكونًا ضارًا تحت هذا الاسم، بطريقة ماكرة بحيث ينشط السلوك الضار فقط عند تثبيت البرنامج على أجهزة كمبيوتر Acme. لم يتم الكشف عن الحزمة لأسابيع بعد نشرها.
يتم تشغيل برنامج نصي للتثبيت يبحث عن بيانات الاعتماد (كان هناك العديد من رموز الوصول المميزة في الكمبيوتر المحمول الخاص بالمطور لدينا)، مما يسمح بالوصول إلى مستودعات البرامج الداخلية، والمستودع الداخلي المذكور أعلاه، والذي لا يمكن الوصول إليه بالطبع إلا عبر VPN. تمكنت التعليمات البرمجية الضارة من استخدام اتصال VPN الحالي ونشر مكون ضار من المرحلة الثانية في السجل الداخلي، مما يؤثر على مكتبة الأدوات المساعدة الشائعة التي تتقاسمها معظم البرامج التي تقدمها Acme.
بعد أسابيع، بدأت المؤسسات الأخرى التي تستخدم أدوات Acme المنشورة في رؤية حركة مرور غريبة على شبكاتها، مع حركة مرور تستخدم بروتوكول Acme ولكنها موجهة إلى مضيفين يشبهون مجال Acme. تم تشفير حركة المرور ولكن أدوات مراقبة النظام عثرت على إمكانية الوصول إلى ملفات غير متوقعة وتنفيذ عمليات تشبه أوامر النظام ولكن ينتهي بها الأمر إلى تشغيل الملفات التنفيذية التي تم تنزيلها.
والباقي أصبح تاريخا: فقد أنكرت شركة أكمي في البداية أن مثل هذا السلوك كان منسوبا إليهم وأن جميع الإجراءات الأمنية كانت متخذة. فقط بعد أن بدأت وسائل الإعلام السيبرانية في التساؤل عن سبب نشأة مصدر السلوك المكتشف من مكونات Acme، ونشر التحليل الأمني مدى امتلاء هذه المكونات بالبرامج الضارة الخفية، كان على Acme التعرف على الحادث واستدعاء شركة الاستجابة للحوادث. حملة تسويقية سلبية قوضت الثقة التي اكتسبتها بشق الأنفس في ثانية واحدة. "كان Acme على بعد تثبيت npm واحد من disaster"كان عنوانًا شائعًا. ثم تبعتها الدعاوى القضائية والعقود الملغاة.
هل ترى تشابهات مع حوادث سابقة معروفة؟ تعرضت شركة Acme لحادث في سلسلة التوريد على مرحلتين، باستخدام مزيج من ارتباك التبعية/القرفصاء المطبعي الهجمات التي استخدمت محطة عمل المطورين كرأس جسر لإصابة المكونات التي انتهى بها الأمر في البرامج المستخدمة من قبل أطراف ثالثة. كيف يمكن منع ذلك أو التخفيف منه؟
لماذا تحظى العبوات المسمومة بشعبية كبيرة؟
يوضح هذا الحادث الافتراضي أنه حتى مع وجود نهج معقول لأمن المصادر المفتوحة، تحتاج المؤسسات إلى تدابير محددة لتجنب الوقوع فريسة للبرامج الضارة في المكونات مفتوحة المصدر. من الناحية التخطيطية، يمكن لممثل التهديد:
- أنشئ حزمة جديدة (باتباع طرق typosquatting أو ارتباك التبعية المعروفة، وهذا هو المسار الأكثر اجتيازًا من قبل الأشرار من حيث الحجم)؛
- حاول إصابة أحد البرامج الضارة الموجودة، إما عن طريق حقنه في الكود المصدر، أو محاولة إخفائه كمساهم عبر pull request، أو استخدام الهندسة الاجتماعية ليصبحوا صيانين (كما فعل "جاو تان" في XZ Backdoor أو right9ctrl قام مستخدم GitHub في تيار الحدث حادثة وقعت في خريف عام 2018)، أو عن طريق الحصول على بيانات اعتماد مستودع مفتوح المصدر وانتحال صفة المشرف؛
- قم بإدخال برامج ضارة أثناء إنشاء الحزمة، إما عن طريق تشغيل برنامج نصي بناء ضار، أو التدخل في تنزيلات الحزمة من خلال اعتراضات الوسيط (لحسن الحظ، TLS مطلوب دائمًا الآن في معظم السجلات).
- قم بحقن المكون المعبأ مباشرة في السجل، عادةً عن طريق التقاط بيانات اعتماد التسجيل (البديل المفضل للعديد من الهجمات المتطورة مثل Acme's، حيث كانت محطة العمل المخترقة في المرحلة الأولى تحتوي على رمز الوصول الداخلي إلى السجل، على سبيل المثال في المعتاد .env or ~/.m2/settings.xml: الممثلون السيئون يعرفون أين يبحثون عن الأسرار). كما تم استغلال نقاط الضعف في السجلات.
يعد تسميم السجلات بالبرامج الضارة هو الأساس لهجمات التبعية. لا شيء جديد تحت الشمس: فقد انتشر انتشاره بشكل كبير، ولكن نفس التقنيات تعمل الآن كما كانت قبل خمس سنوات.
المصدر مجموعة سكين Backstabber.
يمكن أن تعمل الحزمة الضارة عند التثبيت، أو أثناء إنشاء البرنامج، أو في وقت التشغيل. ويتراوح السلوك من استخراج المعلومات، على سبيل المثال، استخراج الأسرار لمحاولة المرحلة الثانية، إلى استخراج كود المصدر، وإسقاط برامج ضارة إضافية. وفي الحلقة القادمة سنشرح الحزم الخبيثة وكيفية نشرها.
لمزيد من القراءة
الحلقة القادمة تشريح الحزم الضارة: ما هي الاتجاهات؟ سنركز على الحالات الحقيقية التي نراقبها من خلال نظام الإنذار المبكر بالبرامج الضارة، يومًا بعد يوم. سنراجع أنواع البرامج الضارة التي تمت مشاهدتها، والتكتيكات والتقنيات والإجراءات المفضلة. سوف ندرس التشويش وكيف يحاولون الاختباء من المراجعين المحتملين، وتقنيات التهرب لتجنب الكشف، وكيف تتطور مع القياس عن بعد والحركة الجانبية. من فضلك لا تنزعج!
مراجع حسابات
- مجموعة سكاكين Backstabber: مراجعة لهجمات سلسلة توريد البرامج مفتوحة المصدر. م. أوم وآخرون، مايو 2020.
- الحماية من البرامج الضارة مفتوحة المصدر. ورقة بيضاء من Xygeni.
- Software Supply Chain Security نظرة إلى الماضي: تشكيل عام 2024 أكثر أمانًا. تقرير من زيجيني.
