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

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

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

هنا النص الكامل لدليل أمان النظام البيئي ل”كوزموس” 👇.

نظرة عامة على كوسموس

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

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

في قلب نظام الكون يوجد بروتوكول التواصل بين السلاسل الفرعية (IBC)، الذي يربط التطبيقات والبروتوكولات عبر سلاسل كتلية مستقلة مختلفة. يسهل هذا ليس فقط نقل الأصول والبيانات بسلاسة ولكنه يتماشى أيضًا مع رؤية Cosmos لخلق 'إنترنت من السلاسل'. تتصور هذه الفكرة شبكة واسعة من السلاسل الفرعية المستقلة والتي يمكن تطويرها بسهولة، متصلة بغرض التوسع والتفاعل.

المشاركة والبحث الخاص بـ CertiK في أمان كوزموس

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

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

الخلفية

CometBFT: تعزيز قابلية التوسع عبر السلاسل الجانبية في جوهرها

في قلب توسيع التكامل بين السلاسل يكمن CometBFT، وهو خوارزمية اتفاقية حديثة تعتبر جزءًا أساسيًا لضمان أمان ولامركزية ونزاهة النظام البيئي بين السلاسل. تتألف هذه الخوارزمية من عنصرين أساسيين: نواة CometBFT الأساسية، التي تعمل كمحرك اتفاقية أساسي، وواجهة سلسلة كتل تطبيقية عالمية (ABCI). من خلال دمج عناصر من PBFT (التحمل العملي للخطأ البيزنطي) وBonded Proof of Stake (PoS)، يزامن CometBFT العقد للحفاظ على سجلات المعاملات الدقيقة، وبالتالي يلعب دورًا حيويًا في اتفاق العقداء داخل بيئة السلاسل المتقاطعة.

SDK كوزموس: تسريع تطوير البلوكشين باستخدام القابلية للتوسيع

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

بروتوكول IBC: دفع التوافق والقابلية للتطوير عبر البلوكشين

بروتوكول التواصل بين البلوكشينات (IBC) أمر حيوي في تيسير نقل البيانات بطريقة آمنة ولامركزية وغير مشروط بين البلوكشينات داخل شبكة Cosmos. نظرًا لأن Cosmos هي شبكة لامركزية تتألف من عدة بلوكشينات مستقلة ومتوازية متصلة من خلال تكنولوجيا الريلي، فإن دور بروتوكول IBC في تعزيز قابلية التوسع والتوافق المركزي. تركز مؤسسة Interchain حاليًا على تحسين هذه الجوانب من بروتوكول IBC، بهدف تعزيز التفاعلات السلسة عبر البلوكشينات والتطبيقات والعقود الذكية داخل النظام البيئي Cosmos.

CosmWasm: تيسير نشر التطبيقات اللامركزية

CosmWasm (Cosmos WebAssembly) هو إطار عقد ذكي مصمم خصيصًا لنظام الكوزموس. استنادًا إلى WebAssembly ، يتيح للمطورين نشر التطبيقات اللامركزية دون الحاجة إلى أذونات محددة. يتيح هذا الإطار لمطوري البلوكشين فصل تطوير المنتج عن تطوير البلوكشين ، مما يقلل من العبء المترتب على ترقيات المحقق. تشمل ميزات CosmWasm البنية المعمارية القابلة للتوسيع ، والتكامل مع Cosmos SDK ، وقدرات الاتصال عبر السلاسل. يتم استخدام Cosmos SDK وبروتوكول IBC ، كونهما نسبيا ناضجين ، على نطاق واسع في نظام الكوزموس الحالي.

التكيف والتخصيص داخل نظام الكون

بالنسبة لمطوري السلاسل في نظام الكوزموس، يفي كوزموس SDK بمعظم الاحتياجات للتخصيص. خلال الأنشطة العابرة للسلاسل، قد يقوم مطورو السلاسل بتخصيص وحدات IBC الخاصة بهم للعمليات الخاصة أو تحسين الأداء. بينما قد يقوم بعض السلاسل بتعديل محركات الأساسية مثل CometBFT Core، تعترض القيود المكانية مناقشة مفصلة لمثل هذه التعديلات في هذا التقرير. لذلك، يركز هذا البحث في المقام الأول على التفاصيل الفنية والاعتبارات الأمنية لـ Cosmos SDK وبروتوكول IBC.

دليل أمان Cosmos SDK

يقدم دليل أمان Cosmos SDK نظرة شاملة على الجوانب الأمنية لـ Cosmos SDK، وهو إطار متقدم لتطوير تطبيقات البلوكشين والبروتوكولات اللامركزية. تم إنشاؤه بواسطة مؤسسة Interchain، ويعتبر هذا الإطار حاسمًا لشبكة Cosmos، وهي شبكة متشعبة من البلوكشينات المتصلة.

