هک بدون باگ کد چطور ممکن است؟ درس‌های اکسپلویت زیرساختی در دیفای

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

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

اکسپلویت زیرساختی چیست و چه فرقی با باگ کد دارد؟

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

باگ کد به خطاهایی گفته می‌شود که در منطق برنامه‌نویسی قرارداد هوشمند وجود دارد؛ مثلاً محاسبه اشتباه در فرمول‌های AMM، ضعف در بررسی ورودی‌ها، یا آسیب‌پذیری‌های reentrancy. این نوع باگ‌ها توسط آدیت قرارداد هوشمند قابل کشف هستند.

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

• مدیریت کلیدهای خصوصی — کسانی که بر قراردادها کنترل دارند
• اوراکل‌های قیمت — منابعی که داده‌های قیمت را به قراردادها می‌دهند
• بریج‌های کراس‌چین — پل‌هایی که دارایی را بین شبکه‌ها منتقل می‌کنند
• سیستم‌های گاورننس — مکانیزم‌های رأی‌گیری و تصمیم‌گیری
• وابستگی‌های خارجی — سرویس‌هایی که پروتکل به آن‌ها متکی است

به زبان ساده: کد قرارداد هوشمند ممکن است کاملاً بی‌نقص باشد، اما اگر کلید خصوصی مدیر پروتکل در معرض خطر قرار بگیرد، هکر می‌تواند هر دارایی‌ای را برداشت کند — بدون اینکه حتی یک خط کد را تغییر داده باشد.

انواع آسیب‌پذیری‌های زیرساختی در دیفای

حمله به کلیدهای خصوصی و مدیریت دسترسی

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

روش‌های دزدیده شدن کلیدهای خصوصی متعدد است:

• مهندسی اجتماعی: فریب اعضای تیم از طریق ایمیل‌های فیشینگ یا پیام‌های جعلی
• بدافزار: نصب keylogger یا trojan روی سیستم توسعه‌دهندگان
• ضعف در امنیت عملیاتی (OPSEC): نگه‌داشتن کلیدهای خصوصی در محل‌های ناامن
• نفوذ داخلی: کارمند یا همکار ناراضی که به کلیدها دسترسی دارد
• آسیب‌پذیری سخت‌افزار: ضعف در کیف پول‌های سخت‌افزاری یا HSM

برای حفاظت از امنیت کیف پول در پروتکل‌های دیفای، استفاده از مکانیزم چندامضایی (Multisig) حیاتی است — اما حتی این هم کافی نیست اگر مدیریت امضاکنندگان ضعیف باشد.

آسیب‌پذیری اوراکل قیمت

اوراکل‌های قیمت، پل ارتباطی بین دنیای واقعی و قراردادهای هوشمند هستند. پروتکل‌های وام‌دهی دیفای مثل Aave یا Compound برای تعیین ارزش وثیقه و محاسبه نسبت وام، به قیمت‌های اوراکل وابسته‌اند.

اگر مهاجمی بتواند قیمتی که اوراکل گزارش می‌دهد را دستکاری کند، می‌تواند:

• با وثیقه‌ای کم‌ارزش، وام‌های بزرگ بگیرد
• باعث لیکوییدیشن ناخواسته موقعیت‌های دیگران شود
• قیمت را مصنوعی بالا ببرد و دارایی‌های گران‌قیمت را با قیمت پایین بخرد

حملات flash loan اغلب با دستکاری اوراکل همراه هستند — مهاجم در یک تراکنش اتمیک، قیمت را دستکاری می‌کند، از این دستکاری بهره می‌برد و همه چیز را به حالت اول برمی‌گرداند. این کار بدون هیچ باگی در کد قرارداد هوشمند انجام می‌شود.

ضعف در مکانیزم بریج و کراس‌چین

بریج‌های کراس‌چین از پیچیده‌ترین و آسیب‌پذیرترین بخش‌های اکوسیستم دیفای هستند. یک بریج باید دو شبکه کاملاً مجزا را به هم متصل کند — هر کدام با قوانین، زمان‌بندی و مکانیزم تأیید تراکنش خودشان.

آسیب‌پذیری‌های رایج در بریج‌ها عبارتند از:

• ضعف در سیستم تأیید امضا: هکر امضاهای جعلی تولید می‌کند
• مشکل در مکانیزم اعتبارسنجی: تراکنش‌های جعلی به عنوان معتبر قبول می‌شوند
• تمرکز در validator ها: تعداد کمی از validator ها کنترل بریج را دارند
• آسیب‌پذیری در پیاده‌سازی: مشکلات فنی در نحوه لاک کردن و آزاد کردن دارایی

بریج‌ها مجموعاً بیش از ۲ میلیارد دلار از دست داده‌اند — رقمی که هیچ نوع دیگری از هک در دیفای به آن نرسیده است.

نمونه‌های واقعی اکسپلویت زیرساختی

هک Ronin Bridge — ۶۲۵ میلیون دلار

مارس ۲۰۲۲: بزرگ‌ترین هک تاریخ دیفای رخ داد. Ronin Bridge، پل ارتباطی بازی Axie Infinity با شبکه خرید اتریوم و اتریوم، ۶۲۵ میلیون دلار را از دست داد. اما نکته جالب اینجاست: هیچ باگی در کد قرارداد هوشمند وجود نداشت.

چه اتفاقی افتاد؟ Ronin از یک سیستم ۹ validator استفاده می‌کرد که برای تأیید تراکنش‌ها نیاز به ۵ امضا داشت. هکرها (بعداً مشخص شد گروه Lazarus کره شمالی هستند) توانستند ۵ کلید خصوصی validator را به دست بیاورند:

• ۴ کلید مستقیماً در اختیار Sky Mavis (شرکت سازنده Axie) بود
• یک کلید متعلق به Axie DAO بود که Sky Mavis دسترسی موقت داشت — اما این دسترسی موقت هرگز لغو نشده بود

با ۵ امضا، هکر توانست دو تراکنش جعلی تأیید کند: یکی ۱۷۳,۶۰۰ ETH و دیگری ۲۵.۵ میلیون USDC. این هک نه از طریق باگ در کد، بلکه از طریق ضعف در مدیریت دسترسی و کلیدهای خصوصی رخ داد.

هک KelpDAO 2026 — ۲۹۲ میلیون دلار

در سال ۲۰۲۶، پروتکل Liquid Staking و Restaking متعلق به KelpDAO هدف یکی از بزرگ‌ترین اکسپلویت‌های تاریخ اخیر قرار گرفت. هکرها از ضعف در مکانیزم oracle قیمت‌گذاری rsETH استفاده کردند — نه از باگ در کد قرارداد.

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

حمله Euler Finance

مارس ۲۰۲۳: پروتکل وام‌دهی Euler Finance در یک حمله flash loan پیچیده ۱۹۷ میلیون دلار از دست داد. اگرچه این حمله از یک باگ در منطق قرارداد استفاده کرد، اما عمق آسیب‌پذیری در نحوه طراحی مکانیزم‌های نقدینگی و اوراکل‌های داخلی بود.

نکته جالب: هکر پس از مذاکرات، ۱۷۷ میلیون دلار را بازگرداند — که نشان می‌دهد حتی هکرها گاهی آماده مذاکره هستند. برای مطالعه بیشتر درباره این نوع رویدادها، Rekt News یکی از بهترین منابع تحلیلی هک‌های دیفای است.

چرا آدیت کد کافی نیست؟

آدیت قرارداد هوشمند یک گام ضروری اما ناکافی است. در اینجا دلایل محدودیت آدیت را بررسی می‌کنیم:

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

۲. محدودیت زمانی: یک آدیت معمولاً چند هفته طول می‌کشد. در این مدت ممکن است تغییرات جدیدی به کد اضافه شود که آدیت نشده باشند.

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

۴. اتکا به فرضیات: آدیتورها فرض می‌کنند که اوراکل‌ها دقیق هستند، کلیدهای مدیریتی امن هستند، و تیم صادقانه عمل می‌کند. این فرضیات در دنیای واقعی لزوماً درست نیستند.

طبق آمار Immunefi، بزرگترین پلتفرم bug bounty کریپتو، بیش از ۵۰٪ از مبلغ کل دزدیده‌شده در دیفای از طریق آسیب‌پذیری‌های زیرساختی و خارج از کد قرارداد بوده است، نه باگ‌های قرارداد هوشمند.

همچنین، کلاهبرداری‌های کریپتو اغلب از همین زیرساخت‌های ضعیف بهره می‌برند — ضعف انسانی مهم‌ترین عامل است.

راهکارهای پیشگیری از اکسپلویت زیرساختی

مدیریت کلیدهای چندامضایی

مکانیزم چندامضایی (Multisig) یکی از مهم‌ترین ابزارهای امنیتی است، اما پیاده‌سازی صحیح آن نیاز به دقت دارد:

• تنوع جغرافیایی: امضاکنندگان باید در مناطق مختلف جهان باشند
• استقلال سازمانی: چند نفر از یک شرکت نباید اکثریت امضاها را داشته باشند
• timelock: تغییرات مهم باید با تأخیر (مثلاً ۴۸ ساعت) اعمال شوند تا جامعه زمان واکنش داشته باشد
• آستانه مناسب: نسبت ۳/۵ یا ۴/۷ برای تراکنش‌های بزرگ توصیه می‌شود
• آموزش امنیتی: همه امضاکنندگان باید آموزش OPSEC دیده باشند

برای پروتکل‌های ییلد فارمینگ و سایر پروتکل‌های با TVL بالا، استفاده از Safe (سابقاً Gnosis Safe) به عنوان استاندارد صنعت شناخته می‌شود.

نظارت آنی و سیستم هشدار

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

• تراکنش‌های غیرعادی را در زمان واقعی شناسایی کنند
• در صورت تغییر ناگهانی TVL بیش از حد آستانه، هشدار فوری بدهند
• فعالیت قراردادها را با Forta Network یا ابزارهای مشابه مانیتور کنند
• برای تراکنش‌های بزرگ تأخیر اجباری (circuit breaker) داشته باشند

تمرکززدایی واقعی vs. ظاهری

بسیاری از پروتکل‌هایی که ادعای غیرمتمرکز بودن دارند، در واقع توسط یک تیم کوچک کنترل می‌شوند. این «تمرکززدایی ظاهری» خطرناک است چون:

• کاربران فکر می‌کنند ریسک متمرکز ندارند
• اما در واقع نقطه شکست واحد (single point of failure) وجود دارد
• هک یا سهل‌انگاری یک تیم می‌تواند کل پروتکل را نابود کند

تمرکززدایی واقعی یعنی هیچ نهاد واحدی نتواند به تنهایی تصمیمات حیاتی بگیرد — نه از طریق گاورننس، نه از طریق کلیدهای مدیریتی. امنیت اتریوم به عنوان یک شبکه، مثالی از تمرکززدایی واقعی در لایه پروتکل است.

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

آینده امنیت دیفای — از آدیت تا امنیت کل سیستم

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

ارزیابی امنیتی جامع (Holistic Security Assessment): به جای فقط آدیت کد، تمام لایه‌های پروتکل ارزیابی می‌شوند؛ از زیرساخت فنی تا فرایندهای عملیاتی و رفتار تیم.

بیمه غیرمتمرکز: پروتکل‌هایی مثل Nexus Mutual بیمه‌ای برای ریسک‌های دیفای ارائه می‌دهند. اگرچه هنوز محدودیت‌هایی دارند، اما در حال رشد هستند.

Zero-Knowledge Proofs در امنیت: استفاده از ZK-proof برای اثبات صحت عملیات بدون فاش کردن داده‌های حساس، آینده‌ای روشن برای امنیت زیرساختی فراهم می‌کند.

استانداردهای جدید صنعت: سازمان‌هایی مثل OpenZeppelin، Trail of Bits و Immunefi دارند استانداردهای جامع‌تری تدوین می‌کنند که فراتر از آدیت کد هستند.

AI در شناسایی تهدید: هوش مصنوعی در شناسایی الگوهای غیرعادی در تراکنش‌های آن‌چین نقش مهم‌تری پیدا می‌کند و می‌تواند قبل از اینکه هک کامل شود، هشدار بدهد.

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

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

سوالات متداول