كشفت تقارير أمنية حديثة عن اختراق خطير استهدف مستودع حزم Python الشهير، PyPI، حيث تمكن قراصنة من زرع برمجيات خبيثة في حزمة Telnyx Python SDK، مما أثر على آلاف المطورين والأنظمة التي تعتمد عليها. وتم اكتشاف النسخ الضارة، والتي تحمل الأرقام 4.87.1 و 4.87.2، وإزالتها بسرعة من قبل فرق PyPI، لكنها بقيت نشطة لمدة أربع ساعات تقريباً.[Main Keyword: Telnyx Python SDK]
وصلت هذه الحزمة الهجومية نحو 750 ألف عملية تنزيل شهريًا، مما يشير إلى نطاق التأثير المحتمل الذي قد يمتد إلى ما وراء المستخدمين المباشرين ليشمل المشاريع وخطوط الإنتاج والخدمات التي تعتمد عليها. ويكمن القلق الأكبر في دقة الهجوم؛ حيث تم تعديل ملف واحد فقط داخل الحزمة، بينما ظلت باقي الملفات متطابقة تمامًا مع النسخة الأصلية.
بدأت تفاصيل الهجوم بالظهور بعد تحليل أجرته فرق Hexastrike، والتي ربطت الهجوم بمجموعة قرصنة تعرف باسم TeamPCP، وهي مجموعة مرتبطة بكيانات التهديد السيبراني القديمة مثل TeamTNT. وقد أظهرت هذه المجموعة مؤخراً نشاطًا متزايدًا في شن هجمات على سلاسل التوريد الرقمية، حيث استهدفت في الأيام الأخيرة أدوات مثل Trivy من Aqua Security، و Checkmarx، و LiteLLM، بالإضافة إلى أكثر من 46 حزمة npm.
وأشارت التقارير إلى أن الهجوم اتبع هيكلاً من ثلاث مراحل. بدأت المرحلة الأولى بتشغيل الحزمة المتسللة لبرنامج تحميل (loader) مخصص للنظام. في المرحلة الثانية، قام برنامج التحميل هذا بجلب حمولة مخفية من خادم يتحكم فيه المهاجم، مخفية داخل ملف صوتي بتنسيق WAV باستخدام تقنية التخفي (steganography).
أما المرحلة الثالثة، فقد شهدت فك تشفير الحمولة ونشر برنامج كامل لجمع بيانات الاعتماد. قام هذا البرنامج بجمع مفاتيح SSH، وبيانات اعتماد مزودي الخدمات السحابية، وأسرار Kubernetes، وإعدادات قواعد البيانات، ومحافظ العملات المشفرة، وملفات البيئة بشكل صامت. بعد ذلك، يتم تشفير جميع البيانات المسروقة وإرسالها إلى خادم المهاجم. تجدر الإشارة إلى أن البرمجية الخبيثة كانت قادرة على العمل عبر أنظمة التشغيل الرئيسية، ويمكنها الانتشار عبر مجموعات Kubernetes بالكامل.
كيف تم تصميم آلية الإصابة لتظل مخفية
كانت نقطة الدخول للهجوم بأكمله عبارة عن تعديل داخل ملف يسمى _client.py. عندما يقوم Python بتحميل مكتبة Telnyx، يتم تشغيل الكود الموجود داخل هذا الملف تلقائيًا.
أضاف TeamPCP استدعاءين لدالتين في نهاية الملف: setup() لأنظمة Windows، و FetchAudio() لأنظمة Linux و macOS. قامت كلتا الدالتين بالتحقق من نظام التشغيل أولاً وتوقفت بصمت إذا كانتا تعملان على منصة غير صحيحة. تم التعامل مع جميع الأخطاء المحتملة وتجاهلها بصمت باستخدام معالجة استثناءات شاملة، مما يعني أن التطبيق الذي يقوم بتشغيل المكتبة لن يتعطل أبدًا أو يصدر تنبيهًا.
لإخفاء ما تقوم به هذه الدوال فعليًا، قام المهاجم بتغليف كل سلسلة نصية حساسة داخل مساعد ترميز base64. تم ترميز عناوين URL، ومسارات المجلدات، وأسماء الملفات، والرؤوس (headers)، بحيث لا يكشف الفحص السريع للكود عن الهجوم.
بعد فك الترميز، قام مسار Windows بتنزيل ملف يسمى hangup.wav من خادم التحكم والسيطرة (command-and-control) على العنوان 83.142.209.203:8080. لم يكن هذا الملف صوتيًا في الواقع، بل كان حاوية WAV صالحة تخفي برنامجًا تنفيذيًا داخل إطارات الصوت باستخدام تقنية التخفي.
تم استخراج البرنامج الثنائي، وفك تشفيره باستخدام مفتاح XOR، وكتابته في مجلد بدء التشغيل الخاص بـ Windows تحت اسم msbuild.exe. تم اختيار هذا الاسم لتقليد أداة Microsoft شرعية لتجنب الشبهات. تم تشغيل البرنامج بصمت دون نافذة مرئية، وكان يعمل تلقائيًا في كل مرة يقوم فيها المستخدم بتسجيل الدخول.
على أنظمة Linux و macOS، كان النهج مختلفًا ولكنه بنفس القدر من التخفي. بدلاً من إسقاط ملف، قام الكود بفك تشفير حمولة Python كبيرة مخزنة في متغير وتشغيلها في عملية فرعية منعزلة. كانت هذه العملية تستمر في العمل حتى بعد إغلاق التطبيق الأصلي. قامت بتنزيل ملف WAV ثانٍ يسمى ringtone.wav، واستخرجت برنامج جمع بيانات الاعتماد الخفي من بيانات الصوت، وقامت بتشغيله بالكامل في الذاكرة، دون كتابة النص البرمجي على القرص.
بمجرد الانتهاء من جمع بيانات الاعتماد، تم تشفير النتائج باستخدام AES-256-CBC، وتم تغليف مفتاح الجلسة باستخدام مفتاح عام RSA-4096 ثابت. وهذا يعني أن المهاجم فقط هو من يمكنه فك تشفير البيانات المسروقة. تم بعد ذلك تجميع كل شيء في ملف وإرساله إلى خادم المهاجم عبر طلب HTTP POST مع الرأس X-Filename: tpcp.tar.gz، وهو توقيع يظهر عبر جميع حملات TeamPCP المعروفة ويعمل كمؤشر اكتشاف قوي على مستوى الشبكة.
يجب على المؤسسات التعامل مع أي تثبيت للإصدارين 4.87.1 أو 4.87.2 على أنه خرق مؤكد، والبدء فورًا في الاستجابة للحوادث. يجب تدوير جميع بيانات الاعتماد التي يمكن الوصول إليها من الأنظمة المتأثرة، بما في ذلك مفاتيح SSH، وبيانات اعتماد AWS و GCP و Azure، ورموز Kubernetes، وبيانات اعتماد Docker، وكلمات مرور قواعد البيانات، ومفاتيح API، وأي أسرار مخزنة في ملفات البيئة.
إن مجرد إلغاء تثبيت الحزمة لا يزيل الباب الخلفي المستمر. على أنظمة Linux، يجب إزالة الملف ~/.config/sysmon/sysmon.py وخدمة systemd المرتبطة به يدويًا. على أنظمة Windows، يجب حذف msbuild.exe في مجلد بدء التشغيل والملف المخفي .lock. في بيئات Kubernetes، يجب تدقيق وإزالة أي Pods تسمى node-setup-* في kube-system، ويجب فحص كل عقدة بحثًا عن خدمة systemd غير متوقعة تسمى sysmon.service.
بالإضافة إلى ذلك، يجب على المطورين تثبيت جميع التبعيات على إصدارات محددة، واستخدام ملفات القفل (lockfiles)، وتمكين المصادقة الثنائية على حسابات PyPI، واستخدام بيانات اعتماد قصيرة العمر قدر الإمكان، وتجنب تخزين الأسرار في ملفات .env على القرص، وحظر الاتصالات الصادرة إلى 83.142.209.203، و checkmarx.zone، وشبكة 83.142.209.0/24 الأوسع على مستوى جدار الحماية.