چگونه می توان قضاوت کرد که آیا به اصطلاح "هک" که برای یک پروژه کریپتو یا بلاک چین اتفاق افتاده است قانونی است یا اینکه فقط مکانیزمی برای پنهان کردن یک RUG است؟

بدیهی است که پس از اتفاقی که با MtGox یا QuadrigaCX یا موارد مشابهی رخ داد که بنیانگذاران ادعا کردند کلیدهای خصوصی را که اکثر دارایی‌های دیجیتال صرافی‌های خود را در اختیار دارند از دست داده‌اند در حالی که ناپدید می‌شوند یا بعداً مرده پیدا می‌شوند، افرادی که در حوزه کریپتو می‌شنوند به طور فزاینده‌ای مشکوک می‌شوند. هک کردن یک پروژه، و اولین فکری که به ذهن می رسد این است که بنیانگذاران اساساً صندوق را خالی کرده اند و با آن فرار کرده اند، این همان چیزی است که معمولاً RUG نامیده می شود.

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

ما فکر می کنیم که این مورد جالبی برای تجزیه و تحلیل است زیرا به درک بهتر اهمیت امنیت و ممیزی در قراردادهای هوشمند یا پروژه های مرتبط با بلاک چین به طور کلی کمک می کند.

ما به طور عینی اتفاقی را که برای پروژه مالی RING رخ داد، تجزیه و تحلیل خواهیم کرد، توکنی که در BSC (بایننس بلاک چین) راه اندازی شد.

قبل از ورود به هک، ابتدا پروژه و وضعیت قبل از آن را خلاصه می کنیم:

RING Financial قبل از هک

RING مالی یک پروژه DeFi با هدف دسترسی بیشتر DeFi برای جامعه DeFi و ارزهای دیجیتال بود. پروژه بلندپروازانه ای که می خواست یک پروتکل تولید گره ایجاد کند که توسط Node دارندگان اداره می شود و نقدینگی را به بیش از 300 پروتکل به طور همزمان تخصیص می دهد. هدف دسترسی به تمام پروتکل ها از طریق یک گره RING و از طریق RING Dapp بود.

این پروتکل‌ها توسط تیم تأیید شد و سپس جامعه به آنها رأی می‌داد که کجا تخصیص دهند. همان مفهوم رای دادن که در DAO دارید که RING را بسیار جذاب کرده است.

RING Financial همچنین بسیاری از فرآیند تحقیق و استقرار را برای یک Node Holder ساده کرده است. یک Dapp برای دسترسی به تمام Dapp های دیگر، بنابراین شما به جای 300 رابط مختلف با دسترسی ها و گره های خود، فقط به یک رابط نیاز دارید.

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

با این حال، استعداد و جاه طلبی همیشه کافی نیست و شما به تخصص و دانش نیاز دارید که در بازارهای جدید و نابالغ یک یافته نادر است و به همین دلیل است که RING Financial نتوانست به طور کامل به قول خود عمل کند.

پس واقعاً با RING Financial چه اتفاقی افتاد؟ و چرا هک شد؟ به لطف بلاک چین، ما تمام شواهد پزشکی قانونی مورد نیاز برای بررسی این موضوع و دیدن آسیب‌پذیری‌ها و دلیل آن را داریم. RING Financial کلاهبرداری نبود.

هک مالی RING در 5 دسامبر 2021 بین ساعت 2:01 و 2:06 UTC رخ داد.

بله، همه چیز فقط در 5 دقیقه اتفاق افتاد! با تشکر از اسکنر بلاک چین برای این جزئیات، به هر حال، ما دقیقاً در زیر پیوندهای تراکنش های مربوط به هک و همچنین آدرس قرارداد را برای کسانی که می خواهند جزئیات بیشتری را جستجو کنند، در اختیار شما قرار می دهیم.

در اینجا خلاصه ای است که نقصی را که مهاجم از آن سوء استفاده کرده است توضیح می دهد:

باید بدانید که قرارداد هوشمند RING Financial از چندین بخش تشکیل شده بود، یکی برای توکن و تمام داده‌های مربوط به آن و دیگری برای هر چیزی که مربوط به حسابداری گره‌ها و پاداش‌ها بود. بخشی از توکن دارای امنیت بود به طوری که فقط مدیر قرارداد می تواند داده های مهم این یکی را تغییر دهد تا مقداری کد را به شما نشان دهد، در اینجا هدر تابعی از قرارداد است که از طریق ویژگی "onlyOwner" محافظت می شود. که تصریح می کند که تابع فقط توسط مدیر قابل اجرا است:

تابعی که ندارد فقط مالک ویژگی (یا ویژگی معادل برای محافظت از دسترسی تابع) را می توان به معنای واقعی کلمه توسط هر کسی اجرا کرد.

