Nym mixnet & vesting contracts security audit

مقدمه

در دسامبر ۲۰۲۲(آذر ۱۴۰۱)، Nym یک ممیزی مستقل امنیتی را توسط Oak Security که یک شرکت مشاوره‌ای امنیت سایبری مستقر در آلمان است و در ممیزی بلاک‌چین‌های نسل سوم و پروتکل‌های غیرمتمرکز تخصص دارد، گذراند. با تجربه گسترده در اکوسیستم‌هایی مانند Cosmos، Terra، Polkadot، و Flow، Oak Security مأموریت یافت تا دو مؤلفه حیاتی از اکوسیستم Nym را ارزیابی کند: (1) شبکه مخلوط Nym و قراردادهای وستیگ (به گزارش کامل) و (2) کیف پول Nym (به گزارش کامل). هدف این ممیزی ارزیابی میزان استحکام این مؤلفه‌ها، شناسایی آسیب‌پذیری‌های احتمالی، و اطمینان از پایبندی به بهترین شیوه‌ها در کد نویسی بود. To make things easier to follow, we’ve broken down the findings for each component. شما می‌توانید خلاصه حسابرسی کیف پول نایم را اینجا مشاهده کنید.

خلاصه‌ای از ممیزی قراردادهای Mixnet و Vesting پروژه Nym توسط شرکت Oak Security

این ممیزی که دو هفته به طول انجامید، شامل یک تیم از ۴ کارشناس بود. تیم Nym دسترسی کامل به پایگاه کد پروژه، مشخصات دقیق پروژه، و مستندات پشتیبان را در اختیار Oak Security قرار داد. دامنه این ممیزی شامل ریپازیتوری contracts/mixnet ،contracts/vesting و واردات مرتبط این قراردادها برای قراردادهای mixnet و vesting پروژه Nym بود.

شرکت Oak Security کد را به طور کامل، با ترکیب تحلیل خودکار کد منبع و وابستگی‌ها به همراه بازرسی دستی خط به خط، به منظور آشکارسازی آسیب‌پذیری‌های امنیتی، ارزیابی کیفیت کد، و بررسی میزان انطباق با اصول کدنویسی امن، بررسی کرد. این رویکرد جامع شامل تحلیل عمیق بخش‌های حیاتی همچون آسیب‌پذیری‌های شرایط رقابتی (race condition)، مشکلات underflow و overflow، شیوه‌های مدیریت کلید، استحکام رمزنگاری، ریسک‌های نشت داده، مدیریت رمزهای عبور، و کنترل‌های دسترسی و مجوزدهی بود.

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

مروری بر یافته‌ها

قراردادهای mixnet و vesting پروژه Nym با خوانایی و وضوح بالا مشخص می‌شدند، همراه با پوشش تست قوی که قابل متکی بودن به آن‌ها را نشان می‌داد. در ارزیابی خود، ممیزان ۱۹ یافته شناسایی کردند که شامل ۹ آسیب‌پذیری امنیتی – شامل مشکلات بحرانی و عمده – و ۱۰ ضعف عمومی که به عنوان جزئی یا اطلاع‌رسانی طبقه‌بندی شده بود.

تیم Nym به سرعت تمامی مشکلات بحرانی و عمده را برطرف کرد. تیم Oak Security اصلاحات ما را تأیید و تصویب کرد.

NYM-MIX-VEST-CONTRACT-1: اجرای ناموفق یک رویداد epoch یا interval موجب مسدود شدن دائمی پیشروی epoch می‌شود (بحرانی)

این ممیزی یک آسیب‌پذیری در پردازش پیام‌های AdvanceCurrentEpoch در مسیر contracts/mixnet/src/interval/transactions.rs شناسایی کرد. یک حلقه متوالی تمام رویدادهای در انتظار را به صورت مستقیم در بستر تراکنش پردازش می‌کند، به این معنی که یک رویداد ناموفق می‌تواند کل تراکنش را بازگرداند و در عمل باعث توقف پیشروی epoch و interval شده و پروتکل را در حالت گیرکرده قرار دهد.

