چطور از باگ‌بانتی کسب درآمد کنیم؟ ۷ استراتژی یافتن باگ‌ در قراردادهای هوشمند

آیا تا به حال به باگ بانتی (Bug Bounty) شغل پیداکردن باگ در کدهای برنامه‌نویسی فکر کرده‌اید؟ این شغل به‌طرز شگفت‌آوری یک درآمد عالی دارد؛ زیرا بخش جدایی‌ناپذیر محافظت اکوسیستم در برابر هک است. اخیرا یک توسعه‌دهنده توانسته باگی به ارزش ۷ میلیارد دلار را در قرارداد هوشمند پالیگان (Polygon) پیدا کند و بابت گزارش این باگ ۲.۲ میلیون دلار پاداش گرفته است. در این مطلب از اکسران  می‌خواهیم ببینیم، این باگ هانتر خوش‌شانس چطور موفق به پیدا کردن باگ شده است. ضمنا ابزارهای مفید و استراتژی‌ یافتن باگ را نیز معرفی می‌کنیم.

 

 

نمونه‌ای از باگ در قرارداد هوشمند پالیگان

بلاکچین متیک (Matic) در ۳۱ ماه مه ۲۰۲۰ (۱۱ خرداد ۱۳۹۹) فعال شد و بعدا به پالیگان (Polygon) تغییر نام داد. پالیگان یک بلاکچین سازگار با ماشین مجازی اتریوم (EVM) است که به دلیل کارمزد گس پایین و زمان کوتاه ایجاد بلاک میان کاربران محبوب شد. این زنجیره اخیرا نیز برای استفاده از فناوری Zk-Rollup اقدام کرده است.

با نگاهی به بلاک شماره صفر، اولین بلاک که به نام جنسیس بلاک (Genesis Block) شناخته می‌شود، ده تراکنش را مشاهده می‌کنید. یکی از این تراکنش‌ها قراردادی به نام MRC20 را ایجاد کرده است.

قرارداد MRC20 در جنسیس بلاک پالیگان چیست؟

برای ارسال توکن بومی باید گس پرداخت شود. تیم توسعه‌دهنده پالیگان قراردادی را ایجاد کرد که به موجب آن یک کاربر می‌تواند تراکنشی را برای ارسال اتر (ETH) به کاربر دیگر امضا کند، در حالی که کاربر سوم (اپراتور) می‌تواند کارمزد گس این تراکنش را پرداخت کند. این قابلیت که «تراکنش متا» (Meta Transaction) نام دارد با معرفی استاندارد EIP-۷۱۲ رایج شد.

تقریبا ۱۰ میلیارد توکن متیک (MATIC) به تسهیل تراکنش‌های بدون گس تخصیص گرفت. اما به هر حال این قرارداد اشکالات و آسیب‌پذیری‌هایی داشت که می‌توانست موجب تخلیه کل موجودی شود.

در ۳ دسامبر ۲۰۲۱ (۱۲ آذرماه ۱۴۰۰) قهرمان داستان وارد ماجرا شد. توسعه‌دهنده‌ای به نام لئون اسپیس‌واکر (Leon Spacewalker) گزارشی را به برنامه باگ بانتی سایت ایمیونیفای (Immunefi) ارسال کرد. او در این گزارش جزئیات دقیق عملکرد تابع را ارائه کرده بود. قهرمان دوم ماجرا که او را هکر کلاه سفید شماره ۲ (Whitehat) می‌نامیم، یک روز بعد این آسیب‌پذیری را گزارش کرد. خبر مربوط به آن را می‌توانید از این لینک مشاهده کنید.

اما به هر حال قبل از هر گونه اقدامی از قبیل فورک (Fork) یا رفع باگ، در ۵ دسامبر ۲۰۲۱ (۱۴ آذر ۱۴۰۰) حدود ۸۰۰٬۰۰۰ توکن متیک به سرقت رفت. حالا سوال این است که آسیب‌پذیری قرارداد چه بود؟ چرا برای مدت طولانی کسی متوجه این اشکال نشده بود؟ چطور این باگ کشف شد؟

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

تصویر زیر تابعی را نشان می‌دهد که انجام معاملات بدون گس را امکان‌پذیر می‌کند:

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

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

تابع ecrecovery در اصل یک آبجکت Wrapper برای دربرگرفتن تابع Solidity ecrecover است که امکان انتقال مجموعه‌ای از امضاها را فراهم می‌کند.

