حملات زنجیره تأمین، باج‌افزار جدید: چگونه مهاجمان هزاران سازمان را از طریق یک هدف به خطر می‌اندازند

حملات زنجیره تأمین نرم‌افزار جایگزین باج‌افزار به عنوان با اهرم‌ترین تکنیک در سناریوی مهاجمان شده است. یک نگهدارنده بسته به خطر افتاده، یک سیستم ساخت مسموم یا یک پلاگین مخرب CI/CD می‌تواند بدافزار را هم‌زمان به هزاران سازمان پایین‌دستی تزریق کند — بدون نیاز به هدف‌گیری فردی، و با پنجره‌های شناسایی که اغلب به ماه‌ها می‌رسد. نقض SolarWinds حدود ۱۸۰۰۰ سازمان را از طریق یک به‌روزرسانی نرم‌افزاری دست‌کاری‌شده به خطر انداخت. درب پشتی XZ Utils که در مارس ۲۰۲۴ کشف شد، دو سال وقت صرف تزریق به یک کتابخانه فشرده‌سازی حیاتی کرد که تقریباً در هر توزیع لینوکس وجود دارد.

اقتصاد حملات زنجیره تأمین برای مهاجمان جذاب است: یک وابستگی بالادستی را به خطر بیندازید و از تمام مصرف‌کنندگان پایین‌دستی بهره ببرید. درک مکانیک‌های حمله — و دفاع واقع‌گرایانه سازمانی — نیازمند عبور از راهنمایی عمومی «نرم‌افزار خود را وصله کنید» به بردارهای خاصی است که مهاجمان واقعاً از آنها استفاده می‌کنند.

چهار بردار اصلی حمله

سردرگمی وابستگی (Dependency confusion) از منطق حل نام مدیران بسته بهره‌برداری می‌کند. وقتی یک نام بسته داخلی با نام یک مخزن عمومی مطابقت دارد، بسیاری از مدیران بسته (npm، pip، RubyGems) به‌طور ضمنی نسخه عمومی را ترجیح می‌دهند. تحقیق الکس بیرسان در سال ۲۰۲۱ این را با انتشار بسته‌هایی با نام‌های داخلی از اپل، مایکروسافت و تسلا نشان داد — آنها به‌طور خودکار در سیستم‌های ساخت آن شرکت‌ها دانلود و اجرا شدند. بیش از ۳۵ سازمان بزرگ آسیب‌پذیر تأیید شدند. راه حل ساده است (تعیین فضای نام، آینه‌سازی مخزن خصوصی) اما پذیرش آن ناهمگون بوده است.

تصاحب حساب نگهدارنده انسان‌های پشت بسته‌های قانونی را هدف قرار می‌دهد. نگهدارندگان بسته اغلب از رمزهای عبور تکراری استفاده می‌کنند، احراز هویت چندعاملی را نادیده می‌گیرند و منابع محدودی برای سخت‌سازی امنیتی دارند. در سال ۲۰۲۲، حساب نگهدارنده بسته محبوب npm با نام ua-parser-js به خطر افتاد؛ مهاجم یک نسخه مخرب منتشر کرد که بیش از ۸ میلیون بار قبل از شناسایی دانلود شد. بسته میزبانی‌شده در PyPI با نام ctx نیز در سال ۲۰۲۲ از طریق دامنه منقضی‌شده‌ای که برای آدرس ایمیل نگهدارنده استفاده می‌شد به خطر افتاد — بازیابی حساب پس از ثبت دامنه توسط مهاجم بی‌دردسر بود.

به خطر افتادن سیستم ساخت زیرساخت CI/CD را به جای مخازن منبع هدف قرار می‌دهد. حمله زنجیره تأمین ۳CX (۲۰۲۳) به یک نصب‌کننده نرم‌افزار Trading Technologies بازمی‌گردد که کارکنان ۳CX به عنوان بخشی از گردش کار توسعه خود دانلود کرده بودند. نصب‌کننده مخرب محیط ساخت ۳CX را تغییر داد که سپس برنامه‌های ۳CX دارای درب پشتی را امضا و به بیش از ۶۰۰۰۰۰ سازمان توزیع کرد. زنجیره حمله دو شرکت را قبل از رسیدن به قربانیان نهایی پیمود و هر مرحله برای کنترل‌های امنیتی استاندارد قانونی به نظر می‌رسید.