في جوهرها ، تم تصميم Cosmos SDK لتبسيط إنشاء تطبيقات blockchain المخصصة مع تسهيل التفاعل السلس بين سلاسل الكتل المتنوعة. تشمل ميزاته البارزة هيكلا معياريا ، وقابلية تخصيص واسعة النطاق ، والتكامل مع CometBFT Core من أجل الإجماع ، وتنفيذ واجهات IBC ، وكلها تساهم في جاذبيتها للمطورين. تتمثل إحدى نقاط القوة الرئيسية ل Cosmos SDK في اعتمادها على محرك إجماع CometBFT Core ، والذي يوفر تدابير أمنية قوية. يلعب هذا المحرك دورا حيويا في الدفاع عن الشبكة ضد الهجمات الضارة وفي حماية أصول وبيانات المستخدمين. تمكن الطبيعة المعيارية ل SDK المستخدمين من صياغة وحدات مخصصة بسهولة. ومع ذلك ، يجب على المطورين توخي الحذر حيث لا يزال من الممكن ظهور الثغرات الأمنية عند نشر التطبيقات باستخدام Cosmos SDK.

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

نقطة تركيز داخل واجهة برمجة تطبيقات Cosmos SDK هي واجهة ABCI، التي تعتبر جزءًا أساسيًا من النظام البيئي لـ Cosmos. تتألف هذه الواجهة من أربع مكونات رئيسية: BeginBlock، EndBlock، CheckTx، و DeliverTx. تشارك BeginBlock و EndBlock مباشرة في منطق تنفيذ الكتل الفردية. بينما تهتم CheckTx و DeliverTx بمعالجة sdk.Msg، الهيكل البياني الأساسي لنقل الرسائل داخل النظام البيئي لـ Cosmos.

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

في Cosmos SDK، يعد دورة حياة المعاملة عملية متعددة المراحل، تشمل الإنشاء، والتحقق، والإدراج في كتلة، وتغييرات الحالة، والتزام نهائي. يمكن توضيح هذه العملية في الخطوات التالية:

1. إنشاء المعاملة: يقوم المستخدمون بإنشاء المعاملات باستخدام أدوات متنوعة مثل واجهات سطر الأوامر (CLI) أو عملاء واجهة المستخدم الأمامية.

2. إضافة إلى Mempool: بمجرد إنشائها، تدخل المعاملات إلى mempool. هنا، ترسل العقد (Application BlockChain Interface) رسالة ABCI، المعروفة باسم CheckTx، إلى طبقة التطبيق لفحص الصحة. تتعرض المعاملات لفك تشفيرها من تنسيق البايت إلى تنسيق Tx. يتم تعريض كل sdk.Msg داخل المعاملة لفحوصات مبدئية بدون حالة بواسطة وظيفة ValidateBasic(). بالإضافة إلى ذلك، إذا كان التطبيق يشمل anteHandler، يتم تنفيذ منطقه قبل وظيفة runTx، مما يؤدي إلى وظيفة RunMsgs() لمعالجة محتوى sdk.Msg. ينتج النجاح في CheckTx عن وضع المعاملة في طابور الانتظار في mempool المحلي، مستعدة للإدراج في الكتلة التالية، وفي نفس الوقت يتم بثها للعقداء عبر P2P.

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

4. تغييرات الحالة: على غرار CheckTx ، يتكرر عملية DeliverTx من خلال معاملات الكتلة. ومع ذلك، يعمل في وضع 'التوصيل'، حيث يقوم بتنفيذ تغييرات الحالة. يوجه MsgServiceRouter رسائل المعاملات المختلفة إلى الوحدات النمطية المعنية، حيث يتم معالجة كل رسالة في الخادم Msg. بعد تنفيذ الرسالة، تضمن فحوصات إضافية صحة المعاملة. إذا فشل أي فحص، يتم إعادة الحالة إلى حالتها السابقة. يتتبع عداد الغاز الغاز المستهلك أثناء التنفيذ. أخطاء ذات صلة بالغاز، مثل الغاز غير الكافي، تؤدي إلى عكس تغييرات الحالة، مشابهة لفشل التنفيذ.

5. التزام الكتلة: بمجرد تلقي عدد كافٍ من أصوات المحققين، يقوم العقد بتأكيد الكتلة الجديدة إلى سلسلة الكتل. يؤدي هذا الإجراء إلى إنهاء عمليات الانتقال في طبقة التطبيق، مما يدل على اكتمال عملية العملية التجارية.

)

[تتضمن هذه القسم رسمًا توضيحيًا يصور دورة حياة المعاملات في نظام الكوسموس.]

[القسم التالي يوفر منطق التنفيذ المحدد لمفتاح ABCI في Cosmos SDK، مفيد لفهم وتحليل الثغرات المناقشة لاحقاً.]

)

فئات الضعف الشائعة

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

)

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

1. عملية إيقاف السلسلة
2. خسارة مالية
3. يؤثر على حالة النظام أو العملية الطبيعية

أسباب هذه المخاطر هي غالبًا ما تكون أنواع الثغرات الأمنية التالية:

1. رفض الخدمة
2. إعدادات الحالة غير صحيحة
3. نقص أو تحقق غير معقول
4. قضايا الفرادة
5. مشاكل خوارزمية التوافق
6. العيوب المنطقية في التنفيذ
7. قضايا ميزات اللغة

تحليل الضعف في النظام البيئي لكوسموس

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

عملية توقف السلسلة: الأسباب والأنواع

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

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

