M-Red-Team: حل وسط لسلسلة التوريد AsyncAPI عبر إجراءات GitHub

في 14 يوليو 2026، فتح أحد المهاجمين 37 طلب سحب إلى مستودع مولد AsyncAPI. حاول الجميع تقريبًا إضافة صفحة تبرعات خيرية مزيفة. تمويهًا في الضوضاء، استغل مسؤول علاقات عامة واحد سير عمل GitHub Actions الذي تم تكوينه بشكل خاطئ لسرقة رمز وصول شخصي مميز للغاية.

تم نشر أربع حزم npm ضارة (خمسة إصدارات إجمالية) ضمن @asyncapi مساحة الاسم. تحتوي الحزم على حمولة متعددة المراحل تثبت الثبات وتتصل بالبنية التحتية للقيادة والتحكم. تشهد هذه الحزم مجتمعة أكثر من 140.000 عملية تنزيل يوميًا. في هذه الحالة، يتم تنفيذ الحمولة عند الاستيراد/الطلب، وليس عند التثبيت.

لا يبدو أن هذا مرتبط بشكل مباشر بالتسوية السابقة @asyncapi في هجوم شاي خلود 2.0.

ماذا حدث؟

استغل المهاجم فئة الثغرة الأمنية المعروفة باسم “طلب pwn” في إجراءات GitHub. ال asyncapi/generator يحتوي المستودع على ملف سير العمل الذي تم استخدامه pull_request_target لتشغيل طلبات السحب، ولكن بعد ذلك قم بفحص رمز طلب السحب بدلاً من الفرع الأساسي.

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

لسوء الحظ، احتمال وجود هذه الثغرة الأمنية تم التعرف عليها قبل أشهر من الهجوم. في 29 أبريل، فتح أحد المساهمين العلاقات العامة للتحقيق في المشكلة باستخدام حمولة إثبات المفهوم. وفي 17 مايو، تابعوا إصلاحًا مقترحًا يقسم سير العمل إلى وظيفتين منفصلتين لعزل الوصول السري عن التعليمات البرمجية غير الموثوق بها. كان هذا الإصلاح لا يزال مفتوحًا، وغير مدمج، عندما ضرب المهاجم بعد 58 يومًا.

في الساعة 05:08 بالتوقيت العالمي، فتح المهاجم PR #2155 الذي يحتوي على ملف تخفيض السعر مع JavaScript غامض مخفي بعد حوالي 1000 بايت من المسافة البيضاء. تم تصميم الحمولة لفحص بيئة تشغيل GitHub Actions بحثًا عن الأسرار وإخراجها إلى عنوان URL ميت على ملف لصق Rentry.co.

أشارت المراجعة الآلية إلى التشويش، وعلى الرغم من أنه لم يتم دمج العلاقات العامة مطلقًا، إلا أن الضرر قد حدث بالفعل. اكتمل سير العمل في الساعة 05:16 بالتوقيت العالمي وتمكن المهاجم من استرداد بيانات الاعتماد المسروقة.

يبدو أن الرمز المميز الذي تم اختراقه هو PAT ينتمي إليه asyncapi-bot، حساب خدمة يتمتع بإمكانية الوصول عبر مؤسسة AsyncAPI.

تم نشر الحزم الضارة

باستخدام تقنية PAT المسروقة، أرسل المهاجم التزامًا ضارًا مباشرةً إلى الفرع “التالي” في الساعة 06:58 بالتوقيت العالمي المنسق. أدى هذا إلى تشغيل سير عمل الإصدار، والذي نشر الحزم الثلاث الأولية المخترقة إلى npm في الساعة 07:10 بالتوقيت العالمي.

ثم تحول المهاجم إلى asyncapi/spec-json-schemas المستودع، ودفع 11 التزامًا بين الساعة 07:51 والساعة 08:28 بالتوقيت العالمي المنسق. نسختان ضارتان إضافيتان من @asyncapi/specs تم نشرها.

تحتوي جميع الإصدارات الخمسة على نفس الحمولة التي تم حقنها في ملفات مختلفة. يتم إخفاء التعليمات البرمجية الضارة في السطر الأول من ملفات المصدر الشرعية، مع ترك مسافة بيضاء عليها لدفعها خارج الشاشة في معظم المحررين.

اتصالات لهجمات أخرى

تشترك الحمولة في بعض الخصائص التقنية مع إطار عمل البرامج الضارة Miasma الذي تم توثيقه مسبقًا في هجمات سلسلة التوريد. تستخدم طبقة التشويش javascript-obfuscator مع أبجدية Base64 مخصصة، نفس التكوين الذي شوهد في الحوادث السابقة.

