توسعه‌دهندگان کلاینت‌های اتریوم نقصی را اصلاح کردند که می‌تواند پاداش‌های ETH را منحرف کند

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

خلاصه

• کلاینت‌های اتریوم Teku و Besu پس از کشف یک آسیب‌پذیری گواهی‌نامه‌ای که می‌تواند به مهاجمان اجازه دهد تا پاداش‌های بلاک اعتبارسنج‌ها را به آدرس‌های خود منحرف کنند، به‌روزرسانی‌های امنیتی را منتشر کردند.
• این آسیب‌پذیری ناشی از کلیدهای رمزنگاری ضعیف مرتبط با هشت مرجع گواهی‌نامه‌ای است که توسط شرکت هندی eMudhra اداره می‌شود و می‌تواند به مهاجمان اجازه دهد تا گواهی‌نامه‌های جعلی ایجاد کنند.
• Teku هشدار داد که مهاجمان می‌توانند خدمات خارجی مورد استفاده توسط اعتبارسنج‌های اتریوم را جعل کنند و پیشنهادات بلاک را دستکاری کنند یا تحت شرایط خاصی امضای حساس اعتبارسنج‌ها را به‌دست آورند.
• پیکربندی‌های پیش‌فرض شبکه اصلی Teku تحت تأثیر قرار نگرفتند و توسعه‌دهندگان تأیید کردند که هیچ گزارشی از سوءاستفاده از این آسیب‌پذیری وجود ندارد.
• اپراتورهایی که از نصب‌های مستقل Teku یا Besu استفاده می‌کنند، باید محیط‌های Java خود را به‌طور جداگانه به‌روزرسانی کنند، زیرا آخرین اصلاحات تصویر Docker به‌طور خودکار گواهی‌نامه‌های Java نصب‌شده محلی را به‌روزرسانی نمی‌کند.

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

Teku نسخه 26.10.3 را در 27 اکتبر منتشر کرد، در حالی که Besu نسخه 26.10.2 را یک روز زودتر معرفی کرد. هر دو به‌روزرسانی اعتماد به گواهی‌نامه‌های آسیب‌دیده eMudhra را از تصاویر Docker خود حذف می‌کنند که اپراتورها برای استقرار و اجرای نرم‌افزار گره اتریوم استفاده می‌کنند.

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

توسعه‌دهندگان Teku تأیید کردند که پیکربندی‌های پیش‌فرض شبکه اصلی تحت تأثیر قرار نگرفته‌اند و گفتند که هیچ گزارشی از سوءاستفاده از این آسیب‌پذیری وجود ندارد.

نقص امنیتی اتریوم به گواهی‌نامه‌های آسیب‌دیده eMudhra نسبت داده شده است

این مشکل امنیتی با یک خطای رمزنگاری مربوط به هشت مرجع گواهی‌نامه‌ای میانه که توسط eMudhra اداره می‌شود، آغاز شد، که کلیدهای خصوصی آن‌ها با استفاده از تصادفی ناکافی تولید شده بود.

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

طبق مشاوره امنیتی 26 اکتبر از مایکروسافت، شش مورد از گواهی‌نامه‌های آسیب‌دیده برای تأمین امنیت اتصالات اینترنتی استفاده شده‌اند، در حالی که دو مورد باقی‌مانده با امضای کد مرتبط بودند.

کلیدهای آسیب‌دیده می‌توانند به کسی اجازه دهند تا گواهی‌نامه‌هایی ایجاد کند که برای برنامه‌هایی که به مرجع گواهی‌نامه آسیب‌دیده اعتماد می‌کنند، واقعی به نظر برسند.

eMudhra گواهی‌نامه‌های میانه آسیب‌دیده را در 18 اکتبر لغو کرد، در حالی که ارائه‌دهندگان فناوری شروع به حذف اعتماد به زنجیره‌های گواهی‌نامه آسیب‌دیده از نرم‌افزار خود کردند.

مایکروسافت به‌طور بعدی مرجع‌های گواهی‌نامه آسیب‌دیده را از طریق یک به‌روزرسانی امنیتی ویندوز در 20 اکتبر مسدود کرد و یک به‌روزرسانی دیگر در 26 اکتبر برای حذف هفت گواهی‌نامه مرتبط از لیست معتبر خود منتشر کرد.

با این حال، این مشکل برای اتریوم همچنان مرتبط بود زیرا Teku و Besu از Java استفاده می‌کنند که اعتبارسنجی گواهی‌نامه آن به‌طور پیش‌فرض وضعیت لغو را بررسی نمی‌کند.

