تحذير أمني: برمجية خبيثة في حزمة node-ipc تسرق أسرار المطورين

مقدمة تحليلية

في تطور خطير يبرز هشاشة مستودعات البرمجيات مفتوحة المصدر، تم الكشف عن هجوم سلاسل توريد (Supply Chain Attack) استهدف حزمة node-ipc الشهيرة، مما يعرض بيانات آلاف المطورين للخطر. الحادثة التي تم رصدها في مايو 2026، ليست مجرد ثغرة أمنية عابرة، بل هي عملية اختراق منظمة استهدفت سرقة 90 فئة مختلفة من بيانات الاعتماد الحساسة. الإصدارات المتضررة هي [email protected] و[email protected] و[email protected]، حيث تم دمج كود برمجي خبيث يقوم بمسح شامل لبيئة العمل بمجرد استدعاء الحزمة. إن ما يثير القلق في هذا الهجوم هو الدقة في الاستهداف والتقنيات المستخدمة لتجنب الاكتشاف. فالإصدار 12.0.1 مصمم ليكون خاملاً تماماً إلا إذا تطابق بصمة نظام الضحية (SHA-256 fingerprint) مع قيم محددة مسبقاً لدى المهاجم، مما يعني أننا أمام هجوم 'جراحي' يستهدف أهدافاً بعينها داخل بيئات تطوير محددة. هذا النوع من العمليات يتجاوز أسلوب 'الصيد العشوائي' التقليدي، لينتقل إلى مرحلة الاستهداف الاستراتيجي للبنى التحتية السحابية وأنظمة الأتمتة.

التحليل التقني

اعتمد المهاجمون على آلية ذكية لتجاوز أدوات المسح التقليدية، حيث لم يتم استخدام نصوص التثبيت المعتادة (preinstall/postinstall) التي تثير الريبة عادةً. بدلاً من ذلك، تم إلحاق الكود الخبيث في نهاية ملف node-ipc.cjs على هيئة دالة يتم استدعاؤها فوراً (IIFE)، مما يضمن تنفيذها في كل مرة يتم فيها كتابة require('node-ipc'). تتضمن القدرات التقنية للبرمجية الخبيثة ما يلي:

• جمع أسرار السحابة: استهداف مفاتيح الوصول لخدمات Amazon Web Services وGoogle Cloud وMicrosoft Azure.
• سرقة بيانات التطوير: الحصول على مفاتيح SSH، وتوكنات Kubernetes، وإعدادات GitHub CLI، وحتى جلسات Claude AI وKiro IDE.
• قنوات الإخفاء المزدوجة: تستخدم البرمجية طريقتين لإرسال البيانات المسروقة؛ الأولى عبر طلبات HTTPS POST إلى النطاق المزيف sh.azurestaticprovider[.]net، والثانية هي الأكثر ابتكاراً عبر سجلات DNS TXT.
• تجاوز الرقابة: يقوم الكود الخبيث بتجاوز خادم DNS الخاص بالشركة واستخدام Google Public DNS (8.8.8.8) مباشرة للتواصل مع خادم التحكم (C2)، مما يجعل النشاط غير مرئي في سجلات DNS المحلية.
• الاستمرارية: تقوم البرمجية بإنشاء عمليات فرعية منفصلة (Detached background child processes) تستمر في العمل حتى بعد إغلاق التطبيق الأصلي الذي استدعى الحزمة.

السياق وتأثير السوق

يعيد هذا الحادث إلى الأذهان تاريخ حزمة node-ipc المثير للجدل، حيث قام صاحبها الأصلي في عام 2022 بإضافة كود تخريبي كنوع من الاحتجاج السياسي. ومع ذلك، فإن الهجوم الحالي مختلف جذرياً؛ فالاختراق تم عبر الاستيلاء على حساب Maintainer باسم 'atiertant'. تشير التحقيقات إلى أن المهاجم استغل انتهاء صلاحية نطاق البريد الإلكتروني المرتبط بالحساب (atlantis-software[.]net) ليقوم بإعادة تسجيل النطاق واستعادة كلمة المرور الخاصة بحساب npm، مما منحه صلاحيات النشر الكاملة. تأثير هذا النوع من الهجمات يتجاوز مجرد سرقة بيانات؛ فهو يضرب في مقتل 'الثقة' التي تقوم عليها بيئة العمل البرمجية الحديثة. تعتمد الشركات الكبرى على آلاف الحزم الفرعية (Dependencies)، واختراق حزمة واحدة نائمة منذ 21 شهراً مثل node-ipc يثبت أن 'الاستقرار الزمني' ليس ضماناً للأمان. السوق الآن يواجه ضغوطاً متزايدة لتبني أدوات تدقيق صارمة لسلاسل التوريد، وهو ما قد يزيد من تكاليف التطوير ويبطئ وتيرة الإنتاج في المدى القريب.

رؤية Glitch4Techs

نحن في Glitch4Techs نرى أن هذه الحادثة تمثل جرس إنذار حقيقي لمجتمع DevOps. المهاجمون لم يعودوا يبحثون عن ثغرات في الكود بقدر ما يبحثون عن 'ثغرات في العمليات'. إن الاستيلاء على حساب عبر نطاق بريد إلكتروني منتهي الصلاحية هو خطأ إداري أدى إلى كارثة تقنية. توصياتنا الصارمة للمؤسسات والفرق البرمجية:

• التحول الفوري لاستخدام Lockfiles (مثل package-lock.json) مع التحقق من سلامة البصمات (Integrity checks).
• حظر جميع الاتصالات الصادرة من بيئات التطوير والاختبار إلا لنطاقات محددة مسبقاً (Allowlisting).
• اعتبار أي بيئة تم استخدام الإصدارات المصابة فيها مخترقة تماماً، وتغيير كافة مفاتيح الوصول (Secrets Rotation) فوراً دون استثناء.
• اعتماد أدوات مسح الحزم التي لا تعتمد فقط على قاعدة بيانات CVE، بل تقوم بتحليل سلوك الحزم وقت التشغيل (Runtime analysis).

المستقبل يتطلب 'انعدام الثقة' (Zero Trust) حتى في الأكواد التي نكتبها ونستوردها بأنفسنا.