بر اساس گزارش خزانه داری THORCchain برای سه ماهه اول 2022 که در 1 آوریل منتشر شد، این زنجیره علیرغم تأثیر دوگانه کسادی مداوم بازار و عوامل ژئوپلیتیکی بسیار ناپایدار، رشد درآمدی را ثبت کرد. داده های عمومی نشان می دهد که THORChain در سه ماهه اول 2022 2.17 میلیارد دلار درآمد ثبت کرده است. THORChain که به عنوان “نسخه زنجیره ای متقابل UniSwap” شناخته می شود، با تکیه بر مزیت های منحصر به فرد خود جایگاهی در بازار معاملات زنجیره ای متقابل به دست آورد و در بین سرمایه گذاران به رسمیت شناخته شد.

پشت همه این زرق و برق ها، THORChain نیز عمیقاً با هک کردن مشکل دارد. این زنجیره از زمانی که روی اتریوم راه اندازی شد، مکرراً دچار نقض امنیتی شده است، واقعیتی که امنیت آن را مورد تردید قرار می دهد. در 11 آوریل، THORChain توئیتی درباره حملات فیشینگ منتشر کرد و به کاربران هشدار داد که با آنها تعامل نداشته باشند. [DeTHOR] یا دیگر توکن های ناشناخته در کیف پول آنها، که بار دیگر نگرانی ها را در مورد مسائل امنیتی آن افزایش داد.

تیم امنیتی CoinEx در حالی که یک سیستم امنیتی سالم برای محصولات CoinEx ایجاد می کند، رویدادهای امنیتی در فضای بلاک چین را نیز پیگیری می کند تا به کاربران کمک کند امنیت پروژه های مختلف را از منظر امنیت فنی بهتر درک کنند و ریسک سرمایه گذاری را کاهش دهند. با هدف بهبود معیارهای امنیتی برای بخش بلاک چین، تیم امنیتی CoinEx خطرات امنیتی THORChain (RUNE) را تجزیه و تحلیل کرده است. این تیم امیدوار است که THORChain بتواند خطرات زیر را با بهینه سازی کدهای قرارداد هوشمند مربوطه یادداشت و کاهش دهد. علاوه بر این، این مقاله همچنین هشداری برای کاربران است و به آنها یادآوری می کند که از امنیت دارایی ها بیشتر آگاه باشند و از ضرر و زیان دارایی جلوگیری کنند.

THORChain (RUNE) چقدر امن است؟

از طریق تجزیه و تحلیل کد قرارداد و منطق THORChain (RUNE)، تیم امنیتی CoinEx خطرات زیر را پیدا کرده است:

برای شروع، اجازه دهید کد قرارداد THORChain (RUNE) را بررسی کنیم:

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code

می توان گفت که RUNE یک توکن استاندارد ERC-20 است. لازم به ذکر است که جدا از رابط ERC-20، THORChain (RUNE) یک رابط اضافی ارائه می دهد:

با توجه به transferTo (همانطور که در تصویر بالا نشان داده شده است)، THORChain (RUNE) از tx.origin استفاده می‌کند که یکی از دلایل پشت خطرات امنیتی آن است. در اینجا، ما باید تفاوت بین tx.origin و msg.sender را توضیح دهیم:

تصویر زیر توضیح می‌دهد که وقتی یک آدرس معمولی قرارداد هوشمند را فراخوانی می‌کند چه اتفاقی می‌افتد:

در چنین مواردی، msg.sender = account.address، و tx.origin = account.address، یعنی msg.sender دقیقاً همان tx.origin است.

وقتی یک حساب قرارداد A را صدا می کند و قرارداد A قرارداد B را می خواند، موارد زیر اتفاق می افتد:

وقتی قرارداد A قرارداد B را فراخوانی می کند (همانطور که در بالا نشان داده شده است)، می توانیم بگوییم که msg.sender برابر با tx.origin در قرارداد A است.

با این حال، در قرارداد B، msg.sender = contractA.address، در حالی که tx.origin = account.address. بنابراین، tx.origin مانند یک متغیر سراسری است که کل پشته تماس را طی می کند و آدرس حسابی را که در ابتدا تراکنش را ارسال کرده است، برمی گرداند. این مسئله مهم است: تا به امروز، تقریباً تمام حملات شناخته شده علیه THORChain (RUNE) به tx.origin مربوط می شود.

اکنون بیایید دریابیم که مهاجمان چگونه توکن های RUNE کاربران را از طریق tx.origin می دزدند:

حمله شماره 1: غارت یک بز از گله

آدرس های موجود در اتریوم به آدرس های خارجی و آدرس های قراردادی تقسیم می شوند. انتقال ETH به این دو نوع آدرس از طریق آدرس های خارجی اساساً متفاوت است. در اسناد رسمی از solidity بیان می کند که یک آدرس قرارداد باید یک تابع دریافت اتر را قبل از انجام انتقال اجرا کند.

با توجه به ویژگی‌های tx.origin، هکرها ممکن است یک قرارداد Attack بسازند:

هنگامی که قرارداد Attack یک انتقال ETH از یک کاربر دریافت می کند، “بز را از گله دزد می کند” – قرارداد در این فرآیند توکن های RUNE کاربر را می دزدد.

حمله شماره 2: حمله داخلی

حمله داخلی نوع خاصی از حمله است. هنگامی که سعی می کنید RUNE یک کاربر را از طریق یک حمله داخلی بدزدید، هکر باید یک توکن متوسط ​​داشته باشد. علاوه بر این، توکن باید قراردادهای شخص ثالث را نیز فراخوانی کند. با توجه به سوابق انتقال RUNE در اتریوم، برخی از مهاجمان RUNE را از طریق انتقال توکن AMP هک کردند.

