تحلیل فنی دفاعی و منبع‌محور: ChainDrop supply chain compromise: Anatomy of a self-propagating worm

مقدمه و مرور کلی حمله ChainDrop

حمله زنجیره تامین ChainDrop که توسط تیم تهدیدات مایکروسافت شناسایی شده، نمونه ای بارز از پیچیدگی روزافزون حملات به اکوسیستم نرم افزارهای متن باز است. این کمپین با انتشار نسخه های مخرب در بیش از 400 بسته npm که توسط ناشران مستقل و نامرتبط مدیریت می شوند، اجرا شده است. نکته قابل توجه اینکه بسیاری از این نسخه های مخرب فاقد هرگونه commit، pull request یا تگ مرتبط در مخازن منبع بودند که نشان می دهد مهاجمان به جای نفوذ به مخازن، مستقیماً فایل های tarball بسته ها را دستکاری و منتشر کرده اند.

بار مخرب این حمله، نوعی کرم خود-تکثیرشونده به نام Mini Shai-Hulud است که از طریق یک payload جاوااسکریپتی مبتنی بر Bun و به شدت مبهم سازی شده توزیع می شود. اجرای بدافزار معمولاً از طریق هوک پیش از نصب (preinstall) در npm صورت می گیرد که پیش از تکمیل فرآیند نصب، فعال می شود. این ویژگی به مهاجم اجازه می دهد تا پیش از هرگونه بررسی امنیتی یا اجرای تست های برنامه، به سیستم توسعه دهنده یا محیط CI/CD دسترسی یابد.

هدف اصلی این بدافزار، سرقت اعتبارنامه های متنوع از جمله npm، GitHub، سرویس های ابری (مانند AWS) و زیرساخت هایی مانند Kubernetes و HashiCorp Vault است. داده های جمع آوری شده رمزنگاری شده و از طریق یک نقطه پایانی HTTPS تحت کنترل مهاجم ارسال می شوند. قابلیت خود-انتشاری این کرم، آن را به تهدیدی جدی تبدیل کرده است؛ به طوری که با استفاده از توکن های انتشار npm، بسته های در دسترس را شناسایی کرده، نسخه جدیدی با کد مخرب منتشر می کند و بدین ترتیب زنجیره آلودگی را گسترش می دهد.

بر اساس تحلیل مایکروسافت، سازمان هایی که بسته های آسیب دیده را با اسکریپت های چرخه حیات فعال نصب کرده اند، باید ایستگاه کاری توسعه دهنده یا سیستم بیلد را به عنوان محیط بالقوه آلوده در نظر بگیرند. اولویت بررسی باید بر روی اعتبارنامه های قابل دسترس برای هویت آلوده، انتشارات غیرمجاز npm، تغییرات غیرمنتظره در مخازن یا workflowها و دسترسی های مشکوک به سرویس های ابری متمرکز باشد. توصیه می شود تمام اعتبارنامه های در معرض خطر از یک محیط پاک، بازنشانی و چرخش شوند و سیستم های آسیب دیده از منابع معتبر بازسازی گردند.

• مقیاس حمله: بیش از 400 بسته npm از ناشران مختلف
• نوع بدافزار: کرم خود-تکثیرشونده Mini Shai-Hulud
• بردار اصلی نفوذ: هوک preinstall در npm
• اهداف سرقت: اعتبارنامه های npm، GitHub، AWS، Kubernetes و Vault
• کانال های خروج داده: HTTPS و مخازن GitHub به عنوان کانال جایگزین

بردارهای حمله و روش اجرا

بر اساس تحلیل‌های منتشرشده از سوی تیم تهدیدات مایکروسافت، زنجیره تأمین نرم‌افزار ChainDrop از طریق انتشار نسخه‌های مخرب در بیش از ۴۰۰ بسته npm آغاز شده است. نکته حائز اهمیت آن است که این نسخه‌ها فاقد هرگونه commit، pull request یا برچسب مرتبط در مخازن عمومی بوده و مهاجمان به‌طور مستقیم فایل‌های tarball بسته‌ها را تغییر داده و منتشر کرده‌اند. این روش، نیاز به نفوذ به مخازن کد را از بین برده و امکان آلوده‌سازی گسترده را با استفاده از اعتبارنامه‌های npm به‌دست‌آمده فراهم می‌کند.