لا يتم استخدام Cosmos SDK و CometBFT ، البنى التحتية الرئيسية في النظام البيئي Cosmos ، فقط من قبل السلاسل الأساسية في Cosmos ولكن أيضا من قبل سلاسل التطبيقات المختلفة بناء على بنيتها. كلهم يتبعون قواعد واجهة ABCI الخاصة ب CometBFT. ينصب تركيز سطح الهجوم الخاص بهم أيضا على واجهة ABCI الخاصة بهم ، ومعظم الثغرات الأمنية التي يمكن أن تسبب توقف السلسلة هي مشكلات يمكن أن تؤثر بشكل مباشر على تنفيذ التعليمات البرمجية للكتلة. لذلك ، يمكن تتبع مسارات حدوثها بشكل عام إلى واجهات BeginBlock و EndBlock.

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

أمثلة من النوع الأول

مثال 1: تحليل الضعف في مشروع SuperNova

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

موقع الضعف: رابط مستودع SuperNova في جيتهاب

مقتطف الكود الضعيف:

مسار تشغيل الضعف:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

تصحيح الثغرة:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

يوجد التصحيح في وحدة معالجة الرسائل الخاصة ب poolincentive (x / poolincentive / types / msgs.go) ، وليس وحدة النعناع. وأضاف التحقق من العنوان إلى رسالة MsgCreateCandidatePool للقضاء على إمكانية عناوين غير صحيحة من الجذر.

مثال 2: مشروع أمان الشبكة بين الشمسين

عنوان المشروع: رابط GitHub لأمان تفاعل قطاعات Cosmos

خلفية الثغرة الأمنية: يمكن للمدققين إبطاء سلسلة الموفر عن طريق إرسال رسائل AssignConsumerKey متعددة في نفس الكتلة. في ملف x/ccv/provider/keeper/key_assignment.go، تسمح وظيفة AssignConsumerKey للمدققين بتعيين مفاتيح مستهلك مختلفة لسلاسل المستهلكين المعتمدة. يزيد المستهلك AddrsToPrune قائمة العناوين بمقدار عنصر واحد لتنفيذ هذه العملية. نظرا لأن قائمة العناوين هذه مكررة في EndBlocker في x / ccv / provider / keeper / relay.go ، يمكن للمهاجمين استغلالها لإبطاء سلسلة الموفر. بالنسبة لهذا الهجوم ، يمكن للممثل الضار إنشاء معاملات باستخدام رسائل AssignConsumerKey متعددة وإرسالها إلى سلسلة الموفر. ستكون العلاقة الأساسية للمستهلكAddrsToPrune AddressList هي نفسها رسائل AssignConsumerKey المرسلة. لذلك ، سيستغرق تنفيذ EndBlocker وقتا وموارد أكثر مما كان متوقعا ، مما يؤدي إلى إبطاء أو حتى إيقاف سلسلة الموفر.

موقع الضعف: رابط GitHub لأمان Cosmos Interchain

قطاع رمز الثغرة:

مسار تشغيل الضعف:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

اند بلوك سي آي اس

HandleLeadingVSCMaturedPackets

HandleVSCMaturedPacket

تخصيص مفاتيح التقليم

مثال 3: مشروع كويكسيلفر - وحدة الإسقاط الجوي

الخلفية الضعيفة: يعتبر BeginBlocker و EndBlocker طرقًا اختيارية يمكن لمطوري الوحدة تنفيذها في وحدتهم. يتم تشغيلهما في بداية ونهاية كل كتلة على التوالي. قد يؤدي استخدام تعطلات للتعامل مع الأخطاء في طرق BeginBlock و EndBlock إلى توقف السلسلة في حالة وجود أخطاء. لم ينظر EndBlocker في ما إذا كانت لدى الوحدة عملات مشفرة كافية لتسوية الأوقاف غير المكتملة، مما قد يؤدي إلى تعطل وتوقف السلسلة.

موقع الضعف: رابط GitHub لـ Quicksilver

قطاع رمز الضعف:

تصحيح الثغرة: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

تصحيح الثغرة: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

تمت إزالة رمز معالجة الذعر واستبداله بتسجيل الأخطاء.

مثال 4: مشروع أمان تبادلات Cosmos

عنوان المشروع: رابط GitHub لأمان السلسلة الفائقة

خلفية الثغرة الأمنية: يمكن للمهاجمين تنفيذ هجوم رفض الخدمة عن طريق إرسال رموز مميزة متعددة إلى عنوان المكافأة لسلسلة الموفر. في تدفق تنفيذ EndBlocker لسلسلة المستهلكين، تقوم وظيفة SendRewardsToProvider المحددة في x/ccv/consumer/keeper/distribution.go باسترداد رصيد جميع الرموز المميزة في tstProviderAddr وإرسالها إلى سلسلة الموفر. لتحقيق ذلك ، يجب أن يكرر من خلال جميع الرموز الموجودة في عنوان المكافأة وإرسال كل واحد عبر IBC إلى سلسلة الموفر. نظرا لأنه يمكن لأي شخص إرسال الرموز المميزة إلى عنوان المكافأة ، يمكن للمهاجمين إنشاء وإرسال عدد كبير من الرموز المميزة المختلفة ، على سبيل المثال ، باستخدام سلسلة مع وحدة مصنع رمزية ، لبدء هجوم رفض الخدمة. لذلك ، سيستغرق تنفيذ EndBlocker وقتا وموارد أكثر مما كان متوقعا ، مما يؤدي إلى إبطاء أو حتى إيقاف سلسلة المستهلك.

