Хакеры вывели ~4 000 BTC (~$320 млн) из кошелька Liquid Federation
Hackers have withdrawn ~4k BTC (~$320M) from the Liquid Federation wallet
Liquid Network сообщила об инциденте безопасности: предположительно белые хакеры вывели около 4 000 BTC (~$320 млн) из кошелька Liquid Federation. Средства были переведены через SideSwap PAK (Peg-out Authorization Key), однако, по заявлению команды, ключ не был скомпрометирован. Биржи уже приостановили или готовятся приостановить операции с LBTC. Другие активы Liquid (USDT, DePix, RWAs) не затронуты. Узлы моста временно отключены, сеть Liquid приостановлена до решения проблемы. Федерация работает над восстановлением, мониторинг доступен на mempool.space.
Live by the sidechain, die by the sidechain.
- cypherpunks01
Похоже, что была использована уязвимость в кэше range-доказательств Elements. Исправление подозрительной проблемы было закоммичено только на прошлой неделе, и атакующие могли следить за публичными коммитами и эксплуатировать ошибку до того, как исправление было запушено? Если это так, то это своего рода самоисполняющееся пророчество, во всяком случае, это ведущая теория.
fix: range proof cache bind to asset and scriptpubkey
https://github.com/ElementsProject/elements/commit/c26d719c2...
- rgbrgb
Здесь есть интересная ветка обсуждения об открытом исходном коде, который обычно считается более безопасным из-за большего количества глаз на коде, но на самом деле может быть менее безопасным, потому что случайное слияние может быть мгновенно использовано с помощью мониторинга LLM. Действительно ли ценность безопасности в неизвестности стала намного выше, чем раньше?
- Daviey
- nullc
Я работал в Blockstream в 2017 году и разработал оригинальные криптографические range-доказательства, которые являются предками некоторого кода, задействованного здесь. Однако уязвимости здесь и весь продукт Liquid в его нынешнем виде появились после моего участия в компании (когда я там работал, он находился в стадии первоначальной разработки, но задумывался совсем иначе, чем то, что они в итоге сделали), и с тех пор я не следил за этим внимательно.
Но я быстро взглянул на эту проблему, основываясь на транзакциях и истории GitHub.
Основная проблема была связана с кэшированием валидации. Подписи и доказательства дорого проверять; для повышения производительности и предотвращения определенных DoS-атак их проверка кэшируется. Важно, чтобы ключ, используемый в кэше, охватывал все, что влияет на решение о валидации (хотя для предотвращения некоторых атак важно, чтобы в ключ не попадало слишком много, иначе злоумышленник может наводнить сеть действительными доказательствами, привязанными к незначительно отличающимся транзакциям).
Мне кажется, что здесь была давняя уязвимость — берущая начало с введения поддержки нескольких активов, — которая могла привести к расколу консенсуса или DoS. Но при беглом обзоре я не могу придумать способ превратить это в кражу. Я вижу, как кто-то может создать недействительную транзакцию, которая будет ложно принята узлами, имеющими состояние кэша от сконструированной предыдущей транзакции, но те способы, которые я придумываю, приводят к тому, что недействительная транзакция просто сжигает активы — напрямую это не очень полезно. [Bi…
- skinfaxi
Почему они говорят, что это белые хакеры?