XRP Ledger уязвимость, по оценке исследователей, могла позволить атакующему выпускать и тратить новые XRP без реального финансирования со стороны отправителя, ставя под удар принцип фиксированной эмиссии в 100 миллиардов токенов. Главное Уязвимость, которая предположительно присутствовала в коде с 2015 года, могла нарушить базовое правило XRP Ledger: после запуска реестра нельзя создать больше 100 миллиардов XRP. […]
XRP Ledger уязвимость, по оценке исследователей, могла позволить атакующему выпускать и тратить новые XRP без реального финансирования со стороны отправителя, ставя под удар принцип фиксированной эмиссии в 100 миллиардов токенов.
Уязвимость описана в отчете по безопасности, опубликованном в пятницу. Баг выявили исследователь Кейден Ляо и компания Veria AI, после чего 22 сентября о находке сообщили внутри проекта.
Инженеры RippleX, разработческого подразделения Ripple, проверили сценарий атаки на отдельном сервере. Тест подтвердил: созданные таким способом XRP могли использоваться в последующих транзакциях, то есть речь шла не о визуальной ошибке баланса, а о расходуемых токенах.
RippleX при этом подчеркнула, что не обнаружила доказательств эксплуатации уязвимости в каких-либо публичных сетях.
Все 100 миллиардов XRP были выпущены при запуске реестра в 2012 году. Архитектура XRP Ledger предполагает, что дополнительные токены не могут быть добавлены позднее. Именно на это ограничение предложения опираются участники рынка и институты, работающие с сетью.
Обнаруженный дефект мог подорвать этот принцип. В теории злоумышленник получил бы возможность создать XRP из ничего, а затем продать их на биржах, фактически увеличив предложение сверх установленного лимита.
Атака была построена вокруг встроенного в XRP Ledger механизма обмена, где аккаунты размещают предложения на покупку и продажу токенов.
По описанному исследователями сценарию злоумышленник мог создать сотни аккаунтов. Каждый из них выставлял бы предложение: отдать небольшое количество токенов в обмен на необычно большой объем XRP. Затем один платеж покупателя одновременно забирал бы все эти предложения.
Именно на этом этапе возникала критическая ошибка. Общая сумма обязательств в XRP становилась слишком большой для корректной обработки программным обеспечением. В результате аккаунты продавцов, контролируемые атакующим, получали бы полную выплату, а со счета покупателя списывалась бы почти нулевая сумма. Так у атакующего появлялись бы XRP, которых раньше не существовало.
Схема показывала, как один платеж мог привести к появлению новых XRP без соответствующего списания средств у отправителя.
XRP Ledger после каждой транзакции выполняет проверку, которая должна подтверждать, что новые XRP не появились. Однако в этом случае механизм опирался бы на уже ошибочно рассчитанную общую сумму, поэтому не выявлял бы нарушение.
Еще один предохранитель — ограничение на объем XRP, который может получить один аккаунт, — также не остановил бы атаку. Причина в том, что выплаты распределялись бы между сотнями аккаунтов, а не концентрировались на одном адресе.
Для запуска описанного метода исследователям требовалось лишь несколько сотен XRP на открытие аккаунтов. Большую часть этой суммы можно было бы восстановить, отдельно оставались бы только транзакционные комиссии.
Разработчики закрыли дефект в версии xrpld 3.4.1, выпущенной 25 сентября. На момент релиза подробности уязвимости не раскрывались.
Этот случай пополнил список долго остававшихся незамеченными проблем безопасности в криптосфере, которые с июля начали выявлять с помощью ИИ. Среди них назывались ошибка в кошельке Coldcard, приведшая к краже как минимум 1 367 BTC, а также уязвимости, из-за которых Core Lightning пришлось рекомендовать операторам Bitcoin-нод отключиться.
JOIN
