عدم وجود تثبيت الإصدار والارتباك التبعية

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

 

المشكلة

تكمن المشكلة في أن المرونة وسهولة الاستخدام بالنسبة للمطورين تستدعي الأشرار، الذين يرون أن تبعيات البرامج ساحرة لا تقاوم لأعمالهم. النتيجة: اتبعت الجهات الفاعلة السيئة جميع مسارات الهجوم المحتملة الموضحة هنا. المصدر: "مجموعة سكاكين Backstabber: مراجعة لهجمات سلسلة توريد البرمجيات مفتوحة المصدر"

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

دعونا نوضح الإعلانات المفتوحة في إعلانات التبعيات لمديري الحزم المختلفين:

• • الآلية الوقائية الوطنية: package.json

{

 

   ...

   "التبعيات": {
      ...
      "يقبل": ">=1.3.8"،
      "لوداش": "~4.16.0"،
      ...
   },
   ...
}

سيتم تثبيت أكبر إصدار موجود لا يقل عن 1.3.8 لحزمة القبول، بالإضافة إلى أكبر تحديث "تصحيح" لـ lodash في النطاق 4.16.x.

• • مخضرم: pom.xml

...

...

     المشاعات-IO
     المشاعات-IO
     يطلق

...

...

ستتم إضافة آخر إصدار متاح لـ commons-io (ملف jar) باعتباره تبعية.

• • PIP: setup.py

...
يثبت(
    ...
    install_requires=['peppercorn', 'launchpadlib'],
    ...
)
...

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

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

هذا هو المعروف باسم عدم تثبيت الإصدار القضية.

يحاول المجرمون السيئون دائمًا وضع إصدارات ضارة من الحزم مفتوحة المصدر الشائعة. قد يحصلون على حق الوصول إلى مفاتيح مستودعات الحزم في تسريب سري؛ وغالبًا ما يستخدمون الهندسة الاجتماعية أو يخفون تبعية ضارة متداخلة في تسريب مفيد على ما يبدو. pull requestحتى أن بعض المؤلفين أنفسهم قرروا ذات يوم أن العالم ليس عادلاً وهاجموا عملائهم. بروتستواري في الحزم الخاصة بهم!

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

دعونا نعرض مثالا. لنفترض أنه في مشروعنا NPM لدينا اعتماد على مكون خاص:

• • الآلية الوقائية الوطنية: package.json

{
  "الاسم": "مشروعي"،

 

  ...
  "التبعيات": {

    ...
    "القسم الخاص بي": ">=1.0.0"،

    ...

   }

   ...

}

 

يمكن للمهاجم إنشاء إصدار رئيسي عالي من my-private-dep (مثل 99.0.0) ونشره في مستودع npm العام، بحسابه المزيف الخاص به (لا يحتاج المهاجم إلى فعل أي شيء مع مؤسستي). سيقوم مدير الحزم NPM بتثبيت التبعية الضارة، مما يؤدي في كثير من الأحيان إلى نتائج مدمرة.

الحل

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

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

• • الآلية الوقائية الوطنية:
    يستخدم مديرو الحزم npm أو الغزل ملفات قفل مختلفة (npm-shrinkwrap.json / package-lock.json أو Yarn.lock، على التوالي) التي تسرد الإصدارات الثابتة لجميع التبعيات، المباشرة وغير المباشرة. يجب أن تكون ملفات القفل تحت التحكم في الإصدار، وإلا فقد تنتهي عقد المطورين/البناء الآخرين بإصدارات مختلفة. تجنب تثبيت npm إلا إذا كنت بحاجة إلى تحديث التبعيات أثناء التطوير (على سبيل المثال لتثبيت إصلاحات الأمان). استخدم npm ci (التثبيت النظيف) الأكثر حتمية بشكل عام، لذلك سيستخدم مدير الحزم ملف القفل أو سينتهي بسبب الخطأ في حالة عدم وجود ملف قفل، أو أنه لا يتطابق مع package.json. إذا تم فحص الإصدارات المدرجة للتأكد من عدم وجود برامج ضارة، فإن ملف القفل يضمن عدم حدوث أي شيء سيئ في وقت الإنشاء.

    بالنسبة للمكونات الداخلية، يوصى بإنشاء نطاق الآلية الوقائية الوطنية تتم إدارته بواسطة المؤسسة (مثل @myorg)، واستخدم هذا النطاق في التبعية (مثل @myorg/my-private-dep)، والذي يمكن أن يكون له رؤية خاصة فقط. هذا يمنع ارتباك التبعية الهجمات، حيث أن عضو المنظمة الوحيد الذي لديه حق الوصول للكتابة يمكنه نشر الحزم ضمن هذا النطاق.

