في 15 مايو 2024 ، عانت Sonne Finance من هجوم على Optimism داخل السلسلة ، مع خسائر تصل إلى 2 k 0000 دولار.

بعد وقوع الهجوم ، قام مستخدم @tonyke_bot على X بتغريدة ، مدعيا أنه قام بحماية حوالي 6.5 مليون دولار من حوض رهن عملات Sonne Finance (المعروف أيضًا بالسوق ، مشابه ل cToken في Compound) بمبلغ حوالي 100 دولار.

（_bot/status/1790547461611860182）

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

（**）

إحاطة الهجوم

Sonne Finance هو بروتوكول الاقتراض والاقتراض المركزي الذي يشبه البنوك على Optimism ، وهو نسخة من Compound V2 ، ويوفر خدمات مالية للأفراد والمؤسسات والبروتوكول. يقوم بروتوكول Sonne Finance بتجميع أصول رموز المستخدم وتشكيل بركة سيولة الاقتراض ، ويوفر للمستخدمين خدمة الاقتراض مشابهة للبنوك. مثل Compound ، يمكن للمشاركين في البروتوكول رهن الرموز التي يمتلكونها في بركة سيولة الاقتراض في Sonne Finance وفي الوقت نفسه الحصول على إيصالات soToken (مثل cToken). وهذا هو إثبات الأصول المستحقة للعائد ، وسوف تنتج أرباحًا بتقدم البلوكات ، وستحصل أيضًا على مكافآت SONNE token. وباستخدام soToken الموجود في يديهم ، يمكن للمشاركين في الاستدانة من بركة أصول الاقتراض في Sonne رهن الرموز الأخرى ، على سبيل المثال ، يمكن للمشاركين رهن كمية معينة من USDC للحصول على إيصال soUSDC ، ثم استدانة WETH للتداول الأكثر تداولًا. يمكن أن يكون الرهن والاقتراض في بروتوكول Sonne Finance علاقة متعددة إلى متعدد من الأصول ، وخلال عملية الرهن والاقتراض ، سيقوم البروتوكول تلقائيًا بحساب صحة عنوان المشارك ، وعندما تكون الصحة أقل من 1 ، ستتم دعم ضمانة عنوانه للتصفية ، وسيحصل الشخص الذي يقوم بالتصفية أيضًا على مكافأة تصفية معينة.

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

في الصيغة أعلاه ، يشير totalCash إلى عدد الرموز المميزة الأساسية التي تحتفظ بها soToken ، ويشير totalBorrows إلى مقدار الرموز الأساسية المقرضة في السوق ، ويشير totalReserves إلى المبلغ الإجمالي للاحتياطيات (بما في ذلك الفوائد التي يدفعها المقترضون) ، ويشير totalSupply إلى عدد الرموز السك soTokens.

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

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

**العنوان حرجة متورطة في الهجوم

التداول الجاهز للهجوم:

\u003e

** > ً \u003e

مهاجمة الصفقات المربحة:

\u003e \u003e > ** > ٪ > إرسال

هجوم العنوان المتعلقة ب EOA:

\u003e \u003e \u003e 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb > > ٪

> \u003e \u003e 0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43

للمزيد من المعلومات \u003e

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

\u003e

\u003e 0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

\u003e

0x02fa2625825917e9b1f8346a465de1bbc150c5b9 \u003e \u003e

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

> Translated text

0x9560e827af36c94d2ac33a39bce1fe78631088db > ً > ٪

العقد الذكي المُسرب (soVELO، مشابه لـ cToken في Compound):

\u003e > Translated text in Arabic: >

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5 >

X 上 @tonyke_bot المستخدمين للتعامل في حالات الطوارئ:

\u003e \u003e **

\u003e

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

ملخص السابقة

Sonne Finance سجلت مؤخرًا اقتراحًا () لإضافة سوق VELO إلى Sonne Finance وقامت بترتيب خمس صفقات () التي ستُنفَذ بعد يومين باستخدام محفظة متعددة التواقيع. تستخدم هذه الصفقات لإنشاء سوق VELO (عقد soVELO) وتعيين بعض الإعدادات الرئيسية لهذا السوق مثل نموذج معدل الفائدة وجهاز أوراكل الأسعار وعامل الرهن الخ. بعد إنشاء سوق VELO ، يمكن للمستخدمين إيداع رمز VELO لصياغة رمز soVELO ، ويمكن استخدام رمز soVELO لاستدانة أخرى soToken.

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

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

الخطوات المحددة على النحو التالي:

1. بعد انتهاء فترة القفل لمدة يومين ، يقوم المهاجم أولاً بتجميع عمليات الصفقات الأربع الأولى المذكورة في الاقتراح في صفقة واحدة (صفقة 0x45c0cc) لإنشاء سوق VELO (عقد soVELO) وضبط التكوين الرئيسي بشكل صحيح. عند تهيئة سوق VELO ، يتم ضبط معدل الصرف على "200,000,000,000,000,000,000,000,000".
2. الهاجم يستدعي وظيفة "الصياغة" في عقد soVELO لإيداع عملة VELO وصياغة عملة soVELO. يحدد الهاجم "المبلغ المطلوب للصياغة" كـ "400،000،001" (عدد عملات VELO). يمكن رؤية قيمة exchangeRate في وظيفة "exchangeRateStoredInternal" ، ونظرًا لأن "totalSuppl" لعملة soVELO في هذا الوقت هو 0 ، فإن قيمة exchangeRate هي القيمة المحددة في الخطوة 1. ووفقًا للصيغة "mintTokens = actualMintAmount / exchangeRate" ، فإن العدد الفعلي لعملة soVELO التي يجب صياغتها في هذا الوقت هو 2. ببساطة ، في هذه الخطوة يقوم الهاجم بإيداع قيمة "400،000،001" لعملة VELO في عقد soVELO ويحصل على عملة soVELO بقيمة 2.