توکن AMP از استاندارد ERC-1820 برای مدیریت ثبت هوک و بررسی اینکه آیا هوک در هر انتقال ثبت می شود یا خیر، استفاده می کند. اگر Hook ثبت شده باشد، Hook فراخوانی می شود.

کد قرارداد AMP Token نشان می دهد که اجرای نهایی انتقال عبارت است از: _transferByPartition. در همین حال، دو تماس مربوط به انتقال هوک وجود دارد: _callPreTransferHooks (قبل از انتقال) و _callPostTransferHooks (بعد از انتقال). به طور خاص، _callPreTransferHooks برای آدرس from است، در حالی که _callPostTransferHooks برای آدرس to (یعنی آدرس دریافت کننده) است.

برای کاربران عادی، سرقت توکن ها از خودشان بی معنی است. بنابراین، مهاجمان ممکن است از _callPostTransferHooks سوء استفاده کنند. بیایید اکنون کدهای _callPostTransferHooks را بررسی کنیم.

IAmpTokensRecipient(recipientImplementation).tokensReceived()

می توانیم بگوییم که تنها تماس برگشتی که مهاجمان می توانند از آن سوء استفاده کنند IAmpTokensRecipient(recipientImplementation).tokensReceived() است.

در مرحله بعد، نحوه استفاده از این تماس را برای انتقال RUNE کاربر در حین انجام یک انتقال توکن AMP نشان خواهیم داد.

مرحله 1: یک قرارداد تماس مورد نیاز است (مانند شکل زیر):

گام 2: قرارداد را برای به دست آوردن آدرس حمله مستقر کنید.

مرحله 3: برای ثبت رابط، با رابط قرارداد ERC-1820 (setInterfaceImplementer) تماس بگیرید.

آدرس ERC-1820: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

رابط قرارداد: setInterfaceImplementer (آدرس toAddr، bytes32 interfaceHash، address implementer)

به طور خاص، toAddr آدرس دریافت کننده انتقال AMP است،

interfaceHash为AmpTokensRecipient的hash:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

interfaceHash هش AmpTokensRecipient است:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

پیاده کننده آدرس حمله ای است که در مرحله 2 به دست آمده است.

مرحله 4: یک کاربر را فریب دهید تا AMP را به Addr منتقل کند تا یک تماس برگشتی ایجاد کند و همزمان RUNE او را بدزدد.

حمله شماره 3: حمله فیشینگ

همانطور که از نام آن پیداست، در یک حمله فیشینگ، مهاجم قول می‌دهد که مزایای باورنکردنی را برای فریب دادن کاربران به انجام عملیات‌های قراردادی خاص از بین ببرد. در اینجا یک حمله فیشینگ رایج را معرفی می کنیم.

مرحله 1: مهاجم یک توکن ERC-20 صادر می کند و ممکن است آن را در هر رابط قراردادی که شامل امضا باشد بنویسد.

گام 2: یک جفت معاملاتی در Uniswap یا هر مبادله دیگری ایجاد کنید.

مرحله 3: ارائه airdrops به همه کاربران/آدرس هایی که توکن های RUNE دارند.

کار اولیه حمله فیشینگ اساساً از طریق این مراحل بالا تکمیل می شود. در مرحله بعد، مهاجم فقط باید منتظر بماند تا کاربران در مبادله معامله کنند و کاربران پس از انجام عملیاتی مانند تایید، انتقال و غیره خطر از دست دادن RUNE خود را دارند.

علاوه بر این، به منظور بررسی بیشتر ریسک امنیتی کد قرارداد THORChain، CoinEx با تیم امنیتی SlowMist و PeckShield، دو آژانس امنیتی معروف در صنعت، گفتگو کرده است. با تایید SlowMist و PeckShield، خطر امنیتی ذکر شده در بالا وجود دارد.

تاکنون چندین نوع حمله و همچنین خطرات امنیتی که کاربران در معرض آن قرار دارند را پوشش داده ایم.

چگونه تیم پروژه باید کد قرارداد را بهینه کند تا خود را ایمن تر کند و از دارایی های کاربران محافظت کند؟

تنها پاسخ این است که در استفاده از tx.origin محتاط باشید.

چگونه کاربران عادی می توانند خطرات را کاهش دهند و از دارایی های خود در برابر حملاتی که اجتناب ناپذیر به نظر می رسد محافظت کنند؟ تیم امنیتی CoinEx پیشنهادات زیر را ارائه می دهد:

1. برای حمله شماره 1: هنگام انتقال، مصرف تخمینی گاز را پیگیری کنید. برای انتقال عادی ETH، هزینه گاز 21000 بیش از حد کافی است. اگر مصرف گاز بسیار بیشتر از این رقم است مراقب باشید.
2. برای حمله شماره 2: توکن های خود را با استفاده از کیف پول های مختلف جدا کنید. شما می توانید توکن های مختلف را در آدرس های مختلف ذخیره کنید. در مورد آدرس کیف پول داغ ارائه شده توسط صرافی ها احتیاط بیشتری لازم است.
3. برای حمله شماره 3: طمع سرچشمه همه بدی ها است. کورکورانه در هیچ رویداد airdrop شرکت نکنید.

امنیت همیشه یکی از دغدغه های اصلی در بخش بلاک چین بوده است. همه بازیکنان، از جمله تیم‌های پروژه و صرافی‌ها، باید امنیت را در طول عملیات پروژه در اولویت قرار دهند، دارایی‌های کاربران را ایمن و ایمن نگه دارند، و به طور مشترک رشد سالم صنعت بلاک چین را ارتقا دهند.