المحاور السفلية: كيف تقوم بإدارة الهجوم على سلسلة الإمدادات في npm

الرئيسية » Python » المحاور السفلية: كيف تقوم بإدارة الهجوم على سلسلة الإمدادات في npm

لعدة ساعات عصيبة، كانت إحدى أكثر مكتبات جافا سكريبت استخدامًا على مستوى العالم، أكسيوسأصبحت وسيلة غير متوقعة لتوصيل البرامج الضارة. هدف مستهدف هجوم على سلسلة التوريد لنظام npm البيئي حوّل تحديث التبعية الروتيني إلى باب خلفي محتمل للمهاجمين على مئات الآلاف من أجهزة المطورين وأنظمة البناء.

قام محققون من عدة شركات أمنية ومجموعة استخبارات التهديدات التابعة لشركة جوجل بتجميع المعلومات حول كيفية قيام جهة خبيثة بالتسلل إلى النظام. حصان طروادة للوصول عن بعد (RAT) في إصدارات محددة من Axios على npm، على غرار دودة سلسلة التوريد npm.

ما هو موقع أكسيوس ولماذا يُعدّ التنازل مهماً للغاية؟

في جوهرها، أكسيوس هي عميل HTTP قائم على الوعود لـ Node.js والمتصفحات. إنه موجود خلف الكواليس في عدد لا يحصى من المشاريع، ويتعامل مع المهام اليومية مثل "جلب رسائلي من الخادم" أو "إرسال هذا النموذج إلى واجهة برمجة التطبيقات" دون أن يضطر المطورون إلى كتابة رمز الشبكة منخفض المستوى يدويًا.

نظرًا لأنه يعمل في كل من المتصفح وعلى خوادم Node.js، فقد أصبح Axios الاعتمادية الأساسية في حزم جافا سكريبت الحديثةقد لا تكون قد قمت بتثبيته بشكل صريح، ومع ذلك فأنت لا تزال تعتمد عليه بشكل غير مباشر عندما:

• استخدم تطبيقات الويب المبنية باستخدام أطر عمل مثل React أو Vue أو Angular التي تغلف استدعاءات واجهة برمجة التطبيقات الخاصة بها باستخدام Axios.
• تشغيل تطبيقات سطح المكتب أو تطبيقات الهاتف المحمول المبنية على تقنيات مثل Electron و React Native وبيئات التشغيل المماثلة المستندة إلى الويب.
• التفاعل مع أدوات SaaS الأصغر حجمًا، أو لوحات تحكم الإدارة، أو الخدمات المستضافة ذاتيًا التي اختار مطوروها Axios لطلبات HTTP.

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

كيف تطور هجوم Axios على npm

تتمحور الحادثة حول إصدارين من npm: axios@1.14.1 و axios@0.30.4باستخدام بيانات اعتماد مخترقة لأحد القائمين الرئيسيين على صيانة المشروع، تمكن المهاجمون من نشر إصدارات خبيثة مباشرة إلى npm مع ترك شفرة المصدر العامة على GitHub دون تغيير، وهو نمط موصوف أيضًا في تحليل شاي الخلود.

بدلاً من إجراء تغييرات ظاهرة على كود Axios، أضاف المهاجم تبعية جديدة تبدو غير ذات صلة: plain-crypto-js@4.2.1صُممت هذه الحزمة خصيصاً للعملية و لم يتم استيرادها في أي مكان في ملفات مصدر Axios، وهو بمثابة علامة تحذير لأي شخص يدقق في الفرق - ولكن من السهل تفويته في سير العمل الآلي الذي يعتمد ببساطة على السجل.

معًا، كان للنسختين الملوثتين من أكسيوس تأثير محتمل هائل، يصل إلى حوالي 100 مليون عملية تنزيل أسبوعية على npmتشير التقديرات إلى أن Axios موجود في ما يقرب من 80٪ من بيئات الحوسبة السحابية وخطوط أنابيب CI/CD، لذا فإن حتى فترة التعرض القصيرة تمثل خطرًا نظاميًا خطيرًا.

والأهم من ذلك، أن النسخ المتأثرة لم تظهر أبداً في علامات GitHub الرسمية بالنسبة لمشروع Axios. تشير هذه التفاصيل بقوة إلى أنه تم تجاوز عمليات الإصدار العادية: استغل المهاجم رمز npm مسروقًا لدفع الحزم مباشرة إلى السجل، خارج نطاق تاريخ المصدر العام.