موقع الضعف: رابط GitHub لأمان تبادل Cosmos Interchain

قطعة رمز الثغرة:

مسار تشغيل الضعف:

AppModule.EndBlock

نهاية الكتلة

انتهاء كتلة الطريق

إرسال المكافآت إلى مقدم الخدمة

النوع الثاني من الوضع

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

مثال 1

الخلفية الخاصة بالضعف: توصية أمان Cosmos SDK Jackfruit

السلوك غير القطعي في طريقة ValidateBasic الخاصة بوحدة x/authz في Cosmos SDK يمكن أن يؤدي بسهولة إلى توقف التوافق. تتضمن هيكل رسالة MsgGrant في وحدة x/authz حقل Grant، الذي يحتوي على وقت الانتهاء الممنوح من قبل الترخيص المحدد بواسطة المستخدم. خلال عملية التحقق من صحة ValidateBasic() في هيكل Grant، يقارن معلومات الوقت الخاصة به مع معلومات الوقت المحلي للعقدة بدلاً من معلومات وقت البلوك. نظرًا لأن الوقت المحلي غير القطعي، قد تختلف الطوابع الزمنية بين العقد، مما يؤدي إلى قضايا التوافق.

إعلان الضعف:

• رابط منتدى كوسموس 1

• رابط منتدى Cosmos 2

• رابط التنبيه الأمني لـ Cosmos SDK على GitHub

جزء رمز الضعف:

تصحيح الثغرة: رابط مقارنة GitHub لـ Cosmos SDK

القضايا مثل الطوابع الزمنية لا تظهر فقط في المكونات الأساسية مثل Cosmos SDK ولكن أيضًا قد حدثت في سلاسل التطبيقات المختلفة.

مثال 2

الخلفية الضعيفة: SuperNova، مشروع نوفا

عنوان المشروع: رابط SuperNova على GitHub

استخدام time.Now() يعيد البصمة الزمنية لنظام التشغيل. الوقت المحلي هو غير موضوعي وبالتالي غير قطعي. نظرًا لأنه قد تكون هناك اختلافات طفيفة في البصمات الزمنية للعقد الفردية، قد لا تصل السلسلة إلى توافق. في وحدة ICAControl، يستخدم وظيفة إرسال المعاملة وقت time.Now() للحصول على البصمة الزمنية.

موقع الضعف: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

قطاع رمز الضعف:

تصحيح الثغرة:

تم التغيير من استخدام الطابع الزمني المحلي إلى استخدام وقت الكتلة.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)

الحالة الثالثة:

خلفية الضعف: وحدة أوراكل في مشروع BandChain

Project URL: مستودع باندتشين على جيتهاب

تشير التعليقات في مستودع الكود إلى أنه يجب تنفيذ وحدة الأوراقل قبل الرهان لتنفيذ إجراءات العقوبة لمخالفي بروتوكول الأوراقل. ومع ذلك، في الكود، يتم عكس التسلسل: في وظيفة SetOrderEndBlockers، تعمل وحدة الرهان قبل وحدة الأوراقل. إذا تم تنفيذ وحدة الرهان قبل وحدة الأوراقل، سيكون من المستحيل فرض العقوبات بناءً على التحققات المكتملة في وحدة الأوراقل.

موقع الضعف: كود مقتطف من GitHub لـ BandChain

قطاع رمز الثغرة:

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

الحالة الرابعة:

الخلفية الضعيفة: وحدة التحكم في الوصول في مشروع Sei Cosmos

Project URL: مستودع Sei Cosmos GitHub

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

في تنفيذ BuildDependencyDag في x/accesscontrol/keeper/keeper.go، هناك تكرار عبر عقدة anteDepSet. بسبب السلوك غير التحديدية لتكرار الخريطة في Go، يمكن أن يؤدي ValidateAccessOp إلى نوعين مختلفين من الأخطاء، مما قد يؤدي في نهاية المطاف إلى فشل التوافق.

الموقع الضعيف: كود مقتطف من سي كوسموس جيتهاب

قطعة كود الضعف:

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

فقدان الأموال

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

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

هنا، نأخذ مشروع SuperNova كمثال لتحليل ثلاث ثغرات ذات صلة.

الخلفية الضعيفة: مشروع SuperNova

Project URL: https://github.com/Carina-labs/nova

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

موقع الضعف: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

جزء الشفرة الضعيف:

مسار تشغيل الثغرة الأمنية:

msgServer.طالبSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

مضاعف الدقة

• الخلفية الضعيفة: مشروع SuperNova

عنوان المشروع: https://github.com/Carina-labs/nova/

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

موقع الضعف: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

قطعة الكود الضعيفة:

تصحيح الخلل: تمت إضافة فحص DenomDuplicateCheck

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

