إليك كيفية حدوث أحد أكثر عمليات اختراق العقود الذكية شيوعاً والتي تُكلف شركات الويب الملايين ...
بعض أكبر الإختراقات في صناعة البلوكتشين ، حيث سُرقت ما قيمته ملايين الدولارات من الرموز للعملات المشفرة ، نتجت عن هجمات إعادة الدخول. في حين أن هذه الأختراقات أصبحت أقل شيوعاً في السنوات الأخيرة ، إلا أنها لا تزال تُشكل تهديداً كبيراً لتطبيقات ومستخدمي البلوكتشين.
إذن ما هي بالضبط هجمات العودة - Reentrancy Attack ؟ كيف يتم نشرهم ؟ وهل هناك أي إجراءات يمكن للمطورين اتخاذها لمنع حدوثها ؟
ما هو هجوم العودة - Reentrancy Attack ؟
يحدث هجوم إعادة الدخول عندما تقوم إحدى وظائف العقد الذكي الضعيف بإجراء مكالمة خارجية لعقد ضار ، وتتخلى مؤقتاً عن التحكم في تدفق المعاملة. ثم تستدعي العقد الضار بشكل مُكرر وظيفة العقد الذكي الأصلي قبل أن ينتهي من التنفيذ أثناء استنزاف أمواله.
بشكل أساسي ، تتبع معاملة السحب على بلوكتشين الإيثريوم دورة من ثلاث خطوات ؛ تأكيد الرصيد و التحويل وتحديث الرصيد. إذا تمكن المجرم الإلكتروني من إختطاف الدورة قبل تحديث الرصيد ، فيمكنه سحب الأموال بشكل مُكرر حتى يتم إستنزاف المحفظة.
كان إختراق Ethereum DAO أحد أكثر عمليات اختراق البلوكتشين شهرة ، كما تم تغطيته بواسطة Coindesk ، وهو هجوم إعادة الدخول الذي أدى إلى خسارة أكثر من 60 مليون دولار من ETH وتغيير مسار ثاني أكبر عملة مشفرة بشكل أساسي.
كيف يعمل هجوم العودة ؟
تخيل بنكاً في بلدتك حيث يحتفظ السكان المحليون الفاضلون بأموالهم ؛ سيولتها الإجمالية 1 مليون دولار. ومع ذلك ، لدى البنك نظام محاسبة معيب - ينتظر الموظفون حتى المساء لتحديث الأرصدة المصرفية.
يزور صديقك المستثمر المدينة ويكتشف الخلل المحاسبي. يقوم بإنشاء حساب ويودع 100 ألف جنية . بعد يوم ، قام بسحب 100 ألف جنية. بعد ساعة قام بمحاولة أخرى لسحب 100 ألف جنية. نظراً لأن البنك لم يقم بتحديث رصيده ، فإنه لا يزال يقرأ 100 ألف جنية. لذلك حصل على المال. يفعل هذا بشكل متكرر حتى لا يتبقى أموال. يُدرك الموظفون فقط أنه لا يوجد مال عندما يوازنون الكتب في المساء.
في سياق العقد الذكي ، تسير العملية على النحو التالي :
1. يحدد مجرم الإنترنت العقد الذكي " X " مع وجود ثغرة أمنية.
2. يبدأ المهاجم معاملة شرعية للعقد الهدف ، X ، لإرسال أموال إلى عقد ضار ، " Y ". أثناء التنفيذ ، تستدعي Y الوظيفة الضعيفة في X.
3. يتم إيقاف تنفيذ عقد X مؤقتاً أو تأخيره حيث ينتظر العقد التفاعل مع الحدث الخارجي.
4. أثناء إيقاف التنفيذ مؤقتاً ، يقوم المهاجم بإستدعاء نفس الوظيفة المعرضة للخطر بشكل متكرر في X ، مما يؤدي مرة أخرى إلى بدء تنفيذها أكبر عدد ممكن من المرات.
5. مع كل إعادة دخول ، يتم التلاعب بحالة العقد ، مما يسمح للمهاجم بإستنزاف الأموال من X إلى Y.
6. بمجرد استنفاد الأموال ، تتوقف إعادة الدخول ، ويكتمل التنفيذ المتأخر لـX أخيراً ، ويتم تحديث حالة العقد بناءً على آخر إعادة دخول.
بشكل عام ، يستغل المهاجم بنجاح ثغرة إعادة الدخول لصالحه ، ويسرق الأموال من العقد.
مثال على هجوم العودة
فكيف بالضبط يمكن أن تحدث هجوم إعادة الدخول تقنياً عند نشره ؟ هذا عقد ذكي افتراضي مع بوابة عودة. سنستخدم التسمية البديهية لتسهيل المتابعة.
يتيح عقد معرض للخطر للمستخدمين إيداع ETH في العقد بإستخدام وظيفة الإيداع. يمكن للمستخدمين بعد ذلك سحب ETH المودعة بإستخدام وظيفة السحب. ومع ذلك ، هناك ثغرة في إعادة الدخول في وظيفة السحب. عندما ينسحب المستخدم ، ينقل العقد المبلغ المطلوب إلى عنوان المستخدم قبل تحديث الرصيد ، مما يخلق فرصة للمهاجم لإستغلاله.
الآن ، هذا ما سيبدو عليه العقد الذكي للمهاجم.
عندما يتم شن الهجوم :
1. يأخذ عقد المهاجم عنوان العقد الضعيف في مُنشنه ويخزنه في متغير العقد الضعيف.
2. يقوم المهاجم بإستدعاء وظيفة الهجوم ، حيث يقوم بإيداع بعض ETH في العقد الضعيف بإستخدام وظيفة الإيداع ثم استدعاء وظيفة السحب الخاصة بالعقد الضعيف على الفور.
3. تعمل وظيفة السحب في عقد مُعرض للخطر على تحويل مبلغ ETH المطلوب إلى عقد المهاجم الخاص بالمهاجم قبل تحديث الرصيد ، ولكن نظراً لإيقاف عقد المهاجم مؤقتاً أثناء المكالمة الخارجية ، فإن الوظيفة لم تكتمل بعد.
4. يتم تشغيل وظيفة الإستلام في عقد المهاجم لأن عقد غير المحصن أرسل ETH إلى هذا العقد أُثناء المكالمة الخارجية.
5. تتحقق وظيفة الإستلام مما إذا كان رصيد عقد المهاجم هو 1 إيثر على الأقل ( المبلغ المطلوب سحبه ) ، ثم يعيد الدخول إلى العقد الضعيف عن طريق إستدعاء وظيفة السحب الخاصة به مرة أخرى.
6. تكرر الخطوات من ثلاث إلى خمس خطوات حتى نفاد الأموال من العقد الضعيف ويجمع عقد المهاجم قدراُ كبيراً من ETH.
7. أخيراً ، يمكن للمهاجم استدعاء وظيفة الأموال المسروقة في عقد المهاجم لسرقة جميع الأموال المتراكمة في عقده.
يمكن أن يحدث الهجوم بسرعة كبيرة ، إعتماداً على أداء الشبكة. عند تضمين عقود ذكية معقدة مثل DAO Hack ، والتي أدت إلى Hard Fork من الإيثريوم إلى الإيثريوم و إيثريوم كلاسيك ، يحدث الهجوم على مدار عدة ساعات.
كيفية منع هجوم العودة
لمنع هجوم العودة أو إعادة الدخول ، نحتاج إلى تعديل العقد الذكي الضعيف لإتباع أفضل الممارسات لتطوير العقود الذكية الآمنة. في هذه الحالة ، يجب أن نطبق نمط " Checks-effects-interactions " كما في الكود أدناه.
في هذا الإصدار الثابت ، قدمنا تعيين isLocked - مغلق لتتبع ما إذا كان حساب معين في طور السحب. عندما يبدأ المستخدم في السحب ، يتحقق العقد مما إذا كان حسابه مغلقاً ( isLocked[msg.sender] ) ، مشيراً إلى عدم وجود سحب آخر من نفس الحساب قيد التقدم حالياً.
إذا لم يتم قفل الحساب ، يستمر العقد مع تغيير الحالة و التفاعل الخارجي. بعد تغيير الحالة والتفاعل الخارجي ، يتم قتح الحساب مرة أخرى ، مما يسمح بعمليات السحب المستقبلية.
أنواع هجمات العودة
بشكل عام ، هناك ثلاثة أنواع رئيسية من هجمات العودة بناءً على طبيعة الإستغلال.
1. هجوم عودة واحد : في هذه الحالة ، فإن الوظيفة الضعيفة التي يستدعيها المهاجم بشكل متكرر هي نفسها التي تكون عرضة لبوابة إعادة الدخول. الهجوم أعلاه هو مثال على هجوم عودة واحد ، والذي يمكن منعه بسهولة عن طريق تنفيد عمليات فحص وإقفال مناسب في التعليمات البرمجية.
2. هجوم متعدد الوظائف : في هذا السيناريو ، يستفيد المهاجم من وظيفة ضعيفة لإستدعاء وظيفة مختلفة في نفس العقد الذي يشترك في حالة مع الحالة الضعيفة. الوظيفة الثانية ، التي يطلق عليها المهاجم ، لها بعض التأثير المرغوب فيه ، مما يجعلها أكثر جاذبية للإستغلال. يعد هذا الهجوم أكثر تعقيد ويصعب اكتشافه ، لذا يلزم إجراء فحوصات وأقفال صارمة عبر الوظائف المترابطة للتخفيف من حدته.
3. الهجوم المشترك : يحدث هذا الهجوم عندما يتفاعل عقد خارجي مع عقد معرض للخطر. أثناء هذا التفاعل ، يتم استدعاء حالة العقد المعرض للخطر في العقد الخارجي قبل تحديثه بالكامل. يحدث ذلك عادة عندما نشترك عدة عقود في نفس المتغير ويقوم البعض بتحديث المتغير المشترك بشكل غير أمن. يجب تنفيذ بروتوكولات الإتصال الآمن بين العقود وعمليات تدقيق العقود الذكية الدورية للتخفيف من هذا الهجوم.
يمكن أن تظهر هجمات العودة بأشكال مختلفة و بالتالي تتطلب تدابير محددة لمنع كل الهجمات.
البقاء في مأمن من هجمات العودة
تسببت هجمات العودة في خسائر مالية كبيرة وقوضت الثقة في تطبيقات البيلوكتشين. لحناية العقود ، يجب على المطورين اعتماد أفضل الممارسات بجدية لتجنب الثغرات الأمنية المتعلقة بإعادة الدخول.
يجب عليهم أيضاً تنفيذ أنماط سحب آمنة ، واستخدام مكتبات موثوقة ، وإجراء عمليات تدقيق شاملة لتعزيز دفاع العقد الذكي بشكل أكبر. بالطبع ، البقاء على اطلاع حول التهديدات الناشئة و الإستباقية مع الجهود الأمنية يمكن أن يضمن دعمها لسلامة النظم البيئية البلوكتشين أيضاً.
