Обзор испытаний, стоящих перед безопасностью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5 Конфиденциальность

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

Слабая защита конфиденциальности подвергает отдельных пользователей различным целевым угрозам, таким как фишинг, эксплуатация, мошенничество и физические атаки. Распространёнными примерами атак пользовательского опыта (UX) является подвержение пользователей риску, таких как повторное использование адресов, утечка данных KYC "Знай своего клиента" и других метаданных.

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

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

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

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

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

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

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

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

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

• Риск обновления контракта. Некоторые контракты предусматривают возможность изменения после внедрения, что позволяет команде разработчиков продолжать обновлять и улучшать приложение. Однако это связано с рисками. Обновления могут привести к появлению новых уязвимостей или полной потере средств пользователя в случае вредоносного обновления.
• Повторный вход, В ситуации, когда контракт А требует контракт Б перед внутренним обновлением, а контракт Б требует исходный контракт А перед завершением первого действия.
• Небезопасное использование внешних библиотек, Когда контракт вызывает внешнюю библиотеку, которая может быть непроверенной, вредоносной или обновляемой.
• Непроверенные компоненты. Несмотря на улучшение аудита и использования стандартных библиотек, разработчики иногда полагаются на непроверенные компоненты в своих приложениях.
• Ошибки доступа, Неправильно настроенные разрешения или неточно определенные позволяют злоумышленникам совершать вредоносные действия.
• Несанкционированный доступ, Когда злоумышленник получает закрытый ключ, позволяющий контролировать контракт.
• Мосты и межцепочечные взаимодействия. Мосты и кроссчейн-протоколы вносят дополнительную сложность, и злоумышленники могут использовать уязвимости в способах передачи или проверки кроссчейн-сообщений.
• Экстерное владение счетом (EOA) или неправомерное использование подписи. Вредоносные приложения могут обманным путём заставить пользователей передать полнoe правомочие своих учётных записей другому лицу, что позволит совершить кражу. Вредоносные приложения также могут использовать подписанные сообщения пользователя необоснованными способами, например, для атаки с повторным воспроизведением.
• Риск ошибок, вызванных генерацией кода искусственного интеллекта или автоматизированными инструментами.

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

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

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

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

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

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

3.1 Цепи слоя 2

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

• Сложность ресурсов с многоадресным мостом. При перемещении ресурсов между уровнями L1 и несколькими уровнями L2 они подвергаются воздействию множества контрактов, каждый из которых должен быть защищён. Несоответствие в учёте или сбои в цепочках уровней L2 могут привести к появлению уязвимостей, которыми могут воспользоваться злоумышленники.
• Накопительные уровни L2 (роллапы) полагаются на системы проверки для обеспечения корректности обновлений. Ошибки или неправильные настройки в этих системах могут затормозить или сделать невозможным завершение работы или допустить завершение работы с ложными обновлениями, что приведет к потере средств пользователей.
• Советы безопасности — это группы держателей ключей, которые служат «резервным» механизмом для обновления программного обеспечения уровня 2 или реагирования на определенные чрезвычайные ситуации. Советы безопасности сами по себе представляют риск, поскольку компромисс или разногласие между их членами могут поставить под угрозу средства пользователей или привести к заморозке активов.

Подробную структуру и панель мониторинга, которая оценивает и сравнивает производительность и безопасность L2, можно найти в разделе L2Beatopens in a new tab.

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

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

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

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

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

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

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

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

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

3.5 Услуги фронтенд интерфейса и связанные с ними риски

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

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

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

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

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

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

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

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

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

Лидирующее многообразие клиентов Ethereum защищает сеть от ошибок в работе любого отдельного клиента. Однако его можно улучшить за счёт более широкого привлечения клиентов из числа меньшинств, что позволит ещё больше снизить риски.

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

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

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

4.4 Неопределенные социальные разрывы и пробелы в координации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.4 Захват управления

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

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