کرم «چین‌دراپ» چگونه بسته‌های معتبر npm را برای سرقت اطلاعات توسعه‌دهندگان به سلاح تبدیل کرد

در تاریخ ۴ اوت ۲۰۲۶، یک کرم خودانتشارشونده به نام «چین‌دراپ» (ChainDrop) در مخزن مدیر بسته نود (npm) منتشر شد و ۴۴۴ بسته و ۲,۲۱۲ نسخه را در کمتر از چهار ساعت آلوده کرد. این حمله برخی از پرترددترین زیرساخت‌های اکوسیستم جاوااسکریپت، از جمله کتابخانه ذخیره‌سازی keyv و flat-cache را که مجموعاً صدها میلیون بار در هفته دانلود می‌شوند، هدف قرار داد.[1][2]

برخلاف بدافزارهای معمولی که به جعل نام (typosquatting) یا بسته‌های ناشناخته متکی هستند، چین‌دراپ هویت نگه‌دارنده اصلی keyv را به خطر انداخت. مهاجمان با ارسال مستقیم فایل‌های مخرب به شاخه اصلی مخزن و انتشار فوری نسخه جدید، از گردش کارهای خودکار خود پروژه سوءاستفاده کردند.[5]

این سازوکار یک نقطه کور حیاتی را در بازاریابی امنیت زنجیره تأمین مدرن برجسته می‌کند. نسخه‌های آلوده با گواهی‌های معتبر SLSA Provenance منتشر شدند که توسط GitHub Actions به صورت رمزنگاری امضا شده بودند. در حالی که این گواهی اثبات می‌کند که یک کامیت خاص توسط یک گردش کار مشخص ساخته شده است، نمی‌تواند ثابت کند که خود کامیت مجاز یا بی‌خطر بوده است.[2]

این حمله که به عنوان گونه‌ای از خانواده بدافزار «مینی شای-هولود» (Mini Shai-Hulud) شناسایی شد، بار خود را از طریق یک هوک چرخه حیات پیش‌نصب (preinstall lifecycle hook) اجرا کرد. این کار از یک ویژگی قانونی npm سوءاستفاده می‌کند که دستورات دلخواه را قبل از نصب کامل بسته اجرا می‌کند و نیازی به تعامل توسعه‌دهنده فراتر از اجرای یک دستور استاندارد npm install ندارد.[3][4]

پس از فعال شدن، اسکریپت توزیع‌کننده (که معمولاً setup.mjs نام دارد) یک محیط اجرای قانونی جاوااسکریپت Bun را به همراه ۷۱۰ کیلوبایت کد مرحله دوم به شدت مبهم‌سازی شده دانلود می‌کند. این بار چندسکویی، محیط‌های لینوکس، macOS و ویندوز را هدف قرار می‌دهد و ایستگاه‌های کاری توسعه‌دهندگان و خطوط لوله یکپارچه‌سازی/استقرار مداوم (CI/CD) را برای یافتن اسرار با ارزش بالا اسکن می‌کند.[1][3]

این بدافزار به طور سیستماتیک توکن‌های npm، اعتبارنامه‌های GitHub، کلیدهای خدمات وب آمازون (AWS)، اسرار کوبرنتیس (Kubernetes) و پارامترهای HashiCorp Vault را جمع‌آوری می‌کند. همچنین زیرساخت‌های ارتباطی و پرداخت را هدف قرار می‌دهد و توکن‌های Slack و Stripe را از محیط‌های محلی استخراج می‌کند.[5]

پس از رمزگذاری داده‌های سرقت شده با استفاده از کلیدهای عمومی RSA-۴۰۹۶ جاسازی شده، کرم اسرار را به نقاط پایانی HTTPS پویا یا مخازن عمومی GitHub ارسال می‌کند. مهاجمان با اشاره به کمپین‌های قبلی، این مخازن مرده (dead-drop) را با شرح «Shai-Hulud: Here We Go Again» برچسب‌گذاری کردند.[1][5]

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

سپس فایل‌های فشرده (tarballs) آخرین نسخه‌های آن بسته‌ها را دانلود می‌کند، بدافزار و بارگذار را در آن‌ها قرار می‌دهد، نسخه پچ را افزایش می‌دهد و بسته‌های اصلاح شده را دوباره در مخزن npm منتشر می‌کند. این انتشار مجدد خودکار باعث شد که تعداد کل تکرارهای مخرب در عرض چند ساعت از ۲,۲۰۰ مورد فراتر رود.[1][2]

این کرم همچنین از اعتبارنامه‌های دزدیده شده GitHub برای ایجاد پایداری در مخازن کد منبع استفاده می‌کند. این بدافزار فایل‌های پیکربندی دستیارهای کدنویسی هوش مصنوعی مانند Claude و محیط‌های توسعه یکپارچه (IDE) مانند Visual Studio Code را مستقیماً به پایگاه کد تزریق می‌کند.[1][4]

مهاجمان با کامیت کردن این فایل‌های هوک – که اغلب برای فرار از بررسی‌های سطحی به حساب‌های ربات‌های خودکار نسبت داده می‌شوند – یک مسیر عفونت اضافی توسعه‌دهنده به توسعه‌دهنده ایجاد کردند. باز کردن یک مخزن در یک ویرایشگر پیکربندی شده می‌تواند بار مخرب را حتی بدون اجرای دستور npm install فعال کند.[4]

محققان امنیتی خاطرنشان می‌کنند که اسکنرهای وابستگی اغلب در شناسایی این هوک‌های سطح منبع شکست می‌خورند، زیرا به دنبال بسته‌های مخرب شناخته شده هستند تا فایل‌های پیکربندی محلی آلوده. این تکنیک شبیه حملات قبلی است که عوامل کدنویسی هوش مصنوعی را هدف قرار داده بودند و نشان‌دهنده تغییر به سمت سوءاستفاده از ابزارهای بهره‌وری توسعه‌دهندگان است.[4]

پیامدهای کمپین چین‌دراپ، تلاش گسترده‌ای برای ترمیم محیط‌های نرم‌افزاری سازمانی را ایجاب کرده است. سازمان‌هایی که از بسته‌های آسیب‌دیده استفاده می‌کنند، از جمله پلتفرم‌های بزرگی مانند Deliveroo و Qlik، باید فرض کنند که هر اعتبارنامه‌ای که در دستگاه‌های آلوده وجود داشته، به خطر افتاده است.[5]

تیم‌های واکنش به حادثه به توسعه‌دهندگان توصیه می‌کنند که سیستم‌های آسیب‌دیده را فوراً ایزوله کنند. به جای حذف صرف بدافزار، تیم‌ها باید فایل‌های فشرده بسته (tarballs)، لاگ‌های npm و تصاویر CI runner را حفظ کنند تا دامنه قرار گرفتن در معرض خطر را محدود کرده و دقیقاً متوجه شوند چه چیزی به سرقت رفته است.[1]

بازسازی CI runnerها، چرخاندن تمام اعتبارنامه‌هایی که احتمالاً در معرض خطر قرار گرفته‌اند، و ممیزی مخازن GitHub برای یافتن کامیت‌های غیرعادی، اکنون گام‌های اجباری برای سازمان‌های آسیب‌دیده است. این حادثه یادآوری تلخی است که امضاهای رمزنگاری و بررسی‌های خودکار تنها به اندازه هویت‌های انسانی که آن‌ها را کنترل می‌کنند، قابل اعتماد هستند.[1][6]