المفاتيح الخاصة معرضة للخطر: XRP Ledger يواجه استغلالًا خطيرًا لسلسلة التوريد

ال دفتر حسابات XRP أكدت المؤسسة اكتشاف ثغرة أمنية خطيرة في مكتبة JavaScript الرسمية الخاصة بها، xrpl.js، التي يستخدمها المطورون للتفاعل مع blockchain XRP Ledger.

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

أثرت الثغرة الأمنية بشكل خاص على الإصدارات من 4.2.1 إلى 4.2.4 من مكتبة xrpl.js وتم اكتشافها لأول مرة بواسطة Aikido في 21 أبريل في الساعة 20:53 بتوقيت جرينتش +0، بعد أن قام نظام المراقبة الخاص بها بتمييز خمس حزم مشبوهة تم نشرها في سجل NPM (Node Package Manager).

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

وأشار أكيدو إلى:

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

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

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

كانت أداة Intel الداخلية الخاصة بـ Aikido، والتي تم تصميمها لمراقبة التغييرات في مستودعات الحزم العامة مثل NPM، فعالة في اكتشاف النشاط الخبيث.

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

ومنذ ذلك الحين، أوقفت شركة Ripple استخدام الحزم المخترقة، وقامت مؤسسة XRP Ledger بإزالتها من NPM بعد فترة وجيزة من الإعلان عن المشكلة.

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

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

مؤسسة XRPL تؤكد وجود ثغرة أمنية، وتصدر إصلاحًا فوريًا

الاختراق الأخير الذي يتضمنتموج تشكل مكتبة JavaScript الرسمية الخاصة بـ Ripple تهديدًا خطيرًا لنظام XRP البيئي - خطيرًا بما يكفي لدفع المدير التقني لشركة Ripple David Schwartz إلى إصدار تحذير عام. https://

كما تحدثت مايوكا فاداري، وهي مهندسة برمجيات كبيرة في شركة ريبل، عن الجوانب الفنية للثغرة الأمنية.

في حين أن XRP Ledger نفسه لا يزال غير متأثر، فقد تم توزيع المكتبة المخترقة من خلال قنوات Ripple الرسمية، مما يعرض المستخدمين والمطورين لمخاطر كبيرة.

إن العواقب المحتملة كبيرة:تحتوي محافظ DeFi العاملة على XRPL بشكل جماعي على حوالي 80 مليون دولار من أموال المستخدمين.

وحتى جزء صغير من ذلك، إذا تم المساس به، فإنه سيمثل خسارة كبيرة.

ردًا على ذلك، أكدت مؤسسة XRP Ledger Foundation، وهي المنظمة غير الربحية التي تدير XRPL، حدوث الاختراق ونشرت إصلاحًا سريعًا.

في 22 أبريل، أصدرت المؤسسة الإصدار 4.2.5 من مكتبة xrpl.js لاستبدال الإصدارات المخترقة.

تم منذ ذلك الحين إيقاف جميع الإصدارات المتأثرة على NPM، مما أدى إلى حظر المزيد من التنزيلات.

نحث المطورين على الترقية إلى الإصدار v4.2.5 أو الرجوع إلى الإصدار v2.14.3، الذي لم يتأثر.

وقالت المؤسسة:

هذه الثغرة موجودة في xrpl.js، وهي مكتبة جافا سكريبت للتفاعل مع سجل XRP. لا تؤثر على قاعدة بيانات سجل XRP أو مستودع Github نفسه. يجب على المشاريع التي تستخدم xrpl.js الترقية إلى الإصدار 4.2.5 فورًا.

الأمر الحاسم هو أن المؤسسة لاحظت أن قاعدة الكود الأساسية لـ XRPL وجيثب لم يتم المساس بالمستودع.

سيتم إصدار تقرير تشريح كامل للجثة قريبًا.

وأكد العديد من المشاركين الرئيسيين في النظام البيئي، بما في ذلك XRPScan وFirst Ledger وGen3 Games، عدم تأثرهم.

أوضحت XRPScan أنها تستخدم إصدارًا أقدم من المكتبة لا يتعامل مع المفاتيح الخاصة، وأكدت Xaman Wallet أنها تعتمد على بنيتها التحتية الخاصة لإدارة المفاتيح.

ومع ذلك، فقد أثار الحادث محادثات أوسع نطاقا حول ممارسات التطوير الآمنة.

وأرجع مارك إيبانيز، المدير التقني لشركة Gen3 Games، نجاح فريقه في تجنب الإصدارات المخترقة إلى "قليل من الحظ" - ولكن أيضًا إلى الممارسات الجيدة.

من خلال إرسال ملف pnpm-lock.yaml الخاص بهم إلى التحكم في الإصدار، ضمنت Gen3 Games إدارة التبعيات بشكل متسق، وتجنب التحديثات غير المتوقعة.

سلطت شركة Ibanez الضوء على أفضل الممارسات مثل تجنب إصدار Caret في package.json، واستخدام Performant NPM (PNPM) عندما يكون ذلك ممكنًا، والالتزام دائمًا بملفات القفل للحفاظ على الإصدارات المتوقعة.

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

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