 |
| المصدر : microsoft.com |
كشفت مايكروسوفت عن هجوم واسع على سلسلة توريد البرمجيات يحمل اسم ChainDrop، أصاب أكثر من 400 حزمة منشورة في مستودع npm، واستهدف أجهزة المطورين وبيئات البناء والتكامل المستمر بهدف سرقة بيانات الاعتماد ثم استخدامها لنشر إصدارات خبيثة جديدة بصورة تلقائية.
وبحسب تقرير نشرته Microsoft Threat Intelligence في 4 أغسطس 2026، تضمنت الحملة حزمًا مرتبطة بمنظومات برمجية معروفة، من بينها keyv وflat-cache وcache-manager. واحتوت الإصدارات المصابة على نسخة من دودة Mini Shai-Hulud قادرة على سرقة المفاتيح والرموز السرية والانتشار بين الحزم والمستودعات دون حاجة المهاجم إلى تعديل كل مشروع يدويًا.
تكمن خطورة ChainDrop في أنه لا يستهدف مستخدمًا واحدًا فقط، بل يستغل الثقة الموجودة بين المطورين والحزم المفتوحة المصدر. وقد تبدأ الإصابة من حساب مشرف واحد، ثم تنتقل إلى عشرات الحزم والمشاريع وأجهزة المطورين وخوادم البناء المرتبطة بها.
ما هو هجوم ChainDrop؟
ChainDrop هو هجوم على سلسلة توريد البرمجيات يعتمد على زرع حمولة خبيثة داخل حزم npm تبدو في ظاهرها كتحديثات عادية. تصف مايكروسوفت الحمولة بأنها دودة ذاتية الانتشار وسارقة لبيانات الاعتماد، مكتوبة ضمن حزمة JavaScript كبيرة ومموهة بشدة وتستخدم بيئة تشغيل Bun.
مستودع npm هو أحد أهم مصادر الحزم التي تعتمد عليها مشاريع JavaScript وNode.js. وقد لا يثبت المطور الحزمة المصابة مباشرة، بل قد تصل إليه باعتبارها تبعية غير مباشرة لحزمة أو أداة أخرى يستخدمها المشروع.
لهذا السبب يمكن لإصابة حزمة واحدة واسعة الاستخدام أن تؤثر في عدد كبير من المشاريع، حتى عندما لا يعرف المطور أن اسم تلك الحزمة موجود أصلًا داخل شجرة التبعيات الخاصة بتطبيقه.
كيف بدأت عملية الاختراق؟
تشير الأدلة التي حللتها مايكروسوفت إلى أن نقطة الدخول الأولى كانت على الأرجح بيانات اعتماد مسروقة تعود إلى مشرفين على حزم برمجية. وبعد الحصول على صلاحيات النشر، ظهرت إصدارات فرعية جديدة لحزم متعددة دون وجود تغييرات مقابلة في مستودعات الشفرة المصدرية.
في عمليات النشر الشرعية، يسبق الإصدار الجديد عادةً تعديل واضح داخل المستودع، مثل commit أو pull request أو tag خاص بالإصدار. لكن عددًا من الإصدارات الخبيثة في حملة ChainDrop لم يكن مرتبطًا بهذه الخطوات، ما يشير إلى تعديل ملفات الحزمة المضغوطة ونشرها مباشرة باستخدام الصلاحيات المسروقة.
لاحقًا، استخدمت الدودة رموز نشر npm التي جمعتها من الأجهزة المصابة، كما احتوت على مسار يستهدف عمليات النشر الموثوقة التي تعتمد على GitHub Actions وOpenID Connect.
تشغيل البرمجية الخبيثة أثناء تثبيت الحزمة
أضاف المهاجمون إلى الإصدارات المصابة أمرًا من نوع
preinstall داخل ملف package.json. وهذه وظيفة
مشروعة في npm تسمح للحزمة بتشغيل برنامج قبل اكتمال عملية التثبيت.
عند تنفيذ أمر مثل npm install على إصدار مصاب، يعمل ملف يحمل
اسم setup.mjs، ثم يشغل الحمولة الخبيثة المموهة باستخدام Bun.
وقد يحدث ذلك قبل بدء اختبارات التطبيق أو بعض عمليات الفحص الأمنية التقليدية.
لا يحتاج المهاجم في هذه الحالة إلى إقناع المطور بفتح مرفق أو تشغيل ملف مجهول. يكفي أن يتم تنزيل الحزمة المصابة داخل جهاز المطور أو خادم البناء مع السماح بتشغيل lifecycle scripts.
الفرق بين الإصابة على جهاز المطور وبيئة CI/CD
بعد التشغيل، تحاول ChainDrop تحديد نوع البيئة التي توجد داخلها. إذا كانت تعمل على جهاز مطور، تنشئ نسخة منفصلة تعمل في الخلفية حتى تستمر بعد انتهاء عملية تثبيت الحزمة.
أما إذا اكتشفت أنها تعمل داخل بيئة تكامل أو تسليم مستمر CI/CD، فتبقى مرتبطة بمهمة البناء الجارية حتى تتمكن من الوصول إلى متغيرات البيئة، وأسرار workflow، وبيانات اعتماد runner، وصلاحيات النشر المتاحة داخل المهمة.
ويجعل ذلك خوادم البناء هدفًا عالي الخطورة، لأنها قد تحتوي على مفاتيح تسمح بنشر الحزم، والوصول إلى مستودعات خاصة، والتعامل مع خدمات سحابية أو بيئات إنتاج حقيقية.
ما البيانات التي كانت ChainDrop تحاول سرقتها؟
لا تكتفي الدودة بالبحث عن رمز npm واحد، بل تجمع معلومات من متغيرات البيئة، وملفات إعداد الخدمات السحابية، وسجل أوامر الطرفية، ومفاتيح SSH، وأدوات سطر الأوامر، وذاكرة GitHub Actions runner.
وتستخدم البيانات التي تجدها لمحاولة تسجيل الدخول فعليًا إلى عدد من الخدمات، من بينها:
- npm وحسابات نشر الحزم.
- GitHub والمستودعات القابلة للكتابة.
- Amazon Web Services.
- Kubernetes.
- HashiCorp Vault.
- بيئات البناء وأسرار GitHub Actions.
ولا يقتصر عملها على اكتشاف نص يشبه المفتاح، بل تتحقق من صلاحيات بيانات الاعتماد، ثم تحاول معرفة الحزم والمستودعات والأسرار والموارد التي يستطيع الحساب المصاب الوصول إليها.
لذلك قد يمتد أثر الإصابة من مشروع JavaScript صغير إلى مستودعات خاصة أو حسابات سحابية أو أسرار نشر وبيئات تشغيل حساسة.
كيف تنتشر الدودة تلقائيًا بين حزم npm؟
تمثل آلية الانتشار الذاتي أخطر أجزاء ChainDrop. فعندما تعثر الدودة على رمز npm يمتلك صلاحية النشر، تجمع قائمة بالحزم التي يستطيع ذلك الحساب تحديثها.
بعد ذلك تنزل أحدث نسخة من كل حزمة، وتضيف إليها الحمولة وملف التشغيل وأمر
preinstall، ثم ترفع رقم الإصدار الفرعي وتنشر النسخة المعدلة
إلى مستودع npm.
وبهذه الطريقة يمكن لرمز نشر واحد مسروق أن ينتج سلسلة من الإصدارات الخبيثة. وإذا ثبّت مشرف آخر إحدى تلك الحزم، فقد تسرق الدودة رمز النشر الخاص به وتستخدمه لإصابة مجموعة جديدة من الحزم.
هذه الحلقة هي التي تمنح الحملة سلوك الدودة: حزمة مصابة تسرق هوية جديدة، والهوية تفتح حزمًا إضافية، ثم تنشر تلك الحزم البرمجية نفسها إلى أجهزة ومشاريع أخرى.
استهداف GitHub وClaude وVisual Studio Code
كشفت مايكروسوفت أن ChainDrop تستطيع استخدام رموز GitHub المسروقة للبحث عن المستودعات التي يسمح للحساب بالكتابة فيها، ثم زرع ملفات داخل إعدادات Claude وVisual Studio Code.
شملت المسارات المستهدفة مجلدات مثل .claude و
.vscode. ويمكن لهذه الملفات إعادة تشغيل الحمولة لاحقًا عند
استخدام المشروع داخل بيئة التطوير، حتى بعد انتهاء عملية تثبيت npm الأصلية.
كما يخلق ذلك مسار انتقال ثانويًا بين المطورين. فقد يسحب عضو آخر في الفريق التعديلات المصابة من المستودع، ثم يفتح المشروع داخل محرره لتعمل الحمولة من جديد.
لماذا لا يكفي وجود بيانات Provenance صالحة؟
احتوت الدودة على طريقة تستهدف GitHub Actions workflows المهيأة كناشرين موثوقين لحزم npm باستخدام OIDC. وفي هذه الحالة يمكن أن يظهر الإصدار الخبيث ببيانات provenance صالحة، لأن عملية النشر خرجت بالفعل من workflow رسمي.
لكن provenance يثبت مصدر عملية البناء والنشر، ولا يثبت وحده أن الحساب أو workflow أو الشفرة التي دخلت في البناء لم تتعرض للاختراق.
ولهذا تحتاج المؤسسات إلى حماية workflow نفسه، وتقليل الصلاحيات، ومراجعة الموافقات، واستخدام البيئات المحمية، ومراقبة أي عملية نشر آلي غير معتادة.
كيف كانت البيانات المسروقة تُرسل إلى المهاجم؟
وفق تحليل مايكروسوفت، تجمع الدودة النتائج داخل بيانات JSON، ثم تضغطها وتشفّرها قبل محاولة إرسالها إلى خادم HTTPS يتحكم فيه المهاجم.
كما تستخدم آليات بديلة لتغيير عنوان خادم الاتصال، من بينها قراءة العنوان من عقد موجود على سلسلة كتل أو من commit موقع داخل GitHub. وإذا تعذر الاتصال بالقناة الأساسية، يمكن استخدام مستودع GitHub عام كمسار بديل لإخراج البيانات المشفرة.
يهدف هذا التصميم إلى منع إيقاف الحملة بمجرد حظر نطاق واحد، وإتاحة تغيير البنية المستخدمة في الاتصال دون إعادة نشر نسخة جديدة من البرمجية.
ماذا تفعل إذا ثبّت مشروعك حزمة مصابة؟
توصي مايكروسوفت بعدم الاكتفاء بحذف الحزمة أو الرجوع إلى إصدار أقدم. فإذا
عمل أمر preinstall بنجاح، يجب التعامل مع جهاز المطور أو خادم
البناء باعتباره مخترقًا محتملًا.
- اعزل الجهاز أو build runner المتأثر عن بقية الشبكة والأنظمة الحساسة.
- راجع شجرة التبعيات وملفات lockfile ومستودعات artifacts وذاكرة CI المؤقتة.
- ثبّت إصدارات معروفة وآمنة بدل الاعتماد على أحدث إصدار تلقائيًا.
- امسح ذاكرة npm وYarn المؤقتة، خصوصًا في بيئات البناء المشتركة.
- ألغِ رموز npm وGitHub ومفاتيح SSH وأسرار السحابة التي كان يمكن الوصول إليها.
- أنشئ المفاتيح الجديدة من جهاز نظيف، وليس من الجهاز المشتبه في إصابته.
- افحص المستودعات بحثًا عن تعديلات غير مصرح بها في workflows وإعدادات المحررات.
- أعد بناء المشاريع والـrunners والصور الأساسية من مصادر موثوقة.
ويجب أيضًا مراجعة الإصدارات التي نُشرت باسم المؤسسة خلال فترة الاشتباه، والتأكد من عدم وجود تحديثات فرعية لم يصدرها الفريق بصورة شرعية.
npm v12 يعطل lifecycle scripts افتراضيًا
أطلقت GitHub وnpm الإصدار 12 من npm CLI مع إعدادات أمنية جديدة أثناء
التثبيت. وأصبحت أوامر التبعيات من نوع
preinstall وinstall وpostinstall
معطلة افتراضيًا، ولا تعمل إلا بعد السماح بها صراحة.
يوفر الأمر npm approve-scripts طريقة لمراجعة scripts والموافقة
فقط على الحزم الموثوقة، ثم حفظ قائمة السماح داخل ملف
package.json.
كان من شأن هذا السلوك منع حمولة ChainDrop من العمل تلقائيًا أثناء التثبيت، ما لم تكن الحزمة المصابة موجودة مسبقًا ضمن قائمة الحزم المسموح لها بتشغيل scripts.
النشر المرحلي يضيف موافقة بشرية قبل إصدار الحزمة
وفرت npm في 2026 ميزة Staged Publishing. وبدل نشر الحزمة مباشرة وإتاحتها للمستخدمين، تُرفع النسخة إلى قائمة انتظار، ثم يحتاج مشرف بشري إلى الموافقة عليها بعد التحقق بخطوتين قبل أن تصبح قابلة للتثبيت.
يمكن دمج هذه الميزة مع النشر الموثوق عبر OIDC، بحيث يسمح workflow برفع الحزمة إلى مرحلة الانتظار فقط، ولا يستطيع نشرها بصورة نهائية دون الموافقة البشرية.
تساعد هذه الخطوة في إيقاف الانتشار الآلي، لأن امتلاك المهاجم رمزًا أو صلاحية داخل CI/CD لن يكون كافيًا وحده لإطلاق إصدار جديد إلى جميع المستخدمين.
فحص الحزم قبل إتاحتها في مستودع npm
بدأت npm أيضًا فحص الحزم الجديدة تلقائيًا قبل إتاحتها للتثبيت. وقد تُنشر الحزمة بصورة عادية، أو تُحتجز للمراجعة اليدوية، أو تُحظر، بحسب نتيجة الفحص.
يؤدي ذلك إلى تأخير قصير بين نشر الإصدار وإتاحته، لكنه يمنح أنظمة الحماية فرصة لاكتشاف البرمجيات الضارة قبل وصولها إلى مشاريع المطورين.
ومع ذلك، لا يمكن الاعتماد على الفحص الآلي وحده. فالبرمجيات المموهة والإصدارات المنشورة عبر حسابات شرعية قد تحتاج إلى طبقات إضافية من المراجعة والمراقبة.
كيف تحمي مشاريعك من هجمات سلسلة التوريد؟
- استخدم npm CLI v12 أو إصدارًا أحدث.
- لا تسمح بتشغيل install scripts إلا للحزم التي راجعتها.
- ثبت الإصدارات المعروفة باستخدام lockfiles ولا تحدّث تلقائيًا دون مراجعة.
- استخدم خاصية min-release-age قبل اعتماد إصدار جديد.
- فعّل المصادقة الثنائية على npm وGitHub.
- تجنب رموز النشر طويلة الصلاحية كلما أمكن.
- استخدم OIDC مع النشر المرحلي والموافقة البشرية.
- قلل صلاحيات GitHub Actions إلى الحد الأدنى المطلوب.
- افصل بيئات البناء عن الأنظمة الإنتاجية والحسابات الإدارية.
- راقب الإصدارات الجديدة التي لا تقابلها commits أو tags معروفة.
الخلاصة
يكشف هجوم ChainDrop كيف يمكن لاختراق هوية مطور واحد أن يتحول إلى تهديد واسع لسلسلة توريد البرمجيات. فقد استخدمت الدودة بيانات الاعتماد المسروقة لإصابة حزم جديدة، والوصول إلى مستودعات وخدمات سحابية، وإنشاء مسارات بقاء داخل أدوات التطوير.
الدرس الأهم هو أن شهرة الحزمة أو صدورها من workflow رسمي أو امتلاكها بيانات provenance صالحة لا يكفي لإثبات سلامتها. تحتاج المؤسسات إلى الجمع بين تقليل الصلاحيات، وتثبيت الإصدارات، وتعطيل scripts، ومراجعة عمليات النشر، والموافقة البشرية، ومراقبة بيئات CI/CD.
وإذا ثبت تشغيل حزمة مصابة، فيجب التعامل مع الحادثة على أنها اختراق محتمل للهوية والبنية التحتية، لا مجرد تبعية سيئة يمكن حذفها ومتابعة العمل.
الأسئلة الشائعة
ما هو هجوم ChainDrop؟
هو هجوم على سلسلة توريد npm استخدم دودة ذاتية الانتشار لسرقة بيانات اعتماد المطورين ونشر إصدارات خبيثة داخل حزم إضافية.
كم عدد حزم npm التي أصابها الهجوم؟
قالت Microsoft Threat Intelligence إن حملتها التحليلية رصدت أكثر من 400 حزمة مصابة عبر ناشرين غير مرتبطين ببعضهم.
كيف تعمل الدودة أثناء تثبيت الحزمة؟
تستخدم أمر preinstall لتشغيل ملف setup.mjs قبل اكتمال التثبيت، ثم تطلق حمولة JavaScript مموهة تعتمد على Bun.
ما البيانات التي تحاول ChainDrop سرقتها؟
تستهدف رموز npm وGitHub، ومفاتيح SSH، ومتغيرات البيئة، وأسرار GitHub Actions، وبيانات AWS وKubernetes وHashiCorp Vault.
هل يكفي حذف الحزمة المصابة؟
لا. إذا نُفذت الحمولة، يجب اعتبار الجهاز أو خادم البناء مخترقًا محتملًا، وتدوير جميع بيانات الاعتماد وإعادة البناء من بيئة نظيفة.
كيف يقلل npm v12 خطر الهجوم؟
يعطل lifecycle scripts الخاصة بالتبعيات افتراضيًا، ولا يسمح بتشغيلها إلا بعد موافقة صريحة من المستخدم.