قد يؤدي الاستغلال الذي واجهته Curve هذه المرة إلى فتح أفكار جديدة للقراصنة

بواسطة جليل ، بلوك بيتس

دخلت صناعة DeFi في حالة من الفوضى بعد حادث استغلال الثغرات الأمنية. أصبحت Curve Finance ، وهي عملاق في صناعة DeFi ، هدفًا لـ "هجوم" خطير ، كما أن مجموعات عملات مستقرة متعددة مثل alETH / msETH / pETH معرضة للخطر. وفقًا للإحصاءات غير المكتملة ، تسبب حدث استغلال الثغرات الأمنية في خسارة إجمالية قدرها 52 مليون دولار أمريكي في مجمعات Alchemix و JPEG'd و MetronomeDAO و deBridge و Ellipsis و CRV / ETH ، وقد اهتزت ثقة السوق بالكامل بشكل خطير.

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

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

لقد وجد المتسللون الذين عادوا إلى "المبادئ الأولى" نقطة دخول مثالية للمترجم ذي المستوى الأدنى لتناول "الكعكة" الضخمة واللذيذة في سوق DeFi. أصبح المترجم ذو المستوى الأدنى مخترقًا أكثر "ذكاءً". خيار. أجرت BlockBeats مقابلة مع مطور العقود الذكية Box (BoxMrChen) وباحث BTX Derek (begas \ _btxcap) حول هذا الحادث والقضايا ذات الصلة التي كشف عنها.

كيف يحدث حدث المنحنى؟

عبّر ستاني (StaniKulechov) ، مؤسس Aave and Lens ، عن آرائه حول الحادث على وسائل التواصل الاجتماعي: "هذه نكسة مؤسفة لـ Curve و DeFi. على الرغم من أن DeFi مساحة مفتوحة يمكن أن تساهم ، يجب أن تحصل عليها بشكل صحيح تمامًا صعب والمخاطر كبيرة. في حالة Curve ، فهموا الأمر بشكل صحيح على مستوى البروتوكول ".

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

قفل Reentrant ومبدأ CEI

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

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

تضع Solidity "مبدأ CEI" (التحقق من تفاعلات التأثيرات) لبرمجة العقود الذكية ، والتي يمكن أن تحمي الوظائف من هجمات إعادة الدخول. تتضمن محتويات مبادئ CEI ما يلي:

1. يجب أن يكون ترتيب الاحتجاج بمكونات الوظيفة: أولاً ، التفتيش ، ثانياً ، التأثير على متغيرات الحالة ، وأخيراً ، التفاعل مع الكيانات الخارجية.

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

3. يجب إجراء عمليات التحقق في بداية الوظيفة للتأكد من أن الكيان المتصل لديه إذن لاستدعاء الوظيفة.

4. يجب تحديث متغيرات الحالة قبل أي مكالمات خارجية لمنع هجمات العودة.

5. حتى الكيانات الخارجية الموثوق بها يجب أن تتبع نموذج CEI لأنها قد تنقل تدفق التحكم إلى أطراف ثالثة ضارة.

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

لكن مجموعة Curve التي تعرضت للهجوم لم تتبع مبدأ CEI لأن Curve استخدم مترجم Vyper. نظرًا لوجود ثغرة أمنية في رمز Vyper للمترجم ، يفشل قفل إعادة الدخول ، مما يجعل هجوم عودة المخترق يتحقق بنجاح.

يعرف معظم الناس Solidity ، لكن Solidity ليست اللغة الوحيدة لإنشاء عقود ذكية ، فالبديل الشائع لـ Solidity هو Vyper. على الرغم من أن Vyper ليس قويًا وشائعًا مثل Solidity ، إلا أنه مثالي للمطورين المطلعين على Python ، لأن Vyper يمكنه ترجمة كود يشبه Python إلى لغة برمجة عقد Ethereum الذكية.

وفقًا لمعلومات github ، فإن المطور الذي يساهم بأول قاعدة كود جيثب Vyper هو أيضًا مطور Curve. ليس من الصعب شرح سبب استخدام Curve لـ Vyper بدلاً من Solidity.

! [قراصنة يعودون إلى "المبادئ الأولى" ، أزمة المنحنى ليست هجومًا عاديًا] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

لماذا يفشل قفل إعادة الدخول من Vyper؟

إذن في هذا الهجوم ، ما هي مشكلة Vyper؟ لماذا فشل قفل إعادة الدخول؟ هل بسبب عدم وجود اختبارات؟ أجرت BlockBeats مقابلة مع مطور العقود الذكية Box 826.eth (BoxMrChen) ، وفقًا له ، تم اختبار قفل Vyper reentrant مع حالات الاستخدام. لكن سبب الفشل هو أن حالة الاختبار موجهة نحو النتائج ، أي أن حالة الاختبار خاطئة أيضًا.

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

! [قراصنة يعودون إلى "المبادئ الأولى" ، أزمة المنحنى ليست هجومًا عاديًا] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

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

