هجوم سلسلة التوريد LiteLLM: التحليل الكامل لحقن البرمجيات الخبيثة عام 2026 ودليل الاستجابة الطارئة

النقاط الرئيسية

1. الإصابات المتأثرة: تم حَقن إصدارات LiteLLM 1.82.7 و1.82.8 على PyPI بكود ضار، وتم إزالتها. آخر إصدار آمن هو 1.82.6.
2. آلية الهجوم: الإصدار 1.82.7 أخفى الحمولة في proxy_server.py؛ بينما استخدم الإصدار 1.82.8 بالإضافة إلى ذلك ملف .pth في Python (litellm_init.pth) الذي ينفذ تلقائياً عند بدء تشغيل أي عملية Python دون الحاجة لاستيراد LiteLLM.
3. البيانات المسروقة: مفاتيح SSH الخاصة، بيانات اعتماد AWS/GCP/Azure، إعدادات Kubernetes والأسرار (Secrets)، ملفات .env، محافظ العملات الرقمية، كلمات مرور قواعد البيانات، بيانات اعتماد Git، سجل الأوامر (Shell history)، وغيرها.
4. الهجوم ثلاثي المراحل: جمع بيانات الاعتماد → الانتقال الجانبي داخل Kubernetes (إنشاء Pods ممتازة) → الاستمرارية عبر خدمة systemd مُقنعة (sysmon.service).
5. السبب الجذري: اخترق المهاجمون ماسح الأمان Trivy سابقاً، وحصلوا على صلاحيات نشر LiteLLM على PyPI، وتجاوزوا نظام CI/CD العادي لرفع الحزم الضارة مباشرةً.
6. نافذة التعرض: كانت الإصدارات الضارة نشطة لمدة 1–2 ساعة فقط قبل أن يتسبب خلل "قنبلة التشعب" (fork bomb) في تعطل أجهزة المطورين، مما أدى إلى اكتشاف الهجوم.
7. نطاق التأثير: لدى LiteLLM أكثر من 95 مليون تحميل شهري، ويعتمد عليه بشكل غير مباشر العديد من أنظمة وكلاء الذكاء الاصطناعي، وخوادم MCP، ومشاريع تنظيم نماذج اللغة الكبيرة (LLM).

الخط الزمني وتفاصيل الهجوم

في 24 مارس 2026، ظهرت إصدارات غير طبيعية فجأة على PyPI لمكتبة LiteLLM الشهيرة — وهي غلاف API موحد لأكثر من 100 مزود لنماذج اللغة الكبيرة. استخدم الفاعل التهديدي TeamPCP (المسؤول سابقاً عن هجمات على Trivy وKICS) بيانات اعتماد مُخترقة أو رموز PyPI لإصدار إصدارين ضارين.

الإصدار 1.82.7: -(نقاطي) تم إخفاء الحمولة الضارة داخل litellm/proxy/proxy_server.py. -(نقاطي) تم تشغيله فقط عند استيراد الوحدة أو تشغيل litellm --proxy. -(نقاطي) كانت الحمولة عبارة عن سكريبت Python مُشفرة مرتين باستخدام base64.

الإصدار 1.82.8 (أكثر تدميراً): -(نقاطي) تم إضافة ملف litellm_init.pth أيضاً. -(نقاطي) تقوم وحدة site في Python بتنفيذ ملفات .pth تلقائياً عند بدء تشغيل المفسر، مما يتيح التشغيل بدون تفاعل. -(نقاطي) هذا يعني أنه حتى المشاريع التي لم تستخدم LiteLLM بشكل صريح يمكن أن تصاب إذا كانت الحزمة موجودة في بيئتها.

استخدم البرنامج الضار تشفيراً هجيناً (AES-256-CBC + RSA-4096) لاستخراج البيانات ونقلها إلى النطاق المزيف models.litellm.cloud.

التحليل التقني للحملة الخبيثة

كشف التحليل أن الحملة تعمل في ثلاث مراحل متميزة:

1. مرحلة جمع بيانات الاعتماد:

   • مسح متكرر للمسارات الشائعة: ~/.ssh/, ~/.aws/, ~/.kube/, ~/.azure/, ملفات .env، تكوينات Kubernetes، بيانات اعتماد Git، إلخ.
   • استخراج متغيرات البيئة، الأسرار في الذاكرة، نقاط نهاية بيانات تعريف السحابة (IMDS)، وملفات متعددة لمحافظ العملات المشفرة.

2. مرحلة الانتشار الجانبي (بيئات Kubernetes):

   • استخدمت رموز ServiceAccount لقراءة الأسرار على مستوى الكتلة.
   • أنشأت حاويات Pod متميزة alpine:latest في نطاق kube-system على كل عقدة، مع توصيل نظام ملفات المضيف.

3. مرحلة الاستمرارية:

   • نشرت بابًا خلفيًا متنكرًا كـ "خدمة قياس عن بعد للنظام" (sysmon.py + خدمة نظام systemd للمستخدم).
   • سحبت حمولات إضافية بشكل دوري من نطاقات مثل checkmarx.zone.

