Обзор проблем безопасности

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

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

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

1.1 Управление ключами

Многие пользователи не обладают навыками для безопасного управления криптографическими ключами.

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

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

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

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

1.2 Слепое подписание и неопределенность транзакций

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

1.3 Управление одобрениями и разрешениями

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

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

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

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

1.4 Скомпрометированные веб-интерфейсы

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

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

1.5 Приватность

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

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

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

1.6 Фрагментация

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

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

Безопасность смарт-контрактов радикально улучшилась за всю историю Эфириума. Ранние инциденты безопасности, такие как взлом The DAO, побудили экосистему к профессионализации и улучшению мер защиты на протяжении всего жизненного цикла программного обеспечения, что приводит к развертыванию кода ончейн. Ключевые достижения включают:

• Аудит безопасности стал стандартной практикой, и несколько фирм по безопасности вошли в экосистему и развили свою экспертизу.
• Инструменты, тестирование и системы статического анализа усовершенствовались и стали стандартной практикой.
• Библиотеки предварительно проверенных общих компонентов предоставили разработчикам безопасные по умолчанию строительные блоки.
• Были внедрены методы формальной верификации, особенно для мостов, систем стейкинга и контрактов с высокой стоимостью.
• Культура безопасности и передовые методы экосистемы улучшились.
• Создание значительных программ вознаграждения за обнаружение ошибок (bounty), которые укрепили уровень приложений.

Однако в этой области остаются слабые места и возможности для улучшения.

2.1 Уязвимости контрактов

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

• Риск обновления контракта. Некоторые контракты спроектированы так, чтобы их можно было изменять после развертывания, что позволяет команде разработчиков продолжать обновлять и улучшать приложение. Однако это влечет за собой риски. Обновления могут привести к новым уязвимостям или полной потере средств пользователей в случае вредоносного обновления.
• Повторный вход (Re-entrancy), когда контракт A вызывает внешний контракт B до обновления своего собственного внутреннего состояния, а контракт B вызывает обратно исходный контракт A до завершения первого вызова.
• Небезопасное использование внешних библиотек, когда контракт вызывает внешнюю библиотеку, которая может быть непроверенной, вредоносной или обновляемой.
• Непроверенные компоненты. Хотя аудит и использование стандартных библиотек улучшились, разработчики иногда полагаются на непроверенные компоненты в своих приложениях.
• Сбои контроля доступа, когда разрешения настроены неправильно или определены слишком широко, что позволяет злоумышленникам совершать вредоносные действия.
• Несанкционированный доступ, когда приватный ключ, способный управлять контрактом, попадает в руки злоумышленника.
• Мосты и кроссчейн-взаимодействия. Мосты и кроссчейн-протоколы вносят дополнительную сложность, и злоумышленники могут использовать слабые места в том, как передаются или проверяются кроссчейн-сообщения.
• Делегирование внешнего аккаунта (EOA) или неправомерное использование подписи. Вредоносные приложения могут обманом заставить пользователей подписать полное делегирование своего аккаунта другой стороне, что делает возможной кражу. Вредоносные приложения также могут использовать подписанные сообщения от пользователя неожиданными способами, например, в атаке повторного воспроизведения.
• Возникающий риск ошибок, вносимых генерацией кода с помощью ИИ или инструментами автоматизированного рефакторинга.

2.2 Опыт разработчиков, инструменты и языки программирования

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

• Отсутствие безопасных настроек по умолчанию в популярных фреймворках. Некоторые инструменты отдают приоритет гибкости или скорости в ущерб безопасности, устанавливая небезопасные настройки по умолчанию, такие как неограниченные одобрения токенов в функции approve(), или не включая шаблоны контроля доступа по умолчанию.
• Пользовательский код для расширенного операционного контроля. Институциональные пользователи со сложными операционными требованиями часто вынуждены создавать необходимые функции с нуля, что увеличивает риск уязвимостей. Существует нехватка стандартизированных безопасных компонентов или фреймворков для расширенных рабочих процессов безопасности.
• Непоследовательное покрытие тестированием в различных стеках инструментов, а также отсутствие норм использования проверенных методов, таких как фаззинг или проверка инвариантов.
• Низкий уровень внедрения методов формальной верификации. Методы формальной верификации эффективны, но они сложны, дороги, требуют специализированных знаний в предметной области и плохо интегрированы в стандартные рабочие процессы разработчиков, где их можно было бы использовать гораздо раньше при производстве программного обеспечения для проверки безопасности на этапе спецификации.
• Проблемы, связанные с верификацией контрактов. Пользователи и разработчики не могут легко оценить надежность развернутых контрактов, степень проверки их безопасности (например, аудит кода) или наличие скрытых рисков. Хотя решения для этой цели существуют, многие проблемы остаются. Инструменты, решающие эти проблемы, не получили широкого распространения, стандарты, которые могли бы унифицировать подходы, остаются фрагментированными, а некоторые из существующих сервисов сами по себе являются централизованными зависимостями.
• Риски компилятора. Компиляторы (программное обеспечение, которое преобразует удобочитаемый код, такой как Solidity, в байт-код, используемый самой EVM) могут иметь недостатки, которые вносят ошибки в смарт-контракты до того, как они будут развернуты. Сегодня экосистема Эфириума в основном зависит от компилятора solc, а это означает, что ошибка может иметь широкомасштабные последствия.
• Разнообразие и глубина языков программирования. Хотя Solidity имеет глубокую экосистему инструментов, созданную на его основе, некоторые разработчики хотят использовать более современные функции безопасности, которые есть в других языках программирования, такие как безопасность памяти.

