تحليل هجوم Sonne Finance

المؤلف: Cara من فريق ZAN (حساب X @Cara6289) وXiG (حساب X @SHXiGi)

في 15 مايو 2024، تعرضت Sonne Finance لهجوم على سلسلة Optimism وبلغت الخسائر 20 مليون دولار.

بعد الهجوم، حصل المستخدم @tonyke_bot على حوالي 6.5 مليون دولار.

(https://twitter.com/tonyke_bot/status/1790547461611860182)

بعد أن اكتشف مشروع Sonne Finance الهجوم، سارع إلى تعليق جميع الأسواق على Optimism وذكر أن Base الأسواق في أمان.

(https://twitter.com/SonneFinance/status/1790535383005966554)

وصف مختصر للهجوم

Sonne Finance is Optimism هو شوكة من Compound V2، وهو بروتوكول إقراض لامركزي يسمح للأفراد والمؤسسات والبروتوكولات بالوصول إلى الخدمات المالية. يقوم بروتوكول Sonne Finance بتجميع الأصول الرمزية للمستخدمين لتشكيل مجمع سيولة للإقراض، مما يوفر للمستخدمين أعمال إقراض تشبه البنوك. مثل Compound، يمكن للمشاركين في البروتوكول رهن الرموز المميزة الخاصة بهم في مجمع سيولة الإقراض الخاص بـ Sonne Finance والحصول على شهادة soToken (مثل cToken). SoToken هي شهادة أصول تحمل فائدة، والتي ستولد قدرًا معينًا من الدخل مع تقدم الكتلة، وستتلقى أيضًا حوافز رمزية من SONE. يمكن للمشاركين أيضًا استعارة الرموز المميزة الأخرى من مجموعة أصول الإقراض Sonne مع وجود soToken في أيديهم. على سبيل المثال، يمكن للمشاركين رهن مبلغ معين من USDC للحصول على شهادات SOUSDC، ثم إقراض WETH لمزيد من التداول. يمكن أن يكون إقراض الرهن العقاري في بروتوكول Sonne Finance عبارة عن علاقة أصول متعددة الأطراف أثناء عملية إقراض الرهن العقاري، سيقوم البروتوكول تلقائيًا بحساب عامل الصحة (عامل الصحة) لعنوان المشارك عندما يكون عامل الصحة أقل من 1،. سوف يدعم رهن منتجات العنوان التصفية، ويمكن للمصفين أيضًا الحصول على مكافآت تصفية معينة.

ترتبط العلاقة بين عدد الرموز المميزة التي يودعها المستخدمون وsoTokens المسكوكة بشكل أساسي بمتغير يسمى ExchangeRate، ويمكن استخدام هذا المتغير تقريبًا للإشارة إلى قيمة الرمز المميز الأساسي لكل SoToken. صيغة حساب ExchangeRate هي كما يلي:

في الصيغة أعلاه، يشير TotalCash إلى عدد الرموز المميزة التي تحتفظ بها SoToken، ويشير TotalBorrows إلى عدد الرموز المميزة التي تم إقراضها في سوق معينة، ويشير TotalReserves إلى إجمالي عدد الرموز المميزة التي تم إقراضها في سوق معينة. الاحتياطيات (بما في ذلك فوائد القروض المدفوعة)، يشير إجمالي العرض إلى عدد الرموز المسكوكة.

عند الاسترداد، يمكن للمستخدم تحديد عدد الرموز المميزة التي سيتم استردادها، واسترداد القيمة، لحساب عدد الرموز التي يجب تدميرها، وطريقة الحساب هي تقريبًا "redeemTokens = redeemAmount / ExchangeRat "، < strong>لاحظ أنه لا يتم التعامل مع فقدان الدقة هنا.

جوهر هذا الهجوم هو أنه عندما تم إنشاء السوق (soToken)، أجرى المهاجم أول عملية صب رهن عقاري وقام بسك كمية صغيرة من soToken مع كمية صغيرة من الرموز المميزة، مما أدى إلى " قيمة "totalSupply" صغيرة جدًا. استغل المهاجم بعد ذلك ثغرة فقدان الدقة في عقد Solidity، ثم أرسل الرمز المميز الأساسي مباشرة إلى عقد soToken (لن يتم سك SoToken، مما يعني أن "totalSupply" يظل دون تغيير ويصبح "totalCash" أكبر) بدلاً من التوقيع المساحي + الإرسال طريقة إيداع الرمز الأساسي. مثل هذه العملية تجعل متغير "totalCash" في العقد أكبر، ولكن "totalSupply" يظل دون تغيير، مما يتسبب في زيادة سعر الصرف. في النهاية، عندما يسترد المهاجم الرمز المميز الأساسي، يكون رمز soToken الذي يجب تدميره أقل من رمز soToken الذي تم سكه أثناء الرهن العقاري. يستخدم المهاجم رمز soToken المكتسب لإقراض الرمز المميز WETH وUSDC إلى رموز soTokens الأخرى (مثل soWETH). ، soUSDC)، وحصل أخيرًا على أرباح تصل إلى 20 مليون دولار أمريكي.

العناوين الرئيسية المشاركة في الهجوم

معاملة التحضير للهجوم:

https://optimistic. etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96

مهاجمة المعاملات المربحة:

https://optimistic.etherscan.io/ tx /0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0

العنوان المرتبط بـ EOA:

0x5d0d99e9886581ff8fcb0 1f35 804317f5ed80bbb

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43

العنوان المرتبط بالمهاجم (العقد):

0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8< /p>

0x02fa2625825917e9b1f8346a465de1bbc150c5b9

الرمز المميز الأساسي (VELO Token V2):

0x9560e827af36c94d2ac33a39bce1fe78631088db

عقد الثغرات الأمنية (soVELO، المشابه لـ cToken الخاص بالمركب):

0xe3b81318b1b6776f0877c3770afddff97b9f5 fe5< /p>

@tonyke_bot معاملة إنقاذ المستخدم على /p>

تحليل عملية الهجوم

الملخص الأولي

أصدر حزب مشروع Sonne Finance مؤخرًا اقتراحًا لإضافة سوق VELO إلى Sonne Finance (https://twitter.com/SonneFinance/status/1786871066075206044) و رتبت خمس معاملات من خلال المحفظة متعددة التوقيع ليتم تنفيذها بعد يومين (https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7)، يتم استخدام هذه المعاملات الخمس لإنشاء سوق VELO (soVELO العقد) وتعيين بعض التكوينات الرئيسية للسوق، مثل تحديد نموذج سعر الفائدة، وتعيين أوراكل السعر، وتعيين عامل الرهن العقاري، وما إلى ذلك. بعد إنشاء سوق VELO، يمكن للمستخدمين إيداع رموز VELO لسك رموز soVELO، والتي يمكن استخدامها بدورها لاستعارة رموز soVELO الأخرى.

التحضير للهجوم

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

الخطوات المحددة هي كما يلي:

1. بعد انتهاء فترة القفل البالغة يومين، سيقوم المهاجم أولاً، يتم تجميع عمليات أربع معاملات في معاملة واحدة (المعاملة 0x45c0cc)، والتي يتم استخدامها لإنشاء سوق VELO (عقد soVELO) وتعيين التكوينات الرئيسية. عند تهيئة سوق VELO، يتم ضبط معدل التبادل على "200,000,000,000,000,000,000,000,000".

2. يستدعي المهاجم وظيفة "mint" لعقد soVELO لإيداع رموز VELO ورموز soVELO المميزة، ويحدد المهاجم "mintAmount" كـ "400,000,001" (رقم رمز VELO المميز لـ. عملات معدنية). كما يتبين من الدالة "exchangeRateStoredInternal"، نظرًا لأن "_totalSuppl" لرمز soVELO هو 0 في هذا الوقت، فإن ExchangeRate هي القيمة المحددة في الخطوة 1. وفقًا للصيغة "mintTokens = الفعليMintAmount /exchangeRate"، فإن العدد المحسوب لرموز soVELO التي يجب سكها في هذا الوقت هو 2. باختصار، في هذه الخطوة، يقوم المهاجم بإيداع رموز VELO بقيمة "400,000,001" في عقد soVELO، ويحصل المهاجم على رموز soVELO بقيمة 2.

   soVELO.mint:

   

3. أرسل المهاجم الرموز في Velo مع SEVEN TO SEVELO عقدت من قبل يزداد عقد soVELO، ولكن نظرًا لعدم سك رموز soVELO الجديدة، يظل إجمالي العرض دون تغيير، مما يعني أن معدل التبادل المحسوب وفقًا لمعادلة حساب معدل التبادل سيصبح أكبر في هذا الوقت.

4. قام المهاجم بنقل رموز soVELO المميزة عدة مرات، وفي النهاية إلى هجوم آخر EOA 0xae4a.

ربحية الهجوم

تتم مرحلة ربح الهجوم بشكل أساسي عندما ينفذ المهاجم المعاملة الخامسة من الاقتراح ويمرر Flash تقوم القروض بإقراض رموز VELO مباشرة إلى عقد soVELO لزيادة سعر الصرف. ثم يستخدم المهاجم رمز soVELO بقيمة 2 في يده لاستعارة الرموز الأساسية مثل WETH وUSDC من عقود soToken الأخرى (مثل soWETH وsoUSDC وما إلى ذلك)، وتصبح هذه الأجزاء ربحًا للمهاجم. ثم ذهب المهاجم لاسترداد رمزه الأساسي في عقد soVELO نظرًا للزيادة في ExchangeRate وفقدان الدقة في حساب رموز soVELO التي يجب تدميرها للاسترداد، استخدم المهاجم في النهاية رمز soVELO المميز بقيمة 1. 1. تم استرداد جميع رموز VELO المودعة مسبقًا تقريبًا، والتي يمكن فهمها على أن المهاجم يستخدم رموز soVELO الإضافية بقيمة 1 لكسب الرموز المميزة مثل WETH وUSDC عن طريق الاقتراض من رموز soVELO الأخرى. واستخدم المهاجم نفس الأسلوب لتكرار الهجوم عدة مرات وحقق في النهاية أرباحًا ضخمة.

الخطوات المحددة هي كما يلي:

1. ينفذ المهاجم الضربة الخامسة في السؤال المعاملة، يحدد عامل الاقتراض المحدد في الاقتراح.

2. أقرض المهاجم رموز VELO بقيمة "35,469,150,965,253,049,864,450,449" من مجموعة VolatileV2 AMM - USDC/VELO، مما أدى إلى تشغيل وظيفة ربط المهاجم. في وظيفة الخطاف، يستمر المهاجم في تنفيذ عملية الهجوم.

3. يرسل المهاجم رموز VELO التي يحملها إلى عقد soVELO لزيادة سعر الصرف. يوجد حاليًا إجمالي رموز VELO بقيمة "35,471,703,929,512,754,530,287,976" في عقد soVELO (مجموع رموز VELO التي نقلها المهاجم ثلاث مرات).

4. يقوم المهاجم بإنشاء عقد جديد0xa16388a6210545b27f669d5189648c1722300b8b. في المُنشئ، يقوم بنقل رمزي soVELO المميزين اللذين يحملهما إلى العقد المنشأ حديثًا (يشار إليه فيما يلي باسم المهاجم 0xa163).

5. استخدم المهاجم 0xa163 رموز soVELO التي كان بحوزته لاقتراض WETH بقيمة "265,842,857,910,985,546,929" من soWETH.

6. يستدعي المهاجم 0xa163 وظيفة "الاسترداد الأساسية" الخاصة بـ soVELO، ويحدد قيمة رموز VELO المستردة على أنها "35,471,603,929,512,754,530,287,976" (قام جميع المهاجمين تقريبًا بنقل أو رهن SoVELO سابقًا رموز VELO في العقد). في هذا الوقت، يجب حساب عدد رموز soVELO التي يجب تدميرها للاسترداد وفقًا للصيغة "redeemTokens = redeemAmountIn /exchangeRate".

   كما يتبين من الدالة "exchangeRateStoredInternal"، نظرًا لأن _totalSupply هو 2 بدلاً من 0 في هذا الوقت، يجب حساب قيمة ExchangeRate، والتي يتم حسابها من خلال الصيغة "exchangeRate = (totalCash + TotalBorrows - TotalReserves) / TotalSupply" ExchangeAte الحالي هو "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000,000,000,000,000,000".

   قيمة "redeemTokens" المحسوبة على أساس سعر الصرف الجديد هي "1.99". نظرًا لخصائص التقريب التنازلي لـ Solidity، فإن قيمة "redeemTokens" هي أخيرًا 1. وهذا يعني أن المهاجم 0xa163 استخدم رموز soVELO بقيمة 1 لاسترداد جميع رموز VELO التي تم إيداعها مسبقًا تقريبًا. وفي الوقت نفسه، حصل المهاجم 0xa163 أيضًا على WETH بقيمة "265,842,857,910,985,546,929" مقترضة من soWETH.

   soVELO.redeemUnderlying:

    

   soVELO.exchangeRateStoredInternal:

   

7. قام المهاجم 0xa163 بنقل جميع رموز WETH المستعارة واسترداد رموز VELO إلى المهاجم ذي المستوى الأعلى، ثم التدمير الذاتي .

8. يستدعي المهاجم وظيفة "liquidateBorrow" الخاصة بـ soWETH لتصفية بعض الأصول المقترضة من العقد المنشأ حديثًا 0xa163 من أجل استعادة soVELO المقفل بقيمة 1 رمز. حاليًا، يحتفظ المهاجم فقط برموز soVELO بقيمة 1.

9. يستدعي المهاجم رموز SoVELO المميزة لوظيفة "mint" الخاصة بـ soVELO والرهون العقارية وسك العملة مرة أخرى، بهدف جمع رموز soVELO بقيمة 2، ثم ينفذ الخطوة 3 أعلاه مرة أخرى -8 خطوات للاستفادة من الرموز المميزة الأخرى.

10. ينفذ المهاجم الخطوة 9 عدة مرات، ويسدد القرض السريع، ويغادر مع الربح.

كيفية الاستفادة من 6.5 مليون دولار بمبلغ 100 دولار

بعد الهجوم، قام مستخدم @tonyke_bot على X بتمرير المعاملة 0x0a284cd 1144 تم رهن رموز VELO في عقد soVELO، وتم سك 0.00000011 soVELO. السبب وراء قدرة هذه العملية على منع المهاجم من المزيد من الهجمات هو أن هذه المعاملة تغير حجم TotalSupply في soVELO وعدد رموز VELO المميزة TotalCash المحتفظ بها، ويكون تأثير نمو TotalSupply على حساب ExchangeRate أكبر من التأثير وبالتالي، يصبح سعر الصرف أصغر، مما يجعل المهاجم غير قادر على استخدام فقدان الدقة لكسب soVELO عند تنفيذ هجوم، مما يجعل الهجوم غير ممكن.

تتبع الأموال

قام المهاجم بتحويل الأموال بعد وقت قصير من الاستيلاء على المكاسب غير القانونية. وتم تحويل معظم الأموال إلى العناوين الأربعة التالية. وكان على البعض تغيير العناوين لمواصلة الهجوم ، وبعضها كان لغسل الأموال:

1. 0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

   < /li>

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

     0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

   1. 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

   < p>قام المهاجم بنقل 724277 USDC و2353 VELO إلى هذا العنوان، وقام باستبدال USDC بـ Ether. ثم تم تحويل بعض الأموال على الفور إلى جسر Stargate عبر السلسلة، وبقيت معظم الأموال غير القانونية في هذا العنوان:

   

   1. 0xbd18100a168321701955e348. f03d 0df4f517c13b  ;

   قام المهاجم بنقل 33 WETH إلى هذا العنوان واستخدم طريقة Peel Chain لمحاولة غسل الأموال يلي:

   0xbd18100a168321701955e348f03d0df4f517c13b -> ; 0xc521bde5e53f537ff208970152b75a003093c2b4 -&g t; 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795.

   1. 0x4fac0651bcc837bf889f6a7d79c1908419fe1770

   < p>نقل المهاجم 563 WETH إلى هذا العنوان، ثم نقله إلى  0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68 لا يوجد أي إجراء آخر في الوقت الحالي.

   إن أسلوب المهاجم في غسل الأموال هذه المرة احترافي نسبيًا، وتظهر الأساليب اتجاهًا للتنوع. لذلك، بالنسبة لنا نحن المشاركين في Web3، يجب علينا الاستمرار في تحسين قدراتنا في مكافحة غسيل الأموال من حيث الأمان، وتحسين أمان مشاريع Defi من خلال KYT وAML وغيرها من منتجات أمان معاملات blockchain ذات الصلة.

   توصيات السلامة

   1. يجب أن يؤخذ فقدان الدقة على محمل الجد

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

   2. من المستحسن أن يتم إنشاء سوق مشابه لـ cToken في المجمع وأول عملية صب الرهن العقاري بواسطة مستخدمين متميزين لتجنب تشغيلها من قبل المهاجمين وبالتالي التلاعب بالتبادل معدل.

   3. عندما يكون هناك متغير رئيسي في العقد يعتمد على قيمة " this.balance " أو " token.balanceOf() "، فأنت بحاجة إلى دراسة الشروط بعناية لتغيير المتغير الرئيسي، مثل هل يُسمح بتغيير قيمة هذا المتغير مباشرة عن طريق تحويل العملة الأصلية أو الرموز المميزة إلى العقد، أم يمكن تغيير قيمة هذا المتغير فقط عن طريق استدعاء وظيفة محددة.