مکانیزم اجرای اولیه بدافزار بر پایه هوک lifecycle نصب npm با نام preinstall طراحی شده است. این هوک پیش از تکمیل فرآیند نصب اجرا می‌شود و به‌طور خودکار فایل setup.mjs را که در بسته جاسازی شده، بارگذاری می‌کند. این فایل سپس باندل جاوااسکریپت مبتنی بر Bun را که به‌شدت مبهم‌سازی شده، اجرا می‌نماید. از آنجا که اسکریپت‌های preinstall در npm به‌صورت پیش‌فرض اجرا می‌شوند، بدافزار می‌تواند پیش از هرگونه بررسی امنیتی یا اجرای تست‌های برنامه، در محیط‌های توسعه و سیستم‌های CI/CD فعال شود.

بدافزار پس از اجرا، ابتدا نوع محیط را تشخیص می‌دهد: در ایستگاه‌های کاری توسعه‌دهندگان، فرآیند خود را از فرآیند نصب جدا کرده و به‌صورت مستقل ادامه می‌دهد؛ در حالی که در محیط‌های CI/CD، در همان job فعال باقی می‌ماند تا به اسرار گردش کار (workflow secrets)، اعتبارنامه‌های runner و مجوزهای انتشار مبتنی بر OIDC دسترسی یابد. این تفاوت رفتاری نشان‌دهنده طراحی هدفمند بدافزار برای بهره‌برداری حداکثری از هر دو محیط است.

• اجرای خودکار از طریق هوک preinstall پیش از تکمیل نصب بسته
• بارگذاری فایل setup.mjs و اجرای باندل مبهم‌سازی‌شده جاوااسکریپت مبتنی بر Bun
• تشخیص محیط اجرا (workstation یا CI/CD) و اتخاذ رفتار متفاوت در هر یک
• جمع‌آوری اعتبارنامه‌ها از فایل‌های محلی، متغیرهای محیطی، ابزارهای خط فرمان و حافظه runner گیت‌هاب

1. مهاجمان نسخه‌های مخرب بسته‌های npm را با افزودن هوک preinstall و فایل setup.mjs منتشر می‌کنند.
2. پس از نصب بسته توسط توسعه‌دهنده یا در خط لوله CI/CD، هوک preinstall به‌طور خودکار اجرا می‌شود.
3. فایل setup.mjs باندل Bun را اجرا کرده و بدافزار کنترل را به‌دست می‌گیرد.
4. بدافزار محیط را شناسایی کرده و بسته به نوع آن، فرآیند خود را جدا می‌کند یا در job فعال باقی می‌ماند.
5. اعتبارنامه‌های محلی و محیطی جمع‌آوری شده و برای احراز هویت در سرویس‌های ابری و مخازن استفاده می‌شوند.

تله‌متری و شواهد فنی (Indicators of Compromise)

بر اساس گزارش منتشرشده توسط تیم اطلاعات تهدید مایکروسافت، در جریان حمله زنجیره تأمین موسوم به ChainDrop، بیش از ۴۰۰ بسته npm از ناشران نامرتبط به‌صورت هم‌زمان و بدون وجود commit یا pull request متناظر در مخازن عمومی، با نسخه‌های مخرب جایگزین شدند. این الگوی انتشار غیرعادی، نشانه بارز دستکاری مستقیم بسته‌های tarball و انتشار آن‌ها از طریق اعتبارنامه‌های npm به‌سرقت‌رفته است. در نسخه‌های آلوده، یک فایل اجرایی با نام setup.mjs و یک hook از نوع preinstall به بسته اضافه شده است که پیش از تکمیل فرایند نصب، بار مخرب را اجرا می‌کند.

