Teku та Besu оновили свої Docker-образи після події eMudhra, оскільки слабкі ключі сертифікатів створювали ризик для програмного забезпечення, що підключається до зовнішніх служб, включаючи деякі розгортання валидаторів Ethereum.
- Teku 26.10.3 та Besu 26.10.2 видалили впливові сертифікати довіри з Docker-образів через подію eMudhra.
- Teku зазначає, що за замовчуванням вузли основної мережі не впливаються, а фактичний рівень відкритості залежить від HTTPS-з’єднань та Java-середовища, яке використовує оператор.
- Ризики, що розкриваються, стосуються підроблених сервісів та діяльності верифікаторів; у повідомленні Teku не повідомляється про використання цих вразливостей.
Для операторів найбільш актуальним питанням є: чи прийматиме їхнє програмне забезпечення підлогові сертифікати під час підключення до інших сервісів. Відповідь залежить від використовуваного підключення та встановленої версії Java, тому оновлення клієнта не означає, що кожен валидатор стикається з однаковим ризиком.
Оновлення Docker-образів Teku та Besu
Команда клієнтів Ethereum опублікувала оновлення для виправлення проблеми з сертифікатом, яка виникла поза блокчейном. Відповідні зміни стосуються того, як програмне забезпечення визначає, чи є віддалені сервіси справжніми.
Teku 26.10.3 та Besu 26.10.2 видалили довіру до впливових кореневих сертифікатів із своїх Docker-образів. Цей випуск був спричинений виявленням слабких ключів, пов’язаних із центром сертифікації eMudhra.
Для операторів валидаторів проблема полягає в тому, що зловмисник підробляє сервіс, до якого під’єднане програмне забезпечення. Залежно від ролі цього сервісу, підроблені відповіді можуть порушити обов’язки або вплинути на те, куди спрямовуються комісії за блоки.
Але це не означає, що кожен валидатор Ethereum піддається ризику. За повідомленням про безпеку Teku, вузли основної мережі за замовчуванням не страждають, і на даний момент не повідомляється про використання цієї вразливості.
Різниця полягає в способі встановлення. Оператори, що використовують зовнішній HTTPS-сервіс, повинні перевіряти з’єднання, які можуть відсутні у повністю локальних компонентах.
Ці оновлення застосовуються до певного середовища встановлення. Патч-версія Docker-образу містить зміни виконавчого середовища, вбудовані в контейнер, тоді як програмне забезпечення, встановлене з архіву, може використовувати Java, надану оператором окремо.
Ця подія вплинула на інфраструктуру навколо валідаторів, але правила консенсусу Ethereum не змінилися.
Чому проблеми з сертифікатами можуть перетворитися на безпекові ризики?
Сертифікати допомагають програмному забезпеченню визначити, чи підключенося до очікуваного сервісу. Довірені центри видачі сертифікатів надають підтвердження ідентичності, що відповідає сертифікату сервера.
Цей механізм поширений на веб-сайтах HTTPS, але також застосовний до додатків, які не комунікують через браузер. Тилові сервіси також можуть залежати від цих перевірок ідентичності.
Центри сертифікації можуть використовувати проміжні сертифікати під довіреними кореневими сертифікатами. Приватні ключі, пов’язані з цими проміжними сертифікатами, повинні залишатися безпечними, оскільки їх можна використовувати для видання додаткових сертифікатів.
У цій події проблема полягала не лише в тому, що хтось отримав звичайну інформацію для входу на сервер. Впливові проміжні ключі можна відновити з вже публічно доступної інформації.
Група безпеки Go зазначила, що ця вразливість дозволяє відновити приватний ключ на рівні мікросекунд. У їх описі також зазначено, що зловмисники можуть створювати сертифікати для доменів, якими вони не володіють.
Якщо вразливе застосунок вважає, що цей сертифікат все ще можна відстежити до організації, якій він довіряє, він може прийняти його. Таким чином, підробка особи може пройти перевірки, призначені для відмови у доступі шахраям.
Проте зловмисникам все ще потрібен якийсь спосіб перехопити або переадресувати з’єднання жертв. Слабкі ключі не дозволяють їм автоматично з’являтися між кожним користувачем та кожним сервером.
Ця умова обмежує способи, за якими може відбутися атака, але не робить недійсність сертифікатів безпечною. Доки програмне забезпечення сприймає підробника як справжній кінцевий пункт, перехоплення мережі стає більш небезпечним.
Дослідження Kudelski Security вивчило вплинуті рівні сертифікатів. Проблема полягає в тому, що програмне забезпечення може приймати сертифікати, підписані ключами, які атакувач може відтворити.
eMudhra приписує слабкі ключі помилкам обробки
Заява eMudhra стверджує, що дослідник повідомив про 8 слабких проміжних ключів 17 жовтня. Компанія відкликала ці 8 ключів на наступний день.
Компанія зазначила, що ці проміжні сертифікати були згенеровані під час церемонії ключів 30 квітня 2025 року. За словами компанії, дефектні кроки wrap і unwrap створили слабкі копії окрім початкових сильних ключів.
Компанія зазначила, що використовує сертифікований апаратний модуль безпеки. Вона пояснила, що відмова була спричинена одним із етапів побічних процесів, а не відсутністю такого обладнання.
Компанія також зазначила, що жоден із 7 проміжних сертифікатів ніколи не використовувався в продуктивному середовищі, а ще один не був виданий. Компанія заявила, що подія не призвела до компрометації інфраструктури або витоку даних.
Ці твердження пояснюють опис eMudhra щодо своїх внутрішніх процесів. Однак постачальнику програмного забезпечення все ще потрібно враховувати іншу можливість: інші сторони можуть використовувати відновлювані ключі.
Система сертифікатів не може покладатися лише на обіцянку початкового оператора більше не видавати жодних сертифікатів. Коли хтось інший зможе відтворити підписовий ключ, така гарантія більше не зможе контролювати всі можливі сертифікати, які можуть бути створені.
Тому заходи щодо реагування вийшли за межі компанії, яка створила ключ. Виробники браузерів, постачальники операційних систем та команди мов програмування повинні враховувати, яке ПЗ їхніх користувачів буде приймати.
Ці виправлення будуть передані користувачам через різні оновлення. Браузер може отримати список блокування, тоді як інший незалежний додаток Java може продовжувати використовувати старий набір довірених сертифікатів.
Слабкі ключі та застосунки, що приймають ці ключі, — це дві різні частини однієї проблеми. Відкликання сертифікатів вирішує проблему на рівні організаційних записів, а клієнти також потребують надійного способу визначення, які шляхи довіри слід відхиляти.
Зовнішні сервіси створюють різні ризики для валидаторів
Вузли Ethereum складаються з програмного забезпечення, яке виконує різні функції. Документація клієнтів Ethereum розрізняє виконавчі клієнти та клієнти консенсусу: перші обробляють виконання транзакцій та стан, а другі дотримуються консенсусу на основі доведення частки.
Програмне забезпечення валидатора додає обов’язки з пропозиції блоків та підтвердження ланцюга. Оператори можуть запускати ці компоненти локально або підключати частину зовнішніх служб.
Teku — це клієнт консенсусу, Besu — це клієнт виконання. Обидва використовують Java, що є причиною того, що довіра до сертифікатів під час виконання пов’язана з їхніми випусками.
Сервіси за межами локального пристрою додають перевірку ідентичності до такої угоди. Програмне забезпечення має підтвердити, що точка відповіді на запит — це саме очікуваний постачальник.
Наприклад, оператори можуть використовувати віддалені сервіси підпису, а не зберігати операції підпису в тому ж процесі. Хтось може залежати від зовнішніх точок для отримання даних або послуг побудови блоків.
Шкода, яку можуть завдати підробники, залежить від того, що дозволено робити цій службі. Служба, яка отримує лише дані моніторингу, має інший рівень ризику, ніж служба, яка бере участь у прийнятті рішень щодо підпису.
Маршрут мережі також важливий. З’єднання через публічну інфраструктуру має інші можливості перехоплення порівняно з компонентами, що знаходяться лише на одному хості або в строго контролюваній приватній мережі.
Приватна мережа не може запобігти всім можливим поломкам, але вона зменшує шанси зловмисників отримати доступ до місця, необхідного для перешкоджання трафіку.
Тому лише за назвою клієнта не можна визначити, чи є він вразливим. Однакове програмне забезпечення може бути розгорнуто в середовищах з різними ендпоінтами, сховищами довіри та контролем доступу.
Справжнє питання, яке потрібно відповісти: яке з’єднання пройшло через вплинутий шлях і прийняло сертифікат. Після того як це буде з’ясовано, оператор зможе оцінити, який рівень повноважень мав би мати підроблений сервіс у роботі перевіряючого.
Чому Docker-образи та архівні встановлення відрізняються?
Docker-образи пакують додаток разом із середовищем, необхідним для його роботи, що може включати Java-середовище виконання та сертифікати, яким це середовище довіряє.
Оновлення Java на хості не замінює автоматично Java у наявних образах. Контейнери можуть продовжувати використовувати вбудовані файли.
Ось чому в примітках до випуску клієнта особливо згадуються зміни, пов’язані з Docker. У примітках до Teku зазначено, що їхній базовий образ Eclipse Temurin на той момент не містив відповідних видалень, тому образ клієнта був змінений безпосередньо.
Замітки про випуск Besu також зазначають, що видалення сертифікатів поширюється на Docker-образи, і чітко вимагають, щоб користувачі, що встановили систему вручну, перевірили надану ними версію Java.
Архівна установка покладає цю відповідальність на оператора. Клієнт Ethereum може бути оновлений, але його окремий середовище виконання все ще може містити старі сховища сертифікатів.
Навпаки, під час обслуговування також виникають подібні відмінності. Заміна виконавчого середовища хоста впливає на процеси, що використовують це виконавче середовище, але не впливає на іншу установку, яка використовує інший шлях до Java.
Подія Oracle рекомендує користувачам оновити впливові середовища виконання або дотримуватися альтернативних рішень, наведених у їхній документації. Також вимагається перезавантажити запущені екземпляри та розглянути кожну окрему установку окремо.
Це робить запущені процеси важливішими, ніж завантажені оновлення. Сервер може містити виправлені файли, але старі процеси продовжуватимуть працювати, доки їх не замінять або не перезавантажать.
Сховище налаштованих сертифікатів додало ще один варіант. Деякі організації можуть використовувати власне сховище сертифікатів, яке підтримується для їхніх служб, а не лише стандартне сховище, що надається Java.
Справжнє завдання — визначити, що саме використовує клієнт. Спосіб встановлення, розташування під час виконання та конфігурація довіри разом визначають, чи було застосовано опубліковане виправлення до того з’єднання, яке його потребує.
Різниця в перевірці відкликання в різних застосунках
Відкликання означає, що сертифікат більше не повинен прийматися. Але це не гарантує, що кожна програма перевірятиме останню інформацію про відкликання перед встановленням з’єднання.
Різні застосунки отримують цю інформацію по-різному. Деякі запитують онлайн-сервіси, інші використовують блакитні списки, надані постачальниками, а деякі в основному покладаються на сертифікати з локального довірених сховищ.
Відповідь команди Go пояснює, чому постачальник середовища виконання може потребувати безпосереднього втручання. Команда запустила терміновий безпечний реліз 19 жовтня і зазначила, що виправлена версія була надана приблизно через 7,5 години після отримання повідомлення.
Ця дія блокує шляхи сертифікатів, що стосуються застосунків, що використовують відповідні дії перевірки Go. Користувачі Java повинні отримати захист через власні налаштування середовища виконання та довіри.
Teku повідомляє, що Java за замовчуванням не перевіряє відкликання. Саме тому, навіть якщо eMudhra вже відкликав ці проміжні сертифікати, все ще необхідно видалити їх з локальної довіри.
Видалення кореневого сертифіката та блокування проміжних сертифікатів також можуть впливати на різні рівні. Перше відмовляє в доступі до певної пошкодженої ланцюжка, тоді як друге може відмовляти в доступі до ширшого ланцюжка сертифікатів, що призводять до видаленого кореневого сертифіката.
Правильна реалізація належить постачальнику та організації, що підтримує застосунок. Тимчасове вимкнення перевірки ідентичності видалить лише захист, але не вирішить проблему довіри.
Також може знадобитися налаштування легальних служб. Якщо їхні сертифікати залежать від шляхів, які клієнти зараз відмовляються приймати, то постачальники служб повинні запропонувати прийнятні альтернативи, а не сподіватися, що користувачі відновлять небезпечну довіру.
Це також пояснює, чому подія з сертифікатом може тривати кілька днів. Виявлення може бути миттєвим, але захист поступово впроваджується через різні процеси публікації та підтримки в браузерах, упакованих додатках та приватній інфраструктурі.
Для операторів валидаторів ключовим результатом є те, чи були відхилені непідтверджені ідентифікації. Оголошення про скасування в інших частинах програмного екосистеми не підтверджують, що процес вузла досяг цього результату.
Чи піддаються винагороди та стейкінг валидаторів однаковому ризику?
Стейкінг валидаторів, обов’язки підпису та оплата комісій взаємопов’язані, але підкоряються різним механізмам. Проблеми, що впливають на одну з них, не повинні автоматично вважатися контролем над усіма цими аспектами.
Документація щодо стейкінгу Ethereum: валідатори отримують винагороди за виконання своїх обов’язків і підлягають покаранню за відключення або доведену неправильну поведінку. Права на підпис та права на вивід коштів відіграють різні ролі в системі.
Ключ сертифіката належить до ідентифікаційної системи, використовуваної для підключення. Він не є приватним підписувальним ключем валидатора і не розкриває безпосередньо облікові дані для виведення вже зарезервованих ETH.
Проте підроблений сервіс все ще може впливати на поведінку верифікаторів. Його вплив залежить від того, які запити або відповіді обробляє цей сервіс, а також які додаткові перевірки залишаються.
Пропозиція блоку містить отримувача плати за виконання відповідних платежів. Якщо певний шлях може змінювати пропозицію чи конфігурацію, це може призвести до наслідків без необхідності контролювати всю ставку.
Служба підпису висуває ще один набір питань, оскільки вона бере участь у автентифікації дій верифікаторів. Її власні заходи захисту, включаючи обмеження запитів та захист від конфліктних підписів, впливають на те, наскільки ефективними можуть бути атаки.
Пропуск обов’язків через перерву в обслуговуванні також є можливим наслідком. Навіть якщо жоден платіж не був успішно переведений, атакувач може зменшити нагороду, просто запобігаючи правильній відповіді.
Фінансові наслідки цих результатів неоднакові. Втрату можливості запропонувати блок, звичайне покарання за офлайн-стан та покарання за слеші не можна поєднувати.
Опис клієнтського оголошення стосується можливих наслідків при впливовій конфігурації, але не підтверджує, що кожен оператор став жертвою цих наслідків, ніж кількість вкрадених ETH.
Для власників, які використовують сервіси стейкінгу, справді важливим є фактичний розгортання сервісу. Кількість ETH, яку керують, не свідчить про те, які віддалені сервіси або сховища сертифікатів використовують їхні оператори.
Валідатори також залежать від програмного забезпечення, яке знаходиться поза Ethereum.
Правила мережі Ethereum — лише частина того, на чому ґрунтується робота. Апаратне забезпечення, середовище виконання, хостинг, конфігурація та зовнішні сервіси впливають на те, чи зможе валідатор правильно виконувати свої обов’язки.
Центр сертифікації розташований поза протоколом Ethereum, але його відмова стає важливою, коли програмне забезпечення верифікатора залежить від нього для ідентифікації служби. Цього одного достатньо, щоб перенести загальну проблему безпеки інтернету до інфраструктури стейкінгу.
Різноманітність клієнтів залишається цінною, оскільки різні реалізації можуть зменшити залежність від однієї кодової бази. Але це не означає, що кожна залежність є незалежною.
Два клієнти можуть використовувати одну й ту саму середовище виконання мови програмування. Різні оператори також можуть використовувати одного й того самого хостинг-провайдера, сервіс підпису або інфраструктуру побудови блоків.
Ці спільні компоненти створюють спільну поверхню вразливості, коли програмне забезпечення Ethereum відрізняється. Тому для розуміння ситуації з розгортанням недостатньо дивитися лише на кількість клієнтів.
Використання зовнішніх послуг також призводить до компромісів. Спеціалізовані сервіси підпису можуть покращити захист ключів, але також роблять аутентифікацію з цим сервісом ще важливішою.
Локальне виконання також має власні вимоги до обслуговування. Розміщення компонентів на одному пристрої може зменшити частину мережевого відкриття, але операторам все ще потрібно керувати оновленнями програмного забезпечення та доступом до цього пристрою.
Цей інцидент не передбачає автоматичного визначення найбезпечнішої архітектури для всіх випадків. Він показує, що необхідно розуміти та підтримувати відповідальність кожної з’єднаної ланки.
Ця різниця важлива й для звичайних користувачів ETH. Застосування патча сертифікатів у інфраструктурі вузлів не означає, що кожен гаманець повинен перемістити кошти, ні що баланс облікового запису Ethereum змінився.
Відповідні дії належать операторам вплинутих програмних продуктів. Лише вони можуть ідентифікувати відповідні середовища виконання, кінцеві точки та налаштування довіри, а потім застосувати рекомендації постачальника до систем, які встановлюють ці з’єднання.
Оператори повинні застосувати та перевірити оновлення
Ці випуски надають операторам можливість видалити вразливі шляхи довіри з підтримуваних образів Docker. Архівні користувачі повинні вирішити окремі робочі завдання середовища виконання згідно з рекомендаціями своїх постачальників Java.
Доступність патча — це лише перший крок. Оновлене середовище також повинно реально працювати та забезпечувати очікувану конфігурацію та нормальне функціонування служб.
Для постачальника послуг перерва, викликана недавно відхиленним сертифікатом, може вимагати заміни сертифіката на ендпоінті. Під час відновлення послуги слід зберігати перевірку тотожності, а не обходити її.
Подальше розкриття інформації може додатково уточнити вплив. Оператори можуть виявити конфігурації, які приймають вплинутий ланцюжок сертифікатів, або повідомити про події, пов’язані з конкретними службами.
На даний момент повідомлення Teku не використовуються і розрізняють використання за замовчуванням на основній мережі та впливові зовнішні підключення. Це найбільш чіткий вихідний матеріал для опису поточного експозиційного поверхню Ethereum.
Завантажені оператори мають підстави для оновлення. Будь-які фінансові втрати залежать від того, який сервіс підробив атакуючий, чи було перехоплено трафік, та чого дозволив цьому сервісу верифікатор.
На що варто звертати увагу
- Оновлення клієнта: Слідкуйте за випусками Teku та Besu та переконайтесь, що ви використовуєте виправлену версію.
- Java-сертифікати: дивіться рекомендації виробника щодо використання середовища виконання Java та сховищ сертифікатів для кожного встановлення.
- Зовнішні посилання: перевірка HTTPS-посилань на сервіси віддаленого підпису, даних та побудови блоків.
- Сповіщення про безпеку: зверніть увагу на підтвердження атаки або додаткові пояснення від команди клієнта та постачальника Java.
Часті питання
Що таке подія eMudhra?
Ця подія стосується слабкого приватного ключа, пов’язаного з проміжним сертифікатом центру видачі сертифікатів eMudhra. Дослідники виявили, що ці ключі можна відновити з відкритої інформації, що може дозволити іншим створювати сертифікати для доменів, якими вони не володіють. Програмне забезпечення, яке довіряє шляху сертифікатів, може приймати такі підроблені ідентифікації. Зловмисникам все ще потрібен якийсь спосіб перехопити або перенаправити з’єднання, щоб вигадувати себе за цільовий сервіс.
Чи провалився консенсус Ethereum?
Ні. Проблеми, згадані у звіті, стосуються того, як програмне забезпечення перевіряє ідентичність зовнішніх служб, а не правил, за якими Ефіріум досягає згоди в блокчейні. Оновлення клієнта змінює довіру до сертифікатів у вплинутих середовищах програмного забезпечення. Деякі розгортання верифікаторів, якщо зовнішня служба буде підроблена, все ще можуть стикатися з операційними ризиками. Ця ймовірність залежить від підключення та ролі служби і не означає, що правила консенсусу Ефіріуму були порушені.
Які клієнти були оновлені?
Teku 26.10.3 та Besu 26.10.2 оновили свої Docker-образи, щоб видалити вразливі сертифікати. Teku — це консенсус-клієнт, Besu — виконавчий клієнт, обидва використовують Java. Спосіб встановлення важливий, оскільки ця зміна стосується середовищ, що надаються цими образами. Оператори, які встановлюють архіви клієнтів і надають Java-середовище самостійно, повинні окремо ознайомитися з інструкціями щодо цього середовища.
Чи постраждають усі валідатори?
Ні. Повідомлення Teku стверджує, що за замовчуванням вузли головної мережі не впливаються. Ризик залежить від того, чи було здійснено відповідне зовнішнє HTTPS-з’єднання та чи перевірка сертифіката приймає вплинутий шлях довіри. Різні оператори можуть запускати один і той же клієнт на різних сервісах, версіях Java та бібліотеках сертифікатів. Тому назва клієнта або кількість застаканої ETH не вказують на те, чи є конкретний валидатор під впливом.
Чи може оновлення Docker перевизначити всі способи встановлення?
Ні. Патчований образ Docker оновить середовище, упаковане всередині цього образу, але архівна встановлення може використовувати Java, надану оператором окремо. Інші контейнери або служби також можуть мати власні середовища виконання. Оператор повинен визначити, який спосіб встановлення використовується процесами, що працюють, і дотримуватися інструкцій від постачальника. Файли, які були запатчені на сервері, не захищають процеси, які все ще працюють у старому середовищі.
Чи підтверджено використання?
На момент, зазначений у цьому тексті, повідомлення Teku не повідомляли про використання. Відповідні розкриття описують слабке місце та його можливі наслідки, а не підтверджують, що зловмисники вже використовували його для валидаторів. Ця різниця важлива при обговоренні втрат. Наявність можливої шляху підробки сервісу не означає, що обов’язки підпису були маніпульовані, платежі за комісії були перенаправлені або стейкінг ETH був вкрадений.
Чи будуть депозити валидаторів автоматично відкриті?
Ні. Ключ підпису сертифіката відрізняється від ключа підпису валідатора та від облікових даних для виведення коштів. Відновлення пошкодженого ключа сертифіката не призводить автоматично до розкриття ключів, необхідних для виведення застаканого ETH. Сервіс, який був підроблений, все ще може порушити обов’язки або вплинути на інформацію, яку використовують валідатори, залежно від способу розгортання. Потрібно оцінити можливі наслідки саме для цього сервісу, а не сприймати це як автоматичний доступ до всіх депозитів.
Що повинен робити оператор?
Оператори повинні дотримуватися відповідних випусків Teku або Besu, а також рекомендацій щодо їхніх випусків Java. Необхідно визначити середовища виконання та сховища сертифікатів, які використовуються кожним впливовим процесом, включаючи ті, що надаються всередині контейнерів. Після застосування рекомендованих оновлень слід переконатися, що оновлені служби працюють і необхідні з’єднання продовжують функціонувати нормально. Вимкнення перевірки сертифікатів для відновлення несправних з’єднань призводить до втрати захисту, який ці перевірки мають забезпечувати.