تیم امنیتی کوینکس | بررسی خطرات امنیتی THORChain (RUNE)

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

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

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

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

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

ابتدا، بهتر است که کدهای قرارداد هوشمند 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 می‌دزدند:

حمله شماره ۱: دزدیدن بز از گله

آدرس های موجود در اتریوم به آدرس های خارجی و آدرس های قراردادی تقسیم می شوند. انتقال ETH به این دو نوع آدرس از طریق آدرس های خارجی اساساً متفاوت است. اسناد رسمی(https://docs.soliditylang.org/en/v0.8.12/contracts.html#receive-ether-function ) سالیدیتی بیان می کند که یک آدرس قرارداد باید یک تابع دریافت اتر را قبل از انجام انتقال اجرا کند.

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

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

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

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

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

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

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

در AmpTokensRecipient(recipientImplementation).tokensReceived()

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

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

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

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

مرحله ۳: برای برقراری ارتباط با رابط setInterfaceImplementer باید ازERC-1820 کمک بگیرید.

ERC-1820 Address: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

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

در اینجا، toAddrآدرس دریافت کننده انتقال AMP است،

interfaceHash is the hash of AmpTokensRecipient:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

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

مرحله ۴: در این مرحله کاربر را فریب می دهند تا AMP را به toAddr منتقل کند تا یک پل برگشتی ایجاد کند و همزمان RUNE او را بدزدند.

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

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

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

مرحله ۲: یک جفت معاملاتی در یونی سواپ یا هر مرکز مبادله دیگری ایجاد می کند.

مرحله ۳: هکر اطلاع می دهد که به همه کاربرانی که رمز ارز RUNE در کیف پول خود دارند ایردراپ خواهد داد.

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

علاوه بر این، به منظور بررسی بیشتر ریسک امنیتی کد قرارداد THORChain، تیم امنیتی کوینکس با دو سازمان امنیتی معروف در این صنعت، یعنی SlowMist و تیم امنیتی Paidunگفتگو کرد.

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

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

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

۱. برای حمله شماره یک: هنگام انتقال، مصرف تخمینی گاز را پیگیری کنید. برای انتقال معمولی ETH، هزینه گاز 21000 بسیار بالا است. اگر مصرف گاز بسیار بیشتر از این رقم نیز هست مراقب باشید.

۲. برای حمله شماره دو: توکن های خود را با استفاده از کیف پول های مختلف جدا کنید. شما می توانید توکن های مختلف را در آدرس های مختلف ذخیره کنید. در مورد آدرس کیف پول داغ ارائه شده توسط صرافی ها احتیاط بیشتری لازم است.

۳. برای حمله شماره سه: طمع سرچشمه همه بدی ها و ضرر ها است؛ کورکورانه در هیچ رویداد ایردراپ یا نظیر آن شرکت نکنید.

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

کوینکس امن ترین و مطمئن ترین صرافی برای ایرانیان

ما را دنبال کنید توییتر | کانال تلگرام | اینستاگرام

تماس با ما تیکت آنلاین | گروه تلگرام

درباره‌ ما وب سایت | اطلاعیه ها | اپلیکیشن