انتشارهای آلوده OVHcloud CLI در GitHub اسرار توسعه‌دهندگان را هدف گرفت

OVHcloud هشدار داده است که چند انتشار از ابزار خط فرمان متن‌باز این شرکت در GitHub دست‌کاری شده و به بدافزاری برای جمع‌آوری اسرار ذخیره‌شده روی سامانه آلوده بوده است. بر پایه گزارش منتشرشده در ۲۰ اکتبر، مهاجم پس از تصاحب حساب GitHub یکی از توسعه‌دهندگان توانست بسته‌های نسخه‌های ۰.۱۱.۰ تا ۰.۱۵.۰ را تغییر دهد. نسخه ۰.۱۰.۰ و انتشار تازه‌تر ۰.۱۶.۰ پاک اعلام شده‌اند.

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

چه نسخه‌هایی آلوده بودند؟

گزارش BleepingComputer می‌گوید دامنه نسخه‌های آلوده شامل ۰.۱۱.۰، ۰.۱۲.۰، ۰.۱۳.۰، ۰.۱۴.۰ و ۰.۱۵.۰ است. در مقابل، نسخه قدیمی‌تر ۰.۱۰.۰ و نسخه اصلاح‌شده ۰.۱۶.۰ پاک معرفی شده‌اند. این تفکیک مهم است، زیرا وجود نام OVHcloud CLI روی یک دستگاه به‌تنهایی ثابت نمی‌کند آن دستگاه آلوده شده است؛ نسخه نصب‌شده و این‌که بسته باینری از کدام مسیر دریافت و اجرا شده، تعیین‌کننده‌اند.

طبق همان گزارش، بسته آلوده در ۱۹ اکتبر ساعت ۱۴:۴۷ منتشر شد و پس از گزارش یک مشتری در ساعت ۱۶:۲۱ شناسایی و مسدود شد. منطقه زمانی این دو ساعت در صفحه گزارش مشخص نشده است، بنابراین نباید آنها را بدون شاهد به زمان محلی دیگری تبدیل کرد. این بازه کوتاه می‌تواند دامنه توزیع را محدود کرده باشد، اما تعداد دقیق دریافت‌ها یا دستگاه‌های واقعاً آلوده در گزارش اعلام نشده است.

پلتفرم‌های در معرض خطر macOS روی پردازنده‌های Intel و ARM، لینوکس روی x86_64 و ARM64 و ویندوز x86-64 عنوان شده‌اند. در عین حال، ساخت مستقیم از کد منبع و تصاویر Docker تحت تأثیر این رخداد گزارش نشده‌اند. این تمایز نشان می‌دهد نقطه حمله، زنجیره انتشار باینری‌ها بوده است و نه لزوماً کد منبع اصلی یا همه مسیرهای توزیع پروژه.

چطور کنترل‌های CI/CD دور زده شد؟

بر اساس توضیح نقل‌شده از مدیرعامل OVHcloud، مهاجم حساب GitHub یکی از توسعه‌دهندگان را در اختیار گرفت. قابلیت تغییرناپذیری انتشارها یا «release immutability» در مخزن فعال نبود؛ در نتیجه حسابی با سطح دسترسی کافی می‌توانست دارایی‌های یک انتشار موجود را تغییر دهد، بی‌آن‌که بسته جدید از مسیر معمول ساخت و آزمایش عبور کند.

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

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

کاربران آسیب‌دیده چه کنند؟

اولین گام، شناسایی نسخه نصب‌شده و منشأ بسته است. اگر یکی از نسخه‌های ۰.۱۱.۰ تا ۰.۱۵.۰ به‌صورت باینری از انتشارهای GitHub در بازه رخداد دریافت و اجرا شده، باید آن سامانه بالقوه آلوده در نظر گرفته شود. صرف ارتقا به ۰.۱۶.۰ برای پاک‌سازی آثار احتمالی یا بی‌اعتبارکردن اسراری که پیش‌تر خوانده شده‌اند کافی نیست.

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

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

پیوند احتمالی با GlassWorm هنوز قطعی نیست

BleepingComputer به ارزیابی یک مجموعه پژوهشی اشاره کرده که این رخداد را احتمالاً بخشی از عملیات تازه GlassWorm می‌داند؛ کارزاری که پیش‌تر اکوسیستم‌های توسعه نرم‌افزار از جمله VS Code، OpenVSX، GitHub و npm را هدف گرفته است. با این حال، همان گزارش تصریح می‌کند که پژوهشگران محموله بدافزاریِ تحویل‌داده‌شده در نسخه آلوده OVHcloud CLI را به‌طور کامل تحلیل نکرده‌اند.

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

درس بزرگ‌تر برای زنجیره تأمین نرم‌افزار

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

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

رونما پیش‌تر نیز در گزارش آلودگی زنجیره تأمین افزونه Rank Math PRO توضیح داده بود که بسته نرم‌افزاری معتبر می‌تواند بدون وجود آسیب‌پذیری در دستگاه کاربر به مسیر توزیع بدافزار تبدیل شود. تفاوت مهم پرونده OVHcloud این است که شواهد فعلی به دست‌کاری دارایی‌های انتشار GitHub اشاره دارند، در حالی که کد منبع و مسیرهای ساخت اصلی دست‌نخورده گزارش شده‌اند.