پاسخ Nym به ممیزی امنیتی Cure53 (ژوئیه 2024)

به‌روزرسانی‌شده در ۱۸ نوامبر ۲۰۲۵

مقدمه

NymVPN به‌منظور تضمین ایمن، حفاظت خصوصی و قابل‌اعتماد کردن ارتباطات آنلاین شما، طراحی شده است. در Nym، شفافیت و اعتماد کاربران در بالاترین اولویت قرار دارند، به همین دلیل کد Nym اُپن سورس است و به‌طور منظم تحت حسابرسی‌های مستقل قرار می‌گیرد تا بالاترین استانداردهای امنیت و حریم خصوصی تضمین شوند.

در ژوئیه ۲۰۲۴(تیرماه ۱۴۰۳)، Nym تحت یک حسابرسی مستقل توسط Cure53، یک شرکت امنیت سایبری مستقر در برلین با بیش از ۱۵ سال تجربه در انجام آزمایش‌های نرم‌افزاری و حسابرسی کد، قرار گرفت. آن‌ها بخش‌های کلیدی زیرساخت Nym، از جمله برنامه‌های موبایل و دسکتاپ، زیرساخت VPN، پیاده‌سازی‌های رمزنگاری، و معماری کلی سیستم را بررسی گسترده‌ای انجام دادند.

تمام آسیب‌پذیری‌های بحرانی و با شدت بالا که شناسایی شده بودند، برطرف شدند. پس از آنکه Cure53 اصلاحات پیاده‌سازی‌شده ما را بررسی کرد، همه آسیب‌پذیری‌های بحرانی و با شدت بالا تأیید شد که برطرف شده‌اند.

گزارش کامل Cure53 در اینجا منتشر شده است. شما همچنین می‌توانید سخنرانی Dr. Nadim Kobeissi’s را برای OSTIF تماشا کنید، جایی که او به بررسی حسابرسی Nym پرداخته و توضیحات عمیق فنی در مورد برخی از مشکلات کشف شده ارائه می‌دهد.

خلاصه‌ای از حسابرسی Nym توسط Cure53

Cure53 یک ارزیابی امنیتی جامع از اکوسیستم Nym انجام داد، شامل تست نفوذ، حسابرسی کد منبع، و بازبینی کد. این حسابرسی بر ارزیابی وضعیت امنیتی برنامه‌های موبایل و دسکتاپ Nym، API پشتی، نرم‌افزار و زیرساخت VPN، و رمزنگاری متمرکز بود. تیم Nym در طول حسابرسی، به‌طور مداوم از تیم Cure53 پشتیبانی کرد تا همکاری روان و فرآیندی شفاف تضمین شود.

Cure53 از یک استراتژی crystal-box استفاده کرد و به‌طور کامل به کد منبع، بیلدها، مستندات، محیط‌های آزمایشی، و مقالات علمی پشتیبان دسترسی داشت. این حسابرسی در طول ۵۶ روز کاری و با مشارکت شش متخصص ارشد امنیت سایبری انجام شد. کار به پنج بسته کاری (WP) تقسیم شد:

• WP1: برنامه‌های موبایل Nym
• WP2: برنامه‌های دسکتاپ Nym
• WP3: API پشتی Nym
• WP4: نرم‌افزار و زیرساخت VPN Nym
• WP5: رمزنگاری Nym

این حسابرسی پوشش گسترده‌ای در محدوده تعریف‌شده داشت و ۴۳ یافته شناسایی کرد، شامل ۷ آسیب‌پذیری امنیتی – شامل مسائل بحرانی و با شدت بالا – و ۲۴ ضعف عمومی، که با پتانسیل بهره‌برداری متوسط یا پایین دسته‌بندی شدند و فرصت‌هایی برای تقویت بیشتر سیستم را نمایان کردند.

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

یافته‌های کلیدی

WP1: تست نفوذ crystal-box و حسابرسی کد منبع اپلیکیشن‌های موبایل Nym

