Безопасность нод и Lightning-инфраструктуры

Обновите или выключите ваш BTCPay Server. Формулировка из официального предупреждения жёсткая не просто так: критическая уязвимость эксплуатируется прямо сейчас и приводит к потере средств, апдейт до 2.4.2 обязателен. Механика простая и от этого неприятная. Неаутентифицированный атакующий мог получить .macaroon файлы LND — то есть полный контроль над Lightning-нодой. Среди пострадавших Foundation, производитель кошельков, и Citadel21: каналы принудительно закрыты, средства выведены. Теперь то, ради чего я вообще сел это писать. За девять дней это второй эксплойт в широко развёрнутой биткоин-инфраструктуре: сначала баг энтропии в Coldcard, теперь macaroon в BTCPay. Соблазн обсуждать каждый случай отдельно как чью-то конкретную ошибку велик, но пара таких событий подряд — это уже не пара невезений, это паттерн, который стоит назвать вслух. Общий корень у них один. И там, и там речь о критичном для безопасности участке кода в опенсорсе, который развёрнут очень широко и который никто не аудировал с той тщательностью, какую оправдывает объём активов под управлением. В Coldcard это была генерация случайности. В BTCPay — контроль доступа к ключам ноды. Разные слои, одна и та же дыра в процессе. Стек самостоятельного хранения вырос быстрее, чем культура его ревью. Мы получили удобные инструменты для того, чтобы обычный человек держал ключи и запускал собственный узел, — и не получили пропорционального роста числа людей, которые эти инструменты читают построчно. Я не знаю, сколько ещё таких участков сейчас лежит в продакшене и ждёт своего исследователя. И это, пожалуй, самая честная формулировка проблемы, какая у меня есть.