Miasma: كيف حوّل حسابٌ مسروق من Red Hat توثيقَ npm إلى حصان طروادة

الهجوم الذي جعل إشارات الثقة غير موثوقة

أمضى أمن سلسلة توريد البرمجيات ثلاث سنوات يسعى نحو هدف واحد: التوثيق (provenance). إذا كان بالإمكان إثبات بشكل مشفر أن حزمةً ما بُنيت من مستودع معروف، عبر سير عمل معروف، في وقت معروف — فيُفترض أن تكون آمناً. غير أن دودة Miasma، التي انفجرت في فضاء أسماء npm الخاص بـ @redhat-cloud-services في 1 يونيو 2026، قضت على هذا الافتراض في غضون ساعات.

باختراق حساب GitHub لأحد موظفي Red Hat، وتسليح خط أنابيب النشر الموثوق OIDC — الذي صُمِّم أصلاً للقضاء على الأسرار طويلة الأمد — نشر المهاجمون 96 إصداراً خبيثاً من الحزم، وكلها تحمل تواقيع SLSA صالحة لإثبات المصدر. كانت هذه الحزم تمتلك أرقام تنزيل حقيقية، وفضاء أسماء موثوقاً، وشهادات تشفيرية من Sigstore. وبالنسبة لأي ماسح أمني آلي، كانت تبدو نظيفة تماماً.

هذه الحادثة ليست مجرد مشكلة تخص Red Hat. إنها دليل على أن بنية الثقة في سلسلة التوريد التي توحّدت عليها الصناعة — رموز OIDC قصيرة الأمد، وتوثيق SLSA، وشهادات Sigstore — يمكن تحويلها ضد نفسها في اللحظة التي يتعرض فيها حساب بشري واحد للاختراق.

كيف وظّفت Miasma إشارات الثقة كسلاح

1. الاستيلاء على الحساب عبر التصيد الاحتيالي الموجّه

يُظهر تحليل Aikido Security لحادثة 1 يونيو أن حساب GitHub خاصاً بأحد موظفي Red Hat قد تعرّض للاختراق، مما أتاح للمهاجمين دفع التزامات (commits) يتيمة خبيثة مباشرةً إلى ثلاثة مستودعات — RedHatInsights/frontend-components، وRedHatInsights/javascript-clients، وRedHatInsights/platform-frontend-ai-toolkit — متجاوزين مراجعة الكود كلياً. أتاحت عملية الاستيلاء على الحساب موجتين من النشر الخبيث: الأولى عند الساعة 10:53 بتوقيت UTC والثانية عند 13:44 UTC، كلتاهما في 1 يونيو 2026.

لم يكن ناقل الوصول الأولي ثغرة يوم الصفر في GitHub أو npm. كان إنساناً. يكفي استهداف مطوّر واحد بصلاحية الكتابة على المستودع عبر التصيد الاحتيالي الموجّه لفتح سلسلة ثقة CI/CD بأكملها — لأن خطوط الأنابيب الحديثة مُصمَّمة للوثوق بهوية من يدفع الـcommit.

لم تظهر Miasma من فراغ. تتبّع Wiz Research سلسلة نسب الهجوم إلى حملة أوسع استهدفت Bitwarden CLI في 22 أبريل، وأربع حزم من SAP في 29 أبريل، وPyTorch Lightning في 30 أبريل، وحزمة DurableTask من Microsoft في 19 مايو. وبحلول 12 مايو، كان الـtoolkit الأساسي — الذي أطلق عليه مجموعة التهديد TeamPCP اسم “Mini Shai-Hulud” — قد نُشر علناً كـsource code، مما مكّن الجهات الفاعلة المستقلة من تكييفه. و Miasma إحدى هذه التكييفات، إذ تستبدل مراجع أساطير Dune بالأساطير اليونانية، وتضيف جامعي بيانات اعتماد جديدة تستهدف هويات GCP وAzure.

2. إساءة استخدام GitHub Actions OIDC لتوليد شهادات موثوقة

لم يكن الاستغلال الحاسم هجوماً بالقوة — بل كان أناقةً في التنفيذ. يوثّق مدوّنة أمان Microsoft أنه بمجرد التمركز في مستودعات Red Hat، أنشأ المهاجمون سير عمل ci.yaml لـGitHub Actions يحمل صلاحيات id-token: write — وهو الإعداد المعياري للنشر الموثوق. كان هذا السير يُفعَّل “عند كل push إلى أي فرع”، وينفّذ حمولة _index.js مُبهمة، ثم يطلب رمز هوية OIDC قصير الأمد من خدمة رموز GitHub. كان هذا الرمز يُستبدل بنقطة نهاية النشر الموثوق في npm لنشر حزم تحت نطاق @redhat-cloud-services مع شهادات SLSA صالحة لإثبات المصدر مُولَّدة عبر خدمتَي Fulcio وRekor من Sigstore.

