Поверхности атаки Web3: обзор тестирования на проникновение

Первые три статьи этой серии объяснили, зачем криптоинституциям нужно тестирование на проникновение в блокчейн (Часть 1), что именно проверяет эта дисциплина (Часть 2) и как можно безопасно подготовить и провести институциональное тестирование (Часть 3).

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

Компоненты web3-институций

Web3-институции, включая централизованные биржи, платежных провайдеров и DeFi-проекты, связывают традиционные среды приложений и инфраструктуры с цепочкой обработки средств от офчейна к ончейну [2]. Они сохраняют традиционные поверхности атак для пентестинга, но при этом добавляют дополнительные проверочные точки вокруг намерения транзакции, полномочий на подписание, учета средств и выполнения в блокчейне. Определение того, как эти поверхности взаимодействуют и какие условия могут сформировать путь к получению ценности, требует специализированной экспертизы в области безопасности web3.

Чтобы систематически рассмотреть эту расширенную поверхность атак, в этом разделе определяется модель из четырех компонентов: Application (Приложение), Authorization and Signing (Авторизация и подписание), Blockchain Interaction (Взаимодействие с блокчейном) и Infrastructure (Инфраструктура). Для каждого компонента описывается его зона ответственности, определяются типичные реализации и обобщаются основные поверхности атак. Обратите внимание, что разные web3-институции могут комбинировать эти компоненты или передавать их на аутсорсинг по-разному.

Компонент 1: Приложение (Application)

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

Распространенные типы тестирования.

• Тестирование на проникновение веб-приложений

• Тестирование на проникновение мобильных приложений

• Тестирование на проникновение расширений браузера

• Тестирование на проникновение API

Компонент Application наследует традиционные поверхности атак, такие как управление идентификацией и сессиями, авторизация и изоляция, а также целостность бизнес-процессов и переходов состояний. В web3-институции бизнес-действие или намерение транзакции, подготовленное на этом этапе, впоследствии может быть авторизовано компонентом Authorization and Signing и исполнено через компонент Blockchain Interaction. Поэтому сбои в этих контролях могут привести к прерыванию сервиса или распространиться в прямую потерю активов.

Компонент 2: Авторизация и подписание (Authorization and Signing)

Компонент Authorization and Signing получает запросы на транзакции, подготовленные компонентом Application, и генерирует криптографические подписи, необходимые для отправки в блокчейн. Некоторые реализации могут дополнительно выполнять проверки политик или подтверждений внутри системы подписания перед генерацией подписи. Типичными представителями в web3-институциях являются системы или сервисы кошельков и подписания.

Распространенные типы тестирования.

• Тестирование идентификации и привилегированного доступа

• Тестирование рабочих процессов подписания и подтверждения

Традиционные поверхности атак, унаследованные компонентом Authorization and Signing, включают управление привилегированной идентификацией и доступом, авторизацию API и разделение обязанностей, а также целостность процессов подтверждения, восстановления и административных операций. В web3-институциях сбои в этом компоненте могут иметь особенно серьезные последствия, поскольку действительная подпись может напрямую авторизовать необратимое изменение состояния или перевод активов. Как финальный этап криптографической авторизации перед отправкой в блокчейн, компонент Authorization and Signing следует рассматривать как критический приоритет обеспечения безопасности везде, где он используется.

Компонент 3: Взаимодействие с блокчейном (Blockchain Interaction)

Компонент Blockchain Interaction отправляет транзакции, авторизованные пользователями или внутренними операторами, подтверждает их статус исполнения и отслеживает результирующее состояние в блокчейне. Типичными представителями в web3-институциях являются шлюзы узлов или RPC, индексаторы и релейеры.

Распространенные типы тестирования.

• Тестирование на проникновение API и RPC

• Тестирование злоупотреблений при отправке транзакций и работе релейеров

Хотя Blockchain Interaction выполняет роль, специфичную для операций web3, тестирование на проникновение этого компонента сосредоточено на возможности враждебной эксплуатации его унаследованных поверхностей атак: учетных данных сервисов и безопасности конечных точек, авторизации RPC и API, а также целостности обработки сообщений и событий — например, можно ли злоупотребить поведением RPC или релейера, манипулировать отправкой транзакций или неверно интерпретировать события в блокчейне. Для институций, эксплуатирующих кастомизированные или самостоятельно размещенные узлы блокчейна, корректность узлов и кластеров, а также масштабная устойчивость RPC — синхронизация, распространение транзакций, отказоустойчивость и доступность — являются дополнительными вопросами, которые решаются в рамках Blockchain Security Testing, а не пентестинга [2].

Компонент 4: Инфраструктура (Infrastructure)

Компонент Infrastructure охватывает специфичную для институции инфраструктуру и операционные системы, поддерживающие или влияющие на остальные три компонента. Типичными представителями в web3-институциях являются облачные платформы, сетевая инфраструктура, системы IAM и управления секретами, системы контроля версий и CI/CD, а также платформы мониторинга.

Распространенные типы тестирования.

• Внешнее и внутреннее тестирование на проникновение сети

• Тестирование на проникновение облачной инфраструктуры

• Тестирование CI/CD и цепочки поставок программного обеспечения