آليات التبعية الخبيثة وبرنامج التحكم عن بعد

يكمن جوهر الحل الوسط فيما حدث أثناء التثبيت. أي سير عمل تم تشغيله npm install وتوقف axios@1.14.1, axios@0.30.4 or plain-crypto-js@4.2.1 أدى تفعيل البرامج النصية إلى تشغيل إجراء مخفي لما بعد التثبيت.

داخل التبعية الخبيثة، أ برنامج نصي لما بعد التثبيت (node ​​setup.js) تم التنفيذ تلقائيًا. قام هذا البرنامج النصي بتنزيل برنامج تثبيت مُشفر، والذي بدوره قام بجلب حمولة RAT خاصة بالمنصة مصممة خصيصًا لـ نظام التشغيل macOS أو Windows أو Linux. منح برنامج RAT المهاجم إمكانية الوصول التفاعلي عن بعد إلى الجهاز المخترق.

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

ومن هناك، يمكن للمهاجمين تغيير مسارهم: فحص شفرة المصدر، والتلاعب بالإصدارات المستقبلية، وإضافة المزيد من الثغرات الأمنية، أو الانتقال بشكل جانبي إلى البنية التحتية للإنتاج. بالنسبة للمطورين العاملين على مشاريع متعلقة بالعملات المشفرة - المحافظ، ومنصات التداول، وواجهات DeFi - يمكن أن يترجم هذا النوع من الوصول مباشرة إلى سرقة العملات المشفرة أو الاحتيال المالي الأوسع نطاقاً.

تكتيكات التخفي: لماذا كان من الصعب اكتشاف التسوية

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

هذا يعني أنه إذا قمت بفحص node_modules/plain-crypto-js/package.json بعد في حالة الإصابة، سترى بيانًا غير ضار تمامًا: لا يوجد برنامج نصي لما بعد التثبيت، ولا setup.jsلا توجد مؤشرات واضحة على وجود جريمة. الأدوات القياسية مثل npm audit أو أن فحص الدليل اليدوي السريع لن يكشف ما حدث بالفعل.

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

المؤشرات الرئيسية للاختراق في حادثة أكسيوس

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

على جانب الشبكةابحث عن التواصل مع:

• المجال: sfrclakcom
• عنوان إب: 142.11.206.73

تم حظر كلا المؤشرين من قبل موردي الأمن الرئيسيين، لكنهما يظلان مؤشرين مفيدين في السجلات التاريخية وعمليات البحث في أنظمة إدارة معلومات الأمان والأحداث (SIEM).

على نظام الملفاتأبرز المحققون القطع الأثرية المرتبطة بجهاز RAT:

• ماك: /Library/Caches/com.apple.act.mond
• لينكس: /tmp/ld.py
• ويندوز: الملفات الموجودة ضمن %PROGRAMDATA%\wt والبرامج النصية المؤقتة مثل %TEMP%\6202033.vbs or .ps1 والتي قد توجد لفترة وجيزة فقط أثناء التنفيذ

فيما يتعلق بحزم npm، فإن النسخ المخترقة ومجموعات التحقق المعروفة الخاصة بها هي:

• axios@1.14.1، SHA-256: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4، SHA-256: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1، SHA-256: 07d889e2dadce6f3910dcbc253317d28ca61c766

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

من يقف وراء الهجوم؟ تحديد الجهة المسؤولة وارتباطها بكوريا الشمالية

ربطت مجموعة استخبارات التهديدات التابعة لشركة جوجل علنًا اختراق موقع أكسيوس بـ جهة تهديد كورية شمالية مشتبه بها تم تتبعها تحت اسم UNC1069. وأشار جون هولتكوست، كبير المحللين في وحدة التهديدات بشركة جوجل، إلى أن لدى المشغلين الكوريين الشماليين سجلاً حافلاً بـ هجمات على سلسلة التوريد تهدف إلى سرقة العملات المشفرة وأصول أخرى.

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

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

كيف تم إساءة استخدام حساب المسؤول عن الصيانة وسير عمل npm

