Краткое содержание

1. Компания ChainSecurity сообщила об обнаруженной уязвимости в реализации ECDSA в кошельке Vultisig, которая позволяла злоумышленнику, скомпрометировав одного участника, отправлять множество вредоносных сообщений для подписи.
2. Изменения, внесенные в августовских версиях для Android и iOS, предотвращают повторные попытки злоумышленника, но не обеспечивают полного устранения уязвимости.
3. Внесенные изменения не гарантируют защиту при перезапуске сеансов.

Vultisig, криптокошелек, использующий механизм совместной подписи, некорректно обрабатывал критический сигнал остановки в своей реализации ECDSA, как обнаружили исследователи в области безопасности из компании ChainSecurity.

В отчете исследователей от 21 октября описывается, как продолжение работы после возникновения ошибки могло позволить злоумышленнику, уже скомпрометировавшему одного участника, восстановить полный приватный ключ.

Разработчики версий для Android и iOS описали код, который повторяет попытки после того, как библиотека обнаруживает вредоносного участника, а затем добавили обработку, чтобы остановить эти повторные попытки и предупредить пользователя. Эти изменения отражены в последующих версиях, опубликованных в репозитории.

Использование нескольких устройств обеспечивает защиту только в том случае, если программное обеспечение сохраняет это требование, когда один из участников начинает действовать ненадлежащим образом.

Многосторонний вычислительный кошелек (MPC-кошелек) распределяет полномочия по подписи между долями ключа. Достаточное количество долей взаимодействует для создания стандартной подписи для блокчейна без сборки полного приватного ключа в процессе нормальной работы.

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

Обнаруженная уязвимость связана с подписью ECDSA и требует первоначальной компрометации. Затем злоумышленник может отправлять множество вредоносных сообщений для подписи и наблюдать, возвращает ли другой участник ошибку.

Эти ответы раскрывают части многократно используемого внутреннего протокола, что в конечном итоге позволяет восстановить другую долю и полный ключ, как утверждают в ChainSecurity.

Этот протокол является внутренним секретом, и библиотека предполагала, что дальнейшая подпись будет остановлена после критической ошибки, пока протокол не будет обновлен. Приложение отображало общее сообщение об ошибке и не обеспечивало соблюдение этого требования.

В исторической реализации ECDSA в Vultisig данные ключа могли утекать через повторные ответы об ошибках; августовские обновления теперь предотвращают повторные попытки и идентифицируют скомпрометированное устройство.

Последствия для безопасности заключаются в том, что неудачная попытка подписания может иметь значение, даже если она не приводит к созданию рабочей подписи транзакции.

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

Что демонстрируют изменения, внесенные в августе

Изменения для Android( #5658) и изменения для iOS( #5235) были объединены 21 августа, за два месяца до публичного раскрытия информации.

В их описаниях говорится, что в старом коде неудачные попытки подписания сравнивались с успешным результатом работы библиотеки, без отдельной обработки ошибок, связанных с блокировкой злоумышленника. Процедуры подписания могли повторяться до трех раз, в то время как пользователю отображалось общее сообщение об ошибке.

Это количество повторных попыток не определяет, сколько сообщений потребуется для восстановления ключа или сколько сессий потребуется злоумышленнику.

Изменения в коде для Android и изменения для iOS учитывают коды ошибок, связанные со злоумышленником (100–109), в библиотеке DKLS при настройке сеанса, обработке сообщений и завершении подписи.

В обоих случаях участник, вызывающий подозрение, сопоставляется с идентификатором устройства, ошибка передается после автоматических повторных попыток, и отображается локализованное предупреждение о том, что не следует повторно использовать это устройство. В Android это исключение также обходит процедуру восстановления связи.

Вместе эти изменения показывают, что приложения различают криптографический вердикт об участнике и обычную ошибку подписи.

Поведение при повторных попытках, уместное для временного сбоя, может стать опасным, когда библиотека сообщает вызывающей стороне о необходимости прекратить взаимодействие со злоумышленником.

В примечаниях GitHub для iOS v1.45.71, датированных 21 августа, указан номер #5235. В релизе Android v1.0.118, датированном 25 августа, указан номер #5658.

Количество кошельков и объем аудита требуют контекста

В описаниях хранилищ Vultisig указывается, кто контролирует подписантов. Fast Vault использует одно устройство пользователя, а VultiServer хранит вторую часть и участвует в совместной подписи. Secure Vault использует два или более устройства, принадлежащих пользователю, без использования VultiServer.

Кошелек с поддержкой провайдера и кошелек, распределенный по устройствам пользователя, могут использовать распределенную подпись, но их операционные зависимости различаются. Наличие двух участников в обмене данными для подписи также не обязательно означает, что в хранилище всего две части.

В предоставленных для анализа документах и материалах приложения не представлена полная матрица затронутых версий и конфигураций хранилищ.

В документации по безопасности Vultisig указано, что компания Trail of Bits провела аудит библиотеки DKLS23, разработанной Silence Laboratories, в 2024 году. Также сообщается, что отчеты об аудите мобильных и настольных приложений будут опубликованы вместе с самими отчетами.

При раскрытии информации компания ChainSecurity заявила, что не проверяла исправления, внесенные Vultisig, и не проводила аудит других частей протокола, поэтому эти исправления не были включены в данную оценку.

Полезная информация о способах устранения уязвимостей должна связывать затронутые конфигурации с выпущенными версиями и объяснять, как обеспечивается защита после автоматических и инициированных пользователем перезапусков. Анализ, охватывающий эти аспекты, позволит решить проблему, связанную с ошибкой на уровне приложения, описанной здесь.

Владельцам защиты гарантируется, что обеспечение безопасности зависит от того, будет ли приложение обеспечивать соблюдение условия остановки библиотеки на протяжении всего процесса подписания, в том числе после перезапуска пользователем в случае сбоя.

Контекст статьи.