در WP1، Cure53 تحلیل‌های ایستا (static) و پویا (dynamic) را همراه با تست white-box بر روی اپلیکیشن‌های موبایل NymVPN برای اندروید و iOS انجام داد. هدف، شناسایی هرگونه ضعف، پیکربندی اشتباه، یا ریسک امنیتی در اپلیکیشن‌ها بود. در مجموع، یافته‌ها دارای شدت پایین‌تری بودند و هیچ آسیب‌پذیری بحرانی یا با ریسک بالا شناسایی نشد. مشکلات شناسایی‌شده عمدتاً دارای شدت متوسط، پایین، یا صرفاً اطلاعاتی بودند و می‌توان آن‌ها را به‌طور مؤثر در قالب تلاشی گسترده‌تر برای تقویت اپلیکیشن‌ها رفع کرد. تحلیل ایستا با هدف یافتن تنظیمات نامناسب یا پیکربندی‌های اشتباه در اپلیکیشن‌ها انجام شد که ممکن بود به ضعف منجر شود. با این حال، این تحلیل هیچ نگرانی با ریسک بالا را نشان نداد.

علاوه بر این، Cure53 یک بررسی عمیق بر مسیرهای حمله رایج در اندروید انجام داد، از جمله دسترسی احتمالی به کامپوننت‌های منتشرنشده (unexported)، دور زدن احراز هویت، گیرنده‌های broadcast ناقص، و اعتبارسنجی ناکافی بر intent extras. در هیچ‌ یک از این حوزه‌ها آسیب‌پذیری‌ای شناسایی نشد که نشان‌دهنده قدرت تدابیر امنیتی پلتفرم است.

Cure53 همچنین تأیید کرد که نه اپلیکیشن اندروید و نه iOS حاوی اطلاعات حساس یا رازهای hardcoded نبودند، که این نکته‌ای مهم در امنیت محسوب می‌شود.

در مجموع، اپلیکیشن‌های موبایل وضعیت امنیتی خوبی از خود نشان دادند با سطح حمله (attack surface) حداقلی. به‌جز چند ناحیه جزئی برای بهبود، مانند استفاده نادرست از فضای ذخیره‌سازی امن بومی iOS (NYM-01-024)، هیچ نقص امنیتی مهمی در این اپلیکیشن‌ها شناسایی نشد.

WP2: تست‌های نفوذ crystal-box و حسابرسی کد منبع اپلیکیشن‌های دسکتاپ Nym

WP2 بر روی اپلیکیشن‌های دسکتاپ NymVPN برای ویندوز، لینوکس، و macOS متمرکز بود. تیم تست بررسی دقیقی از مؤلفه‌های فرانت‌اند از نظر مشکلات سمت کاربر و همچنین لایه ارتباطی بک‌اند نوشته‌شده با Rust انجام داد. در مجموع، اپلیکیشن‌های دسکتاپ عملکرد امنیتی قدرتمندی را نشان دادند.

یافته‌های مثبت کلیدی شامل استفاده از فریم‌ورک React برای مؤلفه‌های فرانت‌اند (frontend) است، که سطح حمله را به‌شکل قابل‌توجهی کاهش می‌دهد. تیم هیچ آسیب‌پذیری عمده‌ای در سمت کاربر شناسایی نکرد، به‌جز یک سناریوی بسیار خاص که در آن یک URL مخرب مربوط به ریپازیتوری می‌توانست در شرایط خاصی منجر به اجرای دلخواه جاوااسکریپت (XSS) شود. این مشکل در دسته ریسک پایین قرار گرفت و هیچ داده حساس یا هیچ آسیب‌پذیری بحرانی شناسایی نشد. در بخش بک‌اند (backend)، ارتباط با daemon از طریق Unix socket (در لینوکس) و pipe (در ویندوز) به‌دقت بررسی شد و هیچ نقص عمده یا ریسک امنیتی شناسایی نشد.

اگرچه چند مشکل جزئی مشاهده شد، اما این یافته‌ها بیشتر بر ارتقاء بیشتر امنیت متمرکز بودند تا رفع نقص‌های بحرانی.