soVELO.mint: سوفيلو.مينت

3. القاتل يرسل عملة VELO مباشرة إلى عقد soVELO بقيمة "2,552,964,259,704,265,837,526" عملة VELO. في هذه الحالة، يزيد العقد soVELO من عدد العملات VELO التي يحتوي عليها، ولكن نظرًا لعدم وجود عملات soVELO جديدة للصك، يظل إجمالي العرض ثابتًا، مما يعني أن سعر الصرف المحسوب وفقًا للصيغة الحسابية لسعر الصرف سيزيد. 4. يقوم المهاجم بنقل عملة soVELO التي يمتلكها عدة مرات ، وفي النهاية ينقلها إلى حساب EOA 0xae4a المهاجم الآخر.

الهجوم من أجل الربح

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

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

1. المهاجم ينفذ المعاملة الخامسة في القضية، ويضبط عامل الإقراض المحدد في الاقتراح.
2. الهجاع الذي يحصل هو أن المهاجم يستدان بشكل فائق من بركة VolatileV2 AMM - USDC/VELO ويستدان بقيمة "35,469,150,965,253,049,864,450,449" عملة VELO، مما يؤدي إلى تنفيذ دالة الخطاف الخاصة بالمهاجم. في دالة الخطاف، يقوم المهاجم بمواصلة تنفيذ عمليات الهجوم.
3. الهجاج يرسل رمز VELO الذي يمتلكه إلى عقد soVELO لزيادة معدل الصرف بشكل أكبر. حاليًا ، يوجد إجمالي 35,471,703,929,512,754,530,287,976 رمز VELO في عقد soVELO (رموز VELO التي تم إيداعها ثلاث مرات من قبل الهاجاج).
4. يقوم المهاجم بإنشاء عقد جديد 0xa16388a6210545b27f669d5189648c1722300b8b، وفي الدالة البنائية، يحول العملات المشفرة soVELO التي يمتلكها إلى العقد الجديد 0xa163 (المشار إليه فيما بعد بـ 0xa163 للمهاجم).
5. يقدم 0xa163 المهاجم WETH بقيمة "265,842,857,910,985,546,929" من عملة soWETH الذي يحمله.
6. يقوم المهاجم 0xa163 بالاستدعاء soVELO لوظيفة "redeemUnderlying" ، وتحديد قيمة استرداد عملة VELO بـ "35،471،603،929،512،754،530،287،976" (تقريبًا كمية جميع عملات VELO التي تم نقلها أو رهنها مسبقًا في عقد soVELO) ، وفي هذه الحالة يجب حساب كمية عملة soVELO التي يجب تدميرها للاسترداد وفقًا للمعادلة "redeemTokens = redeemAmountIn / exchangeRate".

من الدالة "exchangeRateStoredInternal" يمكننا أن نرى أنه نظرًا لوجود "_totalSupply" المساوي لـ 2 وليس 0 في الوقت الحالي ، فإنه من الضروري حساب قيمة "exchangeRate" باستخدام الصيغة "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply" ، وقيمة "exchangeRate" الحالية هي "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000" ، وهذه القيمة تفوق قيمة "exchangeRate" الأولية المحددة والتي هي "200,000,000,000,000,000,000,000,00".

بناءً على سعر الصرف الجديد، قيمة "redeemTokens" المحسوبة هي "1.99". بسبب خاصية تقريب الأرقام في Solidity إلى الأقل، تكون القيمة النهائية لـ "redeemTokens" هي 1. وهذا يعني أن المهاجم برقم المرسل 0xa163 استرد تقريبًا كل رمز VELO المودع سابقًا باستخدام رمز soVELO بقيمة 1. في الوقت نفسه، حصل المهاجم 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، وإعادة رهن تشكيلة عملة soVELO مرة أخرى، بهدف جمع 2 وحدة من عملة soVELO، ثم تنفيذ الخطوات 3-8 المذكورة أعلاه مرة أخرى لتحقيق ربح من العملات الأساسية الأخرى. 10. يقوم المهاجم بتنفيذ الخطوة 9 عدة مرات ، ويسدد القروض السريعة ، ويخرج من السوق بربح.

كيفية استغلال 100 دولار للحصول على 6.5 مليون دولار

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

تتبع الأموال

قام المهاجمون بتحويل الأموال بعد وقت قصير من الاستيلاء على العائدات غير القانونية ، والتي تم تحويل معظمها إلى عناوين 4 التالية ، بعضها لمواصلة الهجوم في العنوان أخرى ، والبعض الآخر إلى غسيل الأموال:

1. 0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

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

بعد الهجوم ، حولت العنوان العائدات إلى * 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb *.

2. 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

المهاجم نقل 724277 USDC و 2353 VELO إلى هذا العنوان وحول USDC إلى Ether. ثم نقل جزءًا من الأموال على الفور إلى جسر السلسلة Stargate، بينما ظلت الأموال غير القانونية الباقية في هذا العنوان:

3. 0xbd18100a168321701955e348f03d0df4f517c13b

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

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003093c2b4 -> * 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795*。

4. 0x4fac0651bcc837bf889f6a7d79c1908419fe1770

تم نقل 563 WETH إلى هذا العنوان من قبل المهاجم ، ثم تم تحويلها إلى 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68 ، ولا توجد حاليًا أي أنشطة إضافية.

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

نصائح الأمان

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

بتصرف فريق ZAN، قامت كارا (بالحساب @Cara6289) و شيغ (بالحساب @SHXiGi) بكتابة هذه المقالة بشكل مشترك.