آسیب‌پذیری امنیتی در کلاینت‌های اتریوم Teku و Besu: ریسک‌ها برای ولیدیتورها
تیم‌های توسعه کلاینت‌های اتریوم Teku و Besu به‌روزرسانی‌هایی برای رفع آسیب‌پذیری ناشی از کلیدهای گواهی ضعیف منتشر کردند. این نقص خارج از بلاکچین می‌توانست امنیت ولیدیتورها را در شرایط خاص تهدید کند؛ بااین‌حال، نودهای پیش‌فرض شبکه اصلی تحت تأثیر قرار نگرفته‌اند.
تیم‌های توسعه‌دهنده کلاینت‌های اتریوم به‌روزرسانی‌هایی را برای رسیدگی به یک مشکل گواهی که از خارج از اکوسیستم بلاکچین آغاز شده بود، منتشر کرده‌اند. این تغییرات به نحوه تصمیم‌گیری نرم‌افزار در مورد واقعی بودن یک سرویس راه دور مربوط می‌شود.
به‌روزرسانی ایمیج‌های داکر Teku و Besu
نسخه‌های Teku 26.10.3 و Besu 26.10.2 اعتماد به ریشه‌های گواهی آسیب‌دیده را از ایمیج‌های داکر (Docker) خود حذف می‌کنند. این اقدام پس از کشف کلیدهای ضعیف مرتبط با مرجع صدور گواهی (certificate authority) به نام eMudhra صورت گرفت.
برای اپراتورهای ولیدیتور، نگرانی اصلی این است که یک مهاجم بتواند هویت سرویسی را که نرم‌افزارشان به آن متصل می‌شود، جعل کند. بسته به نقش آن سرویس، یک پاسخ نادرست می‌تواند وظایف ولیدیتور را مختل کرده یا بر محل پرداخت برخی از کارمزدهای بلاک تأثیر بگذارد.
این به آن معنا نیست که همه ولیدیتورهای اتریوم در معرض خطر بوده‌اند. در اطلاعیه امنیتی Teku آمده است که یک نود پیش‌فرض در شبکه اصلی تحت تأثیر قرار نمی‌گیرد و هیچ سوءاستفاده‌ای نیز گزارش نشده است. تفاوت در نوع نصب و راه‌اندازی است. اپراتوری که از سرویس‌های HTTPS خارجی استفاده می‌کند، اتصالاتی برای بررسی دارد که ممکن است برای کسی که تمام اجزا را به صورت محلی اجرا می‌کند، وجود نداشته باشد.
این به‌روزرسانی‌ها برای نصب‌های خاصی اعمال می‌شوند. یک ایمیج داکر پچ‌شده شامل تغییراتی در محیط اجرایی بسته‌بندی‌شده درون آن است، در حالی که نرم‌افزاری که از یک فایل آرشیو نصب شده، می‌تواند از جاوا (Java) که به طور جداگانه توسط اپراتور تهیه شده، استفاده کند. این حادثه به زیرساخت‌های اطراف ولیدیتورها مربوط می‌شود و قوانین اجماع اتریوم بدون تغییر باقی مانده‌اند.
چگونه یک مشکل گواهی به یک ریسک امنیتی تبدیل شد؟
گواهی‌ها به نرم‌افزار کمک می‌کنند تا تشخیص دهد آیا به سرویسی که قصد تماس با آن را داشته، رسیده است یا خیر. یک مرجع صدور گواهی معتبر، هویت مرتبط با گواهی یک سرور را تأیید می‌کند. این سازوکار در وب‌سایت‌های HTTPS آشناست، اما در برنامه‌هایی که بدون مرورگر با یکدیگر ارتباط برقرار می‌کنند نیز عمل می‌کند.
در این حادثه، مشکل این بود که کلیدهای خصوصی مرتبط با گواهی‌های میانی (intermediate certificates) ضعیف بودند و می‌توانستند از اطلاعاتی که قبلاً عمومی شده بود، بازیابی شوند. طبق گزارش تیم امنیتی Go، این ضعف اجازه می‌داد کلیدهای خصوصی در چند میکروثانیه بازیابی شوند. سپس یک مهاجم می‌توانست گواهی‌ای برای دامنه‌ای که تحت کنترلش نبود، ایجاد کند.
یک برنامه آسیب‌پذیر ممکن بود آن گواهی را بپذیرد زیرا به نظر می‌رسید به یک مرجع مورد اعتماد برنامه منتهی می‌شود. بنابراین، هویت جعلی می‌توانست از بررسی‌ای که برای رد جعل‌کنندگان طراحی شده بود، عبور کند. البته مهاجم همچنان به راهی برای رهگیری یا تغییر مسیر اتصال قربانی نیاز داشت، اما این کلید ضعیف، رهگیری شبکه را بسیار خطرناک‌تر می‌کند.
eMudhra خطای پردازشی را عامل کلیدهای ضعیف می‌داند
در بیانیه شرکت eMudhra آمده است که یک محقق در تاریخ ۱۷ اکتبر، ۸ کلید میانی ضعیف را گزارش داد و این شرکت روز بعد هر ۸ کلید را باطل کرد. به گفته این شرکت، این کلیدها طی یک فرآیند در ۳۰ آوریل ۲۰۲۵ ایجاد شده بودند و یک مرحله ناقص «بسته‌بندی و بازگشایی» باعث تولید نسخه‌های ضعیف در کنار کلیدهای قوی اصلی شده بود.
این شرکت می‌گوید که از ماژول‌های امنیتی سخت‌افزاری معتبر استفاده شده و این نقص را به رویه‌های پیرامونی نسبت می‌دهد، نه به نبود تجهیزات. با این حال، فروشندگان نرم‌افزار همچنان باید به این احتمال که شخص دیگری بتواند از کلیدهای قابل بازیابی استفاده کند، واکنش نشان می‌دادند. در نتیجه، سازندگان مرورگر، فروشندگان سیستم‌عامل و تیم‌های زبان‌های برنامه‌نویسی هرکدام باید بررسی می‌کردند که نرم‌افزار کاربرانشان چه چیزی را می‌پذیرد.
ریسک‌های متفاوت برای ولیدیتورها بر اساس نوع اتصال
یک نود اتریوم نرم‌افزارهای با مسئولیت‌های مختلف را ترکیب می‌کند: کلاینت اجرایی (execution client) مانند Besu که اجرای تراکنش‌ها را مدیریت می‌کند و کلاینت اجماع (consensus client) مانند Teku که از پروتکل اثبات سهام پیروی می‌کند. هر دو از جاوا استفاده می‌کنند و به همین دلیل اعتماد به گواهی در محیط اجرایی جاوا برای این نسخه‌ها اهمیت پیدا کرد.
ریسک زمانی ایجاد می‌شود که اپراتورها از سرویس‌های خارجی مانند سرویس امضای راه دور یا سرویس‌های ساخت بلاک استفاده کنند. میزان خسارتی که یک جعل‌کننده می‌تواند وارد کند به اختیارات آن سرویس بستگی دارد. به همین دلیل است که صرفاً نام کلاینت، میزان آسیب‌پذیری را مشخص نمی‌کند و پیکربندی هر ولیدیتور باید به صورت جداگانه بررسی شود.
تفاوت ایمیج‌های داکر و نصب از طریق آرشیو
ایمیج‌های داکر یک برنامه را به همراه محیط مورد نیاز برای اجرای آن بسته‌بندی می‌کنند که می‌تواند شامل محیط اجرایی جاوا و گواهی‌های مورد اعتماد آن باشد. به‌روزرسانی جاوا روی دستگاه میزبان، به طور خودکار جاوا درون یک ایمیج موجود را جایگزین نمی‌کند. به همین دلیل، نسخه‌های جدید کلاینت‌ها به طور خاص به تغییرات داکر اشاره دارند.
در مقابل، کاربرانی که نرم‌افزار را از فایل آرشیو نصب می‌کنند، مسئولیت به‌روزرسانی جاوا را خود بر عهده دارند. به همین دلیل، در یادداشت‌های انتشار Besu به صراحت به کاربران آرشیو دستور داده شده است که توزیع جاوایی را که خودشان تهیه کرده‌اند، بررسی کنند. نکته مهم این است که فرآیند در حال اجرا شناسایی و جایگزین شود، زیرا یک فرآیند قدیمی می‌تواند حتی پس از دانلود فایل‌های پچ‌شده، به کار خود ادامه دهد.
