برای انتشار نسخه‌ای آلوده از یک بسته نرم‌افزاری، همیشه لازم نیست رمز عبور یا توکن توسعه‌دهنده به سرقت برود. گاهی کافی است سیستم امنیتی یا حتی خود برنامه‌نویس، «نام» یک مخزن را با «هویت دائمی» آن اشتباه بگیرد.
پژوهشگران امنیتی طی چند وقت اخیر چنین نقصی را در قابلیت «انتشار قابل‌اعتماد» در سیستم مدیریت بسته npm پیدا کردند. این نقص که SlugFest نام گرفته، به مهاجم اجازه می‌داد با تصاحب نشانی قدیمی یک مخزن گیت‌هاب، نسخه تازه‌ای از بسته‌ای را منتشر کند که متعلق به شخصی متفاوت است. به گفته پژوهشگران، بیش از ۱۵۰۰ بسته با بیش از ۱۰ میلیون بار دانلود در برابر این حمله آسیب‌پذیر بودند.
حالا گیت‌هاب، مالک npm، راه سوءاستفاده را بسته است: تنظیمات تازه‌ی «انتشار قابل‌اعتماد» اگر ظرف ۴۸ ساعت پس از ساخته‌شدن با یک انتشار موفق تأیید نشوند، منقضی می‌شوند.
مهاجم چطور صاحب «اعتماد» یک مخزن دیگر می‌شد؟
هر مخزن در گیت‌هاب نشانی‌ای به شکل owner/repository دارد که به آن اسلاگ (Slug) می‌گویند. این نشانی دائمی نیست. اگر مالک، مخزن را حذف کند یا نامش را تغییر دهد، ممکن است شخص دیگری همان نام آزادشده را برای خودش بردارد.
مشکل SlugFest از همین‌جا شروع می‌شد.
این روش حمله شبیه قفلی بود که فقط نشانی خانه را بررسی می‌کرد، نه هویت صاحب را. وقتی صاحب قبلی از خانه می‌رفت، هر کس آن نشانی را تصاحب می‌کرد، می‌توانست با همان اعتماد قبلی وارد خانه شود.
گیت‌هاب در کنار اسلاگ، برای هر مخزن یک شناسه عددی دائمی هم می‌سازد که با تغییر نام یا انتقال مخزن عوض نمی‌شود. اما npm تا پیش از نخستین انتشار موفق، رابطه اعتماد را فقط با اسلاگ و نام فایل گردش کار (Workflow) می‌سنجید و شناسه دائمی مخزن را ثبت نمی‌کرد.
در نتیجه، اگر مخزنِ متصل به یک بسته پیش از نخستین انتشار تغییر نام می‌داد، منتقل یا حذف می‌شد، مهاجم می‌توانست اسلاگ آزادشده را تصاحب کند، مخزنی تازه با همان نشانی بسازد و از گیت‌هاب یک توکن معتبر OIDC بگیرد.
مشکل اصلی همین‌جا بود: npm نام مخزن و فایل گردش کار را مطابق تنظیمات قبلی می‌دید و ممکن بود مجوز موقت انتشار صادر کند؛ بی‌آنکه حساب گیت‌هاب یا npm مالک اصلی هک شده باشد.
انتشار قابل‌اعتماد npm چیست؟
تا پیش از این، انتشار بسته‌ها معمولاً به یک توکن دائمی نیاز داشت؛ کلیدی که در تنظیمات سیستم توسعه و انتشار ذخیره می‌شد. اگر این توکن از طریق فایل تنظیمات یا گزارش اجرای برنامه لو می‌رفت، مهاجم می‌توانست از آن برای انتشار نسخه آلوده استفاده کند.
قابلیت «انتشار قابل‌اعتماد» (Trusted Publishing) برای کم کردن همین خطر ساخته شد. در این روش، سرویس‌هایی مثل GitHub Actions دیگر کلید دائمی نگه نمی‌دارند و برای هر بار انتشار، یک اعتبارنامه کوتاه‌عمر بر پایه OpenID Connect (یا OIDC) دریافت می‌کنند. این مجوز فقط برای همان فرایند انتشار معتبر است و پس از مدت کوتاهی از کار می‌افتد.
نوشدارو پلاس
انتشار قابل‌اعتماد را می‌توان به مجوزی یک‌بارمصرف تشبیه کرد. به‌جای آنکه یک کلید دائمی در اختیار سیستم انتشار باشد، برای هر اجرای تأییدشده مجوزی موقت صادر می‌شود که پس از انجام همان کار، دیگر به کار نمی‌آید.
چگونه راه سوءاستفاده بسته شد؟
طبق تغییری که از ۱۰ مهر اعمال شده، هر پیکربندی تازه از بسته‌ی منتشر شده، فقط ۴۸ ساعت فرصت دارد تا نخستین انتشار موفق خود را انجام دهد.
با نخستین انتشار، «رابطه اعتماد» به شناسه تغییرناپذیر مخزن گره می‌خورد و دیگر منقضی نمی‌شود. اگر هویت مخزن یا پروژه تغییر کند، باید رابطه اعتماد تازه‌ای ساخته شود و مهلت ۴۸ ساعته از نو آغاز می‌شود.
ان‌پی‌ام همچنین توکن‌هایی را که از رویداد issue_comment در گیت‌هاب اکشن صادر شده باشند، برای انتشار قابل‌اعتماد نمی‌پذیرد. گردش‌های کاری‌ای که از این رویداد استفاده می‌کنند، باید به رویدادهای مجاز مانند push، release یا workflow_dispatch منتقل شوند.
اگر یک پیکربندی بعد از ۴۸ ساعت منقضی شود، از صفحه تنظیمات حذف نمی‌شود؛ اما دیگر اجازه انتشار ندارد و برای فعال‌شدن دوباره باید از نو ساخته شود.
نگهدارندگان بسته‌ها چه چیزهایی را بررسی کنند؟
این تغییر جدید، فرصت سوءاستفاده را برای مهاجمان بسیار کوتاه‌تر می‌کند، اما به‌طور خودکار برای مخزن‌های قدیمی فعال نمی‌شود. به همین دلیل، اگر از نگهدارندگان بسته‌های npm هستید، این موارد را بررسی کنید:
- در تنظیمات بسته، بخش Trusted Publisher را بازبینی کنید.
- مطمئن شوید اسلاگ ثبت‌شده هنوز به مخزنی می‌رسد که تحت کنترل شماست.
- اگر مخزن تغییر نام داده، منتقل یا حذف شده است، اتصال قبلی را پاک کنید.
- پیکربندی جدید را با نشانی فعلی بسازید و ظرف ۴۸ ساعت نخستین انتشار را انجام دهید.
- انتشارهای اخیر بسته را برای یافتن نسخه‌های ناشناس یا غیرمنتظره بررسی کنید.
- اگر گردش کاری از
issue_commentاستفاده می‌کند، آن را به رویدادی مجاز منتقل کنید. - پس از حذف یا انتقال هر مخزن، اتصال Trusted Publishing آن را هم پاک کنید.
در پایان
ریشه نقص SlugFest در خودِ فناوری OIDC نبود؛ مشکل از آنجا شکل گرفت که اعتماد در ابتدا به نامی واگذارشدنی گره خورده بود، نه به شناسه دائمی مخزن.
توکن‌های کوتاه‌عمر خطر سرقت کلیدهای ثابت را کم می‌کنند، اما امنیت تنها به عمر کوتاه توکن وابسته نیست. سیستم باید مطمئن باشد که مجوز را دقیقاً برای همان مخزنی صادر می‌کند که از ابتدا به آن اعتماد شده بود.
مهلت ۴۸ ساعته npm فرصت سوءاستفاده را محدود کرده است؛ اما برای توسعه‌دهندگان یک قاعده ساده باقی می‌ماند: وقتی مخزنی را حذف یا منتقل می‌کنید، یا نامش را تغییر می‌دهید، اتصال‌ها و مجوزهای امنیتی قدیمی آن را هم فراموش نکنید.
آدرس مطلب: https://nooshdaroo.ir/safe-ecommerce-selling/slugfest-npm-trusted-publishing-flaw/