بار مخرب که یک نمونه از کرم خودانتشاردهنده Mini Shai-Hulud است، به‌صورت یک باندل جاوااسکریپت مبتنی بر Bun و با ابهام‌سازی سنگین ارائه شده است. این کرم پس از اجرا، ابتدا محیط اجرا را تشخیص می‌دهد: در ایستگاه‌کاری توسعه‌دهنده، فرایند خود را از فرایند نصب جدا می‌کند تا پس از اتمام نصب به فعالیت ادامه دهد؛ در محیط‌های CI/CD نیز در همان job فعال باقی می‌ماند تا به اسرار workflow و اعتبارنامه‌های runner دسترسی یابد. سپس کرم به جمع‌آوری اعتبارنامه‌های محلی، متغیرهای محیطی، ابزارهای خط فرمان و حافظه runner گیت‌هاب اکشنز می‌پردازد.

داده‌های جمع‌آوری‌شده پس از رمزنگاری، از طریق یک endpoint HTTPS تحت کنترل مهاجم ارسال می‌شوند. در صورت عدم دسترسی به این endpoint، مخازن گیت‌هاب به‌عنوان کانال جایگزین (fallback) برای انتقال داده استفاده می‌شوند. همچنین کرم با استفاده از اعتبارنامه‌های گیت‌هاب سرقت‌شده، فایل‌های پیکربندی Claude و Visual Studio Code را به مخازن تزریق می‌کند تا ماندگاری و مسیر آلودگی توسعه‌دهنده‌به‌توسعه‌دهنده ایجاد کند. این رفتارها، شاخص‌های کلیدی برای شناسایی و مسدودسازی این تهدید هستند.

• انتشار نسخه‌های جدید بسته‌های npm بدون وجود commit یا pull request متناظر در مخازن عمومی
• افزودن فایل setup.mjs و hook از نوع preinstall به بسته‌های آلوده
• ارتباط شبکه‌ای با endpoint های HTTPS تحت کنترل مهاجم برای انتقال داده‌های رمزنگاری‌شده
• استفاده از مخازن گیت‌هاب به‌عنوان کانال fallback برای انتقال داده در صورت عدم دسترسی به endpoint اصلی
• تزریق فایل‌های پیکربندی Claude و Visual Studio Code به مخازن گیت‌هاب برای ایجاد ماندگاری

1. برای شناسایی بسته‌های آلوده، فایل package.json و اسکریپت‌های lifecycle (به‌ویژه preinstall) را در بسته‌های نصب‌شده بررسی کنید.
2. در لاگ‌های نصب npm، به دنبال اجرای غیرمنتظره فایل‌های setup.mjs یا اسکریپت‌های مشابه بگردید.
3. ترافیک خروجی به endpoint های HTTPS ناشناس و همچنین ارتباط با مخازن گیت‌هاب غیرمعمول را در محیط‌های توسعه و CI/CD پایش کنید.
4. در صورت مشاهده هر یک از شاخص‌های فوق، اعتبارنامه‌های در دسترس آن محیط را از یک سیستم پاک (clean) بازنشانی و بچرخانید.

گردش کار شناسایی و پاسخ (Detection & Response Workflow)

هنگامی که نشانه‌هایی از آلودگی به کرم ChainDrop در محیط مشاهده می‌شود، نخستین گام، تثبیت وضعیت و جلوگیری از گسترش بیشتر است. بر اساس توصیه‌های منبع معتبر، هر سیستم یا ایستگاه کاری که بسته‌های آسیب‌دیده را با اسکریپت‌های چرخه حیات فعال نصب کرده باشد، باید به‌عنوان محیطی بالقوه در معرض خطر تلقی شود. در این مرحله، جداسازی شبکه‌ای سیستم‌های آلوده و قطع دسترسی آن‌ها به مخازن کد، سرویس‌های ابری و سیستم‌های مدیریت اعتبارنامه، اولویت نخست است. این اقدام از بهره‌برداری بیشتر مهاجم از هویت‌های در دسترس جلوگیری می‌کند.

پس از جداسازی، فرآیند شناسایی باید با تمرکز بر دارایی‌های اطلاعاتی که هویت آلوده به آن‌ها دسترسی داشته، آغاز شود. این بررسی شامل ممیزی کامل دسترسی‌های غیرمجاز به مخازن npm و GitHub، بازبینی تغییرات غیرمنتظره در گردش کارهای CI/CD، و پایش هرگونه فعالیت مشکوک در سرویس‌های ابری و فروشگاه‌های اسرار مانند HashiCorp Vault است. همچنین باید به مصنوعات تولیدشده توسط سیستم‌های ساخت آسیب‌دیده توجه ویژه‌ای شود، زیرا ممکن است این مصنوعات به‌عنوان بردار آلودگی ثانویه عمل کنند. توصیه می‌شود که تمام این بررسی‌ها از یک محیط تمیز و ایزوله انجام شود تا از آلودگی متقابل داده‌های جمع‌آوری‌شده جلوگیری شود.

