بلنسر (Balancer) یکی از پروتکل‌های مهم دیفای و پلتفرم ایجاد استخرهای نقدینگی مبتنی بر AMM است. در اولین ساعات رو ۳ نوامبر ۲۰۲۵ (۱۲ آبان ۱۴۰۴)، این پروتکل یکی از بزرگ‌ترین هک‌های سال را تجربه کرد. در این حادثه، مهاجمان از یک ضعف امنیتی در بخش مدیریت موجودی داخلی (Internal Balance) استفاده کردند و توانستند به دارایی‌های کاربران دسترسی پیدا کنند. در ادامه روند این حمله را از لحظه وقوع تا بازیابی بخشی از دارایی‌ها بررسی می‌کنیم.
جزئیات نحوه هک پروتکل بلنسر در نوامبر ۲۰۲۵
هک بلنسر یکی از بزرگ‌ترین حملات در فضای دیفای در سال ۲۰۲۵ است که نشان داد حتی در پروتکل‌های بزرگ و معتبر، طراحی سطح دسترسی می‌تواند نقطه ضعف اصلی باشد و وجود قابلیت‌های پیچیده مثل موجودی داخلی اگر به‌درستی ایمن نشوند، مسیر حمله را باز می‌کنند.
درس اصلی این است که در فضای دیفای، امنیت پروتکل‌ها فقط وابسته به ممیزی و حسابرسی داخلی و خارجی نیست و هر ویژگی جدیدی باید از نظر سناریوهای سوءاستفاده نیز بررسی شود.
- علت اصلی هک: ضعف در کنترل دسترسی تابع‌های مدیریت موجودی داخلی در نسخه دوم پروتکل
- مبلغ سرقت شده: بین ۹۸ تا ۱۲۸ میلیون دلار
- مبلغ بازیابی‌شده تا ۸ نوامبر: حدود ۱۸–۱۹ میلیون دلار
- بخش آسیب‌پذیر: manageUserBalance و validateUserBalanceOp در Balancer V2 (Vault / Composable Stable Pools)
مرحله ۱: شروع حمله؛ ۲ تا ۳ نوامبر ۲۰۲۵
هکر از یک ضعف در توابع زیر سوءاستفاده کرد:
- manageUserBalance
- validateUserBalanceOp
مشکل اصلی این بود که پارامتر op.sender که باید نشان‌دهنده صاحب واقعی بالانس باشد، به‌درستی اعتبارسنجی نمی‌شد و امکان جعل آن وجود داشت. این موضوع باعث شد مهاجم بتواند عملیات زیر را اجرا کند:
WITHDRAW_INTERNAL: برداشت از موجودی داخلی کاربران بدون نیاز به مجوز واقعی.
این نقص در استخرهای Composable Stable Pools و Vault باعث باز شدن مسیر حمله شد. به عبارت دیگر:
سیستم op.sender بلنسر تصور می‌کرد مهاجم همان کاربری است که دارایی متعلق به اوست، بدون اینکه این ادعا را با روش دیگری تأیید کند.
مرحله ۲: دقایقی بعد؛ خروج دارایی‌ها و جابه‌جایی میان زنجیره‌ای
پس از ایجاد اولین برداشت موفق، مهاجم:
- چندین تراکنش پیچیده سواپ انجام داد.
- وضعیت موجودی استخرها را دستکاری کرد.
- دارایی‌ها (ارزهایی همچون اتر و یواس‌دی‌سی) را به چند آدرس تازه واریز کرد.
در این مرحله، ابزارهای ردیابی بلاکچین تخمین زدند که مجموع خروجی بین ۷۰ تا بیش از ۱۲۰ میلیون دلار بوده است. اختلاف عددها به دلیل جابه‌جایی سریع دارایی‌ها و تخمین‌های اولیه بود.
مرحله ۳: همان روز؛ شناسایی حادثه و واکنش بلنسر
بلافاصله بعد از انتشار تراکنش‌ها و مشاهده رفتار غیرعادی، تیم بلنسر و شرکت‌های امنیتی:
- تراکنش‌های مشکوک را بررسی کردند.
- آدرس‌های مرتبط با مهاجم را شناسایی کردند.
- به صرافی‌ها و سرویس‌های ردیابی بلاکچین هشدار دادند تا وجوه بلوکه شود.
اولین تحلیل‌ها نشان داد که مشکل از اشتباه در کنترل دسترسی توابع مربوط به مدیریت بالانس کاربران بوده است، نه حمله به وام‌های فوری (Flash Loan) یا دستکاری قیمت.
مرحله ۴: چند ساعت بعد؛ ارتباط با هکر و بازگردانی بخشی از وجوه
پس از هشدار سراسری و مسدود شدن احتمالی مسیر نقدکردن دارایی‌ها، هکر بخشی از وجوه را بازگرداند. طبق گزارش‌های منتشرشده، حدود ۱۹ میلیون دلار به آدرس‌های کنترل‌شده توسط پروتکل بلنسر برگردانده شد. جزئیات مذاکرات، شامل اینکه چه تیمی با مهاجم تماس گرفت و چه انگیزه‌ای برای بازگردانی ایجاد شد، عمومی نشد.
مرحله ۵: اعلام خسارت نهایی و پیامدها
تیم امنیتی بلنسر پس از بررسی کامل:
- مقدار نهایی زیان را بین ۹۸ تا ۱۲۸ میلیون دلار گزارش کرد.
- ریشه مشکل را «اشتباه در منطق کنترل دسترسی» اعلام کرد.
- به پروژه‌هایی که از پورتکل بلنسر فورک‌شده یا از کد مشابه استفاده می‌کردند هشدار داد که این مسیر آسیب‌پذیر را بررسی کنند.
مرحله ۶: اصلاحات و اقدامات پس از حادثه
بلنسر اعلام کرد:
- تهیه گزارش فنی پس از حادثه (Post-mortem)
- اعمال Patch امنیتی برای رفع ضعف کنترل دسترسی
- مسدود کردن آدرس‌های هکر
- اطلاع‌رسانی عمومی به پروژه‌هایی که از کد بلنسر استفاده کرده‌اند
