کلید اصلی نشت‌یافته LiteLLM به مهاجمان اجازه داد توکن‌های گیت‌هاب را بدزدند و خط انتشار را ربایش کنند
اخبار داغ فناوری اطلاعات و امنیت شبکهیک کلید ابطال‌نشده، پنج ماه بعد، به انتشار نسخه مخرب ۱.۱۰۷.۰ در PyPI منجر شد
تیم LiteLLM — پروژه متن‌باز دروازه مدل‌های زبانی بزرگ (LLM) — اعلام کرده یک کلید اصلی (Master Key) مربوط به Agent Platform که در اواخر ماه می ۲۰۲۶ به‌اشتباه در یک مخزن عمومی گیت‌هاب منتشر شده بود، در نهایت به مهاجم اجازه داده یک نسخه مخرب از این بسته پرطرفدار پایتون را منتشر کند.
ریشه حادثه: یک فایل پیکربندی در مخزن عمومی
بر اساس توضیح الیور جنسن و ماتئو وانگ از تیم LiteLLM، در تاریخ ۲۷ می ۲۰۲۶ یک فایل پیکربندی در مخزن عمومی LiteLLM-Labs/lite-harness ثبت (Commit) شد که ناخواسته حاوی کلید اصلی یک استقرار از Agent Platform بود؛ ابزاری متن‌باز که این تیم برای هماهنگ‌سازی عامل‌ها (Agents) به کار می‌برد.
اشتباه به‌سرعت شناسایی شد، کامیت با Force-push بازنویسی شد و کلیدهای افشاشده به‌عنوان نیازمند ابطال تشخیص داده شدند. اما ابطال کلید اصلی هرگز انجام نشد.
توکن بدون محدودیت؛ دسترسی در سطح مالک سازمان
بر اساس گزارش LiteLLM، مهاجم ناشناس (با آدرس 69.48.229[.]143) در ۱۰ اکتبر ۲۰۲۶ از این کلید ابطال‌نشده استفاده کرد، به Agent Platform دسترسی یافت و یک توکن OAuth ابزار GitHub CLI را که سرویس برای ثبت Pull Request توسط عامل‌های ابری خودمیزبانی‌شده با آن پیکربندی شده بود، استخراج کرد.
این توکن «محدود نشده بود» و به حساب مالک سازمان گیت‌هاب متصل بود. در نتیجه مهاجم به تمام مخازن سازمان دسترسی در سطح مالک پیدا کرد و توانست اعتبارنامه‌های بیشتری را استخراج کند.
جدول زمانی حمله
| زمان (به وقت جهانی) | رویداد |
|---|---|
| ۱۰ اکتبر، ۲۲:۱۱ تا ۲۲:۱۲ | ثبت کامیت در شاخه‌های موقت مخازن داخلی (BerriAI/litellm و BerriAI/litellm-auto) برای اجرای ورک‌فلوهایی که توکن‌های OAuth دو مهندس با دسترسی نگهدارنده را به یک نقطه پایانی webhook.site تحت کنترل مهاجم می‌فرستند؛ هر دو اجرا چند دقیقه بعد حذف شدند |
| ۲۱ اکتبر، ۱۰:۰۸ تا ۱۱:۰۸ | دور زدن حفاظت شاخه و تغییر خط انتشار، با تنظیم منبع روی مخزن شبه‌نام «Berri-AI/litellm» به‌جای «BerriAI/litellm» |
| ۲۱ اکتبر، ۱۱:۳۹ تا ۱۱:۴۰ | انتشار نسخه ۱.۱۰۷.۰ در PyPI |
| ۲۱ اکتبر، ۱۱:۴۶ | انتشار تصاویر Docker Hub و GHCR |
| ۲۱ اکتبر، ۱۱:۵۳ تا ۱۱:۵۴ | حذف سوابق اجرای تولید (Production) و آزمایشی (Staging) |
| ۲۱ اکتبر، ۱۲:۰۶ | گزارش حمله زنجیره تأمین توسط لیدور ماچلوف از شرکت Upwind |
| ۲۱ اکتبر، ۱۳:۲۳ | قرنطینه نسخه ۱.۱۰۷.۰ توسط PyPI |
| ۲۱ اکتبر، ۱۴:۲۰ | حذف یا بازگرداندن تگ‌های Docker Hub (v1.107.0، latest، main-latest و main-stable) به تصاویر سالم |
چگونه کنترل انتشار دور زده شد؟
LiteLLM توضیح داده در حالت عادی، ساخت و انتشار یک نسخه نیازمند آغاز توسط یک مهندس مجاز و تأیید توسط یک حساب ویژه است که به یک دستگاه فیزیکی در دفتر شرکت قفل شده است. این محدودیت در اوایل همان هفته، برای تسهیل انتشارهای مکرر و بک‌پورت رفع باگ، تضعیف شده بود تا هر دو مهندس بتوانند انتشار را آغاز و تأیید کنند.
در نتیجه، مهاجم یکی از توکن‌ها را برای آغاز انتشار (پس از هدایت ابزار استقرار به مخزن مخرب خود) و دیگری را برای تأیید به کار برد. تیم پروژه یادآور شده مهاجم که توکن مالک سازمان را در اختیار داشت، می‌توانست خودش این محدودیت را هم تضعیف یا کامل حذف کند؛ و گمان می‌رود این کار را برای پرهیز از شناسایی انجام نداده است.
ورک‌فلوهای سارق: جزئیات تازه از Socket
شرکت Socket در بررسی مستقل خود دو کامیت مخرب را بازیابی کرده که هرکدام یک ورک‌فلو در مسیر .github/workflows/cache.yml اضافه می‌کنند. کامیت نخست ۱۰ اکتبر ساعت ۲۲:۱۱:۴۵ به وقت جهانی و دومی ۱۲ اکتبر ثبت شده است.
پژوهشگر Socket، کارلو زانکی، می‌گوید هیچ‌کدام در شاخه‌ای که هنوز وجود دارد قرار ندارند؛ هر دو روی شاخه‌های کوتاه‌عمر با الگوی نام ci-tmp-<hex> ثبت شده‌اند که طی چند دقیقه ساخته، استفاده و حذف شده‌اند؛ به همین دلیل، تقریباً هیچ ردی در تاریخچه معمول مخزن باقی نمی‌ماند.
الگوی کار:
۱. ساخت یک شاخه موقت از یک کامیت قانونی اخیر ۲. ثبت کامیتی با عنوان بی‌خطر «ci: bump cache config» که ورک‌فلوی cache.yml را اضافه می‌کند ۳. اجرای خودکار ورک‌فلو با هر Push (رویداد on: [push]) ۴. حذف شاخه
چه چیزی سرقت می‌شد؟
هر دو ورک‌فلو برای برداشت توکن‌های گیت‌هاب، کلیدهای API فضای کاری Linear، استقرار LiteLLM و Together AI، به‌همراه شناسه و کلید امضای یک GitHub App طراحی شده‌اند. اجرای ۱۲ اکتبر دامنه را گسترش داده و شامل موارد زیر نیز بود:
- کلیدهای API سرویس‌های Anthropic، OpenAI، AWS Bedrock، Tavily و مستأجر اسکن اسرار GitGuardian
- حالت ذخیره‌سازی Playwright
- اطلاعات پایگاه داده PostgreSQL (رشته اتصال، نام حساب و رمز عبور)
- نشانی، پورت و رمز احراز هویت Redis
داده‌ها به دو نقطه پایانی webhook.site ارسال می‌شد. زانکی تأکید می‌کند توکن گیت‌هاب و کلید خصوصی GitHub App، اعتبارنامه خود پلتفرم میزبان مخزن‌اند؛ کلید API گیت‌گاردین به مهاجم دید (و بالقوه کنترل) بر هشدارهایی می‌دهد که می‌توانستند این فعالیت را آشکار کنند؛ و حالت ذخیره‌سازی Playwright، دسترسی احراز هویت‌شده به حساب Linear را بدون رمز عبور و بدون عبور از احراز هویت چندعاملی ممکن می‌کند.
LiteLLM در واکنش اعلام کرده در حال ابطال تک‌تک توکن‌های مرتبط با سیستم‌های داخلی و پلتفرم‌های فروشنده است.
نسخه مخرب ۱.۱۰۷.۰ چه می‌کند؟
گزارش‌های متعدد نشان می‌دهد فایل‌های همراه LiteLLM نسخه ۱.۱۰۷.۰ طوری مهندسی شده‌اند که هنگام راه‌اندازی پایتون خودکار اجرا شوند، حتی اگر برنامه‌ای LiteLLM را import نکرده باشد.
این بدافزار دو مسیر اجرا دارد:
- ماژول برداشت اعتبارنامه: مواد احراز هویت را در ابزارهای توسعه، اپلیکیشن‌های هوش مصنوعی، محیط‌های ابری و مرورگرها هدف می‌گیرد.
- بک‌دور مبتنی بر یونیکس: به‌صورت فرایند پس‌زمینه اجرا می‌شود و هر یک ساعت کد دلخواه مهاجم را دریافت و اجرا می‌کند.
سارق همچنین اطلاعات سیستم، فایل‌های SSH، اعتبارنامه‌ها و توکن‌های Git و GitLab، متغیرهای محیطی، و توکن‌های npm، PyPI، pip، Yarn، Maven، Gradle، Composer، RubyGems و Cargo را جمع‌آوری می‌کند. داده‌ها فشرده و با درخواست HTTP POST به litellm[.]dev/healthcheck ارسال می‌شوند؛ دامنه‌ای که ۱۳ اکتبر ۲۰۲۶ ثبت شده است.
نکته مهم برای پاک‌سازی
تیم پژوهش امنیتی مایکروسافت توضیح داده این سازوکارها دامنه تأثیر بالقوه را فراتر از استقرارهای فعال LiteLLM برده‌اند: صرفاً راه‌اندازی پایتون در یک محیط آسیب‌دیده می‌توانست کد مخرب را فعال کند. از آنجا که فایل‌های راه‌اندازی بیرون از پوشه اپلیکیشن LiteLLM قرار داشتند، حذف فقط فایل‌های اپلیکیشن می‌تواند مؤلفه‌های مخرب راه‌اندازی را بر جای بگذارد.
توصیه‌های امنیتی
- اگر نسخه LiteLLM ۱.۱۰۷.۰ را نصب یا اجرا کرده‌اید، آن محیط را آلوده در نظر بگیرید. فقط حذف بسته کافی نیست؛ فایل‌های راه‌اندازی پایتون (Startup Hooks) خارج از پوشه LiteLLM را نیز بررسی و پاک کنید، یا محیط را بازسازی کنید.
- تمام اعتبارنامه‌های موجود در آن محیط را چرخانده و باطل کنید: توکن‌های Git/GitLab، کلیدهای SSH، متغیرهای محیطی، توکن‌های رجیستری بسته‌ها (npm، PyPI، Maven، Cargo و...)، کلیدهای ابری و کلیدهای API سرویس‌های هوش مصنوعی.
- ارتباط شبکه با
litellm[.]devو69.48.229[.]143را در لاگ‌ها جست‌وجو و مسدود کنید. - فرایندهای پس‌زمینه پایتون که هر یک ساعت به یک سرور بیرونی وصل می‌شوند را شکار کنید.
- تصاویر Docker که در بازه ۲۱ اکتبر دریافت کرده‌اید را با نسخه‌های تأییدشده تطبیق دهید.
- درس‌های عمومی برای تیم‌های توسعه: پس از هر نشت اعتبارنامه، ابطال را تا تأیید کامل پیگیری کنید؛ هرگز توکن‌های OAuth بدون محدودیت و در سطح مالک سازمان به سرویس‌های خودکار ندهید؛ کنترل‌های دومرحله‌ای انتشار (مانند تأیید با کلید سخت‌افزاری) را حتی موقتاً تضعیف نکنید؛ و ایجاد ورک‌فلو روی شاخه‌های کوتاه‌عمر را در لاگ فعالیت مخزن پایش کنید.
چرا این حادثه اهمیت دارد؟
این حمله، نمونه‌ای روشن از زنجیره‌ای از کوتاهی‌های کوچک است که با هم به یک فاجعه زنجیره تأمین رسید: یک کلید نشت‌یافته که ابطال نشد، یک توکن بی‌محدودیت، و یک کنترل انتشار که موقتاً تضعیف شده بود. هیچ‌یک از این‌ها به‌تنهایی کافی نبود، اما در کنار هم، به مهاجم اجازه داد خط انتشار یک بسته بسیار پرکاربرد را به دست بگیرد.
فاصله زمانی نیز قابل‌توجه است: کلید در ۲۷ می نشت کرد، اما مهاجم تا ۱۰ اکتبر از آن استفاده کرد و نسخه مخرب تنها در ۲۱ اکتبر منتشر شد. این نشان می‌دهد اعتبارنامه‌های نشت‌یافته ممکن است ماه‌ها در انتظار بمانند.
ماهیت اجرای خودکار هنگام راه‌اندازی پایتون نیز خطرناک است: بدافزار حتی در پروژه‌هایی که LiteLLM را import نمی‌کنند فعال می‌شود و پاک‌سازی ناقص، ردپای مخرب را باقی می‌گذارد. و هدف‌گیری کلیدهای API سرویس‌های هوش مصنوعی و اعتبارنامه‌های رجیستری بسته‌ها، نشان می‌دهد مهاجمان اکنون هم زیرساخت هوش مصنوعی و هم زنجیره توزیع نرم‌افزار را هدف گرفته‌اند.
برچسب ها: LiteLLM, امنیت_اطلاعات, امنیت_سایبری, Cyberattack, cybersecurity, حمله سایبری, news