برای رفع این مشکل، ممیزان پیشنهاد دادند که اجرای رویدادها در زیرپیام‌هایی، همراه با یک سیاست پاسخ‌دهی، قرار گیرد. این رویکرد به سیستم اجازه می‌داد شکست‌ها را بدون بازگرداندن کل تراکنش به‌طور روان مدیریت کند. با این حال، ما عمداً تصمیم گرفتیم این توصیه را دنبال نکنیم. یک شکست در طول اجرای رویداد نشان‌دهنده یک نقص منطقی مهم است که می‌تواند مکانیزم پاداش را به خطر بیندازد، بنابراین توقف پیشروی epoch برای بررسی دستی ترجیح داده می‌شود تا این‌که خطر ادامه کار، در وضعیت خراب، وجود داشته باشد. در عوض، ما نظارت پیشرفته‌ای را در Nym API پیاده‌سازی کردیم تا شکست‌های پیشروی epoch را شناسایی و به ما هشدار دهد. این رویکرد اطمینان می‌دهد که چنین شکست‌هایی به‌سرعت پرچم‌گذاری شده و امکان مداخله به‌موقع برای حل مشکلات فراهم شود.

NYM-MIX-VEST-CONTRACT-2: مهاجمان می‌توانند نودهای mix یتیم را بدون رضایت آن‌ها مجبور به پیوستن به یک خانواده کنند تا تعداد زیادی از آن‌ها را در یک لایه تجمیع کنند (بحرانی)

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

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

NYM-MIX-VEST-CONTRACT-3: تکرار بدون محدودیت در پردازش پیام TrackUndelegation می‌تواند باعث شود کاربر نتواند undelegate کند، که همچنین به‌طور دائمی مانع پیشروی epoch می‌شود (بحرانی)

تکرار بدون محدودیت پیام TrackUndelegation می‌تواند هنگام پردازش حساب‌هایی با تعداد زیاد delegation باعث اتمام gas شود و مانع undelegate شدن کاربران گردد. این شکست همچنین پیشروی epoch را متوقف می‌کند و پروتکل را در وضعیت فعلی خود گیر می‌اندازد.

برای رفع این مشکل، ما یک محدودیت delegations vesting ۲۵ برای هر حساب پیاده‌سازی کردیم. این راه‌حل بر اساس بیشترین تعداد delegation vesting مشاهده‌شده در آن زمان بود.

به‌روزرسانی: از سال ۲۰۲۴، امکان انجام delegation vesting به‌طور کامل غیرفعال شده است.

NYM-MIX-VEST-CONTRACT-4: یک مهاجم می‌تواند پیام‌های BondMixnodeOnBehalf و CreateFamilyOnBehalf را جلوتر اجرا کرده و payload آن‌ها را تغییر دهد (بحرانی)

این آسیب‌پذیری به مهاجم اجازه می‌داد پیام‌های BondMixNodeOnBehalf و CreateFamilyOnBehalf را جلوتر اجرا کند، امضا را استخراج کرده و payload را تغییر دهد. در مورد BondMixNodeOnBehalf، مهاجم همچنین می‌توانست خود را به عنوان proxy قرار دهد و کنترل کامل بر bond ثبت‌شده را به دست‌ آورد.

برای رفع این آسیب‌پذیری، ما یک راه‌حل دوگانه پیاده‌سازی کردیم. نخست، تغییرات ایجاد امضا که در NYM-MIX-VEST-CONTRACT-2 توضیح داده شده بود، افزودن نیت مشخص و nonce منحصربه‌فرد، اعمال شد. دوم، آدرس proxy قانونی به حساب vesting محدود شد تا اطمینان حاصل شود مهاجمان نمی‌توانند خود را به‌عنوان proxy قرار داده و کنترل غیرمجاز بر bondهای ثبت‌شده به دست آورند.

به‌روزرسانی: از سال ۲۰۲۴، تمامی عملیات proxy غیرفعال شده است و این حمله غیرقابل‌اجرا گردیده است.

NYM-MIX-VEST-CONTRACT-5: امضاها می‌توانند در تراکنش‌ها «به‌نمایندگی‌از» بازپخش شوند تا کاربران جعل هویت شوند (بحرانی)

این آسیب‌پذیری اجازه می‌دهد امضاها در تراکنش‌های «به‌نمایندگی‌از» بازپخش شوند و مهاجمان بتوانند کاربران را جعل هویت کنند. از آنجا که امضاها تنها شامل داده خام هستند بدون متادیتای اضافی مانند nonce یا شناسه پیام، مهاجم می‌تواند یک امضا را از یک پیام برای پیام دیگری استفاده کند تا اعضای خانواده را به‌زور حذف کند. علاوه بر این، مهاجمان می‌توانند امضاها را برای همان نوع پیام مجدداً استفاده کنند و به یک عضو اجازه دهند چندین بار با همان امضا به یک خانواده بپیوندد.