2.3 Оценка рисков ончейн-кода

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

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

3.1 Цепи уровня 2 (l2)

Цепи уровня 2 (l2) служат расширениями для Эфириума, обеспечивая более быструю среду с более низкими комиссиями, сохраняя при этом некоторые характерные гарантии безопасности основной сети Ethereum (в зависимости от их конкретного дизайна). Однако они также имеют свои собственные отличительные поверхности атаки, включая:

• Сложность многошагового перемещения активов через мосты. Когда активы перемещаются между уровнем 1 (l1) и несколькими l2, они подвергаются воздействию нескольких наборов контрактов, каждый из которых должен быть безопасным. Несоответствие в учете или сбои в цепях l2 могут привести к уязвимостям, которые могут быть использованы злоумышленниками.
• Роллапы l2 полагаются на системы доказательств для обеспечения правильности обновлений состояния. Ошибки или неправильные конфигурации в этих системах могут остановить или предотвратить финальность, либо позволить финализировать ложные обновления состояния, что приведет к потере средств пользователей.
• Советы по безопасности — это группы держателей ключей, которые служат «резервным» механизмом для обновления программного обеспечения l2 или реагирования на определенные чрезвычайные ситуации. Сами советы по безопасности представляют риски, поскольку компрометация или сговор между участниками могут поставить под угрозу средства пользователей или заморозить активы.

Смотрите L2BEAT (opens in a new tab) для получения подробной структуры и панели мониторинга, которая оценивает и сравнивает производительность и безопасность l2.

3.2 Инфраструктура RPC и узлов

Приложения Эфириума зависят от небольшого числа поставщиков инфраструктуры для доступа к RPC, API и службам узлов. Сюда входят как специфичные для криптовалюты поставщики инфраструктуры, так и традиционные облачные сервисы, которые обычно используются для размещения узлов (например, AWS, Cloudflare, Hetzner).

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

3.3 Уязвимости на уровне DNS

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

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

3.4 Цепочка поставок программного обеспечения и библиотеки

Разработчики Эфириума полагаются на библиотеки с открытым исходным кодом, часто загружаемые напрямую из таких сервисов, как npm, crates.io или GitHub. Если эти библиотеки скомпрометированы, они могут стать вектором для таких атак, как:

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

3.5 Сервисы доставки фронтенда и связанные с ними риски

Многие приложения Эфириума предоставляют свои фронтенды через сеть доставки контента (CDN) или облачную хостинговую платформу (например, Vercel, Netlify, Cloudflare). Если эти сервисы скомпрометированы, они могут стать вектором для таких атак, как внедрение вредоносного JavaScript, когда злоумышленники предоставляют пользователям измененный фронтенд.

3.6 Цензура на уровне интернет-провайдеров

Интернет-провайдеры (ISP) или национальные государства могут использовать контроль над базовой интернет-инфраструктурой для цензуры доступа к Эфириуму. Например, эти атаки могут включать:

• Блокировку или ограничение трафика к общим портам Эфириума
• Фильтрацию DNS-запросов, которые разрешаются в сервисы, связанные с Эфириумом
• Геозонирование или блокировку по IP-адресам известных узлов Эфириума
• Глубокую проверку пакетов для выявления и цензуры трафика, связанного с протоколом Эфириума

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

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

4.1 Хрупкость консенсуса и риски восстановления

Правила выбора форка и финальности Эфириума устойчивы, но они не неуязвимы. В определенных пограничных условиях (таких как длительные разногласия валидаторов, ошибки клиентов или разделение сети) консенсус может остановиться или временно разойтись. В экстремальных условиях это может привести к каскадным штрафам валидаторов из-за утечек неактивности или слэшинга, что в дальнейшем может привести к оттоку капитала от валидаторов.

