Bitcoin Core 31.0 містить уразливість у сфері приватності: зловмисні вузли можуть примусово ініціювати розкриття IP-адреси

Команда розробників Bitcoin Core 12 червня опублікувала допис у X, підтвердивши, що нова функція -privatebroadcast у версії Bitcoin Core 31.0 містить проблему з конфіденційністю: за певних мережевих умов, якщо v2-встановлення зв’язку (handshake) не вдається, Bitcoin Core підключатиметься до рівних (пірингових) вузлів через IPv4 або IPv6, тим самим розкриваючи стороні-отримувачу відкриту (безпосередню) IP-адресу відправника.

Умови, за яких постраждають користувачі: п’ять пунктів мають одночасно виконатися

Згідно з офіційним оголошенням Bitcoin Core, вузол зазнає впливу цього вразливості лише тоді, коли одночасно виконуються всі такі п’ять умов:

· Вузол працює під Bitcoin Core 31.0 і ввімкнено функцію -privatebroadcast

· Транзакції транслюються (ширяться) через RPC-команду sendrawtransaction (гаманецьні RPC на кшталт sendtoaddress, sendall тощо не використовують private broadcast, тож не підпадають під вплив)

Tor може встановити вихідне підключення

· Можна напряму встановити вихідне IPv4 або IPv6-з’єднання (без обмеження -onlynet і без налаштування -proxy=...)

· BIP324 v2-передача не вимкнена (не встановлено -v2transport=0)

Підключення до onion- та I2P-пірингових вузлів не зазнають впливу, оскільки під час будь-яких повторних спроб у рамках v1 ці підключення завжди здійснюються через відповідні проксі-маршрути.

Технічний механізм вразливості: після збою v2 повтор у режимі v1 не проходить через Tor

Згідно з офіційними поясненнями, механізм тригера вразливості такий: коли для private broadcast обирається підтримуваний v2 (BIP324) протокол передачі до IPv4 або IPv6-пірингового вузла, початкове з’єднання, як і очікується, проходить через Tor-проксі-маршрут. Якщо v2-handshake не вдається, Bitcoin Core намагатиметься повторити з’єднання за протоколом v1; при цьому повтор у режимі v1 не проходить через Tor-проксі-маршрут, а встановлюється напряму через IPv4 або IPv6-з’єднання, через що розкривається IP-адреса ініціатора.

Ця поведінка порушує конфіденційні гарантії, описані для версії 31.0: «Отримувачі ніколи не дізнаються їхню IP-адресу (а також геолокацію)». Команда розробників підтвердила, що вразливість найімовірніше штучно спричиняють, коли зловмисний піринговий вузол навмисно вимикає v2-handshake, щоб примусово викликати повтор у режимі v1.

Три тимчасові рішення: до релізу 31.1 можна застосувати одне з них

Офіційно Bitcoin Core пропонує такі три тимчасові рішення:

Рішення перше (рекомендоване): напряму вимкнути налаштування -privatebroadcast, встановивши -privatebroadcast=0

Рішення друге: вимкнути v2-передачу, встановивши -v2transport=0. Увага: це налаштування призведе до того, що всі підключення вузла використовуватимуть незашифрований протокол v1, що на відкритій мережі (в «clear net») робить вузол більш уразливим до відбитків (fingerprinting) і цензури.

Рішення третє: спрямувати вихідний трафік IPv4/IPv6 через Tor, налаштувавши -proxy=127.0.0.1:9050 (замініть порт на фактичний порт SOCKS Tor). Увага: це налаштування робить вузол більш вразливим до атак «молитвника» (Sybil Attack).

Поширені запитання

Чи постраждають вузли, які використовують гаманцеві RPC на кшталт sendtoaddress або sendall?

Згідно з офіційним оголошенням Bitcoin Core, гаманцеві RPC (наприклад, sendtoaddress, sendall тощо) не використовують private broadcast, тому цей вразливості не стосується. Вразливість спрацьовує лише під час трансляції через sendrawtransaction і лише за умови, що виконуються решта чотири умови.

Чи може ця вразливість виникнути природно без необхідності зловмисного вузла?

Згідно з офіційними поясненнями, для реальних пірингових вузлів, які підтримують v2-передачу, у звичайних умовах v2-handshake навряд чи зазнає збою. Найімовірніше вразливість штучно спричиняють, коли зловмисний піринговий вузол навмисно вимикає v2-handshake, щоб примусово викликати повтор у режимі v1.

Який графік релізу Bitcoin Core 31.1?

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