اختراق 145 حزمة من Mastra على npm: تشريح الهجوم واستجابة Microsoft

Mastra هو إطار عمل مفتوح المصدر مبني على JavaScript وTypeScript، ويُستخدم لتطوير تطبيقات الذكاء الاصطناعي والوكلاء البرمجيين. وكانت الحزم المتأثرة تسجل مجتمعةً أكثر من 1.1 مليون عملية تنزيل أسبوعياً، ما وسّع نطاق الخطر إلى عدد كبير من بيئات المطورين وأنظمة البناء .

في 19 يونيو، قالت Microsoft إنها تنسب الهجوم، بدرجة ثقة عالية، إلى Sapphire Sleet، وهي جهة كورية شمالية تركز أساساً على القطاعين المالي والعملات المشفرة .

كيف نُفّذ الاختراق؟

استغل المهاجمون نقطة ضعف مألوفة في هجمات سلسلة التوريد: حساب موثوق يملك صلاحيات نشر واسعة، ثم حُقنت الحزم الخبيثة في مسار التثبيت قبل أن يشغّل المستخدم التطبيق نفسه.

1. هندسة اجتماعية واختطاف حساب مشرف

بدأت العملية باستهداف أحد المشرفين الشرعيين على Mastra عبر الهندسة الاجتماعية، ما مكّن المهاجمين من الاستيلاء على بيانات اعتماد حسابه في npm . وكان الحساب، الذي عُرّف باسم ehindero، يملك صلاحيات نشر على نطاق @mastra بأكمله .

2. نشر جماعي سريع