من أكثر الجوانب إثارة للقلق بالنسبة لمجتمع المصادر المفتوحة هو كيفية تمكن المهاجمين من نشر نسخ خبيثة من برنامج Axios دون المساس بقاعدة الشفرة العامة. وكان المفتاح هو تم اختراق حساب المسؤول عن الصيانة على npm، يُعتقد أنها تنتمي إلى أحد القائمين الرئيسيين على صيانة Axios والمعروف باسم jasonsaayman.

وبحسب التقارير، قام المهاجمون بتغيير عنوان البريد الإلكتروني المرتبط بحساب npm إلى عنوان تحت سيطرتهم. وبهذه الخطوة، تمكنوا من منع المسؤول الشرعي من القيام بأعمال الصيانة ودفع إصدارات جديدة من الحزم كما لو كانت تحديثات حقيقية، كل ذلك بينما ظل مستودع GitHub الرسمي نظيفًا.

كما كشفت العملية عن مشكلة هيكلية في npm: دعم لـ رموز المصادقة القديمة، والحاجة إلى أدوات إدارة سلسلة التوريد وسياسات أكثر صرامة بشأن الرموز المميزة.

في هذه الحالة، أشار باحثو الأمن إلى أن npm لا يزال تم استخدام الرمز المميز القديم افتراضيًا لأغراض النشر، ولم تقم أي جهة تحكم بإلغاء هذا الرمز تلقائيًا بمجرد تهيئة أساليب النشر الحديثة. وقد أدى هذا التعايش إلى خلق ثغرة أمنية يمكن لبرنامج UNC1069 استغلالها.

نافذة التعرض والكشف المبكر

لم يكن اختراق موقع أكسيوس عملية طويلة وبطيئة. تشير التحقيقات إلى أن النسخ الخبيثة كانت متاح على npm لمدة ثلاث ساعات تقريبًا بين وقت متأخر من ليلة الأحد والساعات الأولى من يوم الاثنين أو الثلاثاء، حسب المنطقة الزمنية.

أشارت شركة StepSecurity وشركات أخرى إلى أن المهاجم قد زرع النظام البيئي بـ نسخة نظيفة من التبعية الخبيثة قبل حوالي 18 ساعة ربط النسخة المُعدّلة ببرنامج أكسيوس. ويبدو أن هذه الخطوة صُممت لبناء سجلّ سليم للحزمة وتجنّب تنبيه أجهزة الكشف عن الشذوذ الآلية عند ظهور التبعية فجأة.

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

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

التأثير على المطورين ومشاريع العملات المشفرة والمستخدمين النهائيين

من وجهة نظر عملية، فإن الضحايا الأكثر مباشرة لحادثة أكسيوس هم المطورين وبيئات البناء التي قامت بتثبيت الإصدارات الخبيثة. يجب على أي شخص قام بتشغيل عملية تثبيت أو بناء تتضمن axios@1.14.1 أو axios@0.30.4 أو plain-crypto-js@4.2.1 مع تمكين البرامج النصية أن يفترض أن النظام قد يكون مخترقًا بالكامل.

بالنسبة للمشاريع في مجال العملات المشفرة - المحافظ، والبورصات المركزية واللامركزية، ولوحات تحكم التمويل اللامركزي، وبرامج التداول الآلي، وواجهات الويب 3 - فإن المخاطر عالية بشكل خاص. العديد من هذه الأنظمة يعتمد على Axios للتواصل مع بوابات البلوك تشين وواجهات برمجة التطبيقات وخدمات الواجهة الخلفيةوغالباً ما يديرون أسراراً حساسة مثل المفاتيح الخاصة وبيانات اعتماد واجهة برمجة التطبيقات وبيانات المستخدم.

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

في المقابل، يتمتع المستخدمون الذين يشغلون التطبيقات الجاهزة في متصفحاتهم بوضع أفضل: تم تسليم برنامج RAT خلال خطوات التركيب والبناءلا يحدث ذلك أثناء تشغيل المتصفح. لذا، فإن زيارة موقع يستخدم Axios لإجراء استدعاءات من جانب العميل لا تؤدي، في حد ذاتها، إلى إطلاق الهجوم. يتركز الخطر على من قاموا بتثبيت حزم npm المتأثرة.

الخطوات الفورية التي يجب على المطورين اتخاذها

