Спецификация Lightning BOLT11 требует ровно одного хеша платежа в инвойсе

19 октября в репозиторий спецификаций Lightning Network влили поправку к BOLT11: платёжный запрос должен содержать ровно один хеш платежа и ровно один секрет платежа. Если поле отсутствует или повторяется, инвойс отклоняется. BOLT11 — формат платёжного запроса в Lightning; хеш платежа (поле p) говорит программе, какой платёж отслеживать, секрет платежа лежит в поле s. Такое же требование распространили и на поле s, хотя в описанной атаке подменяли только хеши.

Что именно показал взлом бота

О проблеме рассказал разработчик Roasbeef. 10 сентября в обсуждении поправки он сообщил о недавнем взломе P2P-бота в Telegram. Атака опиралась на разное чтение одного и того же инвойса библиотеками: при нескольких хешах в счёте одни берут первый, другие последний. Ни даты инцидента, ни суммы ущерба Roasbeef не назвал.

Схема простая. Сервис ведёт вывод под одним хешем, его нода проводит платёж по другому. Средства уходят, бухгалтерия сервиса их не видит и считает вывод неоплаченным — и атакующий получает ещё одну выплату. Сам Lightning при этом не взломан: сбой возникает на стыке ноды, исполняющей платёж, и учётной системы сервиса.

Повторы считают, а не схлопывают

Парсерам инвойсов придётся считать число вхождений поля, а не сводить одинаковые значения к одному. В тестовых примерах к предложению два недопустимых счёта: с двумя разными хешами и с одним и тем же хешем, записанным дважды. Решение «если значения совпадают, это одно поле» пропустит инвойс, который по новому правилу нужно отклонить.

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

Где правило пока выполнено наполовину

В вышедших версиях lnd, одной из основных реализаций Lightning-ноды, счета с повторяющимся хешем уже отклоняются. С секретом платежа иначе: внести такую же проверку предложили, но на 27 октября правка ещё не принята. Для описанной атаки ключевое поле — хеш, и эта часть закрыта, полного соответствия стандарту у lnd пока нет. Данных о других реализациях в источнике нет.

Кого это касается

Уязвимость бьёт не по тем, кто платит с обычного кошелька, а по сервисам с автоматическими выводами: P2P-ботам, биржам, обменникам, игровым площадкам на Lightning. Операторам нужно проверить две вещи: сервис отклоняет неоднозначные инвойсы с пропущенными или повторяющимися полями, а учёт вывода привязан к тому же хешу, по которому платит нода. Вторая проверка не менее важна: даже с корректным парсером ошибка в бухгалтерии снова разведёт платёж и его учёт.

Остаётся открытым, примут ли в lnd проверку секрета платежа и как быстро обновятся другие реализации. Неизвестен и масштаб потерь: ни пострадавший бот, ни Roasbeef сумму ущерба не раскрыли.