درس حمله به Binance: امضای معتبر هم می‌تواند اختیار wallet را به مهاجم بدهد

چرا مهم است

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

قبل از خواندن، این‌ها را بدان۳ مفهوم
transaction

درخواستی برای اجرای عملیات در شبکه، مانند انتقال دارایی یا تغییر وضعیت یک حساب یا smart contract.

بیشتر درباره این مفهوم

Delegation

واگذاری بخشی از اختیار یک حساب به کد یا سازوکاری دیگر؛ در EIP-7702،؜ حساب مشخص می‌کند هنگام فراخوانی چه کدی برای آن اجرا شود.

در حال نگارش

Nonce

مقداری که برای تمایز و کنترل ترتیب یا تکرار درخواست‌های امضاشده استفاده می‌شود.

در حال نگارش

حمله اکتبر ۲۰۲۶ به 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،؜ سرویس امضا یا پروتکل‌های پشتیبانی‌شده تکرار کند.

نکته کلیدی

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

خواندن مقاله اصلی (در زبانه‌ی جدید باز می‌شود)
برچسب‌ها (۴)