پس از تکمیل شناسایی، مرحله پاسخ و پاکسازی آغاز می‌شود. کلیه اعتبارنامه‌هایی که در معرض خطر قرار گرفته‌اند، اعم از توکن‌های npm، کلیدهای SSH، رمزهای عبور سرویس‌های ابری و هرگونه اسرار گردش کار، باید از یک محیط شناخته‌شده و تمیز بازنشانی یا چرخش داده شوند. این اقدام باید پیش از هرگونه تلاش برای بازسازی سیستم‌ها انجام گیرد. در ادامه، سیستم‌های آسیب‌دیده باید به‌طور کامل بازسازی شوند و از منابع معتبر و تأییدشده، نه از نسخه‌های پشتیبان بالقوه آلوده، بازنصب گردند. همچنین توصیه می‌شود که تمام مصنوعات نرم‌افزاری تولیدشده توسط سیستم‌های آلوده، از نو ساخته شوند تا از نفوذ کد مخرب به زنجیره تأمین نهایی جلوگیری شود.

• اولویت‌بندی پاسخ بر اساس میزان دسترسی هویت آلوده به سیستم‌های حیاتی
• ممیزی کامل لاگ‌های دسترسی به مخازن کد و سرویس‌های ابری برای یافتن ردپای مهاجم
• بازبینی تمام تغییرات اخیر در فایل‌های پیکربندی مانند Claude و Visual Studio Code که می‌توانند نشانه‌ای از تداوم دسترسی باشند
• مستندسازی کامل تمام اقدامات انجام‌شده برای تحلیل پس از حادثه و بهبود فرآیندهای آتی

1. جداسازی شبکه‌ای سیستم‌های آلوده و قطع دسترسی آن‌ها به سرویس‌های خارجی
2. جمع‌آوری و نگهداری امن لاگ‌ها و مصنوعات دیجیتال برای تحلیل پزشکی قانونی
3. بازنشانی تمام اعتبارنامه‌های در معرض خطر از یک محیط تمیز و ایزوله
4. بازسازی کامل سیستم‌ها از منابع معتبر و نصب مجدد بسته‌های نرم‌افزاری از مخازن تأییدشده
5. پایش مستمر شبکه و سیستم‌ها برای حداقل ۳۰ روز پس از پاکسازی جهت اطمینان از عدم بازگشت آلودگی

// نمونه دستور برای بازبینی بسته‌های npm نصب‌شده از نظر وجود اسکریپت‌های preinstall غیرمنتظره
npm audit --json | jq '.metadata.vulnerabilities'

مثبت‌های کاذب و چالش‌های تشخیص

در تحلیل حملات زنجیره تأمین مانند ChainDrop، یکی از چالش‌های اصلی برای تیم‌های دفاعی، تمایز بین ترافیک یا رفتار مخرب و فعالیت‌های به‌ظاهر مشروع است. از آنجا که داده‌های مستقیم از منبع رسمی درباره موارد مثبت کاذب موجود نیست، این بخش بر اساس تحلیل منطقی از اطلاعات منتشرشده (مانند وجود هوک‌های preinstall در بسته‌های قانونی) تنظیم شده است. توصیه می‌شود تیم‌های امنیتی این سناریوها را به‌عنوان فرضیه‌های احتمالی در نظر بگیرند و پیش از اقدام، اعتبارسنجی لازم را انجام دهند.