من منظور سجل حزم npm، كان النشر لا يمكن تمييزه عن عملية تشغيل CI/CD شرعية لـRed Hat. كانت سلسلة الشهادة كاملة. كان فضاء الأسماء صحيحاً. كان معرف سير العمل متطابقاً. أصبح توثيق SLSA — الذي قدّمه مجتمع الأمان باعتباره ترياق هجمات سلسلة التوريد — هو الآلية التي جعلت الحزم الخبيثة أكثر إقناعاً، لا أقل.

والأهم من ذلك أن Miasma كانت تُولّد حمولة مشفرة فريدة لكل عملية إصابة، متجاوزةً قواعد الكشف القائمة على التجزئة التي تستخدمها أدوات الأمان عادةً للإشارة إلى إصدارات الحزم الخبيثة المعروفة.

3. سكريبت preinstall لكنس بيانات الاعتماد

تضمّنت الحزمة الخبيثة خطّافاً من نوع preinstall — "preinstall": "node index.js" — يُفعَّل تلقائياً خلال npm install، قبل أن تتاح للمطوّر أي فرصة لفحص ما قام بتثبيته. كان الـdropper يزن 4.2 MB ويستخدم تعتيماً متعدد الطبقات: مصفوفة كبيرة من رموز الأحرف تُعاد بنيتها في وقت التشغيل، وتُفكَّك عبر تحويل شيفرة قيصر من نوع ROT، ثم تُنفَّذ ديناميكياً عبر eval(). أضافت المراحل اللاحقة تشفير AES-128-GCM وحماية مصفوفة السلاسل من Obfuscator.io، لتنفّذ في نهاية المطاف حمولة قائمة على Bun.

كانت عملية كنس بيانات الاعتماد شاملة. وفقاً لـالتحليل التقني المفصّل من Microsoft، استهدف البرنامج الخبيث: أسرار GitHub Actions بما فيها GITHUB_TOKEN وACTIONS_RUNTIME_TOKEN؛ بيانات اعتماد AWS IAM وSecrets Manager؛ رموز Azure IMDS OAuth2 والوصول إلى Key Vault؛ رموز حسابات خدمة GCP؛ رموز HashiCorp Vault؛ بيانات اعتماد حسابات خدمة Kubernetes؛ رموز npm وPyPI؛ مفاتيح SSH؛ بيانات اعتماد Docker؛ مفاتيح GPG؛ ملفات .env؛ وبيانات الاعتماد المخزَّنة في المتصفحات. أي مطوّر أو runner لـCI/CD نفّذ npm install على إصدار متأثر، ربما تسرّبت بيانات اعتماده عبر كل السحابات التي كان يملك إليها وصولاً.

ما يجب على فرق الأمان فعله

1. دقّقوا فوراً في نطاقات رموز OIDC لـCI/CD

صلاحية id-token: write هي حجر الزاوية في النشر الموثوق — لكنها أيضاً سطح الهجوم الذي استغلّته Miasma. يجب مراجعة كل سير عمل GitHub Actions في مؤسستكم يحمل هذه الصلاحية. ينبغي تقييد النطاق بالحد الأدنى اللازم للعملية: إذا كان سير العمل ينشر على npm، فلا ينبغي أن يمتلك في الوقت ذاته صلاحيات contents: write أو packages: write. طبّقوا قواعد حماية الفروع بحيث لا يمكن تعديل ملفات سير العمل في .github/workflows/ إلا من قِبل مجموعة محدودة من المُشرفين مع مراجعة إلزامية — لا من قِبل أي شخص يمتلك صلاحية push.

توصي Wiz بتطبيق قوائم السماح بالتبعيات وتوليد SBOM بحيث تُثير أي إصدار جديد من حزمة يُسحب إلى بناء تنبيهاً قبل تنفيذه. يعمل هجوم خطّاف preinstall لأن npm install يُعامَل كعملية آمنة ومؤتمتة — إزالة هذا الافتراض هو أول ضبط عملي.

2. عاملوا التوثيق كإشارة، لا كضمان

تُخبركم شهادات SLSA وشهادات Sigstore كيف بُنيت الحزمة ومن أين — لكنها لا تُخبركم بما إذا كان الحساب الذي أطلق البناء يخضع لسيطرة شرعية من قِبل مالكه في وقت البناء. كانت شهادات Miasma صالحة تشفيرياً لأن البناء جرى على بنية GitHub التحتية باستخدام حساب شرعي (وإن كان مخترقاً).

