تحتوي منصة العقود الذكية NEAR على ثغرة كان من الممكن أن تسمح للمهاجم بتعطيل كل عقدة على الشبكة، مما يؤدي إلى إغلاقها بشكل فعال.
ووفقًا لتقرير صدر يوم ٢٦ سبتمبر من شركة Zellic لأمن البلوكتشين، والتي اكتشفتها، فقد تم القضاء على الثغرة الأمنية بهدوء من خلال التصحيح في يناير، ولكن قد لا تزال بعض الشبكات تحتوي على عيوب مماثلة.
وفي التقرير، أشار Zellic إلى الخلل باسم “Web3 Ping of Death”، نظرًا لقدرته على إسقاط شبكة بأكملها “في لحظة”.
اكتشف الباحثون ذلك أثناء التحقيق في بروتوكول شبكة نظير إلى نظير الخاص بـ NEAR لعقد التحقق من الصحة، والذي يسمح للمدققين بالتواصل بشكل فعال مع بعضهم البعض. يستخدم NEAR “آلية المصافحة” لإنشاء اتصالات بين العقد والتأكد من أن العقد لا تعمل بشكل ضار.
يرسل “النظير البعيد”، أو النظير الذي يريد الاتصال، رسالة مصافحة إلى النظير المحلي. ردًا على ذلك، يرسل النظير المحلي إقرارًا بالرسالة.
NEAR عملية اتصال نظير إلى نظير. المصدر: زيليك.
أثناء هذه العملية، يُطلب من النظير البعيد إثبات هويته من خلال توفير مفتاح عام ومن خلال التوقيع على رسالة تثبت أنه مالك هذا المفتاح العام. تهدف عملية التحقق من الهوية هذه إلى منع العقد الضارة المعروفة من الاتصال بالشبكة.
عندما نظر الباحثون إلى وظيفة التحقق من التوقيع، اكتشفوا حقيقة مثيرة للقلق. سمحت العقد بقبول نوعين من التوقيعات المشفرة.
النوع الأول، الذي يعتمد على خوارزمية التوقيع الرقمي على Twisted Edwards Curves 25519 (Ed25519)، يمكن التحقق منه بشكل آمن عن طريق العقد.
ومع ذلك، فإن محاولة التحقق من النوع الثاني، استنادًا إلى منحنى معايير التشفير الفعال Prime Field 256K1 (SECP256K1)، قد يؤدي إلى استجابة “ذعر” تؤدي إلى تعطل العقدة.
تحتوي وظيفة التحقق لهذا النوع من التوقيع المشفر على اثنتين من نقاط الضعف المختلفة. أولاً، قامت باستدعاء دالة “توقع” وطلبت ألا تحتوي الإجابة على أكثر من 32 بايت من البيانات.
ومع ذلك، لم يكن طول الإجابة التي قدمتها هذه الوظيفة 32 بايت على الإطلاق. وهذا يعني أن العقدة ستتعطل في أي وقت تحاول فيه التحقق من توقيع SECP256K1.
قسم التعليمات البرمجية NEAR الذي يحتوي على ثغرة أمنية “.expect()”. المصدر: زيليك.
ثانيًا، إذا لم يكن البايت الأخير من التوقيع بين صفر وثلاثة، فإن الوظيفة “from_i32()”، التي تم استدعاؤها كجزء من عملية التحقق، ستنتج خطأ.
قد يتسبب هذا الخطأ في توقف وظيفة “unwrap()” النهائية التي تم استدعاؤها في نهاية العملية، مما يؤدي إلى تعطل العقدة. وهذا يعني أنه حتى لو تم إصلاح الثغرة الأمنية الأولى، فيمكن للمهاجم إنشاء توقيع ضار عمدًا يمكن أن يؤدي إلى تعطل العقدة باستخدام الثغرة الأمنية الثانية.
ثغرة أمنية في وظيفة إلقاء الأخطاء في NEAR. المصدر: زيليك.
وبعد اكتشاف هذا الخلل، تفاجأ الباحثون بأنه لم يتم اكتشافه مسبقًا في الاختبارات أو أنه أدى إلى تعطل الشبكة بالفعل.
ومع ذلك، فقد وجدوا أن برنامج عقدة NEAR لا يحتوي على “مسار تعليمات برمجية يسمح لعقدة NEAR بإنشاء مفاتيح من النوع SECP256K1.” بمعنى آخر، على الرغم من أن البرنامج سمح للعقد بقبول توقيعات SECP256K، إلا أنه لم يسمح لها بإنتاج مثل هذه التوقيعات.
ونتيجة لذلك، لم تتسبب أي عقدة في تعطل الشبكة عن طريق الخطأ عن طريق إنشاء مفاتيح SECP256K ومحاولة الاتصال بعقدة أخرى.
ومع ذلك، يمكن للعقدة الضارة تغيير البرنامج للسماح بإنشاء مفاتيح SECP256K. وبمجرد قيامهم بذلك، سيكون لديهم القدرة على تعطل أي عقدة NEAR ببساطة عن طريق محاولة الاتصال بها. يمكن أن تؤدي النتيجة إلى تدمير الشبكة بالكامل، مما يشكل “Web3 Ping of Death”.
ولإثبات أن الثغرة الأمنية حقيقية، أنشأ الباحثون أولاً نسخة من برنامج NEAR تحتوي على تصحيح ضار يسمح بإنشاء مفاتيح SECP256K.
ثم أطلقوا عقدتين على نسخة شبكة اختبار خاصة من NEAR. قامت العقدة الأولى بتشغيل البرنامج الشرعي المقدم من المطورين، بينما قامت العقدة الثانية بتشغيل الإصدار الضار.
بعد أن بدأت العقدة الأولى في إنتاج الكتل، حاولت العقدة الثانية تعطل العقدة الأولى من خلال استغلال الثغرات الأمنية. ووجدوا أن العقدة الخبيثة نجحت في تحطيم العقدة الشرعية في كل مرة.
المجلة: اعتقال مريب لمراسل احتيال العملات المشفرة، ورئيس الوزراء الياباني المؤيد للعملات المشفرة: آسيا إكسبريس
كشفت Zellic سرًا عن الثغرة الأمنية لفريق NEAR في ديسمبر، باستخدام منصة HackenProof لمكافأة الأخطاء لتسهيل الكشف. ردًا على ذلك، دفع الفريق لشركة Zellic مكافأة قدرها 150 ألف دولار وقام بتصحيح برنامج العقدة في يناير.
خلال هذه الفترة الزمنية الفاصلة بين الاكتشاف والتصحيح، لم يكتشف أي مهاجم الخلل، وظلت الشبكة متصلة بالإنترنت.
وقد وفر اكتشاف الثغرة الأمنية نهاية سعيدة لما كان من الممكن أن يكون قصة أزمة.
لم تكن سلاسل الكتل الأخرى محظوظة بما يكفي لتجنب العيوب التي أدت إلى حدوث أعطال. وفي ديسمبر/كانون الأول، تعطلت شبكة Arbitrum لأكثر من 78 دقيقة، مما منع المستخدمين من إجراء أي معاملات.
متعلق ب: يؤدي انقطاع سولانا إلى رد فعل باليستي من مجتمع العملات المشفرة
كشف المطورون لاحقًا أن فترة التوقف هذه كانت بسبب زيادة في سك النقوش، والتي لم تكن الشبكة مستعدة بشكل كافٍ للتعامل معها.
وفقًا للمطورين، في شهر يناير، تعطل حوالي 50٪ من عقد كاردانو بسبب “حالة شاذة”. وقد تسبب هذا الاضطراب في تباطؤ إنتاج الكتل، مما أدى إلى زيادة أوقات تأكيد المعاملات. ومع ذلك، لم يتسبب ذلك في تعطل الشبكة بأكملها.
وفي فبراير، فشلت شبكة Solana في إنتاج كتلة لأكثر من 25 دقيقة. كان هذا هو الأحدث من بين العديد من حوادث تحطم Solana، والتي انتقدها بعض المستخدمين بشدة.