راه‌حل این مشکل مشابه همان چیزی است که در NYM-MIX-VEST-CONTRACT-4 پیاده‌سازی شده بود.

NYM-MIX-VEST-CONTRACT-6: تولید کلید برای جفت‌های (owner, proxy) می‌تواند منجر به تصادم شود (بحرانی)

این آسیب‌پذیری اجازه می‌دهد دو جفت آدرس (owner, proxy) مختلف نتیجه XOR یکسانی را در تابع generate_owner_storage_subkey تولید کنند که می‌تواند منجر به تصادم کلید و بازنویسی داده‌ها شود.

راه‌حل محدود کردن proxy قانونی تنها به آدرس قرارداد vesting، که در NYM-MIX-VEST-CONTRACT-4 اعمال شد، همچنین این آسیب‌پذیری را حل می‌کند. با اطمینان از اینکه عملیات XOR همیشه در برابر یک رشته ثابت انجام شود، این تغییر عملاً خطر تصادم‌ها را از بین می‌برد.

NYM-MIX-VEST-CONTRACT-7: تابع track_delegation می‌تواند delegation موجود را بازنویسی کند اگر بیش از یکی در همان بلاک پردازش شود (بحرانی)

این مشکل می‌تواند منجر به وقوع تصادم کلید شود اگر چندین delegation در یک بلاک انجام شوند، که ممکن است باعث شود تابع save_delegation یک delegation موجود را بازنویسی کند و در نتیجه delegation قبلی از بین برود.

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

NYM-MIX-VEST-CONTRACT-8: مالک bond قادر به انجام عملیات نیست اگر bond توسط «به‌نمایندگی‌از» یک proxy ایجاد شده باشد (اصلی)

این مشکل مانع از آن می‌شود که مالک bond بتواند هرگونه عملیاتی بر روی bond خود انجام دهد اگر bond «به‌نمایندگی‌از» ایجاد شده باشد و تراکنش فعلی توسط مالک به جای proxy آغاز گردد. از آنجایی که ممکن است proxy دچار نفوذ یا از دست رفتن شود و راهی برای مالک جهت تغییر آن وجود ندارد، این می‌تواند منجر به از دست رفتن کنترل مالک بر bond شود.

ما این را یک مشکل در نظر نمی‌گیریم، زیرا از عمد طراحی شده است. زمانی که یک نود mix از طریق قرارداد vesting باند می‌شود (یا delegation انجام می‌شود)، انتظار می‌رود تمامی تعاملات بعدی با bond یا delegation فقط از طریق قرارداد vesting انجام شوند.

به‌روزرسانی: از سال ۲۰۲۴، قرارداد vesting حذف شده است.

NYM-MIX-VEST-CONTRACT-9: اجرای پیام‌های LeaveFamily و LeaveFamilyOnBehalf می‌تواند شکست بخورد اگر تعداد قابل‌توجهی از نودهای mix عضو یک خانواده باشند (اصلی)

این مشکل منجر به شکست اجرای پیام‌های LeaveFamily و LeaveFamilyOnBehalf به دلیل اتمام gas در هنگام تکرار بر روی تعداد زیادی از اعضای خانواده در نقشه MEMBERS می‌شود. این موضوع مانع خروج نودهای mix از یک خانواده شده و عملاً آن‌ها را در خانواده فعلی قفل می‌کند.

راه‌حل: این راه‌حل شامل بازطراحی منطق، برای دسترسی مستقیم به نقشه MEMBERS و تأیید عضویت یک نود mix بود. این تغییر نیاز به تکرار را حذف کرد که می‌توانست منجر به خطاهای out-of-gas شود و اطمینان حاصل کرد که اعضا می‌توانند حتی زمانی که تعداد زیادی عضو در خانواده وجود دارد، با موفقیت از خانواده خارج شوند.

به‌روزرسانی: از سال ۲۰۲۴، خانواده‌های نود حذف شده‌اند.

کلام آخر

ما مایلیم از تیم Oak Security به خاطر تخصص و تعهدشان در طول این فرآیند ممیزی تشکر کنیم. همچنین قدردان همکاری و حرفه‌ای‌گری نشان‌داده‌شده در هر دو مرحله برنامه‌ریزی و اجرای ممیزی هستیم. تعهد مداوم ما به امنیت همچنان یک اولویت اصلی باقی می‌ماند و ما منتظر ادامه همکاری با متخصصان امنیتی هستیم تا بالاترین استانداردها را برای اکوسیستم خود حفظ کنیم.