حزمة Injective SDK الخبيثة تستهدف المفاتيح الخاصة وعبارات البذور

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

عثرت شركة الأمن Socket على الكود الخبيث في الإصدار 1.20.21 من @injectivelabs/sdk-ts، وهي حزمة تساعد التطبيقات على الاتصال بـ Injective وإدارة الوظائف المتعلقة بالمحفظة. تتلقى الحزمة عادةً حوالي 50,000 تنزيل أسبوعياً، على الرغم من أن هذا الرقم يشمل جميع الإصدارات ولا يمثل عدد الأشخاص المتأثرين بالحادث.

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

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

كان الكود الخبيث مخفياً داخل أداة موثوقة

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

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

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

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

زادت سبع عشرة حزمة ذات صلة من احتمالية التعرض للخطر

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

لذلك لا ينبغي وصف الحادث بأنه 18 حزمة منفصلة مصابة. تظهر الأدلة المتاحة أن SDK الرئيسي احتوى على الوظيفة الخبيثة، بينما اعتمدت 17 حزمة ذات صلة مباشرة أو غير مباشرة على ذلك الإصدار. قالت Socket إن الإصدار المتأثر تم وضع علامة عليه كمهمَل بعد اكتشاف الاختراق ونشر إصدار نظيف. ومع ذلك، في وقت تقرير Socket، لم تتم إزالة الإصدار المخترق بالكامل من npm، وظلت مواد الإصدار ذات الصلة متاحة عبر GitHub.

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

يجب على المطورين ومستخدمي المحافظ المتأثرين استبدال بيانات الاعتماد المكشوفة

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

تشمل الإجراءات الموصى بها:

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

قد لا يحمي تحديث الحزمة وحده المحفظة إذا كانت بيانات الاعتماد الخاصة بها قد نُسخت بالفعل. بمجرد حصول طرف آخر على مفتاح خاص أو عبارة استرداد، لا ينبغي اعتبار المحفظة القديمة آمنة بعد الآن. يجب على مستخدمي المحافظ أيضاً فحص الأذونات التي يوافقون عليها. في حالة منفصلة، سرق مهاجم حوالي 92,000 دولار من Tether Gold بعد أن وقع الضحية على طلب إذن خبيث، مما يظهر أن المجرمين لا يحتاجون دائماً إلى الحصول على عبارة البذور مباشرةً للاستيلاء على الأصول.

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