Как атака на Telegram-бота превращала выплаты в «неоплаченные»
О проблеме рассказал разработчик Roasbeef. 10 сентября в обсуждении поправки он сообщил о недавнем взломе P2P-бота в Telegram. Атака использовала то, что библиотеки по-разному читают один и тот же инвойс: если хешей в счёте несколько, одни берут первый, а другие последний. Ни даты инцидента, ни суммы ущерба Roasbeef не назвал.
На практике это выглядит так. Сервис ведёт вывод под одним хешем, а его нода проводит платёж по другому. Деньги уже ушли, но учётная система сервиса их не видит и считает вывод неоплаченным. Так у атакующего появляется возможность получить ещё одну выплату. Сам Lightning при этом не взломан: сбой возникает на стыке между нодой, которая проводит платёж, и бухгалтерией сервиса.
Новое правило BOLT11: один хеш и один секрет платежа
BOLT11 описывает формат платёжного запроса в Lightning. Хеш платежа, поле `p`, указывает, какой платёж отслеживает программа. Секрет платежа хранится в поле `s`. По обновлённой спецификации каждое из этих полей должно встречаться в инвойсе ровно один раз. Если поля нет или оно повторяется, платёж должен завершиться ошибкой.
Заходите в наш Telegram-чат 2Bitcoins, если хотите обсудить новость с другими читателями.
Правило закрывает неоднозначность сразу в обоих полях, хотя в описанной атаке подменяли только хеши. Изменение влили в репозиторий спецификаций Lightning 19 октября, а 23 октября на него обратил внимание бюллетень Bitcoin Optech.
Повторы нужно считать, а не схлопывать
Программы, которые разбирают инвойсы, должны считать, сколько раз встречается поле. В тестовых примерах из предложения есть два вида недопустимых счетов: с двумя разными хешами и с одним и тем же хешем, записанным дважды.
Следите за новостями в нашем Telegram-канале 2Bitcoins.
Поэтому простое решение «если значения совпадают, считаем их одним» не подходит. Код, который склеивает одинаковые значения, пропустит инвойс, который по новому правилу нужно отклонить. Разработчикам кошельков и платёжных библиотек придётся проверять именно число вхождений поля.
Мужчина у двух мониторов с кодом вечером в офисе
Спецификация сама по себе ничего не защищает. Пока конкретная реализация не обновится, старый парсер может по-прежнему брать первое или последнее значение.
lnd уже отсекает дубли хешей, проверка секрета пока не принята
В уже вышедших версиях lnd, одной из основных реализаций Lightning-ноды, инвойсы с повторяющимся хешем отклоняются. С секретом платежа хуже: предложение добавить такую же проверку на 27 октября всё ещё не принято.
Значит, в lnd новое правило BOLT11 пока выполняется только наполовину. Для описанной атаки важнее хеш, и эта часть закрыта. Но полного соответствия стандарту ещё нет. О других реализациях в источнике данных нет.
Две проверки для бирж, ботов и платёжных сервисов
Уязвимость бьёт не по рядовым ходлерам, которые платят с кошелька, а по сервисам с автоматическими выводами: P2P-ботам, биржам, обменникам и казино на Lightning. Операторам рекомендуют проверить две вещи:
- сервис отклоняет неоднозначные инвойсы с пропущенными или повторяющимися полями;
- учёт выводов привязан к тому же хешу платежа, по которому платит нода.
Мужчина проверяет кабели в открытом серверном шкафу
Вторая проверка не менее важна, чем первая. Даже с корректным парсером ошибка в бухгалтерии сервиса может снова разделить платёж и его учёт.
Читайте также: Electrum экстренно обновляет криптовалютный кошелёк: хакеры нашли способ красть BTC без приватных ключей через подмену серверов
Дальше стоит следить, примут ли в lnd проверку секрета платежа и как быстро новое правило внедрят другие реализации Lightning. Отдельный вопрос, раскроют ли пострадавший бот или Roasbeef масштаб ущерба: пока сумма потерь неизвестна.
ПОДПИСЫВАЙТЕСЬ НА НАШ КАНАЛ В ТЕЛЕГРАМЕ, ЧТОБЫ БЫТЬ В КУРСЕ.
