از طریق تجزیه و تحلیل کد قرارداد و منطق Thorchain (Rune) ، تیم امنیتی Coinex خطرات زیر را پیدا کرده است.

ما می توانیم بگوییم که 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 تماس می گیرد ، و قرارداد تماس B را منعقد می کند:

هنگامی که قرارداد یک قرارداد 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 به این دو نوع آدرس از طریق آدرس های خارجی اساساً متفاوت است. مستندات رسمی استحکام بیان می کند که یک آدرس قرارداد قبل از انجام نقل و انتقالات باید عملکرد دریافتی اتر را پیاده سازی کند.

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

هنگامی که قرارداد حمله انتقال ETH را از یک کاربر دریافت می کند ، "یک بز از یک گله" می کند - این قرارداد نشانه های RUNE کاربر را در این فرآیند سرقت می کند.

حمله №2: حمله داخلی

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

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

کد قرارداد AMP نشان می دهد که اجرای نهایی انتقال عبارت است از: _transferbypartition. در همین حال ، دو تماس مربوط به Transferhook وجود دارد: _callpretransferhooks (قبل از انتقال) و _callpostransferhooks (پس از انتقال). به طور خاص ، _callpretransferhooks برای آدرس از آدرس است ، در حالی که _callpostransferhooks برای آدرس (یعنی آدرس دریافت کننده) است.

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

ما می توانیم بگوییم که تنها تماس تلفنی که مهاجمان می توانند از آن سوءاستفاده کنند ، AmptokenSrecipient (گیرنده implementation) است . tokensreceived ()

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

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

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

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

آدرس ERC-1820: 0x1820A4B7618BDE71DCE8CDC73AAB6C95905FAD24

رابط قرارداد: SetInterfaceImplementer (آدرس Toaddr ، Bytes32 InterfaceHash ، مجری آدرس)

به طور خاص ، Toaddr آدرس دریافت انتقال AMP است ، InterfaceHash هش از Amptokensrecipient است: 0xfa352d6368bc643bcf9d528ffa5dd3e826137bc42f935045c6c227bd4c72aaa

مجری آدرس حمله به دست آمده در مرحله 2 است.

مرحله 4: یک کاربر را فریب دهید تا AMP را به Toaddr منتقل کند تا پاسخ به تماس را انجام دهد و همزمان Rune خود را به سرقت ببرد.

حمله №3: حمله فیشینگ

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

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

مرحله 2: ایجاد یک جفت بازرگانی در UniSwap یا هر مبادله دیگری.

مرحله 3: به همه کاربران/آدرس هایی که نشانه های Rune را در اختیار دارند ، به همه کاربران ارائه دهید.

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

علاوه بر این ، به منظور تأیید بیشتر خطر امنیتی کد قرارداد Thorchain ، Coinex با تیم امنیتی از Slowmist و Peckshield ، دو سازمان امنیتی مشهور در صنعت بحث کرده است. تأیید شده توسط Slowmist و Peckshield ، خطر امنیتی که در بالا ذکر شد وجود دارد.

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

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

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

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

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

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