حالا حدس بزنید چی؟ توابع موجود در بخش Nodes and Rewards این ویژگی را نداشتند، همانطور که با نگاه کردن به نام توابع زیر می بینید ( فقط مالک ویژگی گم شده است):

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

اکنون احتمالاً دو سؤال از خود می‌پرسید:

چگونه توسعه دهندگان می توانند چنین شکافی را رها کنند؟

پس از صحبت با توسعه دهندگان Solidity (زبانی که برای کدگذاری قراردادهای هوشمند در اتریوم استفاده می شود)، این یک خطا مربوط به ارث بردن نقش بین دو قرارداد هوشمند است، وراثت مفهومی از زبان برنامه نویسی است و برای اینکه شما را دچار سردرد نکنیم، ما به عبارت ساده باقی می ماند: اساساً، به احتمال زیاد شخصی که قرارداد را کدنویسی کرده است، فکر می کند که توابع قسمت Node نقش های امنیتی توابع قسمت Token را به ارث برده است، اما متاسفانه در Solidity اینطور نیست و لازم است که نقش هر یک از عملکردهای هر قرارداد، صرف نظر از پیوند آنها، دوباره تعریف شود. بنابراین نتیجه‌گیری ما در این مورد این است که توسعه‌دهنده یک متخصص نبوده و احتمالاً قرارداد را بدون صرف وقت برای خواندن دوباره آن، احتمالاً با عجله منتشر کرده است.

از کجا می دانید که این خود توسعه دهنده نیست که عمداً این نقص را ترک کرده است و کلاهبرداری نبوده است؟

اعتراض بسیار خوبی است و زمانی که در مورد نحوه انجام آن مطمئن نیستید، به راحتی می توان کلاهبرداری را فرض کرد قراردادهای هوشمندانه کار می کند اما در واقع بسیار آسان است که بی گناهی توسعه دهنده را فرض کنیم، زیرا او کل کد قرارداد هوشمند را به صورت عمومی در BSCSCAN.COM (معروف ترین اسکنر بلاک چین بایننس) در 19 نوامبر 2021 منتشر و تأیید کرد که یعنی بیش از دو هفته قبل از وقوع هک مالی RING. و همانطور که قبلا توضیح داده شد، نقص در قرارداد به رنگ BLACK ON WHITE نوشته شده بود و هر توسعه دهنده باتجربه ای متوجه آن می شد و واکنش نشان می داد، اما متاسفانه اولین کسی که اصلاً رحم نکرد. بنابراین واضح است که توسعه‌دهنده از این نقص آگاه نبوده است زیرا او این ریسک را نمی‌پذیرد که به کسی اجازه دهد پروژه مالی RING را در هر زمانی بکشد.

برای بازگشت به ادامه هک مالی RING، توسعه دهنده متوجه اشتباه خود شد و به سادگی قرارداد را مسدود کرد تا هرگونه توزیع پاداش را متوقف کند تا مهاجم استخر را به طور کامل خالی نکند. او سپس یک قرارداد Node را دوباره مستقر کرد، این بار با ویژگی امنیتی "onlyOwner". این قرارداد جدید Node توانست توزیع پاداش جدید را به درستی انجام دهد، با این تفاوت که خیلی دیر شده بود، زیرا در نتیجه هک تمام اعتماد به پروژه و تیم از بین رفته بود و فشار فروش باعث از بین رفتن و پایان توکن شد و پروژه.

برای نتیجه گیری، ما این داستان را انتخاب کردیم زیرا دو چیز مهم در مورد قراردادهای هوشمند و پروژه های رمزنگاری را نشان می دهد، هرگز قراردادی را با عجله کدنویسی نکنید و همیشه با شرکت های حسابرسی تماس بگیرید، زیرا وقتی هک اتفاق می افتد، برای نجات قایق خیلی دیر شده است. پروژه مالی RING مثال خوبی است، علاوه بر این، طبق ارتباطات خود، با شرکت های حسابرسی برای این دومین قرارداد Node تماس گرفته اند و تا زمانی که از امنیت آن مطمئن نشده اند، آن را به صورت عمومی در BSCSCAN ارسال نکرده اند. اما همانطور که قبلا گفته شد، برای RING Financial خیلی دیر شده بود و خسارت جبران ناپذیر بود.

در اینجا تمام لینک های اسکنر و آدرس قرارداد آمده است:

کیف پول در حال اجرای تراکنش برای هک اکسپلویت: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 بهره برداری هک تراکنش:

 TRX 1

    link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e

TRX 2

    link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003

TRX 3

    link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• منبع: https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/