• الخلفية الضعيفة: مشروع سوبرنوفا

عنوان المشروع: https://github.com/Carina-labs/nova/

تحديثات الحالة المفقودة. في طريقة IcaWithdraw()، إذا فشلت المعاملة ولم يتم تعديل حالة الإصدار، ستكون WithdrawRecord غير قابلة للوصول ولا يمكن سحب الأموال المقابلة. التفسير الأكثر شيوعًا هو أن يتم تعيين الحالة قبل SendTx، وأنه لا يتم تعديل الحالة بعد الفشل، مما يتسبب في فشل سحب الأموال وعدم إمكانية سحبها مرة أخرى في المرة القادمة.

موقع الضعف: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

مقطع الكود الضعيف:

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

التأثير على حالة النظام أو العملية العادية

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

- عدم استكمال التحقق من المتغير في نوع sdk.Msg:

نظرًا لأن مشاريع مختلفة قامت بتنفيذ مجموعة متنوعة من أنواع المشتقات بناءً على sdk.Msg، لم يتم التحقق من عناصر جميع أنواع العناصر الحالية وفقًا لـ Cosmos SDK. وقد أدى ذلك إلى إغفال التحقق من العناصر المتغيرة المضمنة الحرجة، مما يشكل بذلك بعض المخاطر الأمنية.

دراسة الحالة: إشعار أمان Cosmos SDK Barberry

الخلفية الضعيفة: يفتقر MsgCreatePeriodicVestingAccount.ValidateBasic إلى آليات لتقييم حالة الحساب، مثل ما إذا كان نشطًا. في PeriodicVestingAccount المحددة x/auth، يمكن للمهاجم تهيئة حساب الضحية ليكون حسابًا تمتلكه بشكل خبيث. يسمح هذا الحساب بالإيداعات ولكنه يمنع السحب. عندما يقوم المستخدمون بإيداع الأموال في حسابهم، ستتم قفل هذه الأموال بشكل دائم، ولن يتمكن المستخدم من سحبها.

تصحيح الثغرة:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

مقتطف الكود الضعيف:

بالإضافة إلى ذلك، كانت هناك أيضًا مشاكل في مرحلة التحقق الأساسية في Cosmos-SDK Security Advisory Elderflower و Cosmos-SDK Security Advisory Jackfruit. فقد عانى الأول من حذف مباشر لمكالمة ValidateBasic، بينما تضمن الثاني مشاكل في التحقق من متغير الطابع الزمني داخل الرسالة. في سلاسل التطبيقات، مثل ethermint و pstake-native و quicksilver، هذه المشاكل أكثر انتشارًا حتى. لقد واجهت جميعها ثغرات أمان مماثلة في إجراءات التحقق من معالجة الرسائل.

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

أنواع الضعف الشائعة

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

قضايا الفرادة

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

قضايا ميزة اللغة

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

ملخص

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

• كن حذرًا من ثغرات البنية التحتية: قد تكون المكونات الأساسية مثل CometBFT وCosmos SDK لديها ثغرات أيضًا، لذا فإن التحديثات المنتظمة والصيانة ضرورية للأمان.

• قم بمراجعة المكتبات الخارجية بسرعة: غالبًا ما يستخدم مطورو Cosmos مكتبات خارجية لتوسيع وظائف تطبيقاتهم. قد تحتوي هذه المكتبات على ثغرات بالأمان، مما يتطلب مراجعتها وتحديثها للحد من المخاطر.

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

• النظر في الأمان الفيزيائي: تتطلب تدابير الأمان الفيزيائي للأجهزة والخوادم التي تعمل كعقد كوكموس لمنع الوصول غير المصرح به والهجمات المحتملة.

• إجراء استعراضات الشفرة اللازمة: نظرًا لانفتاح بيئتي تطوير Cosmos SDK وCometBFT، يجب على المطورين والمراجعين مراجعة الشفرة الأساسية والشفرة المكتوبة في الوحدات المخصصة لتحديد وتصحيح المشاكل الأمنية المحتملة.

• Pay attention to ecosystem tools: يتضمن نظام الكوزموس العديد من الأدوات والتطبيقات، التي تحتاج أيضًا إلى خضوع لمراجعات الأمان والتحديثات الدورية لضمان سلامتها.

دليل أمان بروتوكول IBC

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

منذ ظهور بيتكوين، شهدت مجال البلوكشين نموًا متفجرًا. ظهرت شبكات جديدة لا تُحصى، كل منها لها مقترح قيمة فريد، وآليات توافقية، وأيديولوجيات، وداعمون، وأسباب للوجود. قبل تقديم IBC، كانت هذه البلوكشينات تعمل بشكل مستقل، مثلما في حاويات مغلقة، غير قادرة على التواصل مع بعضها البعض، نموذج غير مستدام بشكل جوهري.

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

إذا، كيف تلبي IBC هذه الاحتياجات وتلعب دورًا مهمًا؟ الأسباب الأساسية هي أن IBC هي:

1. الحد الأدنى للثقة

2. قادرة على دعم سلاسل كتل متنوعة

3. قابل للتخصيص عند مستوى التطبيق

4. تقنية ناضجة ومجربة

