Shai-Hulud 2.0: كيفية Secure Supply Chain Software Secure Supply Chain الموجة الثانية

• دودة ذاتية الانتشار: Shai-Hulud 2.0 تسرق بيانات اعتماد GitHub، وتعيد تجميع نفسها، وتعيد نشرها عبر محفظة npm الكاملة للمسؤول عن الصيانة.

• انتشار واسع النطاق:أكثر من 700 حزمة npm مصابة، وأكثر من 25,000 مستودع GitHub، وتأثر 500 مسؤول صيانة؛ وإضافة أكثر من 1,000 مستودع جديد كل 30 دقيقة (Wiz).

• التأثير عبر الأنظمة البيئية: لوحظ أيضًا في Maven/Java عبر النسخ المتطابق التلقائي من npm إلى Maven.

• المخاطر الرئيسية: التعرض لـ CI/CD، وكشف الأسرار، والتنفيذ أثناء التثبيت، وتسجيلات التسجيل الملوثة.

• الدفاع: دقة SBOM، والتحقق من المصدر، ومراقبة وقت التشغيل، والالتزام الصارم بقواعد الأمان الخاصة بالرموز/الأسرار.

تجاوز حجم وسرعة انتشار Shai-Hulud 2.0 أي شيء شوهد في حوادث سلسلة التوريد الأخيرة. ما بدأ كاختراق موجه لـ npm سرعان ما تصاعد إلى عدوى منهجية عبر الأنظمة الأساسية أثرت على آلاف المشاريع ومئات من القائمين على الصيانة.

على عكس البرامج الضارة النموذجية npm، التي عادةً ما تتضمن حزمة واحدة مصابة بفيروس حصان طروادة، يتصرف Shai-Hulud 2.0 كدودة. بعد اختراق مطور، يسرق بيانات اعتماد GitHub، ويعيد تجميع نفسه، ويعيد نشره عبر مجموعة الحزم الكاملة للمسؤول عن الصيانة، مما يحول كل ضحية إلى نقطة توزيع جديدة. والنتيجة هي انتشار سريع وأسي عبر النظام البيئي.

تعرضت مئات الحزم npm للاختراق. وتشمل هذه الحزم مشاريع بارزة تديرها مؤسسات راسخة، مما يزيد من تعرضها للمخاطر.

لقد لوحظ أن الدودة تولد أكثر من 1000 مستودع GitHub ضار جديد كل 30 دقيقة (Wiz)، مدعومة بالنشر التلقائي من بيانات الاعتماد المسروقة. تصبح كل ضحية جديدة عقدة انتشار، مما يضاعف التأثير الإجمالي في كل دورة.

يثبت عنصر سرقة بيانات الاعتماد في Shai-Hulud 2.0 أنه ضار بشكل خاص. تشمل الأسرار المسربة التي تم التحقق منها أكثر من 1500 من بيانات الاعتماد والرموز المميزة التي تغطي منصات رئيسية – GitHub و AWS و Google Cloud و Azure.

يمثل هذا الحجم من الرموز الحساسة خرقًا واسعًا ومتعدد السحابات مع احتمال استغلال طويل الأمد.

لحسن الحظ، استعاد العديد من المطورين البارزين مثل Zapier و PostHog و Postman السيطرة على حزمهم. تمت إزالة الإصدارات الضارة من npm، ويجري استعادة أو تنظيف العديد من المستودعات المتأثرة.

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

والجدير بالذكر أن هذه الموجة قد أثرت أيضًا على أنظمة أخرى مثل Maven/Java من خلال التحويل الآلي للمنتجات من npm إلى Maven (JFrog) .

• بينما يظل npm الهدف الرئيسي لـ Shai-Hulud 2.0، فقد أظهرت هذه الموجة خطر الانتشار عبر الأنظمة البيئية، وتحديدًا في مشاريع Java/Maven. حدد باحثو الأمن الأداة الخبيثة Maven:
  • org.mvnpm:posthog-node:4.18.1 التي تحتوي على نفس الحمولة (setup_bun.js و bun_environment.js) الموجودة في حزم npm المخترقة (أخبار القراصنة).
