Введение
В сфере блокчейна все как будто одержимы поиском уязвимостей в коде смарт-контрактов. Команды разработчиков вкладывают деньги в аудиты, конкурсы по поиску багов, инструменты для фаззинга и формальные методы проверки, потому что верят, что, найдя все эти баги в коде, можно обеспечить безопасность.
Этот метод важен, но он не учитывает один из самых страшных фактов, который выяснился в 2024 году. Самый опасный способ атаки, который сейчас беспокоит протоколы криптовалют, — это не сложные цепочки эксплойтов или скрытые уязвимости кода. Это гораздо более серьезная и даже менее обсуждаемая угроза, которая доминировала в последние годы.
Компрометация закрытых ключей становится главной угрозой
Исследование 2024 года показывает тревожную статистику, которая заставит нас пересмотреть подход к безопасности блокчейна. Доля всех украденных криптовалютных средств за год, которые были скомпрометированы через приватный ключ, составляет 43,8%, что делает этот тип атак самым успешным.
Традиционные аудиторские фирмы, занимающиеся блокчейном, обычно не сообщают о слабых местах в архитектуре системы контроля доступа как о формальных выводах, а конкурентные аудиторские платформы явно не поощряют подачу отчетов, в которых основное внимание уделяется таким системным проблемам.
Такое мышление сильно отличается от лучших практик аудита безопасности в других отраслях, где повышение привилегий и дизайн контроля доступа — это ключевые вопросы, которые нужно рассматривать на ранних этапах разработки, когда часто уже поздно менять общий характер проблем контроля доступа в системе.
Чтобы понять, как решения по дизайну влияют на уязвимость перед атаками на приватные ключи, давайте посмотрим на следующий теоретический протокол кредитования с избыточным обеспечением. Но для выполнения нескольких важных операций нужен привилегированный доступ к таким системам:
- Включение и исключение поддерживаемых активов из списка
- Настройка параметров риска и процентных ставок
- Взимание платы за протокол
- Чрезвычайные паузы и обновления разработки смарт-контрактов
Это определяет общую устойчивость такого протокола к взлому частного ключа.
Уровень 1: Полное раскрытие информации с контролем одной точки
Самый низкий уровень — это когда у разработчика есть одна внешне контролируемая учетная запись с полными правами администратора на все функции протокола. Эта архитектура — самая уязвимая конфигурация, в которой взлом одного секретного ключа даст злоумышленникам мгновенный и полный доступ к системе, возможно, в виде программных кошельков, подключенных к Интернету.
Угроза предательства огромна, а последствия разрушительны и прямы.
Уровень 2: Простое управление рисками с помощью распределенных ключей
Следующий уровень зрелости — это передача административных полномочий в кошелек с несколькими подписями, который потребует залога от нескольких держателей ключей для выполнения обновления. Это может только уменьшить вероятность компрометации и не ограничивает степень, в которой протокол может быть поврежден, но все же является улучшением.
Это намного лучше, чем контроль с помощью одного ключа, с точки зрения безопасности, поскольку для перехвата протокола больше не требуется достаточный доступ с компрометацией одного ключа подписанта. Тем не менее, даже с учетом этих улучшений, риски остаются высокими:
- Быстрота выполнения очень важна, потому что злоумышленники могут начать действовать до того, как вы успеете что-то предпринять.
- Хотя точки отказа распределены между ключами, структура управления остается централизованной
- Даже хорошо защищенные системы с несколькими подписями могут быть взломаны с помощью сложных методов социальной инженерии
Уровень 3: Улучшенная защита за счет разделения по времени и ролям
Чтобы стать по-настоящему зрелым, нужно использовать два важных механизма контроля: временные ограничения и принцип минимальных привилегий.
Таймлоки создают задержку между одобрением и выполнением транзакции, что дает время для проверки транзакции и реагирования на инциденты. Принцип минимальных привилегий заключается в разделении ролей и обязанностей, чтобы каждая роль получала только минимальный набор разрешений, необходимых для выполнения конкретной роли.
Этот уровень решает основные проблемы более простых методов:
- Не разрешайте немедленное выполнение
- Делитесь управлением между несколькими специализациями
- Дает время командам безопасности, чтобы проверить неожиданные транзакции
- Позволяет действовать на упреждение, а не просто исправлять ситуацию
Уровень 4: Максимальный уровень безопасности
Самый высокий уровень зрелости основан на полном отказе от административных действий и является самой радикальной формой приверженности идее децентрализации и минимизации доверия. Такая стратегия категорически исключает контроль доступа как часть модели угроз протокола.
Чтобы справиться с этим уровнем, нужны совсем другие подходы, чем для всех остальных уровней:
- Возможность обновления контрактов нужно убрать - смарт-контракты становятся полностью неизменяемыми
- Список активов становится доступным без разрешения - автономные рынки развертываются независимо
- Параметры риска закреплены навсегда - никакое административное управление невозможно
- Экстренное вмешательство невозможно - системы не поддаются настройке после внедрения
Если речь идет о системах кредитования с избыточным обеспечением, нужно обратить внимание на несколько важных моментов:
- Новые функции, которые можно использовать в разных местах с ручной миграцией пользователей
- Рынки, которые созданы как отдельные протоколы для конкретных активов
- Параметры риска следуйте алгоритмическим рекомендациям или постоянным настройкам развертывания
Это в пять раз больше, чем у других известных видов атак, но система безопасности блокчейна в основном не готова к такой угрозе.
Защити свой протокол уже сегодня
Не ждите, пока будет компромисс. Внедрите правильный контроль доступа прямо сейчас.
Структура разделения ролей
| Тип роли | Обязанности | Требования к безопасности | Продолжительность блокировки |
|---|---|---|---|
| Основная система | Обновления контрактов | Высокие пороги мультиподписи | Длинные задержки |
| Операции | Настройка повседневного протокола | Умеренные требования к безопасности | Средние задержки |
| Пауза Guardian | Приостановка действия протокола в чрезвычайных ситуациях | Возможность немедленного действия | Без задержек |
| Отменить Guardian | Отменяйте злонамеренные одобрения | Право на быстрое реагирование | Без задержек |
Теперь команды безопасности могут активно вмешиваться в ситуации, а не просто реагировать на ущерб, когда он уже нанесен, но это приносит новые риски, такие как возможные ошибки в системах управления ролями.
Хотя этот подход к дизайну не имеет рисков с точки зрения контроля доступа, он имеет большие минусы, включая невозможность экстренного вмешательства и огромные затраты на предварительную проверку.
Создание устойчивых систем с самого начала
Уязвимость закрытых ключей, которая стала причиной почти половины всех краж криптовалюты в 2024 году, — это проблема, которую нельзя игнорировать из-за выбора архитектуры контроля доступа, сделанного в начале процесса проектирования. Хотя традиционная идентификация уязвимостей по-прежнему необходима, основополагающие проектные решения должны будут рассматриваться гораздо раньше в цикле разработки.
Вот что можно сделать в реальном мире, чтобы повысить безопасность:
- Честный анализ того, насколько протокол сейчас готов
- Внедрение контрактов с временным ограничением на административные функции
- Хорошие системы мониторинга для рискованных административных режимов
- Сопоставление привилегированных функций и разделение на логические роли
- Применяйте принципы минимальных привилегий
- Определите элементы дизайна, которые подходят для неизменяемых шаблонов
Разработчики могут создавать протоколы, которые будут одновременно инновационными и надежными, если будут понимать концепции зрелости и сознательно выбирать шаблоны проектирования, которые не зависят от доверия или позволяют распространять компромиссы.
Для этого нужно вложить средства в операционную устойчивость на первых этапах разработки, чтобы протоколы были защищены не только от технических вторжений, но и от человеческого фактора, который делает компрометацию закрытых ключей такой серьезной угрозой.