یکی از سناریوهای محتمل برای مثبت کاذب، هشدار در مورد بسته‌هایی است که به‌صورت قانونی از هوک‌های preinstall استفاده می‌کنند. بسیاری از بسته‌های npm معتبر، برای تنظیم محیط نصب یا کامپایل کد، اسکریپت‌های preinstall دارند. اگر سیستم تشخیص بر اساس وجود چنین هوکی به‌تنهایی هشدار دهد، ممکن است تعداد زیادی بسته امنیتی بی‌نقص به اشتباه پرچم‌گذاری شوند. بنابراین، معیارهای تشخیص باید شامل بررسی محتوای اسکریپت، عدم تطابق نسخه با مخزن منبع، و نبود commit مرتبط باشد.

سناریوی دیگر، فعالیت‌های عادی در خطوط CI/CD است. در محیط‌های توسعه، اجرای خودکار اسکریپت‌ها هنگام ساخت یا استقرار امری رایج است. اگر ابزارهای تشخیصی به‌درستی پیکربندی نشده باشند، ممکن است فراخوانی‌های شبکه به سرویس‌های ابری یا مخازن خصوصی را به‌عنوان تلاش برای استخراج اطلاعات تلقی کنند. به‌ویژه وقتی از سرویس‌هایی مانند GitHub Actions یا ابزارهای مشابه استفاده می‌شود، ترافیک خروجی به مقصدهای شناخته‌شده می‌تواند باعث ایجاد هشدارهای بی‌مورد شود. برای کاهش این مشکل، باید فهرست سفید از مقصدهای مجاز و امضاهای دیجیتال بسته‌های معتبر ایجاد شود.

در نهایت، توصیه می‌شود که تیم‌های دفاعی به‌جای تکیه بر یک شاخص واحد، از ترکیب چندین سیگنال استفاده کنند. به‌عنوان مثال، تغییر ناگهانی نسخه یک بسته بدون تغییر در کد منبع، همراه با افزوده شدن هوک preinstall و ارتباط به یک دامنه ناشناخته، می‌تواند نشانه قوی‌تری از حمله باشد. همچنین، ارزیابی رفتار پس از نصب (مانند جستجوی غیرعادی برای اعتبارنامه‌ها) می‌تواند دقت تشخیص را افزایش دهد. لازم به ذکر است که این موارد صرفاً به‌عنوان راهنمایی کلی ارائه شده‌اند و سازمان‌ها باید متناسب با زیرساخت خود آن را تنظیم کنند.

• هشدارهای اشتباه در مورد بسته‌های قانونی با هوک‌های preinstall
• تشخیص نادرست فعالیت‌های عادی CI/CD به‌عنوان رفتار مخرب
• اتکا به یک شاخص واحد به‌جای تحلیل چندلایه

1. بررسی محتوای اسکریپت‌های preinstall و مقایسه با نسخه‌های قبلی بسته
2. تطبیق تغییرات بسته با مخزن منبع و تأیید وجود commit مرتبط
3. استفاده از فهرست سفید برای مقصدهای شبکه‌ای مجاز در محیط‌های CI/CD
4. پیکربندی ابزارهای تشخیصی برای ترکیب چند سیگنال (نه یک شاخص تنها)

محدودیت‌های تحلیل و شکاف‌های اطلاعاتی

تحلیل حاضر بر اساس گزارش عمومی منتشرشده توسط Microsoft Threat Intelligence در مورد حمله زنجیره تأمین ChainDrop انجام شده است. با وجود جامعیت نسبی گزارش، برخی ابعاد فنی این حمله به‌طور کامل در منابع عمومی افشا نشده است. از جمله این موارد می‌توان به جزئیات دقیق الگوریتم‌های مبهم‌سازی به‌کاررفته در بارگذاری جاوااسکریپت مبتنی بر Bun اشاره کرد. همچنین روش‌های رمزنگاری داده‌های جمع‌آوری‌شده و ساختار دقیق کلیدهای رمزنگاری در منابع ذکر نشده است.

علاوه بر این، زیرساخت دقیق فرماندهی و کنترل (C2) شامل آدرس‌های IP خاص، دامنه‌های مورد استفاده و مکانیزم‌های تغییر مسیر ترافیک به‌طور شفاف در گزارش ارائه نشده است. این محدودیت‌ها ناشی از سیاست‌های افشای اطلاعات توسط مایکروسافت و نیز ماهیت فنی پیچیده بدافزار است. بنابراین، تحلیل حاضر صرفاً بر اساس اطلاعات موجود در گزارش عمومی انجام شده و هرگونه استنتاج در مورد جزئیات فنی رمزنگاری یا زیرساخت C2 باید به‌عنوان حدس و گمان تلقی شود، نه واقعیت قطعی.