WP3: تست‌های نفوذ crystal-box و حسابرسی کد منبع علیه API بک‌اند Nym

WP3 بر API اجزای بک‌اند Nym متمرکز بود، شامل gatewayها و mix nodeها، اما بدون دربر گرفتن validatorها. در فرآیند تست، به‌طور کامل موارد serialization/deserialization، تزریق SQL، سازوکارهای احراز هویت و مجوزدهی، آسیب‌پذیری‌های SSRF، حملات زمانی، و نقاط اجرای کد بررسی شد. نکته مثبت اینکه بک‌اند Nym، امنیت متوسطی از خود نشان داد و هیچ آسیب‌پذیری اجرای مستقیم کد، ریسک تزریق SQL، یا مشکل SSRF با قابلیت سوء‌استفاده با ریسک بالا، شناسایی نشد. سازوکارهای احراز هویت و مجوزدهی در شبکه ما مطابق با استانداردهای ایمن، پیاده‌سازی شده‌اند و به‌طور مؤثری جلوی دور زدن‌های محتمل را می‌گیرد. اگرچه اجزای بک‌اند در مجموع امنیت خوبی نشان دادند، چند مشکل قابل توجه نیز شناسایی شد. از میان آن‌ها، دو مورد در دسته‌ی موارد با شدت بالا یا بحرانی قرار گرفتند (NYM-01-027، NYM-01-030، و NYM-01-032) که در ادامه به آن‌ها می‌پردازیم.

NYM-01-027 WP3: استفاده مجدد از nonce و کلید در AES-CTR در gatewayهای Nym (بحرانی)

در طول بررسی کد منبع ریپازیتوری Nym، مشخص شد که ارتباط بین gateway و کلاینت‌ها دچار یک نقص عمده رمزنگاری است. به‌طور مشخص، مشخص شد که در هندشیک میان درگاه‌های Nym و کلاینت‌ها، داده‌های ارتباطی با AES-CTR، یک کلید یکتای بدون چرخش و یک نانس ثابت صفر رمزگذاری می‌شدند. این موضوع باعث می‌شود که کل ارتباط در صورت نشت یک متن واضح (plaintext) به مهاجم، در معرض خطر قرار گیرد، زیرا مهاجم می‌تواند با عملیات ساده XOR بین متن‌های رمز (ciphertext) و متن واضح نشت‌یافته، رمزنگاری را بشکند.

گرچه محرمانگی داده‌های منتقل‌شده بین کلاینت و gateway تنها در صورت نشت متن واضح در خطر است، ما به‌طور کامل به شدت این مسئله اذعان داریم. تیم Nym به سرعت با جایگزینی رمزنگاری AES-CTR با طرح AES-GCM-SIV پیشنهاد شده پاسخ داد، که به طرز قابل توجهی امنیت ارتباطات را در نسخه 2024.12-aero افزایش می‌دهد.

NYM-01-030 WP3: پرش و عبور gateway از بررسی شماره سریال اعتبارنامه (بحرانی)