استخدم المهاجمون الحساب المختطف لإعادة نشر حزم النطاق @mastra/* خلال نافذة زمنية بلغت نحو 88 دقيقة. وتشير بعض التقارير إلى أن الجزء الأكبر من عملية النشر تم خلال 19 دقيقة فقط . وتوحي هذه السرعة بأن العملية نُفذت بواسطة سكربت آلي، لا عبر رفع الحزم يدوياً واحدة تلو الأخرى.

3. إدخال تبعية تحمل اسماً مشابهاً

زُرعت في كل إصدار متأثر تبعية خبيثة باسم easy-day-js. والاسم يحاكي مكتبة dayjs الشرعية والمستخدمة على نطاق واسع، وهي حيلة تُعرف باسم typosquatting؛ أي استغلال تشابه الأسماء لخداع المطورين أو أدوات إدارة الحزم . وأطلقت شركات وباحثون أمنيون على الحملة اسم easy-day-js .

4. تشغيل تلقائي أثناء التثبيت

اعتمدت الحمولة على سكربت npm المعروف باسم postinstall. لذلك كان تنفيذ الأمر:

npm install

كافياً لتشغيل الكود الخبيث عند تثبيت إصدار متأثر؛ فلم يكن مطلوباً من المطور تشغيل التطبيق أو استدعاء وظيفة محددة حتى تبدأ الحمولة .

5. سرقة مفاتيح وبيانات اعتماد

بعد تشغيلها، بحثت الحمولة عن مفاتيح محافظ العملات المشفرة، وبيانات اعتماد الخدمات السحابية، وأسرار بيئات CI/CD على أجهزة المطورين وأنظمة البناء . كما عطّلت التحقق من TLS ونزّلت أداة سرقة من مرحلة ثانية من بنية تحتية يسيطر عليها المهاجمون .

لماذا نسبت Microsoft الهجوم إلى Sapphire Sleet؟

في تحديث صدر في 19 يونيو 2026، قالت Microsoft إن البنية التحتية المستخدمة وأساليب وتقنيات وإجراءات ما بعد الاختراق—المعروفة اختصاراً بـ TTPs—تتوافق مع عمليات موثقة سابقاً لـ Sapphire Sleet .

وتربط Amazon Threat Intelligence المجموعة أيضاً بحملات سابقة استهدفت حزم npm، من بينها axios وdebug وchalk وtypo-crypto .

استجابة Microsoft: تقليص عمر مفاتيح NuGet

دفعت هذه الحادثة Microsoft إلى تسريع تغييرات أمنية كانت تعمل عليها، وخصوصاً ما يتعلق بمفاتيح النشر طويلة الأجل.

مفاتيح جديدة بعمر أقصى يبلغ 30 يوماً

اعتباراً من 17 أغسطس 2026، خفّضت Microsoft الحد الأقصى لعمر مفاتيح API الجديدة على NuGet.org من 365 يوماً إلى 30 يوماً . كما ستنتهي صلاحية جميع المفاتيح التي أُنشئت قبل هذا التاريخ إجبارياً في 1 نوفمبر 2026 .

وتستند الخطوة إلى مشكلة واضحة: مفتاح API طويل الأجل قد يكون سلسلة نصية يسهل فقدانها أو تسريبها، لكنه يمنح المهاجم—إذا حصل عليه—نافذة زمنية طويلة لنشر حزم متلاعب بها باسم مشروع موثوق .

Trusted Publishing: بديل قائم على OIDC

توصي Microsoft مشرفي الحزم بالانتقال إلى Trusted Publishing، وهو مسار نشر أطلقته على NuGet في سبتمبر 2025 ويستبدل مفاتيح API طويلة الأجل بمصادقة قصيرة الأجل تعتمد على معيار OpenID Connect (OIDC) .

وتتمثل الفكرة في أن سير عمل CI/CD، مثل GitHub Actions، يثبت هويته مباشرة لدى سجل الحزم بدلاً من الاحتفاظ بمفتاح ثابت داخل المستودع أو نظام البناء.

ومن أبرز مزايا هذا النهج :

• عدم تخزين أسرار طويلة الأجل في المستودعات أو أنظمة CI/CD.
• إصدار بيانات اعتماد قصيرة العمر لكل عملية نشر، وتنتهي عادةً خلال نحو ساعة.
• التحقق من هوية سير العمل والمستودع والبيئة الاختيارية المسجلة في سياسة الناشر.
• الاستغناء عن تدوير الأسرار يدوياً.
• تقليص نطاق الضرر المحتمل إذا تسرّبت بيانات الاعتماد.

وعند تشغيل سير العمل، يطلب مزود CI/CD رمز OIDC موقّعاً تشفيرياً. ويتحقق NuGet.org من الرمز مقابل سياسة الناشر المسجلة، ثم يصدر مفتاح API مؤقتاً يُستخدم مرة واحدة تقريباً، وصالحاً لجلسة النشر فقط .

تغييرات أوسع في منظومة npm

لا تقتصر الاستجابة على NuGet. فقد اتخذت npm وGitHub خطوات موازية لتقليل الاعتماد على رموز النشر طويلة الأجل:

• إلغاء الرموز التقليدية: ألغت npm نهائياً جميع الرموز التقليدية طويلة الأجل في ديسمبر 2025، وأصبح الأمر npm login يصدر رموز جلسة مدتها ساعتان فقط .
• تقليص عمر الرموز التفصيلية: أصبحت رموز الوصول التفصيلية الجديدة التي تتيح الكتابة تتمتع بعمر افتراضي يبلغ 7 أيام، وبحد أقصى يبلغ 90 يوماً .
• النشر المرحلي: أصبح خيار staged publishing متاحاً عموماً في مايو 2026، ويطلب من المشرف اجتياز تحدي المصادقة الثنائية 2FA والموافقة صراحةً على الإصدار قبل إتاحته للتثبيت العام .

تستهدف هذه الإجراءات مجتمعةً نقطة الضعف التي استغلها الهجوم: رمز نشر واحد طويل العمر، ضعيف الحماية، ويمنح صلاحية الوصول إلى نطاق كامل من الحزم.

ما الذي ينبغي على المطورين فعله؟

• راجع مفاتيح NuGet الحالية ودوّرها: ستنتهي في 1 نوفمبر 2026 صلاحية المفاتيح التي أُنشئت قبل 17 أغسطس 2026. أنشئ مفاتيح جديدة أو انتقل إلى Trusted Publishing قبل الموعد .
• اعتمد Trusted Publishing حيثما أمكن: فالمصادقة القائمة على OIDC تقلل الحاجة إلى تخزين أسرار طويلة الأجل في خطوط CI/CD، وهي مدعومة في NuGet.org وnpm وPyPI .
• حدّث مسارات النشر في npm: استخدم رموز الجلسات القصيرة أو الرموز التفصيلية محدودة العمر أو النشر المرحلي، وفق ما يناسب مشروعك .
• ثبّت إصدارات الحزم: يساعد تثبيت الإصدارات المعروفة والموثوقة على منع التحديثات التلقائية من إدخال حزم متأثرة إلى المشاريع الحساسة .
• عطّل سكربتات التثبيت التلقائية عند الحاجة: يمكن استخدام npm install --ignore-scripts أو ضبط ignore-scripts = true لتقليل خطر تشغيل سكربتات postinstall الخبيثة أثناء التثبيت .

الدرس الأبرز من حادثة Mastra هو أن سلسلة توريد البرمجيات قد تُخترق من حساب موثوق واحد، وأن سرعة النشر الآلي تجعل تقليص عمر بيانات الاعتماد والتحقق من هوية سير العمل جزءاً أساسياً من أمن تطوير البرمجيات، لا إجراءً إضافياً يمكن تأجيله.