همچنین، گزارش مذکور به‌طور کامل مشخص نکرده است که آیا این حمله توسط یک گروه تهدید شناخته‌شده انجام شده یا یک بازیگر تازه‌کار. اطلاعات مربوط به انگیزه‌های مالی یا جاسوسی نیز در منابع عمومی ذکر نشده است. بنابراین، تحلیل حاضر نمی‌تواند به‌طور قطعی انگیزه یا هویت عامل تهدید را تعیین کند. این شکاف‌های اطلاعاتی باید در ارزیابی‌های ریسک و اقدامات دفاعی مدنظر قرار گیرند.

• جزئیات فنی الگوریتم‌های مبهم‌سازی در بارگذاری جاوااسکریپت به‌طور کامل در منابع ذکر نشده است.
• روش‌های رمزنگاری داده‌های جمع‌آوری‌شده و مدیریت کلیدها در گزارش عمومی افشا نشده است.
• آدرس‌های IP و دامنه‌های مرتبط با زیرساخت فرماندهی و کنترل در منابع موجود نیست.
• هویت یا انگیزه عامل تهدید در گزارش مشخص نشده است.

شاخص‌های کلیدی عملکرد (KPIs) برای اندازه‌گیری اثربخشی

ارزیابی موفقیت اقدامات شناسایی و پاسخ در برابر زنجیره تأمین مانند ChainDrop نیازمند شاخص‌های عملکردی عینی است که بدون اتکا به داده‌های تجربی خاص، بر اساس اصول پذیرفته‌شده دفاع سایبری تعریف شوند. از آنجا که در منابع موجود معیارهای کمّی مشخصی ارائه نشده، این بخش بر پایه چارچوب‌های عمومی سنجش آمادگی و واکنش طراحی شده است.

شاخص زمان شناسایی (Time-to-Detect) به عنوان معیار اصلی، فاصله زمانی بین اولین اجرای بارِ مخرب در محیط و لحظه آگاهی تیم امنیتی را اندازه‌گیری می‌کند. در حمله‌ای که بارِ مخرب از طریق هوکِ پیش‌نصب npm اجرا می‌شود، کاهش این زمان به کمتر از چند ساعت می‌تواند از گسترش افقی جلوگیری کند. سازمان‌ها باید هدف خود را شناسایی در همان روز اول آلودگی تعیین کنند و به‌طور مستمر این شاخص را با رویدادهای شبیه‌سازی‌شده آزمایش کنند.

شاخص تعداد بسته‌های آلوده شناسایی‌شده، به‌ویژه در مقیاس کلان (بیش از ۴۰۰ بسته)، برای ارزیابی دامنه پویش ضروری است. این معیار باید همراه با درصد بسته‌هایی که پیش از انتشار مجدد متوقف شده‌اند گزارش شود. به همین ترتیب، شاخص درصد اعتبارنامه‌های چرخش‌شده (credential rotation) در بازه زمانی مشخص (مثلاً ۲۴ یا ۴۸ ساعت) میزان موفقیت در قطع دسترسی مهاجم را نشان می‌دهد.

شاخص‌های ثانویه شامل فراوانی تماس‌های خروجی به سرورهای فرماندهی و کنترل (C2) شناسایی‌شده، تعداد مخزن‌های گیت‌هاب یا فایل‌های پیکربندی تغییر یافته، و درصد سیستم‌های بازسازی‌شده از منبع مطمئن است. همه این معیارها باید در قالب داشبوردهای بلادرنگ، با تفکیک بین ایستگاه‌های کاری توسعه‌دهندگان و محیط‌های CI/CD ارائه شوند و روند بهبود آنها به‌صورت هفتگی مدیریت شود.

• زمان شناسایی مؤثر (ساعت/روز) از اجرای اولیه بارِ مخرب تا صدور هشدار
• تعداد بسته‌های npm آلوده که در شبکه شناسایی و قرنطینه شده‌اند
• درصد اعتبارنامه‌های در معرض خطر که در پنجره زمانی ۴۸ ساعته چرخش شده‌اند