تكمن أساسيات بروتوكول IBC في العملاء الخفيفين والمرسلين. تمتلك كل من سلاسل A و B التواصل من خلال IBC عملاءً خفيفين لدفتر أستاذ الآخر. يمكن لسلسلة A، دون الحاجة إلى الثقة في طرف ثالث، التوصل إلى توافق حول حالة سلسلة B من خلال التحقق من رؤوس كتلها. تتفاعل السلاسل من خلال IBC (خاصة الوحدات) لا ترسل رسائل مباشرة إلى بعضها البعض. بدلاً من ذلك، تزامن سلسلة A بعض الرسائل المعينة في حزمة بيانات مع حالتها. بعد ذلك، يكتشف المرسلون هذه الحزمات البيانية وينقلونها إلى السلسلة الهدف.

بشكل عام، يمكن تقسيم بروتوكول IBC إلى طبقتين: IBC TAO و IBC APP.

• IBC TAO: يحدد المعايير لنقل حزم البيانات والمصادقة والترتيب، أساسا الطبقة الأساسية. في ICS (معايير السلاسل الفرعية)، يتكون ذلك من فئات النواة والعميل والمعادل.

• تطبيق IBC: يحدد المعايير لمعالجي التطبيقات لحزم البيانات التي تم نقلها من خلال طبقة النقل. وتشمل هذه، دون حصر، تحويلات الرموز القابلة للتبادل (ICS-20)، وتحويلات الرموز غير القابلة للتبادل (ICS-721)، وحسابات السلاسل الفرعية (ICS-27)، ويمكن العثور عليها في فئة التطبيق لـ ICS.

بروتوكول IBC (من بوابة المطورين في Cosmos)

يعد بروتوكول IBC (Inter-Blockchain Communication) حجر الزاوية في رؤية النظام البيئي Cosmos ل "إنترنت Blockchains". في هذا السياق ، تتأثر خيارات تصميم IBC بمعايير TCP / IP. على غرار الطريقة التي يضع بها TCP / IP معايير اتصالات الكمبيوتر ، تحدد IBC مجموعة من التجريدات العالمية التي تمكن سلاسل الكتل من التواصل مع بعضها البعض. مثلما لا يقيد TCP / IP محتوى حزم البيانات التي يتم ترحيلها عبر الشبكة ، تعمل IBC بنفس الطريقة. علاوة على ذلك ، على غرار كيفية بناء بروتوكولات التطبيقات مثل HTTP و SMTP فوق TCP / IP ، فإن التطبيقات مثل عمليات نقل الأصول / الأصول غير القابلة للاستبدال المتجانسة أو مكالمات العقود الذكية عبر السلسلة تستخدم أيضا بروتوكول IBC كطبقة أساسية.

القضايا الرئيسية المرئية حاليًا في بروتوكول IBC تتعلق بنقل القناة ومعالجة الحزم. كانت هناك مشاكل كبيرة في التحقق من البرهان، لكن هذه الحالات نادرة نسبيًا. يركز هذا المقال على القضايا الشائعة في بروتوكول IBC. بفضل التصميم القابل للتوسيع لبروتوكول IBC، لا يحتاج مطورو تطبيقات IBC إلى القلق بشأن التفاصيل الأساسية مثل العملاء والاتصالات والتحقق من البرهان. ومع ذلك، يجب عليهم تنفيذ واجهة IBCModule وطرق معالجة Keeper المقابلة. وبالتالي، تنشأ العديد من المشاكل المتعلقة ببروتوكول IBC في مسارات الكود لواجهات IBCModule لاستقبال ومعالجة الحزم (onRecvPacket، OnAcknowledgementPacket، OnTimeoutPacket، إلخ).

تصنيفات الضعف الشائعة

في نظام الكون، تعمل بروتوكول IBC كمحور اتصال. أنواع الثغرات المرتبطة ببروتوكول IBC متنوعة ومعقدة بسبب التكامل الوثيق لتنفيذاته مع وحدات مثل Cosmos-SDK و CometBFT. بالإضافة إلى ذلك، نظرًا لأن IBC يُستخدم في الأساس في نظام الكون، فإن لغة البرمجة الرئيسية له هي Golang، كما هو موضح في وثائق ibc-go.

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

تصنيفات الثغرات الشائعة:

1. تسمية الضعف

   ① ثغرات معالجة السلاسل

   (2) معالجة الثغرات الأمنية في معالجة الرمز الثانوي

2. تعرض عملية النقل للضعف

   ① ثغرات أمر الحزمة

   ٢ ثغرات في مهلة الحزمة

   ③ ثغرات المصادقة الخاصة بالحزمة

   ④ الثغرات الأخرى في الحزمة

3. الثغرات المنطقية

   ① تحديثات حالة الضعف

   ② الاقتراع وثغرات التوافق

   ③ الثغرات المنطقية الأخرى

4. ثغرات استهلاك الغاز

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

تحليل الضعف

صياغة بروتوكول IBC

دراسة حالة 1: بروتوكول ICS-07، الضعف المنطقي

الخلفية الضعيفة: استخدام غير صحيح لفترة الربط

في الشفرة، يوجد التحقق التالي:

إذا كان الوقت الحالي.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

