خانه » حمله زنجیره تأمین LiteLLM؛ آلوده‌سازی PyPI با بکدور سرقت اعتبارنامه‌ها و توکن‌ها

حمله زنجیره تأمین LiteLLM؛ آلوده‌سازی PyPI با بکدور سرقت اعتبارنامه‌ها و توکن‌ها

توسط Vulnerbyte_News
94 بازدید
حمله زنجیره تأمین LiteLLM

حمله زنجیره تأمین LiteLLM به یکی از مهم‌ترین و پیچیده‌ترین رخدادهای امنیت سایبری در اکوسیستم Python تبدیل شده است. در این حمله، مهاجمان با انتشار نسخه‌های مخرب این پکیج محبوب در PyPI موفق شدند یک بکدور به‌همراه بدافزار سرقت کننده اطلاعات (infostealer) را در زنجیره تأمین نرم‌افزار تزریق کنند و از طریق آن به سرقت گسترده اعتبارنامه‌ها، توکن‌های احراز هویت و داده‌های حساس بپردازند. بررسی‌ها نشان می‌دهند که حمله زنجیره تأمین LiteLLM بخشی از یک کمپین پیشرفته توسط گروه TeamPCP بوده که پیش‌تر نیز در اجرای حملات زنجیره تأمین مهم نقش داشته است.

LiteLLM چیست و چرا در حمله زنجیره تأمین LiteLLM هدف قرار گرفت؟

برای درک عمق حمله، باید نقش این پروژه را در اکوسیستم توسعه بررسی کرد.

LiteLLM یک کتابخانه متن‌باز Python است که به‌عنوان یک گیت‌وی برای اتصال به چندین ارائه‌دهنده مدل‌های زبانی بزرگ (LLM) از طریق یک API واحد عمل می‌کند. این ابزار در پروژه‌های هوش مصنوعی (AI) و زیرساخت‌های مبتنی LLM کاربرد گسترده‌ای دارد.

آمار کلیدی:

  • بیش از 3.4 میلیون دانلود روزانه
  • بیش از 95 میلیون دانلود در ماه

این سطح از محبوبیت باعث شده که حمله زنجیره تأمین LiteLLM به یک هدف بسیار ارزشمند برای مهاجمان تبدیل شود؛ زیرا آلوده کردن یک پکیج پرکاربرد در PyPI می‌تواند هزاران محیط توسعه و سرور را به‌صورت زنجیره‌ای آلوده کند.

نحوه اجرای حمله

طبق گزارش شرکت امنیت سایبری Endor Labs، در جریان حمله، مهاجمان دو نسخه آلوده منتشر کردند:

  • LiteLLM 1.82.7
  • LiteLLM 1.82.8

این نسخه‌ها شامل یک پیلود مخفی بودند که بلافاصله پس از importشدن پکیج اجرا می‌شدند.

تزریق پیلود Base64 در حمله زنجیره تأمین LiteLLM

در این حمله ، کد مخرب در مسیر زیر قرار داده شده بود:

litellm/proxy/proxy_server.py

این کد به صورت یک پیلود رمزگذاری‌شده با Base64 در پروژه قرار داده شده بود و پس از رمزگشایی، بلافاصله اجرا می‌شد.

ایجاد پایداری با فایل .pth در حمله

یکی از پیشرفته‌ترین تکنیک‌ها در این حمله در نسخه 1.82.8 مشاهده شد.

مکانیزم:

  • ایجاد فایل pth
  • اجرای خودکار این فایل هنگام راه‌اندازی مفسر Python (Python interpreter)

نتیجه مهم:

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

اجرای Infostealer در حمله زنجیره تأمین LiteLLM

پس از فعال شدن پیلود در این حمله، یک نسخه از بدافزار TeamPCP Cloud Stealer (سرقت‌کننده اطلاعات ابری) روی سیستم قربانی نصب می‌شد.

این پیلود یک حمله سه مرحله‌ای اجرا می‌کرد:

  1. جمع‌آوری اطلاعات حساس
  2. حرکت جانبی (Lateral Movement) در Kubernetes
  3. ایجاد بکدور پایدار در سیستم

در مرحله پایداری، یک سرویس systemd مخفی با نام جعلی زیر ایجاد می‌شد:

System Telemetry Service

این سرویس به‌صورت دوره‌ای با دامنه زیر ارتباط برقرار می‌کرد:

checkmarx[.]zone

و از آنجا پیلودهای اضافی دریافت می‌کرد.

حمله زنجیره تأمین LiteLLM
کد یک Infostealer برای سرقت اعتبارنامه‌ها از سیستم‌های آلوده
حمله زنجیره تأمین LiteLLM
نصب بکدور پایدار

چه داده‌هایی در حمله زنجیره تأمین LiteLLM سرقت شد؟