Infrastructure в основном наследует традиционные поверхности атак, включая сетевую и сервисную экспозицию, управление идентификацией, привилегиями и секретами, а также целостность доставки программного обеспечения и цепочки поставок. Хотя Infrastructure обычно не выполняет действия по обработке средств напрямую, ее сбой или компрометация могут привести к существенной потере активов. Инциденты с Bybit и TrustWallet, рассмотренные в Части 1, иллюстрируют, как компрометация каналов доставки и распространения программного обеспечения может распространиться в цепочку обработки средств [1].

Поверхности атак web3

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

Чтобы структурировать это покрытие, в этом разделе поверхности атак web3 группируются в пять основных областей поверхности атак, вытекающих из цепочки обработки средств и области тестирования, представленных в Части 2 [2]:

• Производственная среда и автоматизированные операции

• Веб- и dApp-интерфейсы, авторизация и намерение подписания

• Цепочки авторизации подписания, подтверждения и вывода средств

• Бизнес-логика работы со средствами

• Ончейн-транзакции и развернутые контракты

Производственная среда и автоматизированные операции

Производственная среда поддерживает каждый этап цепочки обработки средств. Обычная точка закрепления в инфраструктуре, идентификации или доставке программного обеспечения может не перемещать средства напрямую, но может изменить поведение Application, достичь Authorization and Signing или повлиять на Blockchain Interaction. Поэтому тестирование на проникновение в блокчейн оценивает достижимое влияние точки закрепления на цепочку обработки средств, а не рассматривает инфраструктурную находку как изолированную конечную точку [2].

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

Детальный анализ [3] рассматривает, как компрометация производственной среды может распространиться через контроли развертывания и операционные контроли в компоненты обработки средств.

Веб- и dApp-интерфейсы, авторизация и намерение подписания

Веб- и dApp-интерфейсы являются основным слоем взаимодействия, где пользователи и операторы инициируют и проверяют действия по обработке средств и участвуют в потоках авторизации и подписания, через которые эти действия подтверждаются. Такое положение делает их привлекательной целью для фишинга и захвата интерфейса, поскольку контроль над интерфейсом может манипулировать контекстом или содержимым запроса транзакции до того, как он достигнет кошелька или системы подписания [1].

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

Детальный анализ [4] отслеживает намерение транзакции от представления в приложении через авторизацию в кошельке до подписанного или отправленного результата, фокусируясь на том, где смысл действия может измениться.

Цепочки авторизации подписания, подтверждения и вывода средств

Подписание часто является действием, перемещающим средства, но одна лишь криптографическая действительность не устанавливает корректных бизнес-полномочий. Результат с точки зрения безопасности также зависит от того, кто инициировал запрос, какая политика была применена, что проверили подтверждающие лица и остался ли payload неизменным. Слабость в этой цепочке контроля может привести к тому, что легитимный подписант авторизует непреднамеренное действие [2].

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

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

Бизнес-логика работы со средствами

Кастодиальные институции полагаются на офчейн-состояние для определения балансов, обязательств и возможности высвобождения ценности. Поэтому непреднамеренное зачисление или переход состояния может стать прямой финансовой потерей, даже если ни ключ подписания, ни смарт-контракт не скомпрометированы. Тестирование должно учитывать экономический инвариант и путь сверки, а не только то, ведет ли себя отдельный API так, как реализовано [2].

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

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

Ончейн-транзакции и развернутые контракты

Ончейн-передача — это момент, когда офчейн-намерение становится публичным поведением во время выполнения. Транзакции могут быть необратимыми, а развернутые контракты публично вызываемы и совместимы с системами вне прямого контроля институции. Поэтому оценка должна сохранять связь между предполагаемым действием, отправленной транзакцией, наблюдаемым выполнением и состоянием, интерпретируемым институцией [2].

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

В этой области тестирование на проникновение остается сфокусированным на враждебном взаимодействии во время выполнения и доказательствах на уровне транзакций. Обеспечение качества контрактов на уровне кода остается в рамках Code Audit, а корректность узлов или кластеров и масштабная устойчивость RPC остаются в рамках Blockchain Security Testing [2].

Заключение

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

Чтобы сделать эти взаимосвязи явными, в этой статье используется модель из четырех компонентов: Application готовит бизнес-действия, Authorization and Signing генерирует подписи, Blockchain Interaction отправляет транзакции и интерпретирует результаты, а Infrastructure поддерживает или влияет на остальные компоненты. Кроме того, пять областей поверхности атак определяют, где специализированная экспертиза в области безопасности web3 наиболее важна, особенно на границах между намерением транзакции, полномочиями на подписание, логикой средств и поведением во время выполнения в блокчейне.

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

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

Также в этой серии, скоро выйдет:

• Часть 5: Безопасность авторизации и подписания: веб, dApps и
• Часть 6: Безопасность облака и CI/CD: поверхности атак автоматизированных операций
• Часть 7: Безопасность плоскости управления казначейством: подтверждения подписания и вывода средств
• Часть 8: Безопасность биржевого реестра: пути хищения и логика плоскости данных

Обзорная страница Blockchain Penetration Testing предоставляет представление на уровне проекта в целом.

Список источников

Нумерация в порядке первого появления.

1. BlockSec, От инцидентов к регулированию: зачем криптоинституциям нужно тестирование на проникновение в блокчейн.
2. BlockSec, Что такое тестирование на проникновение в блокчейн? Определения и границы.
3. BlockSec, скоро выйдет.
4. BlockSec, скоро выйдет.
5. BlockSec, скоро выйдет.
6. BlockSec, скоро выйдет.