عدم وجود بررسی شماره سریال اعتبارنامه در سطح دروازه، امنیت سیستم را به خطر نمی‌اندازد چرا که پروتکل zk-nyms مبتنی بر مدل پول الکترونیکی آفلاین است که به‌طور ذاتی برای شناسایی و جلوگیری از خرج مضاعف طراحی شده است. در مدل‌های e-cash آنلاین، ارائه‌دهندگان به‌طور دائم با یک مرجع مرکزی (مثلاً بانک یا بلاک‌چین) در ارتباط هستند و پیش از پذیرش پرداخت، شماره سریال‌ها را در لحظه بررسی می‌کنند. اگر این مدل در NymVPN پیاده‌سازی می‌شد، به این معنا بود که gatewayها باید شماره سریال اعتبارنامه‌ها را هنگام وقوع تراکنش‌ها به‌طور فعال بررسی کنند. در مقابل، مدل e-cash آفلاین نیاز به ارتباط دائمی را حذف می‌کند—ارائه‌دهندگان می‌توانند پرداخت‌ها را بپذیرند و بعداً آن‌ها را واریز کنند، با تضمین رمزنگاری‌شده‌ای که هرگونه تلاش برای دوبار خرج کردن را هنگام تأیید تراکنش، شناسایی خواهد کرد. پروتکل zk-nyms از همین مدل e-cash آفلاین پیروی می‌کند، و تضمین می‌نماید که حتی بدون بررسی محلی شماره سریال در gateway، validatorهای nym-API همچنان می‌توانند دوبار خرج کردن را هنگام تأیید بلیت‌ها شناسایی و جلوگیری کنند. این یعنی بررسی شماره سریال در gateway برای امنیت ضروری نیست. با این حال، بررسی‌های محلی در gateway می‌توانند یک لایه اضافی برای شناسایی زودهنگام فراهم کنند و سرعت تشخیص تلاش‌های دوبار خرج کردن را در همان gateway افزایش دهند. اگرچه چنین بررسی‌هایی می‌توانند کارایی را بهبود دهند، اما برای امنیت اصلی پروتکل ضروری نیستند. تضمین‌های رمزنگاری موجود در پروتکل zk-nyms تضمین می‌کنند که دوبار خرج کردن در مراحل بعدی به‌طور قابل اعتماد شناسایی شود، و بازیگران مخرب قابل شناسایی و قرار گرفتن در لیست سیاه باشند. در نتیجه، بررسی‌های مربوط به مصرف دوباره در gateway باید به‌عنوان یک بهینه‌سازی اختیاری برای کارایی تلقی شوند، نه یک الزام اساسی از دیدگاه امنیتی.

علاوه بر این، در سیستم ما، هر گواهی zk-nym دارای یک تاریخ انقضای ثابت است که در حال حاضر به یک هفته تنظیم شده است. پس از این مدت، اعتبارنامه‌های منقضی‌شده دیگر توسط nodeهای ورودی شبکه پذیرفته نمی‌شوند. این مکانیزم انقضا، تأثیر هرگونه تلاش برای دوبار مصرف کردن را بیشتر محدود می‌کند و تضمین می‌نماید که سیستم حتی بدون بررسی شماره سریال در سطح gateway نیز امن باقی بماند.

NYM-01-032 WP3: تنظیمات فیلتر بلوم می‌تواند منجر به تشخیص‌های مثبت ولی نادرست شود (خطر بالا)

ما اشاره می‌کنیم که این بخش از کد در حال توسعه فعال بود و در زمان انجام ممیزی، در اپلیکیشن NymVPN مورد استفاده قرار نگرفته بود. پارامترهای ارائه‌شده صرفاً برای اهداف آزمایشی در نظر گرفته شده بودند. همان‌طور که در NYM-01-030 WP3 توضیح داده شد، فیلترهای بلوم به‌عنوان بررسی اضافه‌ای برای جلوگیری از دوباره‌خرج‌کردن، اضافه شده بودند. با این حال، از آنجایی که پروتکل ما ذاتاً به‌گونه‌ای طراحی شده است که به شکل متفاوتی با دوباره‌خرج‌کردن برخورد می‌کند، و همچنین فیلترهای بلوم سربار زیادی ایجاد می‌کردند (زیرا مجبور بودیم آن‌ها را بین گیت‌وی‌ها و nym-api همگام‌سازی کنیم)، تصمیم گرفتیم آن‌ها را حذف کنیم.

علاوه بر این مشکلات با اولویت بالا، گزارش ممیزی چندین آسیب‌پذیری با شدت متوسط را نیز مشخص کرده که به‌طور خاص با بردارهای احتمالی حمله‌ی DoS) Denial of Service) مرتبط بودند. این یافته‌ها حوزه‌هایی را مشخص می‌کنند که در آن‌ها بک‌اِند NymVPN می‌تواند تاب‌آوری خود در برابر اختلالات سرویس، بهبود دهد. ما در نظر داریم که این موارد را در نقشه راه سال ۲۰۲۵ خود رسیدگی کنیم.

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

WP4: تست نفوذ Crystal-box و بررسی سورس کد بر روی نرم‌افزار و زیرساخت Nym VPN