1. استقرار سنسورهای تشخیص در محیط‌های توسعه و CI/CD برای ثبت خودکار رویدادهای اجرای هوک‌های npm
2. اتصال لاگ‌های اجرای بسته به SIEM و تعریف هشدار برای رفتارهای غیرمعمول
3. شبیه‌سازی منظم حمله (با استفاده از نمونه‌های بی‌خطر) برای پایش میزان انطباق با اهداف KPI

// نمونه تلگراف متریک - صرفاً تصویری
telegraf {
  inputs { exec { commands = ["/usr/local/bin/check_npm_hooks.sh"] } }
  outputs { influxdb { urls = ["http://monitoring:8086"] } }
}

عملیاتی‌سازی و اقدامات پیشگیرانه

بر اساس تحلیل فنی منتشرشده توسط تیم هوش تهدید مایکروسافت، حملات زنجیره تأمین نرم‌افزار مانند ChainDrop می‌توانند از طریق بهره‌برداری از اسکریپت‌های lifecycle در بسته‌های npm، پیش از تکمیل فرآیند نصب، اجرا شوند. این نوع حمله به‌ویژه در محیط‌های توسعه و یکپارچه‌سازی مداوم (CI/CD) خطرناک است، زیرا مهاجم می‌تواند به توکن‌های انتشار، اسرار گردش کار و اعتبارنامه‌های ابری دست یابد. بنابراین، سازمان‌ها باید پیش‌فرض‌های امنیتی خود را در این حوزه بازبینی کنند.

توصیه اصلی مایکروسافت، غیرفعال کردن اسکریپت‌های lifecycle در محیط‌های حساس است. این اقدام ساده می‌تواند از اجرای خودکار کدهای مخرب در هنگام نصب بسته‌ها جلوگیری کند. همچنین، سازمان‌ها باید دسترسی به توکن‌های npm را محدود کرده و از اعطای مجوزهای انتشار گسترده به هویت‌های غیرضروری خودداری کنند. در محیط‌های CI/CD، توصیه می‌شود از هویت‌های موقت و مبتنی بر OpenID Connect استفاده شود تا در صورت نشت اعتبارنامه، دامنه نفوذ محدود بماند.

برای شناسایی و پاسخ به حملات مشابه، استفاده از ابزارهای امنیتی مانند Microsoft Defender XDR و اجرای جستجوهای پیشرفته (hunting queries) ضروری است. این ابزارها می‌توانند رفتارهای غیرعادی مانند انتشار بسته‌های بدون commit متناظر، تغییرات ناگهانی در مخازن، یا دسترسی‌های مشکوک به سرویس‌های ابری را شناسایی کنند. همچنین، سازمان‌ها باید در صورت نصب بسته‌های آلوده، تمام اعتبارنامه‌های در دسترس آن هویت را از یک محیط پاک چرخش داده و سیستم‌های آسیب‌دیده را بازسازی کنند.

• بازبینی خطوط لوله CI/CD و غیرفعال کردن اسکریپت‌های lifecycle در محیط‌های حساس
• محدود کردن دسترسی به توکن‌های npm و استفاده از حداقل امتیازات لازم
• استفاده از Microsoft Defender XDR برای شناسایی و پاسخ به تهدیدات
• اجرای جستجوهای پیشرفته برای یافتن نشانه‌های سازش (IOC)

1. گام اول: ممیزی کامل بسته‌های npm استفاده‌شده در سازمان و شناسایی نسخه‌های آلوده بر اساس فهرست IOC منتشرشده.
2. گام دوم: غیرفعال کردن اسکریپت‌های lifecycle در تنظیمات npm (مانند تنظیم ignore-scripts=true) در محیط‌های توسعه و ساخت.
3. گام سوم: چرخش و بازنشانی تمام توکن‌ها و اعتبارنامه‌هایی که در معرض خطر قرار گرفته‌اند، از یک محیط ایزوله و تمیز.
4. گام چهارم: بازسازی سیستم‌های آسیب‌دیده و مصنوعات پایین‌دستی از منابع معتبر و تأییدشده.

npm config set ignore-scripts true