غلط‌نویسی و تصاحب فضای نام بسته‌های مخرب را در مجاورت بسته‌های قانونی محبوب قرار می‌دهد. نام بسته‌هایی مانند lodahs (به جای lodash)، reqests (به جای requests) یا colourama (به جای colorama) همگی در کمپین‌های واقعی استفاده شده‌اند. گزارش تهدید ۲۰۲۴ شرکت Checkmarx بیش از ۱۷۰۰۰۰ بسته مخرب منتشر‌شده در PyPI و npm بین سال‌های ۲۰۲۳ و ۲۰۲۴ را شناسایی کرد که بیشتر آنها از غلط‌نویسی به عنوان مکانیسم تحویل اولیه استفاده می‌کردند.

مطالعه موردی XZ Utils: یک حمله مهندسی اجتماعی طولانی

درب پشتی XZ Utils نیاز به تحلیل گسترده دارد زیرا سطحی از پیچیدگی را نشان می‌دهد که بسیاری از کنترل‌های شناسایی موجود را ناکافی می‌کند. از سال ۲۰۲۱، یک مهاجم با هویت «جیا تان» شروع به مشارکت در پروژه منبع‌باز XZ Utils کرد — یک کتابخانه فشرده‌سازی که در sshd و systemd در توزیع‌های اصلی لینوکس استفاده می‌شود. در حدود دو سال، جیا تان یک سابقه مشارکت معتبر ایجاد کرد، دسترسی commit به دست آورد و به تدریج مسئولیت‌های نگهدارنده را در حالی که نگهدارنده اصلی که نشانه‌های فرسودگی نشان می‌داد عقب‌نشینی کرد، بر عهده گرفت.

در اوایل ۲۰۲۴، جیا تان کدی را commit کرد که یک درب پشتی را به فرآیند ساخت معرفی می‌کرد — به طور خاص، یک نسخه اصلاح‌شده از یک اسکریپت ساخت که کد مخرب را فقط تحت شرایط خاص (سیستم‌های لینوکس مبتنی بر glibc با systemd) به باینری کامپایل‌شده تزریق می‌کرد. درب پشتی احراز هویت SSH را هدف قرار می‌داد و به طور بالقوه امکان اجرای کد از راه دور از طریق کلیدهای عمومی ساخته‌شده ویژه را فراهم می‌کرد. این توسط آندرس فروید، مهندس مایکروسافت، از طریق ترکیبی از ناهنجاری‌های عملکرد مشاهده‌شده (sshd ۵۰۰ میلی‌ثانیه بیشتر از حد انتظار CPU مصرف می‌کرد) و تحقیق سیستماتیک کشف شد.

حمله از کنترل‌های امنیتی استاندارد فرار کرد زیرا: درب پشتی در کد منبع commit‌شده نبود، بلکه در فرآیند ساخت بود؛ مشارکت‌کننده مخرب یک سابقه مشارکت دو ساله قانونی داشت؛ و مکانیسم تزریق عمداً با استفاده از فایل‌های باینری آزمایشی که حاوی تغییرات رمزگذاری‌شده اسکریپت ساخت بودند پنهان شده بود. هیچ ابزار SAST خودکاری آن را نگرفت. هیچ بازبینی کدی آن را نگرفت. یک انسان متوجه یک ناهنجاری عملکرد شد.

شناسایی: چه چیزی واقعاً کار می‌کند

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

• صورت‌حساب مصالح نرم‌افزاری (SBOM): نگهداری یک SBOM کامل و به‌روز امکان شناسایی سریع سیستم‌های تحت تأثیر را هنگام افشای یک نقض فراهم می‌کند. دستور اجرایی ۱۴۰۲۸ ایالات متحده (۲۰۲۱) SBOM را برای تأمین‌کنندگان نرم‌افزار فدرال الزامی کرد و این رویه به الزامات تدارکات سازمانی گسترش یافته است. ابزارهایی مانند Syft و Grype تولید SBOM و اسکن آسیب‌پذیری را خودکار می‌کنند.
• ساخت‌های قابل بازتولید: اگر یک ساخت قابل بازتولید باشد، هر دو ساخت مستقل از منبع یکسان باید خروجی یکسان بیت به بیت تولید کنند. این بدان معناست که یک محیط ساخت به خطر افتاده خروجی متفاوت از یک ساخت مرجع تولید می‌کند که قابل شناسایی است. Debian و NixOS بالغ‌ترین زیرساخت ساخت‌های قابل بازتولید را در اکوسیستم منبع‌باز دارند.
• امضای بسته و منشأ: Sigstore (sigstore.dev) که توسط npm، PyPI و Maven پذیرفته شده است، امضاهای رمزنگاری پیوندخورده به منشأ خط لوله ساخت ارائه می‌دهد — نه فقط ثابت می‌کند که یک بسته امضا شده، بلکه ثابت می‌کند که در یک محیط CI خاص از یک commit git خاص ساخته شده است. این به طور مستقیم به حملات به خطر افتادن سیستم ساخت با قابل تأیید کردن زنجیره منشأ می‌پردازد.
• نظارت رفتاری محیط‌های ساخت: قرار دادن سیستم‌های ساخت در جعبه شنی به طوری که نتوانند اتصالات شبکه غیرمنتظره برقرار کنند، به مسیرهای فایل‌سیستم غیرمنتظره بنویسند یا فرآیندهای غیرمنتظره ایجاد کنند، بسیاری از حملات زنجیره تأمین را در زمان اجرا می‌گیرد. تصاویر کانتینری مبتنی بر wolfi شرکت Chainguard و سیستم ساخت هرمنوتیک Bazel هر دو این ایزوله را به عنوان پیش‌فرض اعمال می‌کنند.

