حمله به LiteLLM؛ نسخه‌ی آلوده‌ی ۱.۱۰۷.۰ کلیدهای API را می‌دزدد و راهنمای پاک‌سازی

اخبار · هوش مصنوعی

نسخه‌ی ۱.۱۰۷.۰ کتابخانه‌ی محبوب LiteLLM در PyPI و ایمیج‌های داکر آلوده شد؛ بدافزار با هر بار اجرای پایتون فعال می‌شود، کلیدهای API و رمزها را می‌دزدد و یک درِ پشتی هم باز می‌گذارد.

چکیده. بر اساس گزارش‌های SafeDep، Socket، StepSecurity و Upwind که در The Hacker News بازتاب یافته، همه‌ی بسته‌های wheel نسخه‌ی ۱.۱۰۷.۰ بسته‌ی LiteLLM حاوی یک سارق اطلاعات و یک بک‌دور بودند. بسته از PyPI قرنطینه و ایمیج‌های آلوده‌ی داکر حذف شده‌اند. هر سیستمی که این نسخه را نصب کرده باید کاملاً آلوده فرض شود و تمام کلیدها و رمزهای قابل‌دسترس آن تعویض شود. نسخه‌ی ۱.۱۰۶.۲ پاک گزارش شده است.
هشدار حمله زنجیره تأمین به بسته پایتونی LiteLLM و سرقت کلیدهای API

بخش ۱ — ماجرا چیست و چرا مهم است؟

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

در تاریخ ۲۱ اکتبر ۲۰۲۶ چند شرکت امنیتی گزارش دادند که نسخه‌ی ۱.۱۰۷.۰ این بسته در PyPI با کد مخرب منتشر شده است. نکته‌ی نگران‌کننده این است که مهاجم به‌جای هدف گرفتن کاربران نهایی، خود مسیر انتشار نرم‌افزار را هدف گرفته؛ روشی که به آن حمله‌ی زنجیره‌ی تأمین می‌گویند. کسی که با دستور pip نسخه‌ی جدید را نصب می‌کند، هیچ نشانه‌ی ظاهری از مشکل نمی‌بیند.

اهمیت ماجرا برای دنیای هوش مصنوعی از اینجاست که ابزارهای واسط مثل LiteLLM به‌طور طبیعی به کلیدهای گران‌قیمت و پرمخاطره‌ی مدل‌ها دسترسی دارند. دزدیده‌شدن یک کلید API می‌تواند هم هزینه‌ی مالی سنگین و هم نشت داده‌ی کاربران را در پی داشته باشد. اگر درباره‌ی نقش این شرکت‌ها در بازار می‌خواهید بیشتر بدانید، مقاله‌ی OpenAI چیست؟ نقطه‌ی شروع خوبی است.

بخش ۲ — کدام نسخه‌ها و چه فایل‌هایی آلوده‌اند؟

طبق گزارش‌ها، نسخه‌ی آلوده فقط ۱.۱۰۷.۰ است. این نسخه از دو مسیر توزیع شده بود: بسته‌ی PyPI و ایمیج‌های داکر. در PyPI، wheelهای مخصوص macOS (هر دو معماری x86_64 و arm64)، لینوکس (manylinux و musllinux برای x86_64 و aarch64) و ویندوز (win_amd64) آلوده بودند.

بسته‌ی سورس (sdist) هیچ فایل پی‌لود نداشت، اما فایل pyproject.toml آن دست‌کاری شده بود. نسخه‌ی ۱.۱۰۶.۲ و نسخه‌های کاندیدای ۱.۱۰۷.۰ پاک گزارش شده‌اند. از آنجا که بسته‌ی آلوده از PyPI قرنطینه شده و ایمیج‌های مخرب داکر حذف شده‌اند، خطر اصلی متوجه سیستم‌هایی است که در بازه‌ی انتشار آن را نصب کرده‌اند؛ به‌ویژه پروژه‌هایی که نسخه را با قید باز مثل litellm>=‎ تعریف کرده بودند و ممکن است خودکار به نسخه‌ی آلوده رسیده باشند.

بخش ۳ — بدافزار چطور اجرا می‌شود؟

ترفند اصلی مهاجم استفاده از فایل‌های با پسوند pth در پوشه‌ی site-packages است. پایتون هنگام راه‌اندازی، خطوط import موجود در این فایل‌ها را اجرا می‌کند. بدافزار فایلی به نام cook.pth گذاشته که حاوی دستور import cook است و در کنارش فایل‌های cook.py و sitecustomize.py قرار دارند.

