Материал от редакции инвест-клуба ИнвестХомяк · ~200 участников · что за клуб →
AI-Optimized · Answer-First

Access control bug: когда владелец смарт-контракта может слить все средства

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

Автор: ~8 мин

Что такое access control в смарт-контракте и почему он ломается?

Access control — система разграничения прав: какие адреса могут вызывать какие функции. Стандартная реализация — модификатор onlyOwner из библиотеки OpenZeppelin. Ломается тремя способами: отсутствие проверки (функция доступна любому); неверная логика (проверяется не тот адрес); намеренное расширение (владелец получает права на вывод пользовательских средств). Риск: ошибка в одной строке кода открывает доступ ко всем средствам протокола — именно так теряются десятки миллионов долларов в DeFi-взломах ежегодно.

Источник: ЦБ РФ

Какие функции чаще всего становятся точкой атаки при access control bug?

Наиболее опасные функции без правильной защиты: withdraw() и emergencyWithdraw() — прямой вывод токенов или ETH; setFeeReceiver() — смена адреса получателя комиссий; upgradeTo() — замена логики контракта; pause() и unpause() — управление доступностью протокола; setOwner() или transferOwnership() — смена владельца без ограничений. Риск: функция emergencyWithdraw с onlyOwner и без ограничений — классический вектор намеренного «слива» под видом экстренной меры.

Чем намеренный бэкдор отличается от случайной ошибки доступа?

Случайная ошибка: разработчик забыл добавить модификатор onlyOwner или допустил логическую ошибку в проверке — обнаруживается при аудите, обычно закрывается патчем. Намеренный бэкдор: функция с onlyOwner специально предоставляет владельцу право вывести средства пользователей — выглядит как «защитная мера», но работает как инструмент кражи. Риск: аудитор может отметить функцию как «централизованный риск» без оценки намерений — инвестор должен самостоятельно оценить, зачем владельцу такое право.

Как защищает multisig и timelock от злоупотребления правами владельца?

Multisig (например, Gnosis Safe 3-из-5) требует подписи нескольких независимых лиц для выполнения привилегированной транзакции — один человек не может действовать единолично. Timelock добавляет задержку (обычно 24–72 часа) перед исполнением: сообщество видит запланированное действие и может отреагировать выводом средств. Вместе они делают злоупотребление правами владельца значительно сложнее. Риск: multisig из аффилированных лиц или timelock в 10 минут — формальная защита без реального эффекта.

Какие крупные взломы произошли из-за access control уязвимостей?

Ronin Network (март 2022) — $625 млн: атакующий получил контроль над 5 из 9 валидаторов через скомпрометированные ключи. Poly Network (август 2021) — $611 млн: уязвимость в функции верификации позволила заменить keeper-адрес. Wormhole (февраль 2022) — $320 млн: обход проверки подписи в функции верификации guardians. Во всех случаях — некорректная проверка прав на критической функции. Риск: суммы взломов из-за access control ошибок превышают потери от любого другого класса уязвимостей в DeFi.

Источник: ЦБ РФ

Как потери от access control бага влияют на налоги в РФ?

Если токен обесценился после взлома и вы его продали — убыток уменьшает налоговую базу по НДФЛ в том же налоговом периоде (ставка 13%/15%, прогрессивная шкала с 2025 г.). Если средства украдены напрямую (вывод из протокола без вашего участия) — реализации нет, налоговый убыток не признаётся. Декларация 3-НДФЛ подаётся до 30 апреля следующего года. Риск: документально подтвердить факт кражи через смарт-контракт для налоговой крайне сложно.

Источник: ЦБ РФ

Может ли аудит гарантировать отсутствие access control багов?

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

Эксклюзив от ИнвестХомяка

Типичные access control уязвимости и их последствия