WP4 شامل یک ارزیابی امنیتی جامع از نرم‌افزار NymVPN بود که بر موارد زیر تمرکز داشت:

• عملکرد اصلی: مدیریت پروتکل، رمزگذاری، مدیریت شبکه، DNS resolution، و پیاده‌سازی مسیریابی IP، تونل‌سازی، و یکپارچه‌سازی کلی با ساختار شبکه‌ای.
• یکپارچه‌سازی رابط کاربری: رابط کاربری مبتنی بر Tauri از نظر طراحی، قابلیت استفاده، و یکپارچه‌سازی کارآمد با هسته‌ی Rust از طریق FFI، همچنین عملکرد در پلتفرم‌های مختلف شامل ویندوز، مک‌اواس، و لینوکس ارزیابی شد.
• اقدامات امنیتی کلیدی: فضای ذخیره‌سازی امن اعتبارنامه‌ها، جلوگیری از نشت، مدیریت کلیدها و کاهش آسیب‌پذیری‌های شناخته‌شده VPN.

پیاده‌سازی مبتنی بر Rust برای مدیریت پروتکل، رمزگذاری، مسیریابی IP، تونل‌سازی، و یکپارچه‌سازی پشته‌ی شبکه قابل‌اعتماد تشخیص داده شد و هیچ آسیب‌پذیری‌ای شناسایی نشد. ویژگی‌های امنیتی کلیدی، مانند فضای ذخیره‌سازی اعتبارنامه‌ها، جلوگیری از نشت و مدیریت کلیدهای رمزگذاری، مطابق با استانداردهای امنیتی بالا ارزیابی شدند و خطرها را به‌طور مؤثر کاهش می‌دهند.

رابط کاربری دسکتاپ توانست به‌خوبی بین قابلیت استفاده و یکپارچه‌سازی کارآمد با هسته‌ی Rust تعادل برقرار کند. مکانیزم‌های مدیریت خطا و ثبت وقایع (logging) کامل و با دقت پیاده‌سازی شده‌اند و اطلاعات مفیدی برای رفع اشکال فراهم می‌کنند بدون اینکه داده‌های حساس را افشا کنند.

در طی تحلیل WP4 هیچ آسیب‌پذیری‌ای شناسایی نشد و نرم‌افزار NymVPN دارای وضعیت امنیتی بسیار خوبی ارزیابی شد.

WP5: تست نفوذ Crystal-bo و بررسی سورس کد در رابطه با رمزنگاری Nym

WP5 بر ارزیابی دقیق رمزنگاری به‌کاررفته در پلتفرم Nym تمرکز داشت. این ارزیابی شامل مؤلفه‌های کلیدی مانند بسته‌ی Coconut، بسته‌ی zk-nyms (پول الکترونیکی یا ecash)، پروتکل Sphinx، پروتکل Outfox، و سایر رمزنگاری‌های شناخته شده رایج، بود. کد منبع تمام طرح‌های رمزنگاری، که به‌طور کامل با زبان Rust نوشته شده بود، به‌دلیل سازمان‌دهی عالی آن مورد تحسین قرار گرفت و این ساختار خوب به ارزیابان اجازه داد تا به‌سرعت با پیاده‌سازی آشنا شوند.

پروتکل Coconut و پروتکل پول الکترونیکی (e-cash) به‌صورت گسترده بررسی شدند و استفاده مؤثر از مکانیزم‌های کورسازی (blinding) برای حفاظت از اطلاعات حساس را نشان دادند؛ بدون آنکه نشتی ناخواسته‌ای از اطلاعات شناسایی شود. عدم افشای دانش NIZKP به‌کاررفته در این پروتکل نشان دهنده این است که هیچ آسیب‌پذیری قابل بهره‌برداری نداشتند که امکان دور زدن یا فریب دادن راستی‌سنج (verifier) را فراهم کند. علاوه بر این، انتخاب کتابخانه‌های رمزنگاری پایه، به‌ویژه bls12_381، بررسی‌های سخت‌گیرانه عضویت را تضمین کرد و از حملاتی که از نقاط نامعتبر منحنی یا زیرگروه‌های نادرست استفاده می‌کنند، جلوگیری به‌عمل آورد. همچنین، تولید تصادفی کلیدهای رمزنگاری و نانس‌ها (nonces) از روش‌هایی قوی و امن از نظر رمزنگاری استفاده می‌کند، که یکپارچگی تولید کلید در سراسر پلتفرم را پشتیبانی می‌کند.

