Перейти к содержанию

Риски владельца и восстановления смарт-аккаунта

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

Обновлено

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

Прямой ответ

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

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

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

Как это работает

  1. Определите аккаунт и код. Проверьте ID сети и адрес, затем реализацию, proxy или beacon, фабрику и версию. Для proxy ERC-1967 считайте слоты реализации, beacon и администратора, а не доверяйте значку интерфейса.
  2. Перечислите пути авторизации. Считайте владельцев и пороги, валидаторы ERC-4337, валидаторы, исполнители, hooks и fallback handlers ERC-7579, модули и guards типа Safe, сессионные ключи, контракты восстановления и администраторов аварийного доступа или обновления. Исполнитель или модуль Safe может действовать без обычного порога владельцев.
  3. Разберите автомат состояний восстановления. Установите, кто предлагает нового владельца, как учитываются и истекают одобрения, когда начинается задержка, кто отменяет и завершает процесс и что происходит при замене или повторе восстановления. Не все контракты «социального восстановления» используют одну последовательность.
  4. Проверьте независимость и доступность. Адреса не независимы, если ими управляет одно устройство, лицо, облачная учетная запись, хранилище паролей, кастодиан или администратор. Убедитесь, что после ожидаемого отказа порог достижим, но один домен не получает возможности захвата.
  5. Проверьте права настройки. Определите, кто добавляет или удаляет хранителя, валидатора, исполнителя, hook, модуль или fallback handler; меняет порог или задержку; приостанавливает отмену; обновляет код аккаунта и восстановления. Timelock полезен, только если другая роль не может обойти задержку и отмену.
  6. Отслеживайте и проверяйте. Подпишитесь или независимо опрашивайте изменения восстановления, владельца, модуля, порога, реализации и администратора. После операции декодируйте транзакцию и проверьте квитанции, события, хранилище и итоговых владельцев в правильной сети; сообщение об успехе недостаточно.

Практический пример

Допустим, у аккаунта есть владелец O и три хранителя G1, G2 и G3. Любые 2-of-3 хранителя могут предложить нового владельца N; затем начинается задержка 24-hour; O может отменить процесс во время задержки; после нее завершить может любой. Модуль вызывает смену владельца без одобрения O в финальной транзакции.

Названия предполагают распределенное восстановление, но G1 и G2 — приложения с резервной копией в одной облачной учетной записи. Компрометация этих данных дает одному атакующему фактический порог 2-of-3. Он предлагает N; если мониторинг или отмена не сработают в течение 24 hours, завершение передаст контроль, хотя закрытый ключ O не был украден.

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

Риски и меры контроля

  • Связанные хранители: используйте действительно независимые устройства, учетные данные, людей или кастодианов; тестируйте процедуры, не собирая seed-фразы вместе.
  • Чрезмерные права модуля или исполнителя: изучите установленный код и точный охват. Удаляйте ненужные модули документированным путем и проверяйте в сети.
  • Слабый порог: оцените устойчивость к захвату и доступность. Высокий номинальный порог не помогает при общем домене; недостижимый порог блокирует аккаунт.
  • Нет задержки или ее можно обойти: проверьте в сети задержку, запускающее событие, кто может сократить ее и каждый путь немедленной смены.
  • Неэффективная отмена: отрепетируйте обнаружение и отмену, держите нативный gas и независимый путь отправки, если нужно, и выясните, требуется ли старый владелец, кворум или другая роль.
  • Захват через обновление: следите за реализацией, beacon и администратором. Администратор без задержки способен изменить все документированные правила.
  • Вредоносный или устаревший интерфейс: независимо проверьте сеть, аккаунт, модуль, нового владельца, порог, задержку и calldata. Никогда не сообщайте seed-фразу или закрытый ключ сервису «восстановления».
  • Ложное завершение: после отмены или завершения проверьте квитанцию и итоговое хранилище. Убедитесь, что нужные владелец и модули активны, а нежелательное предложение не исполняется.

При несанкционированном восстановлении прекратите подписывать несвязанные запросы и сохраните ID предложения, hash, calldata, блок, адрес модуля и состояние. С безопасного устройства проверьте тревогу через независимый RPC, используйте документированный путь отмены, если он доступен, и следите за завершением, обновлениями, модулями и переводами. Если контроль уже мог быть потерян, следуйте заранее написанному плану и используйте только аутентифицированные контакты; импровизированный перевод могут опередить или он раскроет адрес назначения.

Распространенные заблуждения

  • «Только владелец может перемещать активы». Валидаторы, исполнители, модули, контракты восстановления или обновленный код могут давать другие пути.
  • «Три хранителя — это три независимые стороны». Контракт считает одобрения адресов; общие устройства, резервные копии и администраторов он не видит.
  • «Задержка 24-hour гарантирует время на реакцию». Нужны мониторинг, рабочая отмена, gas и включение транзакции; другой привилегированный путь может обойти задержку.
  • «Удаление хранителя прекращает его доступ». Подтвердите итоговую настройку и проверьте другие роли, модули, сессионные ключи и ожидающие восстановления этой стороны.
  • «Поддержка восстановит любой смарт-аккаунт». Только записанные или заранее настроенные в сети полномочия меняют некастодиальный аккаунт. Без владельца или пути восстановления доступ может быть утрачен навсегда.

Похожие темы

Источники

Навигация

Поиск по вики...