Клієнти Ethereum виправили вразливість, яка могла перенаправити винагороди ETH

Розробники клієнтів Ethereum Teku та Besu випустили оновлення безпеки для усунення вразливості сертифіката, яка могла дозволити зловмисникам видавати себе за сервіси, що використовуються валідаторами, і потенційно перенаправляти їхні блокові винагороди.

Резюме

• Клієнти Ethereum Teku та Besu випустили оновлення безпеки після виявлення вразливості сертифіката, яка могла дозволити зловмисникам перенаправляти блокові винагороди валідаторів на свої адреси.
• Вразливість виникла через слабкі криптографічні ключі, пов'язані з вісьмома сертифікаційними центрами, які управляються індійською компанією eMudhra, що могло дозволити зловмисникам створювати підроблені сертифікати.
• Teku попередив, що зловмисники могли б видавати себе за зовнішні сервіси, які використовуються валідаторами Ethereum, і маніпулювати пропозиціями блоків або отримувати чутливі підписи валідаторів за певних конфігурацій.
• За замовчуванням конфігурації основної мережі Teku не постраждали, і розробники підтвердили, що про експлуатацію вразливості не було повідомлено.
• Оператори, які використовують окремі установки Teku або Besu, повинні окремо оновити свої середовища Java, оскільки останні виправлення образів Docker не оновлюють локально встановлені сертифікати Java автоматично.

Згідно з рекомендаціями безпеки, що супроводжують випуски, проблема виникла через скомпрометовані ключі сертифікаційного центру, що належать індійському постачальнику цифрових сертифікатів eMudhra, які залишили певні конфігурації вузлів Ethereum відкритими для підроблених HTTPS-з'єднань.

Teku випустив версію 26.10.3 27 жовтня, тоді як Besu представив версію 26.10.2 за день до цього. Обидва оновлення усувають довіру до постраждалих сертифікатів eMudhra з їхніх образів Docker, які оператори використовують для розгортання та запуску програмного забезпечення вузлів Ethereum.

Вразливість могла вплинути на валідаторів, які покладаються на зовнішні сервіси для підписання транзакцій, зв'язку з вузлами маяка або отримання інформації про створення блоків. Зловмиснику потрібно було перехопити постраждале з'єднання та представити підроблений сертифікат, який програмне забезпечення валідатора приймає за легітимний.

Розробники Teku підтвердили, що конфігурації основної мережі за замовчуванням не постраждали і заявили, що не було повідомлень про експлуатацію вразливості.

Вразливість безпеки Ethereum пов'язана з скомпрометованими сертифікатами eMudhra

Проблема безпеки почалася з криптографічної помилки, що стосується восьми проміжних сертифікаційних центрів, які управляються eMudhra, приватні ключі яких, як виявилося, були згенеровані з недостатньою випадковістю.

Дослідники виявили проблему 17 жовтня, виявивши, що приватні ключі можна математично відновити з інформації, доступної в публічних сертифікатах.

Згідно з рекомендацією безпеки Microsoft від 26 жовтня, шість з постраждалих сертифікатів використовувалися для забезпечення інтернет-з'єднань, тоді як решта два були пов'язані з підписанням коду.

Скомпрометовані ключі могли дозволити комусь створювати сертифікати, які виглядали б справжніми для додатків, які продовжували довіряти постраждалим сертифікаційним центрам.

eMudhra відкликав постраждалі проміжні сертифікати 18 жовтня, тоді як постачальники технологій почали усувати довіру до скомпрометованих сертифікатних ланцюгів зі свого програмного забезпечення.

Microsoft, в свою чергу, заблокувала постраждалі сертифікаційні центри через оновлення безпеки Windows 20 жовтня і випустила ще одне оновлення 26 жовтня, щоб видалити сім пов'язаних сертифікатів зі свого списку довірених.

Однак проблема залишалася актуальною для Ethereum, оскільки Teku та Besu використовують Java, в якій перевірка сертифікатів за замовчуванням не перевіряє статус відкликання.

В результаті постраждалі установки Java могли продовжувати приймати сертифікати, пов'язані зі скомпрометованими центрами, навіть після їх відкликання.

Як зловмисники могли перенаправити винагороди валідаторів Ethereum

Рекомендація безпеки Teku вказала на кілька можливих сценаріїв атаки, що стосуються валідаторів, які спілкуються із зовнішніми сервісами через HTTPS-з'єднання.

Один зі сценаріїв передбачає, що зловмисник видає себе за віддалений вузол-маяк, який використовується валідатором для координації своїх обов'язків в Ethereum.

Якщо зловмиснику вдасться перехопити з'єднання та представити підроблений сертифікат, валідатор може отримати маніпульовану інформацію про блок, який він готується запропонувати.

Згідно з Teku, така атака може призвести до того, що валідатор запропонує блок, який перенаправляє комісії за транзакції на адресу, контрольовану зловмисником.

У попередженні було вказано, що зовнішні сервіси підпису є ще одним потенційно вразливим компонентом. Ці сервіси зберігають ключі підпису валідаторів окремо від основного програмного забезпечення вузла та надають підписи за запитом.

Зловмисник, який видає себе за зовнішнього підписувача, може потенційно отримати підписи, пов'язані з виходами валідаторів, залежно від конфігурації та доступних засобів захисту.

Teku класифікував цей сценарій як особливо серйозний, хоча конфігурації, що використовують взаємну аутентифікацію TLS, можуть обмежити наслідки до відмови в обслуговуванні.

Інші потенційно вразливі з'єднання включають клієнтів виконання, будівельників блоків, реле та сервіси, що використовуються для отримання інформації про конфігурацію валідаторів.

Вразливість не вплинула на основні протоколи мережі Ethereum, які не залежать від скомпрометованих сертифікаційних центрів.

Teku та Besu випускають виправлення для вразливих вузлів Ethereum

Після розкриття 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.

Оновлення безпеки слідують за іншими нещодавніми занепокоєннями, пов'язаними з інфраструктурою валідаторів Ethereum. Раніше цього місяця crypto.news повідомив, що MetaMask почав виходити з вразливих валідаторів після окремого інциденту з безпекою інфраструктури, розкритого 30 вересня.

Нещодавно розробники Ethereum виправили дефект депозиту валідаторів у майбутньому оновленні Glamsterdam після того, як дослідники виявили сценарій, у якому облікові записи будівельників могли отримувати ETH, призначений для валідаторів.

Оновлення Glamsterdam окремо зіткнулося з затримками після того, як розробники відклали активацію тестової мережі Hoodi для розслідування проблем сумісності смарт-контрактів, пов'язаних з EIP-8037.

Відкладення 26 жовтня скасувало заплановану активацію як змін виконання Амстердама, так і змін консенсусу Глоас, а також запропоноване збільшення ліміту газу Hoodi до 200 мільйонів. Розробники Ethereum не оголосили нову дату активації.

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.