با وجود این نقاط قوت، حسابرسی چندین مسئله را بار دیگر شناسایی کرده و به‌عنوان بحرانی (critical) یا پرخطر (high risk) طبقه‌بندی کردند. در ادامه، هر یک از آن‌ها را به‌طور جداگانه بررسی می‌کنیم.

شکاف امضای EC BLS12-381 در کتابخانه نارگیل (بحرانی) برای NYM-01-009 WP5

Cure53 مشاهده کرد که تابع verify_partial_blind_signature که برای اعتبارسنجی امضاهای کور جزئی در مرحله صدور طراحی شده، شامل تمامی بررسی‌های لازم برای امضای ارائه‌شده نیست و این امکان را به مهاجم می‌دهد که با استفاده از نقاط بی‌نهایت (infinity points) روی منحنی بیضوی، اعتبارسنجی امضا را دور بزند. با این حال، ما می‌خواهیم روشن کنیم که در پروتکل نارگیل، عملکرد بررسی هزینه اعتبار شامل بررسی‌های لازم است و اعتبارهای نامعتبر را به‌طور قابل‌اعتمادی رد می‌کند. در نتیجه، با توجه به طراحی پروتکل، هرگونه تلاش برای حمله ناکام خواهد بود، زیرا مدارک جعلی در مراحل بعدی شناسایی و رد می‌شوند. این موضوع تضمین می‌کند که امنیت و یکپارچگی سیستم در عمل دچار اختلال نخواهد شد.

با این حال، ما می‌پذیریم که بررسی‌های اضافی پیشنهادی توسط Cure53 می‌توانند استحکام این توابع را در صورت استفاده در خارج از زمینه خاص Coconut افزایش دهند. از آنجا که کد ما اوپن سورس است و هدف ما ارائهٔ اجزای قابل استفاده مجدد برای جامعهٔ بزرگ‌تر است، ما بررسی‌های امضای پیشنهادی را برای نقاط بی‌نهایت به‌عنوان احتیاطی اضافی در نسخهٔ 2024.13-magura پیاده‌سازی کرده‌ایم. این تضمین می‌کند که این توابع می‌توانند با اطمینان در سایر زمینه‌ها نیز استفاده شوند و در عین حال بالاترین استانداردهای امنیتی حفظ شوند.

NYM-01-014 WP5: دور زدن امضای جزئی در eCash آفلاین (مهم)

این مسئله مشابه مورد شرح‌داده‌شده در بالا است، اما مربوط به طرح e-cash است نه Coconut. همانند پیاده‌سازی Coconut، تمام بررسی‌های لازم در مرحله خرج‌کردن پروتکل قبلاً پیاده‌سازی شده بودند که اطمینان حاصل می‌کرد هرگونه تلاش برای حمله ناکام خواهد ماند. این بدان معناست که در عمل، امنیت و یکپارچگی سیستم هرگز به خطر نیفتاده‌ است، علیرغم این که مسئله به‌عنوان بحرانی طبقه‌بندی شده بود.

با این وجود، همانند مورد Coconut، ما به‌صورت پیش‌گیرانه بررسی‌های امضای اضافی پیشنهادی Cure53 را در تمامی توابع مربوطه در نسخه 2024.13-magura پیاده‌سازی کرده‌ایم. اگرچه این بررسی‌ها برای ایمن‌سازی جریان موجود پروتکل ضروری نبودند، اما استحکام کد را افزایش دادند و تضمین کردند که این توابع می‌توانند با اطمینان در زمینه‌های دیگر مجدداً استفاده شوند. این رویکرد نشان‌دهنده تعهد ما به حفظ استانداردهای بالای امنیتی است، هم برای سیستم خودمان و هم برای جامعه گسترده‌تر اُپن سورس.

