Что такое пентест блокчейна? Определения и границы

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

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

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

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

Что добавляет web3: модель угроз, связанная с обращением средств

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

Три характеристики формируют это расширение.

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

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

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

Мы моделируем возникающую подверженность риску как цепочку обращения со средствами — off-chain намерение подписания, утверждение и контроли логики средств, которые ведут к ончейн-транзакциям (а также, всё чаще, к собственным развёрнутым контрактам институции) — наряду с уровнями облака, веба, API и идентификации, которые поддерживают эти шаги [1]. Злоумышленник может начать с обычной точки входа и продвигаться через несколько контролей: манипулировать тем, что предоставляется для подписания, добраться до привилегированного рабочего процесса, воспользоваться пробелом в авторизации или заставить логику средств принять непреднамеренный переход состояния.

Определяющим пробелом композиции является переход между off-chain и on-chain: сохраняют ли контроли идентификации, интерфейса, утверждения, подписания и логики средств предполагаемое действие, когда оно становится ончейн-транзакцией. Не каждая атака проходит через всю цепочку. Суть в том, что цель обеспечения гарантий является межслойной: контроли, которые кажутся надёжными по отдельности, всё же могут объединиться в эксплуатируемый путь через работающую систему обращения со средствами.

Что делает тестирование на проникновение в блокчейн

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

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

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

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

В рамках институциональной среды web3 этот процесс от сценария к доказательству проходит через пять взаимосвязанных возможностей — тестируемые поверхности одной и той же цепочки обращения со средствами. Они охватывают инфраструктуру, поддерживающую цепочку, три её off-chain контроля и ончейн-транзакции, которым она передаёт управление; они взаимосвязаны, потому что единый путь может пересекать несколько из них:

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

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

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

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

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

Часть 4: Поверхности атак web3: обзор тестирования на проникновение отображает эти поверхности и их связи, не изменяя основную цель: установить, объединяются ли условия в согласованной работающей среде в воспроизводимое воздействие.

Где оно вписывается наряду с другими видами обеспечения гарантий

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

Тестирование на проникновение и аудит на уровне кода

Code Audit — именованная форма аудита на уровне кода — в первую очередь формирует доверие к коду (а также включает предположения о дизайне, архитектуре и протоколе). Он сочетает экспертную проверку с инструментами обнаружения, может включать динамические методики и завершается подписанным отчётом в рамках согласованной области аудита. Для контрактов, блокчейнов, мостов, роллапов, кошельков или других реализаций аудит задаётся вопросом, удовлетворяют ли дизайн и код своим предполагаемым свойствам безопасности.

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

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

Таким образом, враждебное поведение контракта в реальном институциональном пути может относиться к тестированию на проникновение, в то время как обеспечение гарантий относительно самого кода контракта направляется в соответствующий Code Audit.

Сканирование, bug bounty и специализированное тестирование

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

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

Например, Blockchain Security Testing от BlockSec — это смежная программа, а не родительская или подмножество тестирования на проникновение. Она использует специализированные движки — включая дифференциальное тестирование, фаззинг, приватное развёртывание, крупномасштабное тестирование отказа в обслуживании RPC и тестирование инфраструктуры узлов или кластеров — для проверки корректности реализации и устойчивости кастомизированной инфраструктуры [2]. Тестирование на проникновение в блокчейн сосредоточено на межслойных путях уровня институции через работающую систему обращения со средствами. Хостинг приложений и CI/CD приложений относятся к поверхности тестирования на проникновение; инфраструктура узлов и кластеров и крупномасштабная устойчивость RPC относятся к Blockchain Security Testing. Архитектуре может потребоваться и то, и другое.

Смежные цели также требуют точной маршрутизации. Обеспечение гарантий кода контракта на уровне кода направляется в соответствующий Code Audit. Криптографическая корректность реализаций хранения ключей, включая MPC, TSS и TEE-конструкции, направляется в Wallet Security Audit. Платёжные агентские системы направляются в Agentic Payment Security [1]. Тестирование на проникновение всё же может исследовать окружающий рабочий процесс подписания, операционных агентов или путь приложения, когда это составляет часть согласованной институциональной области.

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

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

Как начать

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

Затем обсуждение по определению области может согласовать цель, предположения о доступе, меры защиты и ожидаемые результаты. Часть 3: Правила взаимодействия и безопасность продуктивной среды для институционального тестирования на проникновение в блокчейн охватывает авторизацию, безопасность и координацию, необходимые для практической реализации работы [4].

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

Продолжите изучение руководств по поверхностям атак:

• Часть 4: Поверхности атак web3: обзор тестирования на проникновение

Также в этой серии, скоро в публикации:

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

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

Источники

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

1. BlockSec, Blockchain Penetration Testing.
2. BlockSec, [Blockchain Security Testing], скоро в публикации.
3. BlockSec, От инцидентов к регулированию: почему криптоинституциям необходимо тестирование на проникновение в блокчейн.
4. BlockSec, Правила взаимодействия и безопасность продуктивной среды для институционального тестирования на проникновение в блокчейн.