يُعرّف وقت تشغيل المرحلة 3 بشكل صريح بأنه "M-RED-TEAM v6.4" في تعليقات التعليمات البرمجية التي تصف تشفير المنارة وبروتوكولات الاتصال C2. مجموعات ملفات التكوين المستخرجة giteaPackagesOrg ل "miasma-test-org." تستخدم الحمولة miasma-monitor.service ضمن رمز الثبات. يستخدم Nostr Relay C2 "miasma” العلامات ذات العلامات التجارية.

ومع ذلك، فإن عنوان URL الخاص بـ Rentry يستخدم الارتباط التقريبي "elzotebo," مطابقة أنماط التسمية من حملة prt-scan، والتي تم ربطها بهجمات سابقة تعتمد على طلب السحب. ال prt-scan لم يتم ربط الحملة بـ Miasma.

وبعيدًا عن المراجع وطريقة التشويش الأولية، تحتوي الحمولة على الحد الأدنى من التشابه مع حمولات Miasma وShai-Hulud السابقة. بدلاً من الفيروس المتنقل، يبدو أنه يحتوي على إطار أوامر كامل مع إمكانيات حصان طروادة الكلاسيكية (Dirlist, GetFile, PutFileوما إلى ذلك) مع اتصال مباشر بالبنية التحتية للقيادة والسيطرة.

في هذا الوقت، نحن لا نقوم بأي إسناد نهائي.

الحمولة

تتبع الحمولة سلسلة عدوى مرحلية:

1. يتم تنفيذ المرحلة الأولى عند استيراد الحزمة. إنه يولد عملية فرعية منفصلة تقوم بتنزيل المرحلة التالية من IPFS، وحفظها في دليل خاص بالنظام الأساسي:

   1. لينكس: ~/.local/share/NodeJS/sync.js

   2. ماك: ~/Library/Application Support/NodeJS/sync.js

   3. ويندوز: %LOCALAPPDATA%\NodeJS\sync.js

2. المرحلة الثانية عبارة عن حزمة مشفرة بحجم 8.25 ميجابايت تم استردادها من IPFS. أنه يحتوي على بيانات التكوين ووقت التشغيل الرئيسي.

3. المرحلة الثالثة عبارة عن إطار عمل ضار مكون من 92000 سطر مع بنية معيارية. إنه يؤسس للاستمرارية عبر خدمات مستخدم systemd على Linux ويتواصل مع البنية التحتية للقيادة والتحكم عبر قنوات متعددة بما في ذلك HTTP، ومرحلات Nostr، وعقود Ethereum الذكية، وشبكة libp2p الشبكية.

تتضمن الحمولة إمكانات سرقة بيانات الاعتماد التي تستهدف كلمات المرور وملفات تعريف الارتباط المحفوظة في المتصفح (Chrome وBrave وFirefox وEdge) ومفاتيح SSH ورموز npm وGitHub وبيانات اعتماد AWS وmacOS Keychain ومحافظ العملات المشفرة. بمجرد التثبيت، يبدو أن البرنامج الضار يقبل الأوامر عن بعد لعمليات الملفات، وقائمة الدليل، واستخلاص البيانات.

ما هي الخطوات التي يجب على فرق الأمن اتخاذها؟

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

• يجب على المؤسسات التحقيق على الفور في محطات عمل المطورين وبيئات CI/CD والمستودعات بحثًا عن علامات التسوية. يجب على الفرق مراجعة الأنظمة للحزم المتأثرة.

• نظرًا لأن البرامج الضارة تستهدف بيانات اعتماد المطورين وأسرارهم، يجب على المؤسسات افتراض التعرض المحتمل لرموز GitHub المميزة ومفاتيح SSH وبيانات الاعتماد السحابية وأسرار CI/CD وتدويرها وفقًا لذلك.

• أخيرًا، يجب على المؤسسات تعزيز دفاعات سلسلة توريد البرامج من خلال تنفيذ قائمة التبعية المسموح بها، وإنشاء SBOM، والتحقق من الحزمة، وتحسين مراقبة بيئات التطوير والبناء.

كيف يمكن أن يساعد الحذق؟

يجب على عملاء Wiz الرجوع إلى النصائح المعدة مسبقًا في Wiz Threat Intel Center للحصول على خطوات قابلة للتنفيذ للتحقيق في بيئاتهم ومعالجتها وتقويتها. ستواصل Wiz Research تحديث هذه النصائح مع تطور الوضع.

مؤشرات التسوية