با استفاده از تابع فوق می‌توانیم بفهمیم که تراکنش‌های امضا‌شده از کجا می‌آیند. توجه داشته باشید که در برنامه‌نویسی سالیدیتی (Solidity) دستور “Return 0” به این معنی است که در صورت خطا، مقدار برگردانده می‌شود. اکنون تابع ecrecovery این دستور را کپی کرده است و در صورتی که خطایی وجود داشته باشد، مقدار صفر را برمی‌گرداند. همانطور که بسیاری از توسعه‌دهندگان می‌دانند، این موضوع می‌تواند ترسناک باشد. اگر تابع در صورت وجود خطا، صفر را برگرداند به این معنی است که آدرس برگشت صفر نیست!

کد مطابق تصویر زیر بود:

در حالی که احتمالا باید به صورت زیر نوشته می‌شد:

بنابراین لازم نیست آدرس را بررسی کنیم تا ببینیم منجر به خطا شده است یا خیر. چراکه آخرین خط کد در تابع TransferWithSig انتقال را انجام می‌دهد و بررسی‌های لازم را باید در این خط انجام دهیم.

اکنون تابع TransferFrom، تنها تابع Transfer را که در تصویر بالا مشاهده می‌کنید، فرا می‌خواند. همانطور که متوجه شدید این تابع، From Address را بررسی نمی‌کند تا ببیند آیا پول کافی دارد یا خیر.

بنابراین شخص می‌تواند یک امضای نامعتبر را ارسال کند و قرارداد MRC20 به جای اینکه مقدار را از تابع ecrecovery برگرداند، همچنان پول را به آدرس ارسال می‌کند. این باگ همان اشکالی است که می‌توانست منجر به تخلیه ۹,۹۹۹,۹۹۳,۰۰۰ واحد توکن متیک شود، چراکه قرارداد MRC20 پول را مستقیما از خودش می‌فرستد.

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

چرا باگ‌‌ قراردادهای هوشمند تا مدت‌ها کشف نمی‌شوند؟

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

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

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

معرفی استراتژی‌های مهم در باگ بانتی

آیا می‌دانید افرادی مانند لئون در مثال بالا یا سایر باگ هانترها از چه مهارت‌هایی برای پیداکرن آسیب‌پذیری یا افشای باگ استفاده می‌کنند؟ با فرض اینکه شما اصول قراردادهای هوشمند را می‌دانیدُ نکات زیر ارائه می‌شود. ضمنا فراموش نکنید که یادگیری زبان برنامه‌نویسی سالیدیتی مهم‌ترین پیش‌نیاز است.

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

پیشنهاد لئون برای پیداکردن باگ این است که ابتدا «نقاط قوت و توانایی‌های خود را بیابید.» اما منظور او چیست؟ به عبارت دیگر باید گفت چیزی را در خودتان بیابید که شما را از سایر هکرها متمایز می‌کند. جامعه و کامیونیتی هر پلتفرم باید بتواند تمام فضای قرارداد هوشمند را پوشش دهد، بنابراین باید بخشی را انتخاب کنید که عملکرد بهتری در آن دارید.

۱. یک پروژه بیابید و باگ‌های آن را جستجو کنید

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

۲. با توجه به یک باگ مشخص پروژه‌ها را بررسی کنید

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

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

۳. سرعت عمل داشته باشید

پروژه‌هایی که نیازمند باگ هانتینگ هستند و می‌خواهند از توانایی شکارچیان باگ برای قراردادهای هوشمند خود استفاده کنند، باید در برنامه‌های باگ بانتی مانند Immunefi ثبت نام کنند. بنابراین هر چقدر زودتر از سایر شکارچیان اقدام کنید، فرصت بیشتری برای پیداکردن باگ دارید.

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

۴. خلاقانه عمل کنید

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

۵. از ابزارها برای پیداکردن باگ استفاده ‌کنید

باگ هانترها معمولا از ابزارهایی مانند افزونه توسعه‌دهنده ویژوالVSCode Solidity ،Hardhat ،Foundry ،Brownie ، Etherscan و ابزارهای متعدد دیگری استفاده می‌کنند.

یک استراتژی رایج برای پیداکردن باگ این است که VSCode را بارگذاری کنید. سپس کد را با استفاده از افزونه ویژوال سالیدیتی به VSCode اضافه کنید و خط‌به‌خط کدها را بررسی کنید تا باگ‌های متداول را بیابید.

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

۶. از پروژه‌های آدیت‌شده غافل نشوید

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

۷. دانش خاص مربوط به این صنعت را یاد بگیرید

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

بنابراین سعی کنید در یک حوزه خاص مانند صرافی‌های غیرمتمرکز (Decentralized Exchanges)، پروتکل‌های استقراض (Borrowing Protocols) یا توکن‌های غیرمثلی (NFT) دانش تخصصی به‌دست آورید. اگر در حوزه امنیت یا وب ۳ دانش و تخصص فوق‌العاده‌ای داشته باشید، قطعا نسبت به سایر شکارچیان باگ موقعیت بهتری دارید.

سخن پایانی

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