منذ اكتشاف شاي خلود 2.0 (المعروف أيضًا باسم sha1-hulud)، تتبعت شركة Wiz Research “الذيل الطويل” المستمر للعدوى. حتى الآن, لقد أثر هذا الحادث على أكثر من ثلث قائمة Fortune 100، من بين مئات المنظمات الأخرى.
وبينما تم الاحتواء الأولي في أواخر نوفمبر، ظلت الدودة في البيئات لأسابيع بسبب التبعيات التي تم تجاهلها في سلسلة التوريد. بناءً على تقاريرنا السابقة حول الحادث الأولي و علم الضحايا، تفاصيل هذا التحديث:
-
ميكانيكا الثبات: كيف أبقت السجلات الخاصة وامتدادات IDE الدودة على قيد الحياة.
-
“قص الذيل”: كيف ساعدت Wiz Research في التخفيف من استمرارية الدودة.
-
غير مستدير أسرار: تقرير حالة عن بيانات الاعتماد المسربة التي لا تزال صالحة حتى اليوم.
-
رابط محفظة الثقة: تحليل الارتباط المحتمل لاستغلال 7 ملايين دولار بـ sha1-hulud.
شكل الذيل الطويل
وفي ذروة تفشي المرض في 24 نوفمبر، سجل GHArchive 13,686 مستودعًا جديدًا تحتوي على بيانات الضحية المسربة. يلتقط GHArchive عمومًا 50% من نشاط GitHub، وهو ما يطابق استحواذ Wiz على أكثر من خمسة وعشرين ألف مستودع في اليوم الأول من الحادث. أثناء الاحتواء الصارم من قبل فريق npm وشركاء النظام البيئي أثار تحطمًا فوريًا وفي الإصابات الجديدة، لم تختف الدودة.
وبدلاً من ذلك، دخلنا في فترة “ذيل طويل” مدتها شهر. وفي الفترة من 25 نوفمبر إلى 24 ديسمبر، استقر معدل الإصابة عند مستوى مستمر يقارب 1 100-200 مستودع جديد مخترق كل يوم.
في 24 ديسمبر، انتقلت شركة Wiz Research إلى “قص الذيل”. من خلال التنسيق مع فريق AsyncAPI لنشر نسخة نظيفة (v1.1.0) من ملحق OpenVSX الخاص بهم، فرضنا تحديثًا عبر نظام IDE البيئي. كان التأثير فوريًا: بحلول 29 ديسمبر، انخفضت المستودعات الجديدة يوميًا إلى مجرد حفنة.
لماذا بقيت الدودة
يحدد تحليلنا محركين أساسيين لهذا الاستمرار، حتى بعد إزالة الحزم الضارة من سجل npm العام:
-
السجلات الخاصة والحزم المخزنة مؤقتًا (5% من الحالات): استمرت المرايا الداخلية وذاكرة التخزين المؤقت المحلية في تقديم الإصدارات “المسمومة” التي تم إبطالها بالفعل في المراحل الأولية.
-
ملحق OpenVSX “Zombie” (90%+ من الحالات): الخبيثة معاينة asyncapi v1.0.1 ظل الامتداد نشطًا على أجهزة المطورين نظرًا لعدم وجود إصدار أعلى لتشغيل التحديث التلقائي… حتى تدخلنا في 24 ديسمبر.
سيف ذو حدين للسجلات الخاصة والحزم المخزنة مؤقتًا
ما يقرب من 5% من الإصابات في الذيل الطويل يمكن إرجاعها إلى السجلات الخاصة والحزم المخزنة مؤقتًا.
تعد السجلات الخاصة (مثل Sonatype Nexus وJFrog Artifactory) بمثابة توصية أمنية شائعة للتحكم في كود الطرف الثالث. ومع ذلك، فإنها تقدم المنبع خطر عدم التزامن. في هذه الحملة، فشلت بعض السجلات الخاصة في إزالة حزم sha1-hulud الضارة بعد أن تم إبطالها من سجل npm الرسمي. ونتيجة لذلك، استمرت هذه السجلات في تقديم الحزم “المسمومة” للمطورين الداخليين لمدة أسابيع بعد تحييد التهديد العام.
الثبات عبر ذاكرة التخزين المؤقت المحلية
لقد حددنا أيضًا الحالات التي استمرت فيها البرامج الضارة من خلال ذاكرة التخزين المؤقت npm المحلية. في حين أن npm CLI عادةً ما يتحقق من صحة الإصدارات مقابل السجل، فإن تكوينات معينة تتجاوز هذا التحقق:
-
--offline: يفرض npm على استخدام ذاكرة التخزين المؤقت المحلية حصريًا. -
--prefer-offline: يعطي الأولوية لذاكرة التخزين المؤقت المحلية، ولا يصل إلى السجل إلا في حالة فقدان الحزمة.
في بيئات CI/CD عالية السرعة حيث تكون هذه العلامات عبارة عن تحسين شائع للأداء، فإن “إزالة” الحزمة من السجل العام تكون غير ذات صلة إذا كانت نسخة ضارة مثبتة بالفعل في بيئة البناء المحلية.
معاينة OpenVSX غير المتزامنة (الإصدار 1.0.1)
أكثر من 90% من حالات العدوى طويلة الذيل تنشأ من مصدر واحد: ملحق asyncapi-preview v1.0.1 الخبيث. على الرغم من سحبه من سجل OpenVSX في 26 نوفمبر، ظل الامتداد نشطًا على أجهزة المطورين.
وجد تحليلنا مؤشرًا متكررًا في سجلات تسرب الضحايا: "_PACOTE_NO_PREPARE_": "git+ssh://git@github.com/asyncapi/cli.git#2efa4dff59bc3d3cecdf897ccf178f99b115d63d"
هذا ارتكاب نقاط التجزئة مباشرة إلى الشوكة الخبيثة تم استخدامه في هجوم شاي خلود الأصلي. كانت آلية الاستمرارية بسيطة: نظرًا لأن السجل “تراجع” إلى الإصدار 1.0.0، لم تجد IDEs أي سبب لتحديث الإصدار 1.0.1 المثبت (الضار) أو استبداله.
في 23 ديسمبر، قامت Wiz Research بالإبلاغ عن هذه المشكلة إلى جهة الاتصال الأمنية AsyncAPI. في 24 ديسمبر، نشر فريق AsyncAPI إصدارًا نظيفًا 1.1.0 من الامتداد الخاص بسجل OpenVSX. يتم تحديث IDEs المثبت عليها الإصدار الضار تلقائيًا إلى الإصدار النظيف، مما أدى إلى إزالة غالبية الإصابات المعلقة.
أسرار لم يتم علاجها
بعد مرور شهر على وقوع الحادث، لم تكتمل عملية التنظيف بعد. على الرغم من أن الرموز المميزة الخاصة بالمنصة (npm/GitHub) شهدت إبطالًا شديدًا، إلا أن البنية التحتية الحيوية وبيانات اعتماد الذكاء الاصطناعي تظل مكشوفة.
نطاق مجموعة بيانات بحث Wiz: يغطي تحليلنا > 29000 مستودع مسرب و > 12000 جهاز فريد مخترق، يمثلون جميع الضحايا تقريبًا.
اعتبارًا من 28 ديسمبر، يكشف قياسنا عن بعد للمناظر الطبيعية “غير المدورة” عن بقايا خطيرة:
| نوع الاعتماد | معدل الإلغاء | الحالة / المخاطر القائمة |
|---|---|---|
| رموز جيثب | > 95% | العشرات لا تزال صالحة. |
| رموز npm | > 90% | ما يقرب من اثني عشر لا تزال صالحة. |
| بيانات اعتماد السحابة | ~50% | تظل المئات من المفاتيح طويلة العمر صالحة. |
| مفاتيح واجهة برمجة تطبيقات الذكاء الاصطناعي | قليل | > 200 مفتاح صالح (OpenAI، Gemini). |
| أدوات SaaS/Dev | قليل | العشرات من المفاتيح الصالحة (Slack، Cloudflare، Airtable). |
حادثة محفظة الثقة، دراسة حالة عالية المخاطر
في 25 ديسمبر، Trust Wallet أبلغ عن سرقة 7 ملايين دولار الناتجة عن تحديث ضار (v2.68) إلى ملحق المتصفح الخاص بهم. تواصل Trust Wallet تحقيقاتها، وذكرت أنها ستغطي خسائر المستخدمين.
وبينما لا يزال التحقيق مستمرًا، حددت شركة Wiz Research مؤشرات تشير إلى أن هذا الانتهاك قد يكون نتيجة مباشرة لحادث شا1 خلود.
تحديث 12/30 16:10 بالتوقيت العالمي: بعد وقت قصير من نشر منشور المدونة هذا، أصدرت Trust Wallet تقريرًا أوليًا بعد الوفاة، جاء فيه “لدينا ثقة كبيرة في أن حادثة ملحق المتصفح v2.68 من المحتمل أن تكون مرتبطة بحادثة Sha1-Hulud على مستوى الصناعة في نوفمبر”.
الدليل الأكثر إقناعا يكمن في الأسرار المحددة التي تم تسريبها خلال حملة شاي خلود. تؤكد مجموعة البيانات لدينا أن Trust Wallet كانت ضحية، ومن بين البيانات الأخرى، تسربت بيانات الاعتماد التالية:
-
رمز جيثب: رمز صالح مع
admin:enterpriseالنطاق علىtrustwalletمنظمة جيثب. -
بيانات اعتماد متجر الويب: معرف عميل Chrome Web Store، وسر العميل، ورمز التحديث الذي تم سحبه من أسرار إجراء GitHub.
يوفر تسرب هذين الأصلين مسارات متعددة قابلة للتطبيق لاختطاف خط أنابيب التوزيع الخاص بامتداد المتصفح.
المحاذاة الموضوعية والزمنية
هناك مؤشرات إضافية على وجود صلة محتملة ضمن تسمية الهجوم وتوقيته.
-
الجدول الزمني: وكان المجال الخبيث تم التسجيل في 8 ديسمبر، تماشيًا مع تحول هجوم شا 1 خلود إلى الاستغلال المستهدف للأسرار المحصودة.
بينما ظرفية حتى يتم الإفراج عن الجثة بعد الوفاة، يكون التداخل بين الأسرار المسربة وطبيعة استغلال Trust Wallet كبيرًا. إنه بمثابة تذكير صارخ: في هجمات سلسلة التوريد، تشكل الأسرار المتسربة تهديدًا مستمرًا، بغض النظر عن وقت احتواء الدودة الأولية.
التوصيات
إن استمرار شاخلود يثبت أن “الإزالة من التسجيل” ليست “نهاية الحادث”. لمنع البرمجيات الخبيثة “الزومبي” من البقاء، نوصي بإجراء التحولات الهيكلية التالية:
1. امتلك إدارة السجل الخاص بك
يؤدي استخدام سجل خاص (مثل Artifactory وNexus) إلى نقل مسؤولية النظافة الأمنية من السجل العام (npm) إلى مؤسستك.
-
إبطال المزامنة: تأكد من تكوين مرايا التسجيل الخاصة بك لإجراء إسناد ترافقي لبيانات التعريف الأولية بشكل متكرر. إذا كانت الحزمة “غير منشورة” أو “تم إبطالها” في npm، فيجب أن تعكس المرآة الداخلية هذه الحالة على الفور. لسوء الحظ، يتطلب هذا غالبًا أتمتة مخصصة.
-
تدقيق ذاكرة التخزين المؤقت “السحب”.: قم بفحص ذاكرة التخزين المؤقت الداخلية بشكل دوري بحثًا عن الحزم التي لم تعد موجودة في المستودعات العامة، حيث يعد هذا مؤشرًا رئيسيًا على وجود حزمة خطيرة أو ضارة.
2. تحييد ذاكرة التخزين المؤقت
تحسينات أداء CI/CD مثل --prefer-offline يمكن أن تصبح التزامات أمنية.
-
بناء النظافة: في إصدارات الإنتاج عالية المخاطر، تجنب استخدام ذاكرة التخزين المؤقت المحلية التي تتخطى التحقق من صحة التسجيل.
-
عمليات تهدئة التبعية: عند تخزين الحزم مؤقتًا، تفضل المقايضة فترات تهدئة التبعية أبعد من ذلك.
-
تحديثات القوة: في حالة الاشتباه في وقوع حادث في سلسلة التوريد، قم بفرض إنشاء نظيف عن طريق مسح ذاكرات التخزين المؤقت npm/yarn/pnpm المحلية عبر أسطول البناء الخاص بك.
3. التناوب السري الشامل
تُظهر مجموعة بيانات Shai-Hulud أن المؤسسات (والأنظمة الأساسية) كانت سريعة في تدوير رموز VCS المميزة ولكنها كانت بطيئة في تدوير المجموعة الأوسع من المفاتيح المسربة. تقييم جميع التسريبات من حيث الأهمية. يمكن أن يكون سر Chrome Web Store الذي تم تسريبه مدمرًا تمامًا مثل مفتاح AWS المسرب. الفرز والعلاج حسب ترتيب المخاطر.
4. احذر من الإصدارات الضارة اليتيمة
كما هو موضح من خلال عملنا مع AsyncAPI، قد يكون من الضروري إجراء تعديل إجباري للإصدار لإزالة الحزم الضارة المثبتة. إذا كنت مشرفًا، فقم دائمًا بنشر تحديث نظيف وإصدار أعلى لتشغيل آليات التحديث التلقائي في بيئة التطوير المتكاملة (IDEs) وبيئات المطورين.