جعل طرح امضای قرارداد در Pointcheval-Sanders (بحرانی)

Cure53 یک آسیب‌پذیری را در پیاده‌سازی تابع sign در چارچوب طرح امضای Pointcheval-Sanders شناسایی کرد. قاعدتاً، این آسیب‌پذیری ناشی از آن است که در پیاده‌سازی، مقدار تصادفی h در زوج امضای (h، s) به‌صورت تصادفی انتخاب نمی‌شود. در نتیجه، اگر فقط ویژگی‌های عمومی را امضا کنیم، امضا در برابر جعل آسیب‌پذیر خواهد بود.

با این حال، مهم است که تأکید شود این آسیب‌پذیری جعل امضا در زمینهٔ پروتکل‌های Coconut یا e-cash هیچ خطری ایجاد نمی‌کند. هر دوی این پروتکل‌ها به‌صورت ذاتی بر ویژگی‌های خصوصی (private attributes) متکی هستند و از این رو، برای محاسبهٔ امضا از فرایند صدور کور (blind issuance) استفاده می‌کنند. در پروتکل blind issuance، استفاده از یک commitment به پیام‌ها به‌عنوان ورودی تابع هش تضمین می‌کند که ترکیب‌های متفاوتی از پیام‌ها، مقادیر منحصربه‌فردی برای h تولید کنند. در نتیجه، این آسیب‌پذیری تنها در صورتی بروز پیدا می‌کند که پروتکل‌های Coconut یا e-cash صرفاً با ویژگی‌های عمومی (public attributes) استفاده شوند، که در شبکهٔ Nym چنین نیست. بنابراین، ریسکی که توسط Cure53 شناسایی شده، در مورد سیستم ما صدق نمی‌کند، زیرا پروتکل‌های مورد استفاده ذاتاً این مشکل را کاهش می‌دهند.

NYM-01-042 WP5: تجمیع معیوب منجر به امضاهای بی اعتبار eCash آفلاین (بحرانی)

این مشکل مشابه مشکلات NYM-01-009 و NYM-01-014 است، که در آن تابع تجمیع مستقل برای امضاها می‌تواند یک امضای نامعتبر تولید کند، زمانی که مهاجم بتواند امضاهای جزئی را طوری دستکاری کند که منجر به نقطهٔ بی‌نهایت (infinity point) شود. با این حال، در هر دو پروتکل Coconut و e-cash، فرایند تأیید به‌طور صریح هر امضایی را که به نقطهٔ بی‌نهایت منجر شود رد می‌کند، بنابراین این مشکل امنیت یا یکپارچگی هیچ‌یک از پروتکل‌ها را به خطر نمی‌اندازد. با این وجود، مطابق با اقداماتی که برای مشکلات NYM-01-009 و NYM-01-014 انجام شده، ما بررسی‌های اضافی را در تابع تجمیع پیاده‌سازی کرده‌ایم تا پایگاه کد خود را بیشتر تقویت کرده و از هرگونه استفادهٔ نادرست احتمالی در زمینه‌های دیگر جلوگیری کنیم. (https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md).

NYM-01-005 WP5: نبود بررسی نقطهٔ بی‌نهایت منجر به افشای متن ساده در ElGamal (خطر بالا)

پیاده‌سازی فعلی Coconut و e-cash از رمزنگاری ElGamal استفاده نمی‌کند (و همچنین در طول ممیزی نیز استفاده نشده بود). در عوض، ما از commitmentهای کارآمدتر Pedersen استفاده می‌کنیم که چنین خطراتی را ایجاد نمی‌کنند. بنابراین، مشکل مربوط به ElGamal هیچ خطر امنیتی در سیستم موجود ما ایجاد نکرد‌ه‌ است. همچنین، ما اکنون ماژول Coconut crate را حذف کرده‌ایم و به تبع آن، طرح ElGamal را نیز کنار گذاشته‌ایم.

کلام آخر

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