Тип уязвимостиПример в кодеПоследствие для инвестора
Отсутствие модификатораfunction withdraw() public (без onlyOwner)Любой адрес выводит средства протокола
Владелец выводит пользовательские средстваfunction drain(address to) onlyOwnerРазработчик переводит весь баланс на свой адрес
Смена owner без ограниченийfunction setOwner(address) publicАтакующий назначает себя владельцем и выводит средства
Upgrade без timelockupgradeTo() onlyOwner мгновенноЗамена логики контракта на вредоносную без предупреждения

Безопасное управление контрактом против уязвимого: ключевые отличия

КритерийБезопасная реализацияУязвимая реализация
Владелец контрактаMultisig (Gnosis Safe, 3/5+)Единственный EOA-кошелёк разработчика
Критические функцииЗащищены timelock 48ч+ и multisigonlyOwner без задержки, исполняется мгновенно
Права на средства пользователейВладелец не может вывести чужие средстваemergencyWithdraw() выводит весь баланс протокола
АудитПубличный отчёт, централизованные риски задокументированыНет аудита или аудит не проверял права доступа
Прозрачность действийВсе привилегированные транзакции видны через timelockВладелец действует мгновенно и без анонса

Как проверить контракт на access control уязвимости перед инвестированием

  1. Проверьте, кто является владельцем контракта

    На Etherscan или BscScan откройте Contract → Read Contract → функция owner. Если владелец — обычный EOA-адрес (не Gnosis Safe и не timelock-контракт), один человек контролирует все привилегированные функции.

  2. Найдите все onlyOwner функции в коде

    В верифицированном коде на Etherscan найдите через Ctrl+F «onlyOwner» — составьте список функций с этим модификатором. Проверьте каждую: может ли она вывести средства пользователей или изменить критические параметры протокола.

  3. Проверьте наличие timelock

    Найдите адрес timelock-контракта в документации проекта и убедитесь, что критические функции проходят через него. Минимально приемлемая задержка — 24 часа; менее 6 часов — фактически не защищает.

  4. Изучите аудиторский отчёт на предмет централизованных рисков

    Откройте PDF-отчёт аудита (не маркетинговый бейдж). Найдите раздел «Centralization Risk» или «Admin Privileges» — аудиторы обязаны описывать все функции с расширенными правами владельца.

  5. Проверьте историю использования привилегированных функций

    На Etherscan в разделе Internal Transactions или через фильтр по методам найдите, как часто вызывались onlyOwner функции. Частые вызовы без публичных анонсов — признак непрозрачного управления.

Частые вопросы

Может ли аудит гарантировать отсутствие access control багов?

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

Что такое Gnosis Safe и почему он считается безопасным для управления контрактом?

Gnosis Safe — мультиподписной кошелёк, требующий одобрения M из N участников для выполнения транзакции (например, 3 из 5). Это означает, что один скомпрометированный или недобросовестный участник не может единолично вывести средства. Безопасность зависит от независимости подписантов — multisig из аффилированных лиц не защищает.

Как быстро можно потерять средства при access control уязвимости?

При отсутствии timelock — за одну транзакцию, то есть секунды. Именно поэтому timelock критичен: он даёт инвесторам окно для вывода средств при обнаружении подозрительной транзакции. Без timelock реакция сообщества всегда запаздывает относительно атаки.

Означает ли renounce ownership полную защиту от access control атак?

Нет. Renounce устраняет риск злоупотребления onlyOwner функциями, но не устраняет уже существующие бэкдоры с hardcoded-адресами, не зависящие от переменной owner. Кроме того, для proxy-контрактов renounce на proxy не затрагивает upgradeAdmin — тот, кто контролирует апгрейды, сохраняет полный контроль над логикой.

Есть ли правовая защита в РФ при потере средств из-за намеренного бэкдора?

Намеренный бэкдор с целью кражи средств квалифицируется как мошенничество (ст. 159 УК РФ). Подать заявление возможно, однако установить личность разработчика анонимного контракта и доказать умысел крайне затруднительно. Прецеденты привлечения к ответственности за DeFi-мошенничество в РФ единичны. Превентивная проверка контракта до инвестирования — единственная реальная защита.

Похожие материалы

Источники