نتیجه این است که کد مخرب در هر بار اجرای هر برنامه‌ی پایتون در همان محیط فعال می‌شود، حتی اگر برنامه اصلاً LiteLLM را import نکند. به همین دلیل صرفاً «استفاده نکردن از LiteLLM در یک اسکریپت» تضمین نمی‌کند که از شر بدافزار در امان باشید.

این بدافزار دو بخش دارد: یک سارق اطلاعات که StepSecurity آن را privcollect نامیده و یک درِ پشتی که امکان اجرای کد از راه دور را فراهم می‌کند. در بخش‌های بعد هر دو را بررسی می‌کنیم.

نحوه اجرای بدافزار cook.pth هنگام راه‌اندازی مفسر پایتون

بخش ۴ — سارق اطلاعات چه چیزهایی را جمع می‌کند؟

بر اساس تحلیل‌های منتشرشده، سارق اطلاعات طیف گسترده‌ای از داده‌های حساس را هدف می‌گیرد:

  • توکن‌ها و کلیدهای سرویس‌های ابری و سامانه‌های CI/CD
  • کلیدهای خصوصی SSH و GPG
  • فایل‌های اعتبارنامه‌ی ابزارهای هوش مصنوعی و کدنویسی
  • رمزها و کوکی‌های ذخیره‌شده در مرورگرهای کرومیوم و فایرفاکس
  • متغیرهای محیطی فرایندهای در حال اجرا
  • اعتبارنامه‌ها و پیکربندی مدل‌های ذخیره‌شده در پروکسی LiteLLM، شامل کلیدهای API ارائه‌دهندگان مدل

داده‌ها در یک آرشیو فشرده بسته‌بندی می‌شوند. StepSecurity می‌گوید رمزنگاری آن با AES-256-CBC و کلید پوشانده‌شده با RSA-4096 انجام می‌شود و ارسال از طریق HTTP به دامنه‌ی litellm.dev صورت می‌گیرد؛ دامنه‌ای که شبیه دامنه‌ی رسمی به نظر می‌رسد اما به پروژه تعلق ندارد.

بخش ۵ — درِ پشتی و اجرای کد از راه دور

بخش دوم بدافزار، یک دیمن پس‌زمینه است. این دیمن هر ساعت یک فایل متنی به نام domain.txt را از یک مخزن گیت‌هاب می‌خواند. اگر مهاجم نام دامنه‌ای در آن فایل بنویسد، دیمن ابتدا سارق را دوباره اجرا می‌کند و سپس از مسیر codepy همان دامنه کد پایتون می‌گیرد و اجرا می‌کند.

در زمان تحلیل، این فایل خالی بود و مخزن پاسخ ۴۰۴ می‌داد؛ اما نکته همین است که یک کامیت ساده می‌توانست همه‌ی میزبان‌های آلوده را همزمان فعال کند. به همین دلیل کارشناسان توصیه می‌کنند هر درخواستی به مسیر codepy را نشانه‌ی این بدانید که دامنه‌ی خسارت از سرقت اولیه فراتر رفته است.

بخش ۶ — مهاجم چگونه به انتشار رسید؟

الیور جنسن، مدیر امنیت LiteLLM، توضیح داده که اقدامات مخرب از طریق حساب‌های گیت‌هاب سه مهندس انجام شده و ظاهراً از توکن‌های OAuth دزدیده‌شده‌ی ابزار GitHub CLI استفاده شده است. یکی از حساب‌ها اجرای انتشار را راه انداخته و حساب دیگری آن را تأیید کرده است.

این توکن‌ها باطل شده‌اند، اما پروژه هنوز نمی‌داند توکن‌ها چگونه به دست مهاجم افتاده‌اند. به‌عنوان اقدام موقت، همه‌ی اعضا به‌جز یک کاربرِ بدون آلودگی از سازمان گیت‌هاب حذف شده‌اند و پیوندهای انتشار مورد اعتماد (trusted publisher) سازمان از رجیستری‌های عمومی برداشته شده است. تحقیقات ادامه دارد.

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

راهنمای پاک‌سازی و تعویض کلیدهای API پس از آلودگی LiteLLM

بخش ۷ — چطور بفهمیم آلوده شده‌ایم؟

برای بررسی سریع، این نشانه‌ها (IOC) را جست‌وجو کنید:

  • وجود litellm==1.107.0 در فایل‌های requirements، lock یا پیکربندی داکر
  • وجود فایل‌های cook.pth، cook.py یا sitecustomize.py مشکوک در پوشه‌ی site-packages
  • وجود فایل‌های /tmp/.pc_once_72129118c59f5636c0bb و /tmp/remote_code_loader.lock
  • ترافیک شبکه به litellm.dev یا www.litellm.dev
  • درخواست به مسیر codepy روی هر میزبان
  • وجود متغیر محیطی PRIVCOLLECT_ACTIVE=1