وفقًا لنموذج أمان Tendermint، لكتلة (رأس) في الوقت t، يجب على المحققين في NextValidators أن يعملوا بشكل صحيح قبل t+TrustingPeriod. بعد ذلك، قد يظهرون سلوكًا آخر. ومع ذلك، يتم التحقق هنا من UnbondingPeriod، وليس من TrustingPeriod، حيث UnbondingPeriod > TrustingPeriod. إذا كانت الموعد النهائي لـ consState بين TrustingPeriod و UnbondingPeriod، فسيتم قبول هذا الرأس كمعيار للتحقق من أحد الرؤوس المتعارضة التي تشكل السلوك غير اللائق. خلال هذه الفترة، لم يعد محققو consState.NextValidators يُعتبرون موثوقين، ويمكن للمحققين السابقين العدائين إيقاف تشغيل العميل دون أي مخاطر.

عنوان المشروع: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

موقع الضعف:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

مقتطف الشيفرة الضعيفة:

وظيفة تعريف البروتوكول

الشفرة

تنفيذ بروتوكول IBC

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

1. الغموض والقضايا غير القياسية في تنفيذ البروتوكول.

2. أخطاء في إعدادات البروتوكول.

الغموض والقضايا غير القياسية في تنفيذ البروتوكول

دراسة الحالة 1: بروتوكول ICS-20، ثغرة في التسمية

الخلفية الضعيفة: تعارض العنوان التعاقدي. احصل_على_عنوان_الضمانتولد وظيفة SHA256 المقتصرة على 20 بايتًا (معرف المنفذ + معرف القناة). لهذه الطريقة ثلاث مشاكل:

1. نقص في فصل النطاق بين المنافذ والقنوات. طريقة ربط السلاسل لا تقسم نطاقات المنفذ والقناة. على سبيل المثال، ستؤدي تجميعات المنفذ/القناة ("نقل"، "قناة") و ("ترانس"، "فيرتشانيل") إلى نفس عنوان الوصاية، أي SHA256 المقطوع ("نقلفيرتشانيل"). إذا سُمح لبعض الوحدات بوظائف المكتبة باختيار معرفات المنفذ والقناة، فقد تنشأ ثغرات.

2. التعارضات بين عناوين حساب الوحدة النمطية. يتم استخدام السلاسل الأبجدية الرقمية التعسفية في الصورة المسبقة ل SHA-256 ، بحجم ما بعد الصورة 160 بت. هذه الصورة الصغيرة المدمجة مع وظيفة التجزئة السريعة تجعل هجوم عيد الميلاد ممكنا ، حيث يتم تقليل أمانها إلى 80 بت فقط. هذا يعني أن هناك حاجة إلى ما يقرب من 2 ^ 80 تخمينا للعثور على تصادم بين عنوانين مختلفين لحساب الوصاية. في عام 2018 ، تم إجراء تحليل مفصل للتكلفة لمهاجمة اقتطاع SHA256 في سياق Tendermint ، مما يثبت أن مثل هذا الهجوم ممكن من منظور التكلفة. يعني العثور على تضارب أن حسابي احتجاز مختلفين يتم تعيينهما إلى نفس عنوان الحساب. وقد يؤدي ذلك إلى مخاطر سرقة الأموال من حسابات الحفظ. لمزيد من التفاصيل، راجع تداخل مجال الصورة المسبقة ICS20 GetEscrowAddress مع المفاتيح العامةT:BUG.

3. الصراعات بين عناوين الحسابات ذات الوحدات وغير الوحدات. بناء العناوين العامة للحسابات هو نفسه كـ 20 بايت SHA-256 لمفاتيح Ed25519 العامة. على الرغم من أن الأمان 160 بت كافٍ لمنع هجمات التصادم على العناوين العامة المحددة، إلا أن الأمان ضد هجمات عيد الميلاد يبلغ 80 بت فقط. هذا الوضع مشابه لوضع هجوم شبه عيد الميلاد، حيث يتم إنشاء عنوان واحد بواسطة SHA-256 السريع، والعنوان الآخر يتم إنشاؤه بواسطة حسابات مفتاح Ed25519 البطيئة نسبيًا. على الرغم من أن هذا الوضع أكثر أمانًا، إلا أنه لا يزال يشكل هجمات محتملة على الحسابات الوديعة والعامة.

عنوان المشروع: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

موقع الضعف: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

مقتطف شفرة ضعيف:

مشكلة في إعداد البروتوكول

• الحالة 1: توجيه أمان IBC دراجون بيري، ثغرة في عملية النقل

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

1. الوضع الطبيعي: النجاح في الوقت المحدد

2. حالة فشل المهلة: فشل المهلة

رسم بياني لتدفق نقل حزمة طلب تطبيق IBC