بدافزار نصب‌شده در حمله زنجیره تأمین LiteLLM طیف گسترده‌ای از اطلاعات حساس را جمع‌آوری می‌کند، از جمله:

  • کلیدهای SSH
  • توکن‌های ابریAWS ، GCP،  Azure
  • اطلاعات Kubernetes
  • فایل‌های.env
  • اطلاعات دیتابیس
  • کلیدهای خصوصی TLS
  • اطلاعات CI/CD
  • داده‌های کیف پول رمزارزی

همچنین بدافزار برای شناسایی سیستم دستورات زیر را اجرا می‌کند:

  • hostname
  • pwd
  • whoami
  • uname -a
  • ip addr
  • printenv

تمام داده‌های سرقت‌شده در آرشیوی با نام tpcp.tar.gz ذخیره شده و سپس به زیرساخت models.litellm[.]cloud مهاجم ارسال می‌شوند.

حمله زنجیره تأمین LiteLLM
استخراج و انتقال داده‌های سرقت‌شده که در فایل tpcp.tar.gz ذخیره شده‌اند

ابعاد حمله

بر اساس گزارش‌ها:

  • حدود 500 هزار مورد استخراج داده ثبت شده است.
  • بخشی از داده‌ها تکراری هستند.

این آمار هنوز به‌صورت مستقل تأیید نشده، اما نشان‌دهنده مقیاس بالای حمله زنجیره تأمین LiteLLM است.

ارتباط حمله زنجیره تأمین LiteLLM با کمپین TeamPCP

نکته مهم این است که حمله زنجیره تأمین LiteLLM احتمالاً بخشی از یک زنجیره حملات گسترده‌تر توسط گروه TeamPCP است.

این گروه پیش‌تر در حمله به موارد زیر نیز دخیل بوده است:

  • Aqua Security Trivy
  • ایمیج‌های Docker
  • پروژه Checkmarx KICS

در برخی گزارش‌ها نیز آمده است که این گروه با اسکریپت‌های مخرب به کلاسترهای Kubernetes حمله کرده و در صورت تشخیص سیستم‌هایی با تنظیمات مربوط به ایران، تمامی ماشین‌ها را پاک‌سازی می‌کند. در سایر مناطق، بکدور  CanisterWorm نصب می‌شود.

راهکارهای مقابله با حمله زنجیره تأمین LiteLLM

پس از شناسایی حمله زنجیره تأمین LiteLLM، نسخه‌های مخرب از PyPI حذف شده‌اند و نسخه امن فعلی LiteLLM 1.82.6 است. با این حال، سازمان‌هایی که از این کتابخانه استفاده می‌کنند باید فوراً اقدامات زیر را انجام دهند.

  1. بررسی نسخه‌های آلوده

اطمینان حاصل کنید که نسخه‌های زیر نصب نشده باشند:

  • 82.7
  • 82.8
  1. تغییر فوری تمام اعتبارنامه‌ها

در صورت استفاده از نسخه‌های آلوده در حمله زنجیره تأمین LiteLLM باید فوراً موارد زیر تغییر داده شوند:

  • توکن‌های API
  • اعتبارنامه‌های ابری
  • کلیدهایSSH
  • اطلاعاتKubernetes
  • توکن‌های CI/CD
  1. بررسی پایداری و فایل‌های مشکوک

وجود فایل‌ زیر می‌تواند نشانه نفوذ باشد:

  • ~/. config/sysmon/sysmon.py
  • /tmp/pglog
  • /tmp/.pg_state
  1. بررسی کلاسترهای Kubernetes

مدیران باید namespace زیر را بررسی کنند:

  • kube-system

و به دنبال podهای غیرمجاز بگردند.

  1. مانیتورینگ ترافیک خروجی

اتصال به دامنه‌های models.litellm[.]cloud باید بررسی شود.

چرا تغییر اعتبارنامه‌ها در حمله زنجیره تأمین LiteLLM حیاتی است؟

یکی از مهم‌ترین درس‌های حمله زنجیره تأمین LiteLLM این است که بسیاری از سازمان‌ها پس از نفوذ اولیه، اعتبارنامه‌ها و توکن‌های افشا شده را تغییر نمی‌دهند.

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

جمع‌بندی

حمله زنجیره تأمین LiteLLM نمونه‌ای جدی از تهدیدات فزاینده علیه اکوسیستم‌های توسعه نرم‌افزار است. مهاجمان با آلوده کردن یک پکیج بسیار محبوب در PyPI توانستند به طیف گسترده‌ای از زیرساخت‌های ابری، محیط‌های توسعه و کلاسترهای Kubernetes دسترسی پیدا کنند.

این رخداد نشان می‌دهد که امنیت زنجیره تأمین نرم‌افزار باید به یکی از اولویت‌های اصلی تیم‌های DevOps و امنیت سایبری تبدیل شود.

منابع

همچنین ممکن است دوست داشته باشید

پیام بگذارید