• • مخضرم:
    لا يحتوي Maven/Gradle على ملفات قفل (لكن انظر هذه المقالة StackOverflow).

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

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

• • نقطة:
    توجد في Python أدوات مختلفة للتعامل مع ملفات القفل:

    - Pipenv، الذي يقوم بإنشاء ملف قفل Pipfile.lock.
    - الشعر، الذي يولد Poetry.lock.
    - تجميد النقطة، الأمر الذي ينشئ ملف require.txt الذي يعمل كملف قفل. تحقق مما إذا كانت جميع التبعيات تستخدم إصدارات ثابتة باستخدام عامل التشغيل ==. ثم يستخدم pip install -r require.txt التبعيات الثابتة.

ذكّر أن ملفات القفل المذكورة أعلاه يجب أن تكون تحت التحكم في الإصدار، وأن أمر الإنشاء الذي تم اختياره يجب أن يستخدم ملف القفل.

لا يحتوي مستودع الحزمة المعتاد المستخدم مع النقطة (PyPI) على نطاقات تسمية، وهو عرضة لهجمات ارتباك التبعية. تجنب ارتباك التبعية في نظام بايثون البيئي ليس الأمر سهلاً، ويوصي بعض المؤلفين باستخدام مستودع داخلي ليكون بمثابة وكيل للتبعيات العامة التي يتم جلبها من PyPI، ولكن أخذ التبعيات الخاصة أولاً من المستودع الداخلي (يجب أن يشير -index-url إلى المستودع الداخلي، وليس PyPI، و -يجب إزالة عنوان URL للفهرس الإضافي).

بعض الهجمات الحقيقية

هجوم Getcookies: أضاف الممثل Dustin87 تبعية غير مباشرة إلى حزمة npm mailparser الشهيرة إلى حزمة ضارة ذات باب خلفي RCE (gCOMMANDhDATAi):

JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, ع، ت) => {})

على الرغم من توقفه عن العمل (لا يوجد مراجعون!)، لا يزال برنامج Mailparser يتلقى حوالي 64,000 عملية تنزيل أسبوعيًا. كانت هذه حالة هجوم كاد أن يُصيب الهدف، حيث لم يتم استخدام RCE فعليًا.cisأد.

تم نشر NPM هذا آخر مع تفاصيل حول هجوم getcookies.

ارتباك التبعية:

اكتشف أليكس بيرسان في عام 2021 مشكلة ارتباك التبعية ونشر منشورًا بعنوان “كيف قمت باختراق أبل ومايكروسوفت وعشرات الشركات الأخرى".

تذكر أنه بالنسبة لـ npm، يجب حجز نطاق المؤسسة مثل @myorg، ويجب تعديل الحزم الداخلية لاستخدام النطاق.

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

عقدة IPC:

عندما بدأت الحرب بين روسيا وأوكرانيا، قام مالك الحزمة بحقن تعليمات برمجية ضارة لإزالة الملفات العشوائية، عند تثبيتها على المضيفين الروس والبيلاروسيين. كان الملف ssl-geospec.js يقوم بهذا التمييز الجغرافي:

ومن المثير للاهتمام أن الحزم الأخرى استخدمت إصدارات مفتوحة لتبعية Node-IPC، مثل إطار عمل Vue.js الشهير، وقد تلقى المشرفون عليها رسالة نداء عاجل لتثبيت تبعية Node-IPC على إصدار آمن.

هذه المنشور يحتوي على مزيد من التفاصيل على هذا التخريب الذي يذهب أبعد من الآخر أدوات البروتوتوار مسائل.

 

ملاحظات ختامية

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

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

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

لقراءة المزيد

أوم إم، بليت إتش، سيكوش إيه، ماير إم: "مجموعة سكاكين الطعن الخلفي: مراجعة لهجمات سلسلة توريد البرمجيات مفتوحة المصدر". DIMVA 2020. ملاحظات محاضرة في علوم الكمبيوتر، المجلد 12223. سبرينغر – 2020 (مصدر شكل شجرة هجوم التبعية.)

@آدم-npm: "الوحدة الضارة التي تم الإبلاغ عنها: getcookies". مدونة npm (المؤرشفة) – 2 مايو 2018.

أليكس بيرسان: "كيف قمت باختراق أبل ومايكروسوفت وعشرات الشركات الأخرى". متوسط ​​– 9 فبراير 2021.

اكس شارما :"التخريب الكبير: حزمة npm الشهيرة تحذف الملفات احتجاجًا على حرب أوكرانيا"BleepingComputer – 17 مارس 2022