4.2 Разнообразие клиентов

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

4.3 Централизация стейкинга и доминирование пулов

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

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

4.4 Неопределенный социальный слэшинг и пробелы в координации

В некоторых экстремальных режимах сбоя Эфириум будет полагаться на «социальный слэшинг» для наказания валидаторов, которые действовали злонамеренно для атаки на сеть (см. раздел 6.1). Однако инфраструктура, нормы и ожидаемые процессы для такого рода слэшинга недостаточно развиты. Не существует установленного механизма, который сообщество использовало бы для участия в этом процессе.

4.5 Экономические и теоретико-игровые векторы атак

Многие потенциальные экономические векторы атак остаются малоизученными, в том числе:

• Грифинг-атаки или грифинг слэшинга. Валидаторы могут понести расходы или штрафы за слэшинг не по своей вине, а из-за враждебного поведения, направленного исключительно на причинение вреда другим с чистыми затратами для злоумышленника.
• Стратегические выходы или рассчитанная по времени неактивность. Валидаторы могут намеренно отключаться или выходить в критические моменты, чтобы максимизировать прибыль или нарушить консенсус с минимальными штрафами.
• Сговор между валидаторами или ретрансляторами. Скоординированное поведение между валидаторами или между ретрансляторами и валидаторами может снизить децентрализацию или извлечь MEV.
• Использование пограничных стимулов в MEV, разделении предлагающего и создающего (PBS) или дизайне ликвидного стейкинга. Участники могут манипулировать редкими условиями протокола для получения огромных вознаграждений.

4.6 Квантовый риск

Основная криптография Эфириума (например, подписи на эллиптической кривой, такие как secp256k1) однажды может быть взломана квантовыми компьютерами. Хотя это не является неминуемым риском, реальная угроза может мгновенно сделать существующие кошельки, контракты и ключи стейкинга уязвимыми. Эта будущая проблема ослабляет долгосрочные гарантии Эфириума для пользователей.

Пути миграции на квантово-устойчивую криптографию (например, с помощью схем постквантовых подписей) должны быть разработаны, протестированы и, возможно, встроены в протокол за годы до того, как они понадобятся. Организации в экосистеме Эфириума, включая Фонд Ethereum, активно изучают эти варианты и отслеживают риски.

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

• Связь с пострадавшей командой. Может быть сложно связаться с командой, чье приложение было скомпрометировано. Это может привести к многочасовым задержкам, ограничивая возможности реагирующих лиц по возврату средств.
• Эскалация проблем в связанных организациях. Когда проблема затрагивает платформу (например, социальную сеть или централизованную биржу), реагирующим лицам может быть сложно эскалировать проблему, если у них нет предварительного контакта.
• Координация реагирования. Часто неясно, сколько команд реагирования на инциденты помогают пострадавшему приложению, что приводит к недопониманию или напрасным усилиям, когда групповые усилия могли бы быть более эффективными.
• Отсутствие возможностей мониторинга. Может быть сложно отслеживать ончейн- и офчейн-проблемы, что обеспечило бы раннее предупреждение и гарантировало бы быстрое реагирование на угрозы.
• Доступ к страхованию. Страхование является важным инструментом для смягчения потерь в большинстве традиционных систем, которые имеют дело с деньгами, финансовыми системами, идентификацией и другой ценной информацией. Однако сегодня традиционные финансовые сервисы предлагают мало вариантов страхования для криптоэкосистемы.

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

6.1 Централизация стейка

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

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

Если бы этот экстремальный сценарий произошел, сообщество Эфириума предположило, что ответом мог бы стать «социальный слэшинг». Социальный слэшинг — это использование офчейн-социального консенсуса для принятия решения о слэшинге недобросовестных валидаторов в качестве контроля над их властью. Но не существует четких норм, процедур или инструментов для принятия таких мер (см. раздел 4.4).

6.2 Централизация офчейн-активов

В Эфириуме размещены значительные объемы активов реального мира (RWA), где активы хранятся офчейн на банковских счетах или других депозитах, которые затем торгуются ончейн с помощью токенов, представляющих собой право на востребование офчейн-активов. Например, многие крупные стейблкоины функционируют таким образом.

Учреждения, которые хранят офчейн-депозиты, могут иметь влияние на экосистему Эфириума. Например, во время экстремального сценария, когда происходит спорный форк или обновление сети, крупные вкладчики могут повлиять на то, какая цепь станет широко принятой, просто решив признавать токены только в одной цепи или в другой.

6.3 Регуляторная атака или давление

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

6.4 Организационный захват управления

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

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