تنتشر موجة جديدة من هجمات سلسلة التوريد عبر منظومة npm، تستهدف هذه المرة أدوات تطوير البرمجيات من خلال حملة برمجيات خبيثة ذاتية الانتشار تُعرف باسم CanisterWorm. تستغل هذه التهديدات مساحات أسماء المطورين الشرعية لدفع نسخ ضارة من الحزم، محولة بذلك أدوات التطوير الموثوقة إلى آليات لتوصيل برمجيات سرقة بيانات الاعتماد.
ظهرت CanisterWorm لأول مرة في تقارير باحثي الأمن السيبراني، الذين تتبعوا نمطًا متكررًا لتحديثات الحزم الخبيثة عبر حسابات مطورين متعددة على npm. يتم إخفاء البرمجية الخبيثة بعناية ضمن ما يبدو أنها تحديثات روتينية لإصدارات حزم SDK، مما يسهل على المطورين تثبيتها دون إثارة أي شبهات.
CanisterWorm: هجوم سلسلة توريد متطور يهدد منظومة npm
كشف باحثو JFrog عن نسخ جديدة من الحزم المتأثرة بهجوم CanisterWorm، موسعين بذلك نطاق الحملة المعروفة إلى ما هو أبعد من الكشوفات السابقة. رصدت خطوط مراقبتهم المستمرة إصدارات إضافية متأثرة عبر مساحات أسماء متعددة، بما في ذلك الحزم التي تديرها حسابات مثل @emilgroup و @teale.io، والتي لم يتم الكشف عنها في تقارير سابقة.
يتجاوز تأثير الإصابة الناجحة مجرد التأثير على جهاز واحد. فبمجرد قيام مطور بتثبيت إحدى الحزم الملوثة، تقوم CanisterWorm بإسقاط باب خلفي مكتوب بلغة Python على الجهاز المضيف، وتبدأ في جمع رموز مصادقة npm، وتستخدم بيانات الاعتماد المسروقة لنشر نفسها بشكل مستقل في كل حزمة يديرها المطور المصاب. هذا السلوك المتسلسل يعني أن حساب مطور واحد مصاب قد يصبح نقطة انطلاق لتلويث عشرات الحزم الأخرى، مما يعرض مجموعة واسعة من المشاريع المعتمدة والمستخدمين لخطر فوري.
ما يجعل CanisterWorm صعبة الاحتواء بشكل خاص هو مدى اندماجها الطبيعي في سير عمل التطوير المعتاد. من خلال الاختباء خلف تحديثات الإصدارات والاستفادة من البنية التحتية اللامركزية للتحكم والقيادة، تتجنب هذه البرمجية الخبيثة المؤشرات التقليدية التي تبحث عنها معظم أدوات الأمان، موسعة نطاق وصولها بصمت قبل أن يلاحظ أحد وجود مشكلة.
آلية الإصابة وانتشار CanisterWorm
تبدأ عملية الإصابة بالبرمجية الخبيثة لحظة قيام المطور بتشغيل الأمر npm install على حزمة مصابة. يقوم خطاف postinstall الخبيث المدمج في ملف package.json بالتنفيذ تلقائيًا وبصمت، ليقوم بإسقاط باب خلفي مكتوب بلغة Python على نظام المضيف دون أي تحذير مرئي. على أجهزة Linux، يسجل الدود بعد ذلك خدمة خلفية مستمرة تسمى pgmon من خلال systemd، مما يضمن بقاءها نشطة وتجاوزها لإعادة تشغيل النظام.
بمجرد إنشائه، يقوم الباب الخلفي باستقصاء مستمر لخادم “dead-drop” للتحكم والقيادة مستضاف على شبكة بروتوكول الإنترنت (ICP)، وهو جهاز لامركزي مستضاف على البلوك تشين. هذا التصميم يجعل حركة المرور الخبيثة تندمج بشكل طبيعي مع طلبات الويب العادية، مما يعيق بشكل كبير اكتشافها بواسطة أدوات مراقبة الشبكة. يتم كتابة الحمولات الثانوية المستردة عبر هذه القناة إلى /tmp/pglog، بينما يتتبع الدود حالة تنفيذه داخل /tmp/.pg_state.
تعتبر مرحلة الانتشار الذاتي هي أخطر مرحلة في الهجوم. تقوم البرمجية الخبيثة بمسح ملفات .npmrc عبر دليل المشروع، ومجلد المستخدم، ومسارات التكوين على مستوى النظام، بحثًا عن قيم _authToken. كما تقرأ متغيرات البيئة NPM_TOKEN و NPM_TOKENS. باستخدام بيانات الاعتماد المسروقة هذه، يقوم البرنامج النصي المدمج deploy.js بالاستعلام من سجل npm، وتحديد كل حزمة يديرها الضحية، وزيادة رقم إصدار التصحيح لكل منها، ونشر التحديث الملوث تلقائيًا.
الحزم المعروفة المتأثرة
يجب على أي شخص يستخدم أيًا من إصدارات الحزم الملوثة المحددة أن يعامل بيئته على أنها مصابة بالفعل. يجب على المطورين على الفور تدوير جميع رموز نشر npm المخزنة في ملفات .npmrc، ومتغيرات البيئة، وأسرار مسارات CI/CD. على أنظمة Linux، يجب إيقاف خدمة pgmon وتعطيلها باستخدام systemctl، مع إزالة ملفات الخدمة والمجلدات المرتبطة بها بالكامل.
يجب حذف الملفات المؤقتة /tmp/pglog و /tmp/.pg_state. يجب تنظيف مجلدات node_modules المتأثرة وإعادة بنائها من الصفر باستخدام إصدارات حزم آمنة وموثوقة. يجب على المطورين الذين سُرقت رموزهم إلغاء نشر إصدارات الحزم الملوثة يدويًا من سجل npm، نظرًا لأن نشر إصدار أحدث لا يحمي المستخدمين النهائيين الذين قد يثبتون الإصدار المصاب.
يمنع تشغيل npm config set ignore-scripts true على مستوى عالمي تشغيل خطافات postinstall بصمت عند التثبيت المستقبلي، مما يوفر إجراءً دفاعيًا عمليًا ضد هذه الفئة من هجمات سلسلة التوريد.