سبب الاكتشاف: أدت استدعاءات subprocess.Popen للكود الخبيث إلى إنشاء قنبلة تفريخ أسية تحت آلية .pth، مما استنفد الذاكرة بسرعة وأدى إلى تعطل الآلات – عيب كشف عن الهجوم بشكل غير مقصود.

لماذا كانت LiteLLM هدفًا عالي القيمة

تعمل LiteLLM كوكيل عالمي يدعم أكثر من 100 موفر لـ LLM وتستخدم على نطاق واسع في أنظمة وكلاء الذكاء الاصطناعي الإنتاجية، وخوادم MCP، والتوجيه متعدد النماذج. غالبًا ما يستبدل المطورون الاستدعاءات الأساسية بسطر واحد من الكود، مما يعني أن مفاتيح API الحساسة تتواجد غالبًا في نفس البيئة.

كان سلسلة هجوم سلسلة التوريد واضحة: اختراق Trivy → CI/CD لـ LiteLLM المعتمد على Trivy → تسريب حقوق النشر → تحميل خبيث مباشر إلى PyPI. هذا يسلط الضوء على الأهمية البالغة لمبدأ "الثقة مع التحقق" في نظام الإيكولوجي مفتوح المصدر اليوم.

الإجراءات الفورية: خطوات الكشف والتنظيف

الخطوة 1: التحقق من الإصدار المثبت

pip show litellm
pip list | grep litellm

إذا تم العثور على الإصدار 1.82.7 أو 1.82.8، قم بإزالته فورًا:

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

الخطوة 2: تنظيف ذاكرة التخزين المؤقت لـ Python و site-packages 5- حذف أدلة site-packages/litellm* وأي ملفات .pth.

• تطهير ذاكرة التخزين المؤقت لـ pip: pip cache purge

الخطوة 3: تدوير جميع بيانات الاعتماد

• فورًا قم بتدوير مفاتيح SSH، وجميع مفاتيح الوصول السحابية (AWS IAM، حسابات خدمة GCP، Azure AD)، ورموز Kubernetes، وكلمات مرور قواعد البيانات، وأسرار CI/CD.
• راجع سجلات التدقيق السحابية (CloudTrail، Audit Logs، Activity Log) للوصول المشبوه.

الخطوة 4: فحوصات إضافية لبيئات Kubernetes .

• افحص نطاق kube-system بحثًا عن حاويات Pod مشبوهة.
• ابحث عن أدلة ~/.config/sysmon/ وخدمات systemd ضارة على العقد.
• أعد بناء العقد المتأثرة (موصى به بشدة).

الخطوة 5: فحص المشاريع التابعة

• راجع جميع ملفات requirements.txt، و pyproject.toml، وصور Docker؛ ثبت LiteLLM على ==1.82.6.
• استخدم أدوات مثل pip-audit أو safety لفحص البيئات.

التخفيف المتقدم وأفضل الممارسات

• تثبيت الإصدارات: قم دائمًا بقفل LiteLLM إلى الإصدار ==1.82.6 (أو إصدار آمن أحدث) في الإنتاج باستخدام Poetry أو Pipenv أو ما شابه.
• فحص سلسلة التوريد: ادمج أدوات مثل Dependabot أو Snyk أو JFrog Xray أو Endor Labs لمراقبة تغييرات حزم PyPI.
• الحد الأدنى من الصلاحيات: تجنب خلط بيانات اعتماد التطوير والإنتاج؛ استخدم مديري الأسرار المخصصين مثل AWS Secrets Manager أو HashiCorp Vault.
• التثبيت المعزول: للبيئات ذات الأمان العالي، قم بالبناء من المصدر المضمون على GitHub وتحقق من التجزئات.
• المراقبة: نشر حلول EDR لمراقبة إنشاء ملفات .pth والسلوك غير الطبيعي للتفريع والاتصالات الصادرة إلى نطاقات مشبوهة.

الحالات المتطرفة:

• التثبيت غير المباشر عبر نصوص CLI (مثل install.sh) يعرض الأنظمة أيضًا للخطر.
• يجب إعادة بناء صور Docker المعتمدة على صور أساسية معرضة للاختراق.
• البيئات الافتراضية (venv) معزولة لكن التثبيتات العامة لبايثون لا تزال تؤثر على عمليات النظام.

الخلاصة

هجوم سلسلة توريد LiteLLM يذكرنا بوضوح أن راحة النظم البيئية مفتوحة المصدر تأتي مع مخاطر أمنية جسيمة. باختراق ماسح أمني أولاً، حقق المهاجمون تأثيرًا دقيقًا في المصب.

تصرف الآن: افحص كل بيئة بايثون بحثًا عن إصدارات LiteLLM، ارجع إلى الإصدار 1.82.6، وقم بتدوير جميع بيانات الاعتماد المعرضة للخطر فورًا. أنشئ عمليات مراجعة صارمة للتبعيات لمنع الحوادث المستقبلية.

ابقَ مُحدثًا عبر إعلانات LiteLLM الرسمية على GitHub وPyPI. في عام 2026 وما بعده، المراجعة المنتظمة للتبعيات هي مهارة أساسية لكل مطور ذكاء اصطناعي.

كن يقظًا وحمِ سلسلة التوريد — ابدأ بتثبيت الإصدارات اليوم.