عندما يحدث خطأ في الوقت المحدد، يعني أن عملية الإرسال فشلت، وسيقوم بروتوكول IBC ببدء عملية استرداد. يجب ملاحظة أن IBC يحتوي على آلية مهلة قابلة للتكوين من قبل المستخدم. ينشأ ثغرة Dragonberry من ICS-23 (IBC). السبب الجذري لهذه الثغرة هو أن المستخدمين يمكنهم تزوير دلائل عدم الوجود في عملية التحقق (أي تزوير دلائل كاذبة على عدم تلقي حزم البيانات)، وبالتالي تجاوز عمليات التحقق الأمنية وتزوير الوضع المعقول للمهلة في IBC يتم استخدامه لخداع بروتوكول IBC، مما يؤدي إلى إرسال مكرر الحزم بشهادات كاذبة، وقد يتصاعد إلى مشكلة الإنفاق المزدوج ICS-20. يمكن رؤية عملية تشغيل الثغرة المحددة في الشكل أدناه.

مخطط تدفق مبدأ ثغرة التوت الأحمر

عنوان المشروع: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

موقع الضعف: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

كود نصي معرض للثغرات:

• الحالة 2: تنبيه أمان IBC هاكلبيري، ثغرة في عملية النقل

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

خطورة هذه المشكلة يمكن أن تكون طفيفة لأن القناة التي يتم نقلها بواسطة ICS-20 FT في معظم الأحيان غير مرتبة والمكرر لا يعتمد على هذه النقطة النهائية grpc لتحديد أي حزم يسبب انتهاء المهلة. ومع ذلك، إذا كان هناك عدد كبير من الحزم في سلسلة الهدف، وتم تكوين القناة المرتبة لنقل IBC، ولم يتم تجزئة استجابة grpc، فإن هذا سيخلق خطر تدهور أداء عقد الخدمة أو حتى تعطله. يمكن رؤية العملية المحفزة بشكل محدد في الشكل أدناه.

مبدأ تدفق مبدأ الضعف هاكلبيري

عنوان المشروع: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

موقع الضعف: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

مقتطف الكود الضعيف:

تطبيق وتوسيع بروتوكول IBC

• الحالة 1: ثغرة في توزيع الهواء، ثغرة منطقية

الخلفية الضعيفة: الوظيفة TryUpdateAirdropClaimيحول عنوان المُرسِل لحزمة IBC إلى عنوان Stride يُسمىsenderStrideAddress، ويستخرجairdropIdوعنوان الهبوط الجوي الجديدعنوان جديد للخطوةمن بيانات التعبئة. ثم يقوم بالاتصالتحديث عنوان الإسقاط الجويلتحديثالمرسلعنوانوسجل المطالبةمع تحديثسجل المطالبة, newStrideAddressستتمكن من المطالبة بالتوزيع الجوائي. ومع ذلك، تحقق هذه الوظيفة التحديثية فقط مما إذا كان عنوان المرسل للطلب فارغًا، ولا تقوم بالتحقق منعنوان newStride. نظرًا لأن IBC يسمح باتصالات الجهاز المنفرد لتنفيذ سلاسل تمكين IBC، فإن هذا يشكل خطرًا أمنيًا حيث يمكن تحديث أي عنوان حساب آخر كعنوان للتوزيع الجوي.

عنوان المشروع: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

موقع الضعف: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

كود قابل للاختراق:

• الحالة 2: ثغرة وحدة neutron ibc، ثغرة استهلاك الغاز

خلفية الضعف: في سياق العقود الذكية ، هناك مشكلة في كيفية التحقق من الرسوم لتأكيد أو توقيت أحداث IBC (Inter-Blockchain Communication). يسمح هذا الخلل للعقود الذكية الخبيثة بإطلاق تحطم "ErrorOutOfGas". يحدث هذا التعطل أثناء معالجة رسائل 'OnAcknowledgementPacket' و 'أون تيميوتباكيت'. عند حدوث هذا الخطأ ، لا يمكن حله من خلال طريقة "outOfGasRecovery" المعتادة. نتيجة لذلك ، فشل تضمين المعاملات المتأثرة في كتلة blockchain. يمكن أن يتسبب هذا الفشل في محاولة عمليات إعادة تشغيل IBC إرسال هذه الرسائل بشكل متكرر. يمكن أن تؤدي عمليات الإرسال المتكررة هذه إلى خسائر مالية لإعادة التدوير وإثقال كاهل الشبكة بعدد مفرط من الحزم غير المعالجة ("المهجورة") ، مما يشكل خطرا على استقرار الشبكة.

عنوان المشروع: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

موقع الضعف:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

مقتطف الشيفرة الضعيفة:

ملخص

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

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

استنتاج

تتمحور تحقيقاتنا في أمان نظام الكون، التي تشمل عمليات التدقيق التفصيلية والملخصات والتصنيفات، حول مكوناته الأكثر حساسية: Cosmos SDK وبروتوكول IBC. باستناد إلى خبرتنا العملية الواسعة، قمنا بتجميع مجموعة شاملة من الخبرة العامة في التدقيق.

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

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

تنصل:

1. هذه المقالة مأخوذة من [GateCertiK]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [CertiK]. إذا كانت هناك اعتراضات على إعادة الطبع هذه ، فيرجى الاتصال ب بوابة تعلمالفريق، وسوف يتعاملون معها على الفور.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك الخاصة بالكاتب ولا تشكل أي نصيحة استثمارية.
3. تقوم فرق Gate Learn بترجمة المقال إلى لغات أخرى. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.