Аудит микснета Nym и контракта на вестинг
Аудит безопасности микснета и контрактов вестинга Nym
Введение
В декабре 2022 года Nym прошел независимый аудит безопасности, проведенный Oak Security — немецкой консалтинговой фирмой по кибербезопасности, специализирующейся на аудите блокчейнов третьего поколения и децентрализованных протоколов. С обширным опытом работы в экосистемах, таких как Cosmos, Terra, Polkadot и Flow, компания Oak Security получила задание оценить два критических компонента экосистемы Nym: (1) микснет Nym и вестинг-контракты (см. полный отчет) и (2) кошелек Nym (см. полный отчет). Аудит был направлен на оценку надежности этих компонентов, выявление потенциальных уязвимостей и обеспечение соблюдения лучших практик разработки кода. Чтобы облегчить понимание, мы разбили результаты по каждому компоненту. Вы можете ознакомиться с резюме аудита Nym Wallet здесь.
Резюме аудита микснета Nym и вестинг-контрактов компанией Oak Security
Аудит длился 2 недели и проводился командой из 4 экспертов. Команда Nym предоставила Oak Security полный доступ к исходному коду проекта, подробным спецификациям и сопроводительной документации. В рамках аудита были проверены репозитории contracts/mixnet и contracts/vesting, а также соответствующие импорты, используемые в микснете и вестинг-контрактах Nym.
Oak Security провела тщательный обзор кода, сочетая автоматический анализ исходного кода и зависимостей с ручной посрочной проверкой, чтобы выявить уязвимости, оценить качество кода и проверить соответствие принципам безопасного программирования. Такой комплексный подход включал детальный анализ критически важных аспектов: уязвимостей состояния гонки, проблем с переполнением и недополнением, практик управления ключами, криптографической устойчивости, рисков утечки данных, обработки паролей, а также контроля доступа и авторизации.
Основное внимание аудита было направлено на обеспечение корректной работы протоколов, выявление возможных эксплуатационных уязвимостей или ошибок в смарт-контрактах, а также рекомендации по улучшению безопасности и читаемости кода.
Обзор результатов
Микснет и вестинг-контракты Nym отличались высокой читаемостью и понятностью, а также надёжным покрытием тестами, что обеспечивает их стабильность. В ходе оценки аудиторы выявили 19 замечаний, включая 9 уязвимостей в области безопасности — среди них критические и серьёзные по степени важности — а также 10 общих недостатков, отнесённых к категории незначительных или информационных.
Команда Nym оперативно устранила все критические и серьёзные проблемы. Команда Oak Security проверила и одобрила внесённые исправления.
NYM-MIX-VEST-CONTRACT-1: Сбой выполнения события эпохи или интервала навсегда блокирует продвижение эпохи (Критическая)
В ходе аудита была выявлена уязвимость в обработке сообщений AdvanceCurrentEpoch в файле contracts/mixnet/src/interval/transactions.rs. Последовательный цикл обрабатывает все ожидающие события непосредственно в контексте транзакции, что означает — если одно из событий завершится неудачей, вся транзакция откатывается, что эффективно останавливает продвижение эпохи и интервала, вызывая зависание протокола.
Для решения этой проблемы аудиторы рекомендовали оборачивать выполнение событий в подсообщения с политикой ответов. Такой подход позволил бы системе корректно обрабатывать ошибки без отката всей транзакции. Однако мы сознательно решили не следовать этой рекомендации. Сбой при выполнении события указывает на серьёзную логическую ошибку, которая может повлиять на механизм вознаграждений, поэтому предпочтительнее приостанавливать продвижение эпохи для ручной проверки, чем рисковать работой в повреждённом состоянии. Вместо этого мы реализовали усиленный мониторинг в API Nym для обнаружения и оповещения о сбоях в продвижении эпох. Такой подход гарантирует своевременное выявление проблем и оперативное вмешательство для их устранения.
NYM-MIX-VEST-CONTRACT-2: Злоумышленники могут заставить изолированные миксноды присоединяться к семье без их согласия, объединяя большое количество нод на одном уровне (Критическая)
Была выявлена уязвимость в сообщении JoinFamilyOnBehalf, которая позволяла злоумышленнику добавить миксноду в семью без его согласия. Создавая вредоносную семью и используя ключ идентичности жертвы, подписанный её приватным ключом, злоумышленник мог принудительно включить миксноду в эту семью. Это могло позволить злоумышленнику сгруппировать изолированные миксноды в одну семью, нарушая работу сети за счёт концентрации ноды на одном уровне и увеличивая шансы влиять на маршрутизацию.
Для устранения уязвимости в сообщении JoinFamilyOnBehalf механизм подписей в контракте был переработан. Вместо простой подписи идентичности миксноды, подписи теперь включают сообщение с чётко определённым намерением и уникальным числом (nonce). Это изменение гарантирует, что подписи не могут быть повторно использованы или воспроизведены.
NYM-MIX-VEST-CONTRACT-3: Неограниченная итерация при обработке сообщения TrackUndelegation может лишить пользователя возможности отказаться от делегирования, что также навсегда блокирует продвижение эпохи (Критическая)
Неограниченная итерация при обработке сообщения TrackUndelegation могла привести к исчерпанию газа при работе с аккаунтами, имеющими большое количество делегирований, что мешало пользователям отказаться от делегирования. Такая ошибка также блокировала продвижение эпохи, из-за чего протокол застывал в текущем состоянии.
Для решения проблемы был введён лимит в 25 вестинг-делегирований на аккаунт. Это ограничение основано на максимально зафиксированном количестве делегирований на момент внедрения.
Обновление: с 2024 года возможность создавать вестинг-делегирования полностью отключена.
NYM-MIX-VEST-CONTRACT-4: Злоумышленник может провести атаку с упреждением (фронт-раннинг) сообщений BondMixnodeOnBehalf и CreateFamilyOnBehalf и изменить их содержимое (Критическая)
Эта уязвимость позволяла злоумышленнику провести атаку с упреждением (фронт-раннинг) сообщений BondMixnodeOnBehalf и CreateFamilyOnBehalf, извлечь подпись и изменить содержимое сообщения. В случае BondMixnodeOnBehalf атакующий мог также назначить себя прокси и получить полный контроль над зарегистрированным бондом.
Для устранения уязвимости была применена двухэтапная мера. Во-первых, реализованы изменения в создании подписей, описанные в NYM-MIX-VEST-CONTRACT-2, которые добавляют чётко определённое намерение и уникальное число (nonce). Во-вторых, адрес легального прокси был ограничен только вестинг-аккаунтом, что предотвращает возможность злоумышленникам назначать себя прокси и получать несанкционированный контроль над бондами.
Обновление: с 2024 года все операции с прокси отключены, что делает атаку невозможной.
NYM-MIX-VEST-CONTRACT-5: Подписи могут быть повторно использованы в транзакциях «от имени» для подделки личности пользователей (Критическая)
Эта уязвимость позволяет повторно использовать подписи в транзакциях «от имени», что даёт злоумышленникам возможность выдавать себя за пользователей. Поскольку подписи содержат только необработанные данные без дополнительных метаданных, таких как nonce или идентификаторы сообщений, злоумышленник может повторно применить подпись из одного сообщения для другого, например, чтобы принудительно исключить членов семьи. Кроме того, злоумышленники могут повторно использовать подписи для одного и того же типа сообщения, позволяя участнику многократно вступать в семью, используя одну и ту же подпись.
Решение этой проблемы аналогично тому, что было реализовано в NYM-MIX-VEST-CONTRACT-4.
NYM-MIX-VEST-CONTRACT-6: Генерация ключей для пар (владелец, прокси) могла приводить к коллизиям (Критическая)
Эта уязвимость позволяла двум разным парам адресов (владелец, прокси) генерировать одинаковый результат XOR в функции generate_owner_storage_subkey, что могло привести к коллизиям ключей и перезаписи данных.
Решение, заключающееся в ограничении легального прокси только адресом вестинг-контракта, применённое в NYM-MIX-VEST-CONTRACT-4, также устраняет эту уязвимость. Благодаря тому, что операция XOR теперь всегда выполняется с постоянной строкой, риск коллизий эффективно исключён.
NYM-MIX-VEST-CONTRACT-7: функция track_delegation может перезаписать существующее делегирование, если несколько делегирований обрабатываются в одном и том же блоке (Критическая)
Эта проблема могла приводить к коллизиям ключей, если несколько делегирований происходили в одном блоке, из-за чего функция save_delegation могла перезаписать существующее делегирование, что приводило к потере предыдущего значения.
Для устранения проблемы была изменена логика функции save_delegation: теперь перед сохранением нового делегирования сначала считывается текущее значение для данного ключа. Если делегирование уже существует, мы получаем текущее количество, прибавляем новое и сохраняем обновлённую сумму, что предотвращает перезапись существующего делегирования.
NYM-MIX-VEST-CONTRACT-8: Владелец бонда не может выполнять операции, если бонд создан «от имени» через прокси (Серьёзная)
Эта проблема могла бы помешать владельцу бонда выполнять операции с ним, если бонд был создан «от имени» через прокси, а текущая транзакция инициируется владельцем, а не прокси. Поскольку прокси может быть скомпрометирован или утерян, а у владельца нет способа его сменить, это могло привести к потере контроля над бондом.
Однако мы не считаем это проблемой, так как это намеренное поведение по дизайну. Когда микснода привязывается (или делегирования осуществляются) через вестинг-контракт, все последующие взаимодействия с бондом или делегированием предполагается выполнять только через этот контракт.
Обновление: с 2024 года вестинг-контракт удалён.
NYM-MIX-VEST-CONTRACT-9: Выполнение сообщений LeaveFamily и LeaveFamilyOnBehalf может завершиться неудачей при большом количестве микснод в семье (Серьёзная)
Эта проблема приводила к сбоям при выполнении сообщений LeaveFamily и LeaveFamilyOnBehalf из-за исчерпания газа при переборе большого количества участников семьи в карте MEMBERS. Это мешало микснодам покинуть семью, фактически «запирая» их в текущей группе.
Решение: проблема была устранена путём переработки логики, предусматривающей прямой доступ к карте MEMBERS и проверку членства миксноды. Это исключило необходимость итерации, которая могла приводить к ошибкам из-за нехватки газа, и обеспечило возможность успешного выхода из семьи даже при большом числе участников.
Обновление: с 2024 года семьи нод удалены.
Заключение
Мы хотели бы поблагодарить команду Oak Security за их профессионализм и преданность на протяжении всего процесса аудита. Мы также ценим сотрудничество и профессионализм, проявленные как на этапе планирования, так и на этапе выполнения аудита. Наше постоянное обязательство перед безопасностью остается нашим главным приоритетом, и мы надеемся на дальнейшее сотрудничество с экспертами в области безопасности для поддержания самых высоких стандартов для нашей экосистемы.