اکسپلویت پل اتریوم Verus: همان باگ ۱۱.۵۸ میلیون دلاری
در ۱۸ می ۲۰۲۶، کسی پل Verus-Ethereum را به مبلغ ۱۱.۵۸ میلیون دلار تخلیه کرد. بر اساس گزارش CoinDesk، این هشتمین هک پل در آن سال بود. اکسپلویت پل Verus Ethereum شامل هیچ کلاس حمله جدید و غریبی نبود. همان شکستی بود که از سال ۲۰۲۱ شاهد از پا درآوردن پل‌ها بوده‌ایم: قرارداد وجوه را در یک زنجیره آزاد کرد بدون اینکه به درستی تأیید کند در زنجیره دیگر چه اتفاقی افتاده است.
تابع آسیب‌پذیر این بار یک نام داشت. checkCCEValues. این همان روتینی بود که قرار بود پیش از مینت یا آزادسازی در سمت اتریوم، تأیید کند که مقادیر صادرات زنجیرهای با واقعیت مطابقت دارند. کارش را نکرد، و مهاجم رفت.
من چهار سال است که زیرساخت‌های مرتبط با پل را در یک بستر تنظیم‌شده می‌سازم، و بخش ناامیدکننده این است که چقدر این ماجرا قابل پیش‌بینی شده. ما مدام به همان زخم نام‌های تازه می‌دهیم.
اکسپلویت پل Verus Ethereum یک شکست اعتبارسنجی منبع بود
از برندسازی که بگذریم، هر پلی یک کار انجام می‌دهد. یک رویداد را در زنجیره A رصد می‌کند (یک واریز، یک قفل، یک صادرات) و یک اقدام متناظر در زنجیره B تولید می‌کند (یک مینت، یک قفل‌گشایی، یک آزادسازی). کل مدل امنیتی به یک سؤال واحد فرو می‌ریزد: آیا زنجیره B واقعاً آنچه را که زنجیره A به او گفته باور می‌کند، و آیا آن را بررسی کرده است؟
وقتی اعتبارسنجی که مقادیر سمت منبع را تأیید می‌کند معیوب باشد، جواب می‌شود "نه." مهاجم مقدار صادرات ادعاشده را جعل یا متورم می‌کند، قرارداد مقصد به آن اعتماد می‌کند، و توکن‌هایی که هرگز پشتوانه نداشتند مینت یا آزاد می‌شوند. The Block گزارش داد که زیان حدود ۱۱.۵۸ میلیون دلار بود که دقیقاً از طریق همین نوع شکاف حسابداری در بررسی صادرات زنجیرهای تخلیه شده بود.
این اعتبارسنجی مقدار منبع در یک پل است، و حیاتی‌ترین تابع در کل سیستم. یک مقایسه اشتباه کافی است تا پل به یک چاپخانه پول رایگان تبدیل شود.
checkCCEValues تنها جدیدترین نام برای یک آسیبپذیری قدیمی است
آسیبپذیری checkCCEValues از نظر ساختاری با باگ‌هایی یکسان است که پیش از این میلیاردها دلار از صنعت بلعیده‌اند. نام‌ها عوض می‌شوند. مکانیسم تغییر نمی‌کند.
- Wormhole، ۲۰۲۲: شکافی در تأیید امضا به مهاجم امکان داد ۱۲۰٬۰۰۰ اتر بسته‌بندی‌شده ضرب کند که هرگز سپرده‌گذاری نشده بود.
- Nomad، ۲۰۲۲: مقداردهی اولیه اشتباه ریشه مرکل به این معنا بود که هر پیامی معتبر تلقی می‌شد و پل به دست انبوهی از کپی‌کاران از پا درآمد.
- Multichain، ۲۰۲۳: کلیدها و فرضیات اعتمادی که هیچ‌کس از بیرون نمی‌توانست واقعاً آنها را تأیید کند.
هر یک از اینها در هسته خود یک چیز بود: زنجیره مقصد بدون اثبات محکمی از رویداد مبدأ، ارزش آزاد می‌کرد. checkCCEValues نگارش ۲۰۲۶ همین کلمه است.
به نظرم صنعت همچنان این موارد را اشتباهات مهندسی فردی می‌انگارد، در حالی که اینها یک شکست دسته‌بندی هستند. یک دسته را با ممیزی سخت‌تر یک تابع نمی‌توان اصلاح کرد.
Tornado Cash حمله‌کننده را تأمین مالی کرد، که چیزی درباره نیت می‌گوید
کیف پول مهاجم پیش از سوءاستفاده از طریق Tornado Cash تأمین مالی شده بود. این جزئیات برای انتساب اهمیت کمتری دارد تا اینکه از آمادگی چه می‌گوید. این یک هکر کلاه‌سفید نبود که داشت قراردادی را بررسی می‌کرد و از نتیجه غافلگیر شد. الگوی مهاجم تأمین‌مالی‌شده از Tornado Cash، امضای کسی است که روزها قبل پوشش عملیاتی برپا کرده و از پیش می‌دانسته که وجوه در مسیر خروج نیاز به پولشویی خواهند داشت.
این همان بخشی است که مدافعان دست کم می‌گیرند. تا زمانی که تراکنش سوءاستفاده ثبت می‌شود، مسیر فرار وجوه از پیش ساخته شده است. ردیابی پس از وقوع به دادستان‌ها کمک می‌کند، اما تقریباً هیچ کاری برای پروتکلی که تازه هشت رقم از دست داده انجام نمی‌دهد.
شکست‌های امنیتی پل اکنون یک مالیات ماهانه شده‌اند
از دور نگاه کنید و هک Verus یک ردیف در جدول است، نه یک استثنا. بر اساس دادههای PeckShield که Bitcoin.com نقل کرده، سوءاستفاده از پلهای رمزارزی تنها در ماه می ۲۰۲۶ در مجموع به حدود ۳۲۸ میلیون دلار رسید. هشت حادثه پل در کمتر از پنج ماه ابتدای سال.
بازار این موضوع را بی‌سر و صدا به عنوان هزینه‌ای از جنس تجارت زنجیره به زنجیره پذیرفته است. این نتیجه‌گیری اشتباه است. یک زیان ماهانه نه رقمی مکرر، نوسان نیست، بلکه یک نقص ساختاری است که فضای طراحی از رویارویی با آن سر باز می‌زند.
برای هر کسی که ارزش واقعی جابه‌جا می‌کند، نتیجه‌گیری ناخوشایند است: بیشتر پل‌ها فرض‌های اعتماد هستند که لباس ریاضیات پوشیده‌اند. پیش‌تر در چگونه پلهای استیبل‌کوین واقعاً شکست می‌خورند استدلال کرده‌ام که امن‌ترین پل اغلب همانی است که صادقانه اعتراف می‌کند چقدر کم اعتبارسنجی انجام می‌دهد.
یک بررسی واقعاً قابل دفاع در پل چه شکلی است
اگر در حال ساخت یا ممیزی یک پل هستید، اعتبارسنجی مقدار مبدأ جایی است که باید بخش نامتناسبی از پارانویای خود را صرف آن کنید. چند چیز است که آنها را غیرقابل مذاکره می‌دانم:
- قرارداد مقصد باید یک اثبات رمزنگاری از رویداد مبدأ را تأیید کند، نه حرف یک رله‌کننده را. اثبات‌های light-client یا zk به جای گواهی‌های multisig، در هر جایی که بودجه تأخیر اجازه می‌دهد.
- بررسی مقدار باید در هر مسیر جامع باشد. کلاس باگ
checkCCEValuesمعمولاً در شاخه‌ای پنهان می‌شود که برخی ورودی‌ها از آن عبور می‌کنند. مقایسه را fuzz کنید، به چشم نبینید. - محدودیت‌های نرخ و circuit breaker به ازای هر دارایی، تا یک مقدار جعلی نتواند کل ذخیره را در یک تراکنش تخلیه کند. سقفی که به طور خودکار در، مثلاً، ۵ درصد از TVL در ساعت متوقف می‌شود، بیشتر حوادث ۲۰۲۶ را کاهش می‌داد.
- نظارت مستقل بر invariant که مجموع mint شده در برابر مجموع قفل شده را به صورت real-time رصد کند و در صورت واگرایی متوقف شود.
هیچ‌کدام از اینها تازگی ندارد. پشته ممیزی برای شناسایی این موارد وجود دارد، که در مقاله پشته ممیزی به آن پرداختم. مشکل این است که پل‌ها همچنان اعتبارسنجی را به عنوان یک فکر بعدی به جای خود محصول ارسال می‌کنند.
هک بعدی پل در ۲۰۲۶ در حال نوشته شدن است. نام تابع متفاوتی خواهد داشت و همان علت ریشه‌ای را، و ما دوباره تعجب خواهیم کرد. نباید.