• الآلية: تعمل أدوات الربط الآلية على إعادة إنشاء حزم npm كأدوات Maven لمشاريع Java. قد تتعرض الفرق التي لا تستخدم Node.js بشكل مباشر للخطر إذا كانت مشاريعها تعتمد على هذه الأدوات المعكوسة.

وهذا يوضح المخاطر غير المرتبطة بالنظام البيئي التي تنطوي عليها هجمات سلسلة التوريد. حتى المشاريع التي لا تستخدم npm بشكل مباشر يمكن أن تتعرض للمخاطر من خلال الأدوات الآلية.

يُظهر اختراق PostHog مدى دقة التعرض لـ CI/CD:

• طلبات السحب الضارة استغلت pull_request_target في GitHub Actions.

• تم تسريب بوت PAT، مما سمح بنشر SDKs npm مصابة بفيروس حصان طروادة.

تعد سير عمل CI/CD، حتى تلك الآلية منها، سطحًا عرضة للهجمات عالية المخاطر. قم بتقييد البرامج النصية، وتقليل تعرض الرموز المميزة، وفرض استخدام بيانات اعتماد قصيرة الأجل.

• قد يفشل تثبيت التبعية بسبب التبعيات الانتقالية.

• لا تستطيع الماسحات الضوئية الثابتة SCA اكتشاف الشفرات البرمجية المزيفة التي تم نشرها حديثًا تحت أسماء حزم برمجية شرعية.

• إساءة استخدام الرموز عبر خطوط أنابيب CI/CD تعني أن حتى المستودعات الداخلية معرضة للخطر.

يمكن أن توفر أدوات SBOM وأدوات سلسلة التوريد ما يلي:

1. شفافية التبعية: يتتبع التبعيات المباشرة والانتقالية مع بيانات تعريف الإصدار والمسؤول عن الصيانة.
2. التحقق من المصدر: يحدد التغييرات غير المتوقعة في الحزمة أو القائمين على الصيانة غير المعروفين.
3. مراقبة بيانات الاعتماد والسرية: يكتشف محاولات التسريب أو إساءة استخدام الرموز المميزة.
4. رؤى سلوكية: تراقب الوصول إلى الموارد أو أنماط التنفيذ غير العادية أثناء عمليات التثبيت.

على الرغم من أنه ليس حلاً سحرياً، إلا أن الجمع بين SBOM والمراقبة المستمرة يعزز الدفاعات ضد الهجمات الشبيهة بالديدان.

تقوم تقنية OPSWAT بمسح مستودع الكود المصدري والكشف عن حزمة npm sha1-hulud الضارة.

1. تناوب بيانات الاعتماد: PATs GitHub، رموز npm، مفاتيح SSH، بيانات اعتماد السحابة؛ تمكين MFA.
2. إزالة الحزم المخترقة: مسح ذاكرة التخزين المؤقتة npm و node_modules وتثبيت الإصدارات النظيفة المعروفة.
3. تدقيق GitHub و CI/CD: ابحث عن مستودعات جديدة وسير عمل وعمليات التزام مشبوهة.
4. تقوية خطوط الأنابيب: تقييد البرامج النصية لدورة الحياة، والحد من الوصول إلى الشبكة الخارجية، وتقليل نطاق الرموز المميزة.
5. المراقبة المستمرة: تعامل مع التبعيات وقم ببناء خطوط الأنابيب كجزء من سطح الهجوم الحرج.

إن انتشار Shai-Hulud 2.0 إلى Maven/Java عبر جسر npm-to-Maven يوضح أن هجمات سلسلة التوريد يمكن أن تتجاوز حدود اللغة والنظام البيئي. حتى المشاريع التي لا تستخدم npm بشكل مباشر قد تكون معرضة للخطر إذا تم استخدام أدوات الجسر الآلية.

تتيح الرموز المسروقة (GitHub و npm والسحابة) الانتشار والوصول إلى البيئات الحساسة. استخدم رموزًا قصيرة الأجل ومحددة النطاق، وفرض المصادقة متعددة العوامل (MFA)، وقم بتدوير بيانات الاعتماد فورًا بعد أي شك في حدوث اختراق. استخدم أدوات المسح السري الآلي لتسريع العملية.