استراتژی‌های دفاع سازمانی

فراتر از شناسایی، سازمان‌ها می‌توانند از طریق کنترل‌های ساختاری به طور معناداری قرار گرفتن در معرض خطر را کاهش دهند:

• آینه‌سازی مخزن خصوصی با لیست سفید: تمام درخواست‌های مدیر بسته را از طریق یک آینه داخلی (Artifactory، Nexus یا AWS CodeArtifact) که فقط بسته‌های تأیید شده را ارائه می‌دهد، هدایت کنید. بسته‌های جدید نیاز به تأیید صریح دارند. این کار سردرگمی وابستگی، غلط‌نویسی و معرفی بسته غیرمجاز را در یک کنترل واحد حذف می‌کند.
• پین کردن وابستگی و فایل‌های قفل: وابستگی‌ها را به نسخه‌های خاص و هش‌های رمزنگاری پین کنید (نه فقط شماره نسخه). package-lock.json در npm، requirements.txt در پایتون با پرچم‌های --hash و Cargo.lock در Cargo همگی از وابستگی‌های پین‌شده با هش پشتیبانی می‌کنند. این بدان معناست که افزایش نسخه بسته به خطر افتاده به طور خودکار به ساخت‌ها جریان نمی‌یابد.
• CI/CD با کمترین دسترسی: سیستم‌های ساخت نباید بیش از حد لازم برای اجرای ساخت دسترسی داشته باشند. جدا کردن کلیدهای امضا، محدودیت‌های دسترسی شبکه و محیط‌های ساخت موقتی که پس از هر اجرا از بین می‌روند، تأثیر یک مرحله ساخت به خطر افتاده را به طور قابل توجهی کاهش می‌دهد.
• امتیازدهی ریسک زنجیره تأمین: ابزارهایی مانند OpenSSF Scorecard بهداشت امنیتی پروژه منبع‌باز را ارزیابی می‌کنند — آیا پروژه از حفاظت شاخه استفاده می‌کند؟ آیا از مشارکت‌کنندگان خواسته شده است که commitها را امضا کنند؟ آیا خط‌مشی امنیتی وجود دارد؟ گنجاندن امتیازات Scorecard در گردش‌های کاری تأیید وابستگی، پروژه‌های پرخطر را قبل از ورود به گراف ساخت آشکار می‌کند.

نکات عملی

• یک آینه مخزن بسته خصوصی با لیست سفید صریح به عنوان با اهرم‌ترین کنترل زنجیره تأمین پیاده‌سازی کنید — این کار سردرگمی وابستگی و غلط‌نویسی را هم‌زمان حذف می‌کند.
• برای تمام نرم‌افزارهای تولیدی SBOM تولید و نگهداری کنید؛ آنها پیش‌نیاز هر پاسخ به حادثه معنادار در هنگام افشای یک نقض زنجیره تأمین هستند.
• در صورت وجود، امضاهای Sigstore را برای تمام بسته‌های موجود در لیست سفید خود الزامی کنید؛ npm و PyPI هر دو اکنون با سربار پیکربندی حداقلی از این پشتیبانی می‌کنند.
• امنیت خط لوله CI/CD را معادل امنیت شبکه تولیدی در نظر بگیرید — سیستم‌های ساخت به خطر افتاده نقطه ورود برای مخرب‌ترین حملات در سال‌های اخیر هستند.
• حمله XZ Utils نشان می‌دهد که حتی شناسایی رفتاری خودکار ممکن است حملات پیچیده طولانی را نگیرد؛ نظارت ناهنجاری (تأخیر غیرمنتظره، مصرف منابع غیرمنتظره) یک لایه شناسایی واقعی است، نه فقط یک نگرانی عملکردی.