حمله اکتبر ۲۰۲۶ به Binance پرسشی فراتر از سرقت کلید مطرح میکند: آیا کنترلهای امنیتی تشخیص میدهند که یک امضای معتبر، اختیار wallet را به مهاجم میدهد؟ گزارش هشدار میدهد که پایش انتقال دارایی و تغییر مالکیت بهتنهایی ممکن است تغییر اختیار حساب را تا زمان جابهجایی دارایی پنهان نگه دارد.
گزارش اولیه Binance از نفوذ به یک لپتاپ DevOps، دسترسی به یک container سرویس و ثبت برداشتهای غیرمجاز خبر میداد. گزارش بعدی شواهدی از افشای کلید خصوصی پیدا نکرد. در گزارش ۳ نوامبر، Binance حمله گستردهتری شامل مهندسی اجتماعی، سوءاستفاده از ابزار داخلی AI، اطلاعات احراز هویت سرقتشده و دسترسی غیرمجاز به سرویس امضای wallet را شرح داد. نکته اصلی این است که مهاجم میتواند بدون استخراج کلید، از دسترسی یک سرور برای گرفتن امضای معتبر سوءاستفاده کند.
مهاجم از Delegation در EIP-7702 استفاده کرد؛ سازوکاری که به حساب اجازه میدهد تعیین کند هنگام فراخوانی، چه کدی اجرا شود. Ethereum این دستور را تا تغییر یا پاکشدن با کلید wallet حفظ میکند. همین موضوع انتقالهای مکرر، حتی برداشت داراییهای واریزشده پس از سرقت اولیه، را بدون امضای تازه از Binance ممکن کرد. برخی walletهای دیگر نیز با انتقالهای معمولِ امضاشده تخلیه شدند.
گزارش چهار محور برای بررسی پیشنهاد میکند. نخست، تمام سرویسها و APIهای دارای امکان درخواست امضا، دسترسی فراخوانها و اختیارشان ثبت شوند؛ زیرساخت امضا از سامانههای روزمره جدا باشد و جزئیات transaction بهطور مستقل بررسی شود. آزمون نفوذ به هر مسیر باید نشان دهد کنترل مورد انتظار واقعاً مانع تولید امضای قابلاستفاده میشود.
دوم، Delegation باید اختیاری مدیریتی محسوب شود. برای حسابهای فاقد نیاز به آن، درخواست باید حتی از مسیر API عمومی امضا رد شود. در موارد مجاز، حساب، مقصد، کد، شبکه و Nonce جداگانه تأیید شوند. شبیهسازی نیز باید تغییر اختیار آینده را ببیند، نه فقط تغییر فوری موجودی را.
سوم، حفاظتهای مستقل باید حتی با فرض نفوذ به کلید عملیاتی برقرار بمانند؛ چون کلید اصلی همچنان میتواند دارایی منتقل کند یا مقصد Delegation را تغییر دهد. چهارم، پایش باید مسیرهای اختیار حساب، از جمله Safe module و ERC-4337 UserOperation را پوشش دهد. گزارش توصیه میکند مسئول مشخصی این بررسی را دورهای و پس از تغییر wallet، سرویس امضا یا پروتکلهای پشتیبانیشده تکرار کند.




