حمله زنجیره تأمین به LiteLLM؛ نسخه ۱.۱۰۷.۰ رمزها و کلیدها را می‌دزدید

چه اتفاقی افتاد؟

LiteLLM محصول شرکت BerriAI است و یک رابط یکپارچه برای کار با ارائه‌دهندگان مختلف مدل‌های زبانی فراهم می‌کند. به گزارش The Register، حدود ۲۳ میلیون دانلود هفتگی دارد.

بر اساس اطلاعیه رسمی LiteLLM، نسخه ۱.۱۰۷.۰ هر هفت بسته wheel در PyPI تقریباً از ساعت ۱۱:۳۹ تا ۱۳:۲۳ به وقت UTC در دسترس بود. تگ‌های `v1.107.0`، `latest`، `main-latest` و `main-stable` در Docker Hub و GHCR نیز تقریباً از ۱۱:۴۶ تا ۱۴:۲۰ UTC آلوده بودند. به گفته شرکت، مشتریان سازمانی که از رجیستری خصوصی استفاده می‌کردند تحت تأثیر قرار نگرفتند.

نکته نگران‌کننده در سمت کانتینرها بود: هر استقراری که در آن بازه تگ `latest` یا `main-stable` را pull کرده، کد مخرب را گرفته است، حتی اگر بسته PyPI بعداً حذف شده باشد.

بدافزار چگونه کار می‌کرد؟

طبق گزارش The Register، مهاجم سه فایل به بسته اضافه کرد. فایل `cook.pth` باعث می‌شد `cook.py` با هر بار راه‌اندازی پایتون اجرا شود؛ یعنی حتی اگر LiteLLM هرگز import نشود. `cook.py` سارق اطلاعات بود و `sitecustomize.py` یک RAT را به‌صورت فرایند پس‌زمینه اجرا می‌کرد که ظاهراً هر ساعت از زیرساخت مهاجم دستور می‌گرفت.

سارق اطلاعات طبق گزارش‌ها این موارد را هدف می‌گرفت: رمزهای ذخیره‌شده مرورگرها، اعتبارنامه‌های AWS و GCP و Azure، کلیدهای API سرویس‌های هوش مصنوعی، کلیدهای SSH و GPG و تاریخچه شل. داده‌ها پیش از ارسال رمزنگاری می‌شدند.

ریشه نفوذ از دید LiteLLM

به گفته LiteLLM، مهاجم از طریق یک حساب با نام بی‌خطر در بخش استقرار داخلی که از اینترنت در دسترس بود، به توکن‌های OAuth ابزار خط فرمان GitHub رسید؛ توکن‌هایی که به گفته شرکت توسط Claude Code لاگ شده بودند. سپس با اعتبارنامه‌های مالکان سازمان، حفاظت شاخه‌ها را غیرفعال کرد و گردش‌کار انتشار را به مخزنی با نام شبیه‌ساز (`Berri-AI/litellm` به‌جای `BerriAI/litellm`) هدایت کرد. در نهایت بسته‌های مخرب از مسیرهای رسمی امضا و منتشر شدند.

این دومین حادثه زنجیره تأمین LiteLLM در سال ۲۰۲۶ است. حادثه قبلی (نسخه‌های ۱.۸۲.۷ و ۱.۸۲.۸) به گفته پژوهشگران Datadog به گروه TeamPCP مرتبط بوده است.

چرا مهم است و چه باید کرد؟

پروکسی‌ها و گیتوی‌های LLM معمولاً کلیدهای چند ارائه‌دهنده را یک‌جا نگه می‌دارند، پس هدف پرارزشی هستند. اگر پروژه شما LiteLLM را نصب می‌کند و نسخه را پین نکرده، ممکن است در ساعات آن روز نسخه آلوده را گرفته باشید؛ این موضوع برای سرویس‌ها و CI در هر کشوری، از جمله ایران، صادق است.

توصیه LiteLLM: وجود `litellm-1.107.0.dist-info` و فایل‌های `cook.pth` و `sitecustomize.py` را بررسی کنید، فرایندهای پایتون جداشده را متوقف کنید، فایل‌های مخرب را حذف کنید و به نسخه ۱.۱۰۶.۲ برگردید. اگر نسخه آلوده روی میزبان متصل به اینترنت اجرا شده، آن را آلوده فرض کنید و همه رمزها و کلیدها، از جمله نقش‌های IAM، کلیدهای API ارائه‌دهندگان و رمز پایگاه داده را بچرخانید. محققان همچنین به بررسی فایل‌هایی مانند `/tmp/.pc_once_*` به‌عنوان نشانه خروج داده اشاره کرده‌اند.

# بررسی نسخه نصب‌شده و برگشت به نسخه سالم
pip show litellm
pip install "litellm==1.106.2"

# پین کردن در requirements.txt
# litellm==1.106.2