EIP-7702 عامل اصلی سرقت ۶٫۳ میلیارد دلاری بایننس نیست؛ روش بهدستآوردن امضا است.
زمان پکن، ۳۰ اکتبر ۲۰۲۶، ساعت ۰۴:۲۴.
سوابق زنجیرهای نشان میدهند پول از آدرس ۰x28C6…1d60 خارج شده است. این آدرس «بایننس ۱۴» نام دارد و یکی از بزرگترین کیفپولهای گرم اتریوم بایننس است که هر روز هزاران برداشت انجام میدهد. این تراکنش ۱۶۷۴۶۴ اتر، ۱٫۶۱۵ میلیارد دلار تتر و بیش از ۶۰ نوع توکن به ارزش حدود ۲٫۵ میلیارد دلار در آن زمان را جابهجا کرد. پس از آن تنها ۱ اتر در کیفپول باقی ماند.
هزینه گاز ۰٫۰۰۰۴ اتر (کمتر از ۱ دلار) بود.
سه دقیقه زودتر، در ساعت ۰۴:۲۱، شخصی تراکنشی از نوع EIP-7702 با ۵۰ مجوزِ تأییدیه به این آدرس ارسال کرد که غیره ترتیبی از ۱۸۹۱۴۷۷۵ تا ۱۸۹۱۴۸۲۴ داشتند. ۴۹ مورد نامعتبر و ۱ مورد موفق بود. موفقیت یعنی: از این لحظه به بعد، هر فراخوانی به «بایننس ۱۴» کد قراردادی را که مهاجم در شب قبل ساعت ۲۳:۵۹ منتشر کرده بود اجرا میکند — قراردادی بدون تأیید و تنها با یک تابع «جمعآوری».
پس «بایننس ۱۴» دیگر کیفپول نیست؛ بلکه پوستهای شده که حاوی برنامهای از دیگری است.
تا ساعت ۰۸:۰۶ هنوز مجوز فعال بود. ۳ ساعت و ۴۵ دقیقه گذشت و هیچکس آن را لغو نکرد.
همچنین لغو این مجوز تنها با یک امضای مجدد با همان کلید امکانپذیر است. در ساعت ۰۶:۵۵ صبح همان روز، بایننس همچنان از این کلید برای انتقال توکنهای پراکندهای که جمعآوری نشده بودند به کیفپول خود استفاده میکرد.
آیا EIP-7702 عامل اصلی این حمله است؟
منطق EIP-7702 این است: اجازه میدهد آدرس معمولی (EOA) کد یک قرارداد هوشمند را «اجاره» کند، بدون تغییر آدرس، موجودی و کلید خصوصی. این اجاره با نوشتن ۲۳ بایت در فیلد کد آدرس انجام میشود: «۰xef0100» بهعلاوه آدرس قرارداد. این ۲۳ بایت کد اجرایی نیستند، بلکه اشارهگری هستند. از آن لحظه به بعد، هر فراخوانی به این آدرس، ماشین مجازی اتریوم (EVM) کد اشارهشده را در محیط خودِ آدرس اجرا میکند: «address(this)» همچنان خودِ آن آدرس و موجودی نیز همان موجودی آن است.
این استاندارد باگی ندارد. دِرِک چیانگ، بنیانگذار زِرو دِو و یکی از مشارکتکنندگان EIP-7702، در روز حادثه صراحتاً اعلام کرد: خودِ EIP-7702 آسیبپذیری ندارد و کاربران کیفپولهای پشتیبان این استاندارد نیازی به نگرانی ندارند. او افزود: برای استفاده مهاجم از ۷۷۰۲، یا باید کلید خصوصی را کنترل کند یا بایننس را فریب دهد تا مجوز ۷۷۰۲ را امضا کند.
این اولین باری نیست که بهعنوان ابزار حمله استفاده شده است. پس از ارتقای پکترا اتریوم، وینترمیوت ظرف چند هفته کشف کرد که بیش از ۹۷٪ از مجوزهای ۷۷۰۲ روی شبکه اصلی به یک «قرارداد جمعآوری» تقریباً یکسان اشاره دارد؛ تحقیقات نشان دادهاند حدود ۳٫۶۶ میلیون تراکنش مجوز وجود دارد که ۶۳٪ آنها مربوط به قراردادهای مخرب بوده و خسارات تأییدشده ۲٫۳ میلیون دلار است؛ بلاکِید چهار حملهٔ ۷۷۰۲ را در نیمهٔ اول ۲۰۲۶ تأیید کرده و پیشبینی کرده بود که اولین مورد با خسارت بالای یک میلیون دلار تا پایان سال رخ خواهد داد.
نتیجه به رقم دهرقمی رسید — سه مرتبه بزرگتر از پیشبینی آنها.
این امر بسیاری را وادار کرده تا علت هک ۵٫۶ میلیارد دلاری بایننس — بزرگترین هک تاریخ بشر — را به EIP-7702 نسبت دهند. اما آیا واقعاً مشکلی از نوع ۷۷۰۲ است؟
روش بهدستآوردن امضاها
قبل از ادامه، یک نکته باید روشن شود: ۵۰ مجوز یعنی ۵۰ امضا — پس این ۵۰ امضا دقیقاً چگونه تولید شدهاند؟
اگر مهاجم کلیدهای خصوصی کامل را بهدست آورده بود، چرا باید ۵۰ عدد غیره را بهصورت تصادفی و بدون اطمینان تست میکرد؟ اگر کلیدها همیشه در اختیار بایننس بوده، چرا ۱۱ کیفپول در عرض ۱۲ دقیقه همزمان قربانی شدند؟ توضیحی ارائه نشده است.
بیستوچهار ثانیه پس از اصلیترین جمعآوری، بایننس ۱۶ مقدار ۲۸۰۰۵٫۶ اتریوم، ۵۵٫۷ میلیون دلار تتر، ۲۵٫۹ میلیون دلار آرالیواسدی و ۸۴٫۵ ویبیتیسی را به یک آدرس دریافتکنندهٔ مشترک انتقال داد.
در عرض ۱۲ دقیقه، ده کیف پول داغ دیگر بایننس نیز همین کار را در چهار زنجیره انجام دادند: بایننس ۵۵ در اُپتیمیسم ۴۴٫۲ میلیون دلار اوپی انتقال داد؛ چهار کیف پول در آربیترام ۷۴٫۶ میلیون دلار آربی و ۸۴۲۶ اتریوم ارسال کردند؛ و چهار کیف پول در آوالانش ۱٫۸۱ میلیون آواکس و ۸٫۴۱ میلیون دلار تتر را خروجی دادند.
هیچیک از این کیفپولها حاوی هیچ کدی نبودند. همهٔ تراکنشها انتقالهای معمولی بودند که توسط کلید خصوصی خود کیفپول امضا شده و بین برداشتهای روتین قرار گرفته بودند.
کسی که کلیدهای خصوصی را در اختیار دارد نیازی به «شکار سریع غیرقابل پیشبینی» (blind-snipe) نانسها ندارد؛ بررسی تابع eth_getTransactionCount تنها یک ثانیه طول میکشد.
نوع شخصی که برای ساخت ۵۰ امضای مجاز برای ۵۰ نانس متوالی در یک زمان نیاز دارد، فردی متفاوت است: یا کسی که میتواند امضاها را بهدست آورد اما نمیتواند به وضعیت لحظهای کیفپول دسترسی پیدا کند؛ یا کسی که تنها قادر است دستهای از امضاهای پیشساخته را یکجا ارسال کند و سیستم اجازه دهد آنها را امتحان کند.
قابلتوجهتر این است که این ۵۰ امضای مجاز در یک تراکنش واحد و همزمان تأیید شدند.
ارزیابی شرکت امنیتی بلوكاید این است که «کلید بهصورت نادرست استفاده شده»، نه اینکه کلید خصوصی مستقیماً استخراج شده باشد. کوئیت، معاون اجرایی بلاکچین یوگا لابز، نیز به همین سو تمایل دارد: حملهگر «امضاهای مجاز» را بهدست آورده، نه کلید خصوصی، و استفاده از رلهر ممکن است دقیقاً برای پنهانسازی منبع امضاها بوده است.
شنیو در خلاصهبرداری صبحگاهیاش جزئیاتی را یادآور شد: تا ساعت ۰۶:۵۵، بایننس همچنان از همان کلید خصوصی برای امضا استفاده میکرد و توکنهای تکهتکهای که بازپسگرفته نشده بودند را به کیفپول خود منتقل میکرد.
این نشان میدهد که آن روز صبح کلید هنوز تحت کنترل بایننس بود.
هماکنون در ساعت ۱۰:۲۶، بایننس اعلامیهٔ اولیهٔ خود را صادر کرده است: احتمالاً لپتاپ یک مهندس دِو-اُپس مورد نفوذ قرار گرفته و حملهگر از طریق آن به کانتینرهای سرویس دسترسی پیدا کرده و تراکنشهای برداشت غیرمجاز را ارسال کرده است؛ تاکنون هیچ شواهدی از نشت کلید خصوصی کیفپول یافت نشده است.
لحظهٔ از دست رفتن آن بر روی زنجیره نبود.
پس مسئلهٔ اصلی ایآیپی-۷۷۰۲ نیست، بلکه بخشی قبل از امضا است.
یک کیف پول داغ هر روز هزاران تراکنش امضا میکند، پس باید خودکار باشد؛ و چون باید امن باشد، نیازمند HSMها، MPC، چندامضایی و جریانهای تأیید است. بنابراین کل مدل امنیتی در یک جمله خلاصه میشود: آیا این فرآیند میتواند پیش از امضا تشخیص دهد که «این تراکنش نباید امضا شود»؟
مشکل این است که اکثر معیارهای تصمیمگیری تنها دو ستون دارند: مبلغ و آدرس.
اجازهنامهٔ ۷۷۰۲ هیچکدام را ندارد. مبلغی ندارد. آنچه تغییر میدهد «چقدر انتقال داده شود» نیست، بلکه «این آدرس چیست» است.
این به این معنا نیست که بایننس دفاع نکرده است.
سه روز پیش از حادثه، در ۲۷ اکتبر، بایننس بهصورت پیشگیرانه اطلاعاتی ارزشمند را افشا کرد: در هفتهٔ گذشته، تیم امنیتی چندین حملهٔ مرتبط با کرهٔ شمالی را شناسایی و مسدود کرده است. این روش «مصاحبهٔ واگیردار» نام دارد — طرف مقابل خود را بهعنوان استخدامکننده جلوه میدهد و با استفاده از مصاحبه، تستهای کدنویسی و جملهٔ «لطفاً ابتدا یک ابزار توسعهدهنده نصب کنید»، افراد را فریب میدهد تا برنامههای مخرب را اجرا کنند؛ پس از اجرای برنامه، کلیدها، شبکههای داخلی و حرکت بعدی وجوه همگی نقطهٔ ورودی پیدا میکنند.
اما نتوانست از «آیا این تراکنش باید امضا شود» جلوگیری کند.