! [قراصنة يعودون إلى "المبادئ الأولى" ، أزمة المنحنى ليست هجومًا عاديًا] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

اليسار هو الكود المهاجم ، واليمين هو الكود الذي تم إصلاحه

"من المتوقع ظهور نتائج اختبار خاطئة ، وبالطبع لا يمكن التحقق من أي أخطاء. لإعطاء مثال بسيط ، نجري مشكلة حسابية الآن ، 1+ 1 = 2 ، ولكن الإجابة المعيارية المعينة خاطئة ، حيث تقول 1+ 1 = 3 . وهذا الزميل الذي كان يقوم بالسؤال أعطى إجابة خاطئة ، وأجاب 1+ 1 = 3 ، لكنها كانت مماثلة للإجابة القياسية المقدمة مسبقًا ، لذلك لم يكن لدى البرنامج بطبيعة الحال طريقة لتحديد أن نتيجة الاختبار كانت خطأ. "قال بوكس في مقابلة مع BlockBeats.

شنق لمدة عامين "سيف داموكليس"

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

من أجل الحصول على فهم متعمق لمحرر Vyper ، أجرى BlockBeats مقابلة مع باحث BTX Derek (begas \ _btxcap) ، وقال إنه بالنسبة للمطورين المطلعين على Python ، يعد Vyper خيارًا مثاليًا أكثر من Solidity ، مع واجهة مستخدم أكثر راحة. وتعلم أسرع. لكن على ما يبدو ، لم يتم تدقيق بعض إصدارات كود محرر Vyper بواسطة طرف ثالث موثوق به. حتى بعض أعمال التدقيق قد يتم إجراؤها من قبل المطورين أنفسهم. "هذا النوع من الأشياء لن يحدث في صناعة تكنولوجيا المعلومات التقليدية ، لأنه بعد ظهور لغة جديدة ، سيكون هناك عدد لا يحصى من شركات التدقيق تبحث عن ثغراتك."

ناهيك عن السماح للخلل بالوجود علانية لمدة عامين.

قال أحد المساهمين في Vyper fubuloubu أيضًا: لا يخضع المترجم للمراجعة أو المراجعة كما يعتقد الجميع. معظم المجمعين لديهم تغييرات كبيرة ومتكررة ، مما يجعل التدقيق عيبًا. حتى مع إجراء تدقيق كامل لقاعدة البيانات ، سيصبح قديمًا كلما تمت إضافة المزيد من الإصدارات بعد ذلك. لا تعد مراجعة المترجم فكرة جيدة ، لأنه من المنطقي مراجعة المنتج النهائي (أي رمز EVM الخام) الذي ينتجه المستخدم النهائي باستخدام الأداة.

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

قراصنة الإنترنت يعودون إلى "المبادئ الأولى"

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

بعد ذلك ، نشر Stani (StaniKulechov) ، مؤسس Aave and Lens ، أيضًا مقالة طويلة على وسائل التواصل الاجتماعي للتعبير عن مشاعره: الهجوم على Curve يعني أن خطر DeFi شمل دائمًا المكدس الأساسي بأكمله ، لغة البرمجة ، EVM ، إلخ. هذا يحذرنا من أن نكون أكثر حذرًا وحساسية ، خاصة عند استخدام أجهزة EVM المخصصة وسلاسل التطبيقات في المستقبل.

! [قراصنة يعودون إلى "المبادئ الأولى" ، أزمة المنحنى ليست هجومًا عاديًا] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

الهجمات من مستوى أدنى

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

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

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

وفقًا للتنبيهات الأمنية التي يصدرها بانتظام فريق تطوير Solidity ، كانت هناك ثغرات أمنية في العديد من الإصدارات المختلفة من مترجم Solidity.

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

يمكننا أيضًا رؤية ملف في مستودع Github الخاص بـ Solidity يسرد بعض الأخطاء المعروفة المتعلقة بالأمان في مترجم Solidity. تعود القائمة إلى الإصدار 0.3.0 ، ولم يتم سرد الأخطاء التي كانت موجودة فقط قبل هذا الإصدار. هنا ، يوجد ملف bugs \ _by \ _version.json آخر. يمكن استخدام هذا الملف للاستعلام عن الأخطاء التي يتأثر بها إصدار مترجم معين.

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

لمساعدة مطوري Solidity على الاختبار بشكل أفضل ومنع حدوث نفس الشيء. أصدر المؤسس المشارك لشركة UnitasProtocol SunSec (@ 1 nf 0 s 3 cpt) دليل اختبار أمان DeFiVulnLabs Solidity بعد هجوم Curve ، حيث يدعم 47 نوعًا من الثغرات الأمنية ، بما في ذلك أوصاف الثغرات الأمنية والسيناريوهات والدفاعات ورموز الثغرات الأمنية وإجراءات التخفيف وكيفية الاختبار .

كيف تتجنب الهجمات منخفضة المستوى قدر الإمكان؟

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

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

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

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

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

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