أوضحت فرق الأمن والقائمون على الصيانة ما يلي: إذا كان هناك أي احتمال أن تكون أنظمتك قد قامت بتثبيت إصدارات Axios أو plain-crypto-js المخترقة، فتعامل مع تلك الأجهزة المضيفة على أنها لا يُوثق به إطلاقاً حتى يتم التحقيق فيهوهذا يعني أكثر من مجرد تغيير رقم الإصدار.

تشمل الإجراءات الملموسة التي أوصى بها الباحثون والبائعون ما يلي:

• راجع تبعياتك وملفات القفل: البحث عن axios@1.14.1, axios@0.30.4 و plain-crypto-js@4.2.1 in package-lock.json, pnpm-lock.yaml, yarn.lock وسجلات التكامل المستمر؛ انظر كيفية إصلاحها بأمان.
• قم بالترقية إلى الإصدارات الآمنة والموثوقة: انتقل إلى إصدارات Axios النظيفة (على سبيل المثال، العلامات المصححة اللاحقة مباشرة التي أوصى بها القائمون على الصيانة) وتأكد من إعادة إنشاء ملفات القفل الخاصة بك.
• قم بتغيير بيانات الاعتماد بشكل مكثف: افترض أن أي سر موجود على الأجهزة أو خطوط الأنابيب المتأثرة - مفاتيح واجهة برمجة التطبيقات السحابية، ورموز npm، ومفاتيح SSH، ومفاتيح النشر، ومتغيرات .env - قد يكون قد سُرق وقم بتدويرها.
• إعادة بناء الأنظمة المخترقة: حيثما أمكن، أعد نشر عوامل البناء، ومشغلي التكامل المستمر، ومحطات عمل المطورين من صور موثوقة بدلاً من محاولة تنظيفها في مكانها.
• البنية التحتية للمربع C2: إضافة sfrclak.com و 142.11.206.73 إلى جدران الحماية، وقوائم حظر نظام أسماء النطاقات، وقواعد الاستجابة لنقاط النهاية.
• البحث عن القطع الأثرية: تحقق من مسارات نظام الملفات والملفات المؤقتة المرتبطة ببرنامج التحكم عن بعد على أجهزة macOS وWindows وLinux.

نصحت العديد من شركات الأمن المؤسسات التي قامت بتثبيت النسخ المصابة بما يلي: افتراض التنازل افتراضياًبمعنى آخر، انطلق على افتراض أن المهاجمين قد تمكنوا من الوصول، واعمل بشكل منهجي من خلال خطوات الاستجابة للحوادث بدلاً من التمني ألا يفعل البرنامج الضار أي شيء.

دروس أوسع نطاقاً لأمن سلسلة توريد البرمجيات

إلى جانب الاستجابة الفورية للحالات الطارئة، أعادت حادثة أكسيوس إشعال النقاشات حول كيفية تعامل النظام البيئي الأوسع مع الثقة والهوية والتوزيع في المصادر المفتوحة. وهي توضح كيف أن حساب واحد لصيانة المكتبة يمكن أن يصبح ركيزة أساسية للوضع الأمني ​​للعديد من المنظمات.

وقد برزت عدة مواضيع من خلال عمليات التشريح وتحليلات البائعين:

• تُعتبر الرموز القديمة عبئاً: يمكن أن تبقى رموز npm القديمة موجودة بهدوء إلى جانب سير العمل الأحدث القائم على OIDC. تحتاج المشاريع إلى سياسات واضحة لإلغائها بمجرد تطبيق طرق أكثر أمانًا.
• التحديثات الآلية سلاح ذو حدين: تؤدي عمليات التحديث التلقائي للتبعيات إلى تسريع عملية التطوير، ولكنها تعني أيضًا أن الإصدار الخبيث يمكن أن ينتشر عبر الأنظمة البيئية قبل أن يلاحظه أي شخص.
• يُعد فحص التبعيات ضروريًا ولكنه غير كافٍ: الفحوصات الثابتة و npm audit مفيدة، لكنها تكافح ضد سلوك عابر مثل البرامج النصية التي تُحذف تلقائيًا بعد التثبيت.
• يُعد أمن القائمين على الصيانة بنية تحتية بالغة الأهمية: أصبحت المصادقة متعددة العوامل القوية، ومفاتيح الأمان المادية، والتعامل الدقيق مع رموز الوصول، والمراجعة المنتظمة لمن يمكنه النشر، الآن بنفس أهمية كتابة التعليمات البرمجية الجيدة.

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

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