تحتاج الصناعة إلى تكديس إشارات إضافية فوق التوثيق: الكشف عن الشذوذ السلوكي (سير عمل لم ينشر أبداً من قبل ينشر فجأة 32 إصداراً من الحزم في موجتين هو شذوذ)، وتصنيف درجة المخاطرة على مستوى الحساب (هل جرى الوصول إلى حساب GitHub مؤخراً من موقع غير معتاد؟)، والثقة المحدودة زمنياً (شهادة توثيق لإصدار حزمة نُشر بعد 12 ساعة من آخر إصدار شرعي ينبغي أن تُثير مراجعة بشرية، لا تثبيتاً تلقائياً). التوثيق شرط ضروري للثقة — لكنه ليس شرطاً كافياً.

3. اشترطوا مراجعة سكريبتات preinstall في سياسة npm

يمنع خيار --ignore-scripts في npm install تنفيذ خطافات preinstall وpostinstall. بالنسبة لخطوط أنابيب CI/CD الإنتاجية التي لا تحتاج إلى سكريبتات دورة الحياة، ينبغي أن يكون هذا الخيار إعداداً افتراضياً لا تنازل عنه. أوصت Microsoft بذلك صراحةً في إرشادات معالجة Miasma. في البيئات المؤسسية، ينبغي لسياسات حزم npm الإشارة إلى أي حزمة تُدخل حديثاً سكريبت preinstall في إصدار محدَّث — وهو نمط لا يوجد له حالة استخدام سليمة في معظم التبعيات الإنتاجية.

بالنسبة للفرق التي تُشغّل إصدارات متأثرة بالفعل، توصي Microsoft بتدوير جميع بيانات الاعتماد المكشوفة فوراً: رموز GitHub، وبيانات اعتماد سحابة IAM (AWS وGCP وAzure)، ومفاتيح SSH، ورموز npm وPyPI، وحسابات خدمة Kubernetes، ورموز HashiCorp Vault. تجري عملية التسريب بصمت عند وقت التثبيت — افترضوا أن أي نظام نفّذ إصداراً متأثراً قد تعرّض للاختراق الكامل حتى اكتمال تدوير بيانات الاعتماد.

مفارقة الثقة: حين يصبح التوثيق سلاحاً

تُمثّل Miasma أوضح دليل حتى الآن على أن بنية أمان سلسلة التوريد الحالية تعاني نقطة فشل وحيدة: الحسابات البشرية. صُمِّم النشر الموثوق OIDC للقضاء على خطر سرقة رموز npm طويلة الأمد — وقد نجح في ذلك. لم تكن Miasma بحاجة إلى رمز طويل الأمد. احتاجت فقط إلى حساب مطوّر واحد مخترق و15 دقيقة من وقت تشغيل GitHub Actions.

تُظهر حملة الهجوم الأوسع خلف Miasma — التي امتدت إلى Bitwarden وSAP وPyTorch وحزمة DurableTask من Microsoft خلال الأسابيع الستة السابقة لحادثة Red Hat — أن هذا ليس عشوائياً. يقوم الجهات المهددة بمسح منهجي للبنية التحتية للنشر الموثوق في النظم البيئية الكبرى، وتحديد الحزم ذات أعلى تضخيم لاحق (116,991 تنزيل أسبوعي لنطاق Red Hat وحده)، وتوقيت الاختراقات لاستهداف خطوط الأنابيب قبل أن يلاحظ المُشرفون.

يجب على الاستجابة السياسية أن تلحق بالركب. تُوفّر شهادة SLSA من المستوى 3 ضمانات قوية بشأن بنية البناء التحتية — لكنها لا تقول شيئاً عن نظافة الحسابات. الحدود التالية هي SLSA من المستوى 4: عمليات بناء محكمة وقابلة للاستنساخ تفصل المنتج عن أي حساب بشري محدد كلياً. حتى يصبح ذلك سائداً، فإن التوثيق إشارة تعلّم مهاجمون متطورون تزويرها بالصعود مستوى واحداً أعلى في سلسلة الثقة. فرق الأمان التي تعامل شارة التوثيق الخضراء باعتبارها حزمة آمنة تعمل على افتراض أبطلته Miasma الآن.

الأسئلة الشائعة

المصادر والقراءات الإضافية

• Miasma Malware Targets npm Packages — The Hacker News
• Preinstall Persistence Inside Red Hat npm: Miasma Credential-Stealing Campaign — Microsoft Security Blog
• Miasma Supply Chain Attack Targeting Red Hat npm Packages — Wiz
• Red Hat npm Packages Compromised: Credential-Stealing Worm — Aikido Security