در نتیجه، نصب‌های آسیب‌دیده Java می‌توانند به پذیرش گواهی‌نامه‌های مرتبط با مراجع آسیب‌دیده ادامه دهند حتی پس از لغو آن‌ها.

چگونه مهاجمان می‌توانند پاداش‌های اعتبارسنج اتریوم را منحرف کنند

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

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

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

بر اساس گزارش Teku، چنین حمله‌ای می‌تواند باعث شود که یک اعتبارسنج بلوکی را پیشنهاد کند که هزینه‌های تراکنش را به آدرسی که تحت کنترل مهاجم است، هدایت کند.

این مشاوره خدمات امضای خارجی را به عنوان یک جزء دیگر که ممکن است در معرض خطر باشد، شناسایی کرد. این خدمات کلیدهای امضای اعتبارسنج را به طور جداگانه از نرم‌افزار اصلی گره نگه می‌دارند و در صورت درخواست، امضاها را ارائه می‌دهند.

یک مهاجم که خود را به عنوان یک امضاکننده خارجی جا می‌زند، ممکن است بتواند امضاهای مرتبط با خروج اعتبارسنج‌ها را بسته به پیکربندی و حفاظت‌های موجود به دست آورد.

Teku این سناریو را به‌ویژه جدی طبقه‌بندی کرد، اگرچه پیکربندی‌هایی که از احراز هویت TLS متقابل استفاده می‌کنند، می‌توانند عواقب را به یک حمله انکار سرویس محدود کنند.

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

این آسیب‌پذیری بر پروتکل‌های شبکه همتا به همتای زیرساخت اتریوم تأثیر نگذاشت، که به گواهی‌های صادر شده آسیب‌دیده وابسته نیستند.

Teku و Besu اصلاحاتی برای گره‌های آسیب‌دیده اتریوم منتشر کردند

پس از افشاگری، Teku نسخه 26.10.3 را منتشر کرد تا چهار ریشه گواهی را از تصاویر Docker خود حذف کند، از جمله emSign ECC Root CA G3، emSign Root CA G1، emSign Root CA G2 و AAA Certificate Services.

Besu همان حذف گواهی‌ها را در نسخه 26.10.2 معرفی کرد و خطر را برای اپراتورهایی که از تصاویر Docker به‌روز شده خود استفاده می‌کنند، برطرف کرد.

با این حال، این نسخه‌ها به‌طور خودکار نصب‌های Java را که به‌طور جداگانه توسط اپراتورهای گره نگهداری می‌شوند، به‌روزرسانی نمی‌کنند.

کاربرانی که Teku یا Besu را از طریق توزیع‌های باینری مستقل اجرا می‌کنند، باید زمان اجرای Java نصب شده خود را بررسی کرده و در صورت لزوم گواهی‌های معتبر آن را به‌روزرسانی کنند.

Teku هشدار داد که اپراتورهایی که هنوز از Java 26 استفاده می‌کنند، باید به Java 25 مهاجرت کنند زیرا نسخه قبلی به پایان عمر خود رسیده و به‌روزرسانی‌های لازم را دریافت نخواهد کرد.

این مشاوره همچنین برخی از پیکربندی‌های شبکه آزمایشی را به عنوان مواردی که ممکن است در معرض خطر باشند، شناسایی کرد، از جمله تنظیماتی که وضعیت اولیه بلاک‌چین خود را از طریق HTTPS دانلود می‌کنند.

به‌روزرسانی‌های امنیتی پس از نگرانی‌های اخیر دیگر در مورد زیرساخت اعتبارسنجی اتریوم انجام می‌شود. اوایل این ماه، crypto.news گزارش داد که MetaMask شروع به خروج از اعتبارسنج‌های آسیب‌دیده پس از یک حادثه امنیتی زیرساختی جداگانه که در 30 سپتامبر افشا شد، کرده است.

به‌تازگی، توسعه‌دهندگان اتریوم یک نقص سپرده اعتبارسنج را در به‌روزرسانی Glamsterdam اصلاح کردند پس از اینکه محققان سناریویی را شناسایی کردند که در آن حساب‌های سازنده می‌توانستند ETH را که برای اعتبارسنج‌ها در نظر گرفته شده بود، دریافت کنند.

به‌روزرسانی Glamsterdam به‌طور جداگانه با تأخیر مواجه شده است پس از اینکه توسعه‌دهندگان فعال‌سازی شبکه آزمایشی Hoodi را برای بررسی نگرانی‌های سازگاری قرارداد هوشمند مربوط به EIP-8037 به تعویق انداختند.

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