هشدار امنیتی: تداوم حملات زنجیره تأمین در npm و PyPI | تهدید جدید Mini Shai-Hulud
حملات زنجیره تأمین نرمافزار (Software Supply Chain Attacks) دوباره به یکی از مهمترین تهدیدات امنیت سایبری تبدیل شدهاند. گزارشهای جدید نشان میدهد که کمپین مخرب Mini Shai-Hulud همچنان گسترش پیدا میکند و اینبار مخازن محبوب npm و PyPI را هدف میگیرد.
در این میان، مهاجمان چندین پکیج و کتابخانه پرکاربرد مانند TanStack ،UiPath ،Mistral AI ،OpenSearch و Guardrails AI را آلوده کردند و آنها را وارد زنجیره تأمین نرمافزار کردند.
Mini Shai-Hulud چه نوع حملهای است؟
کمپین Mini Shai-Hulud یک حمله مشخص در حوزه امنیت زنجیره تأمین نرمافزار است. در این کمپین، مهاجمان بهجای حمله مستقیم به سازمانها، در ابتدا دست به آلوده کردن dependencyها و کتابخانهها میزنند.
در واقع، آنها نسخههای مخرب از پکیجها را منتشر میکنند تا این نسخهها وارد فرآیند توسعه، build و CI/CD شوند.
بررسیهای امنیتی نشان میدهد که نسخههای آلوده، payloadهایی را حمل میکنند که چند هدف اصلی دارند:
- جمعآوری توکنها و Secrets مورد استفاده در GitHub ،GitHub Actions و سایر سرویسها
- خواندن متغیرهای محیطی (Environment Variables) در محیطهای CI/CD
- شناسایی و برداشت اطلاعات از زیرساختهای build
- جمعآوری دادههای حساس مرتبط با pipelineها و فرآیندهای استقرار
در نتیجه، مهاجمان از همین مسیر به زیرساخت توسعه و حتی محیط عملیاتی سازمانها نزدیک میشوند.
چرا این حملات زنجیره تأمین تا این حد خطرناک هستند؟
در ابتدا ممکن است این حملات فقط یک آلودگی ساده در یک کتابخانه به نظر برسند؛ اما در عمل، این حملات یک تهدید جدی در مقیاس بزرگ محسوب میشوند.
از یک سو، بسیاری از پکیجهای هدف در مخازن npm و PyPI، میلیونها دانلود هفتگی دارند. همچنین این پکیجها در تعداد زیادی از پروژهها و dependency chainها نقش حیاتی بازی میکنند.
از سوی دیگر، تیمهای توسعه معمولاً:
- بهصورت خودکار dependencyها را بهروزرسانی میکنند
- نسخههای جدید را مستقیماً وارد pipelineهای CI/CD میکنند
- و بدون بررسی امنیتی کافی، build جدید را به محیطهای staging یا production میفرستند
بنابراین حتی یک فاصله زمانی کوتاه بین انتشار نسخه آلوده و شناسایی آن، میتواند باعث آلودگی گسترده در محیطهای توسعه و عملیاتی شود.
در نتیجه، یک پکیج آلوده بهسادگی به هزاران پروژه تزریق میشود و زیرساخت نرمافزاری سازمانها را در معرض نفوذ قرار میدهد.
نقش npm و PyPI در حملات Supply Chain
مخازن npm و PyPI بهعنوان دو ستون اصلی اکوسیستم JavaScript و Python عمل میکنند. این دو مخزن روزانه میلیونها پکیج را به سیستمها و توسعهدهندگان ارائه میدهند.
به همین دلیل، مهاجمان معمولاً چند الگوی تکراری را برای سوءاستفاده از این مخازن دنبال میکنند:
1. انتشار نسخه آلوده از پکیجهای محبوب
در این سناریو، مهاجم یک نسخه جدید از پکیج منتشر میکند و در آن، کد مخرب را بهصورت مخفیانه قرار میدهد. در ظاهر، این نسخه فقط یک بهروزرسانی عادی به نظر میآید؛ اما در باطن، payload مخرب اجرا میشود و اطلاعات حساس را جمعآوری میکند.
2. حملات Dependency Confusion
در این نوع حمله، مهاجم پکیجی با نام مشابه یک پکیج داخلی یا خصوصی سازمان در مخازن عمومی منتشر میکند. سپس سیستمهای build، بهصورت ناخواسته این نسخه عمومی را بهجای نسخه داخلی دریافت میکنند. به این ترتیب، مهاجم خود را در میانه زنجیره dependency قرار میدهد.
3. دسترسی به حساب نگهداریکنندگان (Maintainers)
در برخی موارد، مهاجمان ابتدا حساب توسعهدهندگان اصلی یک پکیج را هدف قرار میدهند. پس از نفوذ، آنها نسخه جدیدی از پکیج را با محتوای آلوده منتشر میکنند. از آنجا که این نسخه از حساب رسمی maintainer منتشر میشود، بسیاری از سیستمها به آن اعتماد میکنند.
در مجموع، همین الگوها باعث میشوند که حملات Supply Chain بهسرعت و بیصدا گسترش پیدا کنند.
رفتارهای مخرب و وابسته به Locale در Mini Shai-Hulud
طبق گزارشها، بخشی از payload این کمپین، رفتار خود را بر اساس locale سیستم تنظیم میکند.
بهعنوان مثال، در برخی تنظیمات منطقهای خاص، کد مخرب رفتار تخریبی شدیدتری نشان میدهد و توسعهدهندگان گزارش دادهاند که:
- حجم زیادی از فایلها حذف شده
- دادههای پروژهها آسیب دیده
- محیط توسعه دچار اختلال شده است
به این ترتیب، حمله فقط به سرقت اطلاعات محدود نمیشود و در برخی سناریوها، ویژگیهای Sabotage نیز مشاهده شده است. بنابراین مدیران امنیت باید این حمله را همزمان یک تهدید اطلاعاتی و یک تهدید تخریبی در نظر بگیرند.
راهکارهای کاهش ریسک حملات Supply Chain در npm و PyPI
در ادامه، مجموعهای از اقدامات عملی را میبینی که سازمانها و تیمهای فنی باید در اولویت قرار بدهند. این اقدامات بهصورت مستقیم به کاهش ریسک حملات زنجیره تأمین کمک میکنند.
1. بازبینی فوری dependencyها و نسخههای نصبشده
در قدم اول، تیمها باید dependencyها را در سطح پروژه و در سطح سازمان بررسی کنند. در این بررسی، موارد زیر اهمیت دارند:
- شناسایی پکیجهای آلوده یا مشکوک
- بررسی نسخههای نصبشده در سرورهای build و محیطهای CI/CD
- حذف و جایگزینی نسخههای ناامن
به این ترتیب، سازمانها مسیر نفوذ از طریق پکیجهای مخرب را محدود میکنند.
2. اعتبارسنجی lockfileها و جلوگیری از بهروزرسانی کنترلنشده
استفاده از lockfileها در مدیریت dependency نقش مهمی دارد. بهعنوان مثال:
- در پروژههای JavaScript:
package-lock.jsonیاyarn.lock - در پروژههای Python:
requirements.txt،poetry.lockو ابزارهای مشابه
وقتی تیمها این فایلها را بهدرستی مدیریت میکنند، نسخههای dependency ثابت میمانند و build، بهطور ناخواسته به آخرین نسخه (که ممکن است آلوده باشد) مهاجرت نمیکند.
بنابراین، کنترل lockfileها بهطور مستقیم احتمال دریافت نسخههای آلوده را کاهش میدهد.
3. محدودسازی دسترسی توکنها و Secrets در محیطهای CI/CD
در گام بعد، سازمانها باید سطح دسترسی Tokenها، API Keyها و Secrets را در pipelineهای CI/CD کاهش دهند. برای این کار، میتوانند:
- اصل Least Privilege را پیاده کنند
- از Secret Rotation استفاده کنند
- دسترسی GitHub Actions، GitLab CI و سایر ابزارها را به حداقل برسانند
به این ترتیب، حتی اگر کد مخرب اجرا شود، مهاجم به تمام زیرساخت دسترسی پیدا نمیکند و فقط دامنه محدودی از اطلاعات را میبیند.
4. پایش رفتارهای غیرعادی در فرآیند Build و Deployment
علاوه بر اقدامات قبلی، سازمانها باید رفتار pipelineهای build و deployment را رصد کنند. برای نمونه، موارد زیر میتوانند نشانه یک حمله باشند:
- اجرای اسکریپتها یا دستوراتی که قبلاً در pipeline وجود نداشتند
- ایجاد ارتباطات شبکهای غیرمنتظره از محیط build
- ارسال دادهها به مقصدهای ناشناخته
- تغییرات غیرعادی در زمان یا حجم build
در نتیجه، مانیتورینگ دقیق میتواند آلودگی را در مراحل اولیه شناسایی کند و از گسترش آن جلوگیری کند.
5. استفاده از ابزارهای تحلیل امنیت زنجیره تأمین نرمافزار
امروزه ابزارهای متعددی برای Software Supply Chain Security و Software Composition Analysis (SCA) ارائه میشوند. این ابزارها:
- dependencyها را تحلیل میکنند
- نسخههای آسیبپذیر یا آلوده را شناسایی میکنند
- وابستگیهای پنهان را آشکار میکنند
سازمانها میتوانند این ابزارها را در کنار راهکارهای امنیتی خود مانند EDR، NGFW و راهکارهای امنیت شبکه استفاده کنند تا یک لایه دفاعی قدرتمند در برابر حملات Supply Chain ایجاد کنند.
6. استفاده از Mirror و Registry داخلی برای پکیجهای حیاتی
در نهایت، یکی از راهکارهای بسیار مؤثر، راهاندازی registry داخلی برای پکیجهای حیاتی است. سازمانها میتوانند:
- نسخههای مورد تأیید را در یک mirror داخلی نگهداری کنند
- دانلود پکیجها را از طریق این mirror انجام دهند
- دسترسی مستقیم به مخازن عمومی را محدود کنند
به این روش، تیمها منابع dependency را کنترل میکنند و هر نسخه جدید را قبل از ورود به محیطهای حساس، بررسی امنیتی میکنند.
چرا امنیت زنجیره تأمین نرمافزار حیاتی است؟
بهطور کلی، تقریباً تمام نرمافزارهای مدرن به کتابخانهها و پکیجهای شخص ثالث وابستهاند. همین وابستگی، زنجیره تأمین نرمافزار را به یک نقطه حساس تبدیل میکند.
هر حمله موفق در این زنجیره میتواند:
- هزاران پروژه را آلوده کند
- دسترسی مهاجمان به محیطهای production را فراهم کند
- دادههای حساس را افشا کند
- در مقیاس سازمانی، نفوذ گسترده ایجاد کند
به همین دلیل، امنیت زنجیره تأمین نرمافزار، یکی از ارکان اصلی تابآوری سایبری در سازمانها محسوب میشود. در واقع، سازمانی که dependencyهای خود را مدیریت نمیکند، بخشی از کنترل امنیت را به مهاجمان میسپارد.
جمعبندی
ادامه کمپین مخرب Mini Shai-Hulud علیه مخازن npm و PyPI نشان میدهد که مهاجمان تمرکز ویژهای بر زنجیره تأمین نرمافزار دارند. آنها نسخههای آلوده پکیجها را وارد اکوسیستم توسعه میکنند و از همین مسیر به زیرساختهای CI/CD و محیطهای عملیاتی نزدیک میشوند.
در نتیجه، سازمانها باید با ترکیبی از اقدامات فنی و فرآیندی، از جمله:
- بازبینی dependencyها
- کنترل lockfileها
- محدودسازی دسترسی Secrets
- مانیتورینگ pipelineها
- استفاده از ابزارهای SCA
- و استفاده از registryهای داخلی
ریسک این حملات را کاهش دهند.
در نهایت، امنیت نرمافزار فقط به کد اصلی محدود نمیشود؛ بلکه امنیت تمام زنجیره تأمین نرمافزار، بخش جداییناپذیر استراتژی امنیت سایبری مدرن است.