همچنین لاگ‌های شبکه و DNS را برای دامنه‌ی ذکرشده و آدرس مخزن گیت‌هاب بررسی کنید. اگر پروژه‌ای با قید باز نصب شده، تاریخچه‌ی نصب در CI را هم نگاه کنید تا مطمئن شوید نسخه‌ی آلوده روی ماشین‌های ساخت نرفته است.

بخش ۸ — راهنمای گام‌به‌گام پاک‌سازی

توصیه‌ی مشترک شرکت‌های امنیتی این است که هر میزبانِ نصب‌کننده‌ی نسخه‌ی آلوده را کاملاً مشکوک بدانید. مراحل پیشنهادی:

  • شناسایی: میزبان‌ها، کانتینرها و ماشین‌های CI که نسخه‌ی ۱.۱۰۷.۰ را نصب کرده‌اند فهرست کنید.
  • توقف دیمن: فرایندی که قفل remote_code_loader را نگه داشته پیدا و متوقف کنید.
  • حذف پی‌لود: سه فایل تزریق‌شده و فایل نشانگر را پاک کنید و نسخه را روی ۱.۱۰۶.۲ پین کنید؛ بهتر است با hash یا digest پین شود.
  • تعویض اعتبارنامه‌ها: از یک محیط تمیز، همه‌ی کلیدهای ابری، SSH و GPG، توکن‌های رجیستری و CI، رمزهای ذخیره‌شده در مرورگر و توکن‌های ابزارهای هوش مصنوعی را عوض کنید. روی هر میزبان پروکسی LiteLLM، تمام کلیدهای API ارائه‌دهندگان مدل و همچنین master key و salt key را هم تعویض کنید.
  • مسدودسازی و پایش: دامنه‌ی litellm.dev را در DNS یا فایروال ببندید و برای آدرس dead drop هشدار تنظیم کنید.

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

بخش ۹ — درس‌هایی برای تیم‌هایی که از ابزارهای هوش مصنوعی استفاده می‌کنند

این حادثه چند درس عملی دارد. اول، وابستگی‌ها را همیشه با نسخه‌ی دقیق و hash قفل کنید و از قیدهای باز در محیط تولید پرهیز کنید. دوم، نصب خودکار آخرین نسخه در CI را با یک فاصله‌ی زمانی (مثلاً چند روز صبر پس از انتشار) ترکیب کنید تا نسخه‌های آلوده‌ی تازه‌منتشرشده زودتر شناسایی شوند. سوم، کلیدهای API را با دامنه‌ی دسترسی و سقف هزینه‌ی محدود بسازید تا اگر دزدیده شدند، آسیب کوچک بماند.

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

بخش ۱۰ — پرسش‌های متداول

آیا همه‌ی نسخه‌های LiteLLM آلوده‌اند؟

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

اگر LiteLLM را import نکرده‌ام، باز هم در خطرم؟

بله، اگر نسخه‌ی آلوده نصب شده باشد. بدافزار از طریق فایل pth هنگام راه‌اندازی پایتون اجرا می‌شود و به import بسته نیاز ندارد.

فقط حذف بسته کافی است؟

خیر. حذف بسته داده‌های دزدیده‌شده را برنمی‌گرداند. باید فایل‌های تزریق‌شده و دیمن را پاک کنید و همه‌ی اعتبارنامه‌های قابل‌دسترس را تعویض کنید.

آیا مهاجم مشخص شده است؟

بر اساس منابع مورد استفاده در این مقاله، هنوز انتساب قطعی منتشر نشده است. تنها اشاره شده که رفتار مشابهی در حمله‌ی مارس دیده شده بود.

خبرهای بیشتر را از کجا بخوانم؟

آخرین خبرها در بخش اخبار هوش مصنوعی مجله‌ی Mr ChatGPT منتشر می‌شود. برای مقایسه‌ی ابزارها هم می‌توانید مقایسه‌ی ChatGPT و DeepSeek را ببینید.

جمع‌بندی. حمله به LiteLLM یادآوری می‌کند که ابزارهای واسط هوش مصنوعی به‌دلیل دسترسی به کلیدهای متعدد، هدف جذابی برای مهاجمان‌اند. اگر نسخه‌ی ۱.۱۰۷.۰ را نصب کرده‌اید، میزبان را آلوده فرض کنید، به نسخه‌ی ۱.۱۰۶.۲ برگردید و همه‌ی کلیدها را همین امروز عوض کنید. برای دریافت سریع‌ترین هشدارها و اخبار هوش مصنوعی، کانال @MrChatGPT_IR را دنبال کنید.

نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید

— (0 رأی)

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *