داده‌های آنچین نشان می‌دهند که پول از آدرس 0x28C6…1d60 خارج شده است. این آدرس که «Binance 14» نامیده می‌شود، یکی از بزرگ‌ترین کیف پول‌های گرم (Hot Wallet) اتریوم بایننس است که روزانه هزاران تراکنش برداشت را پردازش می‌کند. در این تراکنش، ۱۶۷,۴۶۴ اتریوم (ETH)، ۱.۶۱۵ میلیارد دلار تتر (USDT) به همراه بیش از ۶۰ نوع توکن دیگر که در آن زمان حدود ۲.۵ میلیارد دلار ارزش داشتند، جابه‌جا شد. در نهایت تنها ۱ اتریوم در این کیف پول باقی ماند.
کارمزد گس (Gas Fee) این تراکنش ۰.۰۰۰۴ اتریوم، یعنی کمتر از ۱ دلار بود.
سه دقیقه قبل از آن، فردی یک تراکنش از نوع EIP-7702 را به این آدرس ارسال کرده بود که حاوی ۵۰ مجوز (Authorization) با نانس‌های (Nonce) ۱۸,۹۱۴,۷۷۵ تا ۱۸,۹۱۴,۸۲۴ بود. ۴۹ مورد از آن‌ها نامعتبر بودند، اما ۱ مورد به هدف نشست. به هدف نشستن یعنی: از این ثانیه به بعد، هرگونه فراخوانی (Call) به آدرس Binance 14، قراردادی را اجرا می‌کند که مهاجم شب قبل در ساعت ۲۳:۵۹ مستقر کرده بود؛ یک قرارداد تخلیه‌کننده (Sweeper) تاییدنشده که تنها یک تابع sweep (برای تخلیه کامل) داشت.
بنابراین، Binance 14 دیگر یک کیف پول نبود؛ بلکه به پوسته‌ای تبدیل شده بود که برنامه شخص دیگری را در خود جای داده بود.
این نمایندگی اختیار (Delegation) همچنان برقرار بود. ۳ ساعت و ۴۵ دقیقه گذشت و هیچ‌کس آن را لغو نکرد.
این در حالی است که «لغو کردن» این وضعیت، تنها نیازمند یک بار امضای مجدد با همان کلید خصوصی است. تا ساعت‌ها بعد، بایننس همچنان در حال استفاده از همین کلید بود تا توکن‌های خرد و پراکنده‌ای را که تخلیه نشده بودند، به کیف پول خودش بازگرداند.
آیا EIP-7702 دلیل اصلی این حمله است؟
منطق EIP-7702 به این صورت است: به یک آدرس عادی (EOA) اجازه می‌دهد کدهای یک قرارداد هوشمند را بدون تغییر در آدرس، موجودی و کلید خصوصی، «اجاره» کند. روش اجاره کردن هم نوشتن ۲۳ بایت در بخش کد (Code field) آن آدرس است و عبارت 0xef0100 به علاوه آدرس قرارداد. این ۲۳ بایت کد قابل اجرا نیستند، بلکه یک اشاره‌گر (Pointer) هستند. از آن لحظه به بعد، هر کسی که این آدرس را فراخوانی کند، ماشین مجازی اتریوم (EVM) کدهای اشاره شده توسط آن اشاره‌گر را بارگذاری کرده و در بستر (Context) خودِ آن آدرس اجرا می‌کند؛ یعنی address(this) همچنان خود آدرس است و موجودی نیز همان موجودی خودش باقی می‌ماند.
این استاندارد هیچ باگی ندارد. درک چیانگ (Derek Chiang)، بنیان‌گذار ZeroDev و یکی از مشارکت‌کنندگان در تدوین EIP-7702، در روز حادثه صراحتاً اعلام کرد: خود استاندارد EIP-7702 هیچ آسیب‌پذیری‌ای ندارد و کاربران کیف پول‌هایی که از این استاندارد پشتیبانی می‌کنند، نیازی به نگرانی ندارند. او یک نکته دیگر را هم اضافه کرد: برای اینکه یک مهاجم بتواند از 7702 استفاده کند، یا باید کنترل کلید خصوصی را در دست داشته باشد و یا بایننس را فریب دهد تا یک مجوز 7702 را امضا کند.
این اولین باری نیست که از این قابلیت به عنوان ابزار حمله استفاده می‌شود. پس از ارتقای Pectra در اتریوم، شرکت Wintermute ظرف چند هفته کشف کرد که بیش از ۹۷ درصد از نمایندگی اختیارهای 7702 در شبکه اصلی (Mainnet) به قراردادی تقریباً یکسان از نوع «Sweeper» اشاره دارند. پژوهش‌ها حدود ۳.۶۶ میلیون تراکنشِ مجوز را ثبت کرده‌اند که حدود ۶۳ درصد آن‌ها مربوط به قراردادهای مخرب بوده و زیان تاییدشده‌ای معادل ۲.۳ میلیون دلار به همراه داشته‌اند. شرکت امنیتی Blockaid نیز چهار حادثه مرتبط با 7702 را در نیمه اول سال ۲۰۲۶ تایید کرد که در مجموع حدود ۱.۰۸ میلیون دلار خسارت داشتند و پیش‌بینی کرده بود که اولین سرقت میلیون دلاری در طول همان سال رخ خواهد داد.
اما نتیجه یک سرقت ده رقمی بود؛ یعنی سه مرتبه بزرگی بالاتر از برآورد آن‌ها.
همین موضوع باعث شده بسیاری دلیل هک ۵.۶ میلیارد دلاری بایننس، بزرگ‌ترین هک در تاریخ را به EIP-7702 نسبت دهند. اما آیا واقعاً مشکل از 7702 است؟
امضاها چگونه به دست آمدند؟
پیش از ادامه، یک نکته باید روشن شود: ۵۰ مجوز به معنای ۵۰ امضا است، پس این ۵۰ امضا دقیقاً چگونه تولید شده‌اند؟
اگر مهاجم کلیدهای خصوصی کامل را به دست آورده بود، چرا باید ۵۰ نانس را به صورت کورکورانه هدف‌گیری می‌کرد؟ و اگر کلیدها همیشه در دست بایننس بوده‌اند، چرا ۱۱ کیف پول به طور هم‌زمان در عرض ۱۲ دقیقه سقوط کردند؟ هنوز هیچ توضیحی برای این موضوع وجود ندارد.
بیست و چهار ثانیه پس از تخلیه اصلی، کیف پول Binance 16 مقدار ۲۸,۰۰۵.۶ اتریوم، ۵۵.۷ میلیون دلار USDT، ۲۵.۹ میلیون دلار RLUSD و ۸۴.۵ واحد WBTC را به همان آدرس گیرنده منتقل کرد.
در عرض ۱۲ دقیقه، ۱۰ کیف پول گرم دیگر بایننس نیز دقیقاً همین کار را روی چهار شبکه مختلف انجام دادند: کیف پول Binance 55 روی شبکه آپتیمیزم (Optimism) ۴۴.۲ میلیون دلار توکن OP را خارج کرد؛ چهار کیف پول روی شبکه آربیتروم (Arbitrum) ۷۴.۶ میلیون دلار توکن ARB و ۸,۴۲۶ اتریوم را انتقال دادند و چهار کیف پول روی شبکه آوالانچ (Avalanche) ۱.۸۱ میلیون واحد AVAX و ۸.۴۱ میلیون دلار USDT را خارج کردند.
هیچ‌یک از این کیف پول‌ها حاوی کدی نبودند. تمام این تراکنش‌ها انتقال‌های عادی بودند که با کلید خصوصی خودِ کیف پول امضا شده و در لابه‌لای برداشت‌های روزمره و عادی قرار گرفته بودند.
کسی که کلیدهای خصوصی را در اختیار دارد، نیازی به حدس زدن و هدف‌گیری کورکورانه نانس‌ها ندارد. بررسی eth_getTransactionCount تنها یک ثانیه زمان می‌برد.
فردی که مجبور می‌شود ۵۰ مجوز را برای پوشش ۵۰ نانس متوالی به صورت یکجا بسازد، شرایط متفاوتی دارد: او کسی است که می‌تواند امضاها را به دست آورد، اما به استیت لحظه‌ای (Real-time state) کیف پول دسترسی ندارد؛ یا کسی است که تنها می‌تواند یک دسته از مجوزهای از پیش آماده شده را به صورت یکجا ارسال کند و بگذارد سیستم آن‌ها را امتحان کند.
نکته قابل توجه‌تر این است که این ۵۰ مجوز همگی به صورت یکجا و در قالب یک تراکنش واحد تایید شده‌اند.
ارزیابی شرکت امنیتی Blockaid این است که «از کلید سوءاستفاده شده است»، نه اینکه کلید خصوصی مستقیماً استخراج و سرقت شده باشد. کوئیت (Quit)، معاون بخش بلاکچین در Yuga Labs نیز به همین فرضیه متمایل است:
آنچه مهاجم به دست آورده «امضاهای مجاز» بوده است، نه خودِ کلید خصوصی و استفاده از یک رله‌کننده (Relayer) برای ثبت تراکنش‌ها احتمالاً دقیقاً با هدف پنهان کردن منبع اصلی امضاها صورت گرفته است.
شنیو (Shenyu) در مرور صبحگاهی خود به جزئیات جالبی اشاره کرد:
بایننس همچنان از همان کلید خصوصی برای امضا و بازگرداندن توکن‌های خردِ باقی‌مانده به کیف پول خود استفاده می‌کرد.
این موضوع نشان می‌دهد که کلید خصوصی در آن صبح همچنان تحت کنترل بایننس بوده است.
بایننس گزارش اولیه خود را منتشر کرد:
احتمالاً لپ‌تاپ یکی از مهندسان DevOps آلوده شده و مهاجم از طریق آن به کانتینرهای سرویس دسترسی پیدا کرده و تراکنش‌های برداشت غیرمجاز را ثبت کرده است؛ در حال حاضر هیچ مدرکی دال بر لو رفتن کلید خصوصی کیف پول‌ها یافت نشده است.
لحظه‌ای که دارایی از دست رفت، آنچین نبود
بنابراین، مسئله اصلی EIP-7702 نیست، بلکه مرحله‌ای است که «پیش از امضا» رخ می‌دهد.
یک کیف پول گرم روزانه هزاران تراکنش را امضا می‌کند، پس باید خودکار (Automated) باشد؛ از طرفی باید امن باشد، بنابراین به ماژول‌های امنیتی سخت‌افزاری (HSM)، محاسبات چندجانبه (MPC)، چندامضایی (Multi-sig) و فرآیندهای تایید نیاز دارد. در نتیجه، تمام مدل امنیتی در یک جمله خلاصه می‌شود: آیا این فرآیند می‌تواند پیش از امضا تشخیص دهد که «این تراکنش نباید امضا شود»؟
مشکل اینجاست که اکثر معیارهای ارزیابی و قضاوت، تنها دو ستون دارند: یعنی «مبلغ» و «آدرس».
مجوز 7702 هیچ‌کدام از این‌ها را به شکل متعارف ندارد. این تراکنش اصلاً مبلغی ندارد. چیزی که تغییر می‌دهد این نیست که «چه مقدار منتقل شود»، بلکه این است که «ماهیت این آدرس چیست».
این‌طور نیست که بایننس هیچ دفاعی در برابر حملات نداشته است.
سه روز پیش از این حادثه، در ۲۷ اکتبر، بایننس به طور پیش‌دستانه موضوع قابل توجهی را افشا کرده بود: در طول هفته گذشته، تیم امنیتی آن‌ها چندین حمله مرتبط با کره شمالی را رهگیری و خنثی کرده بود. روش این حملات مصاحبه مسری (Contagious Interview) نام دارد، طرف مقابل خود را به عنوان یک جذب‌کننده نیرو (Recruiter) جا می‌زند و با استفاده از مصاحبه، تست‌های کدنویسی و بهانه‌هایی مانند «فقط اول این ابزار توسعه را نصب کن»، افراد را فریب می‌دهد تا برنامه‌های مخرب را اجرا کنند؛ به محض اجرای برنامه، کلیدها، شبکه‌های داخلی و جابه‌جایی‌های بعدی سرمایه، همگی یک نقطه ورود پیدا می‌کنند.
اما این سیستم دفاعی نتوانست جلوی یک سوال کلیدی را بگیرد:
آیا این تراکنش باید امضا شود؟
