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

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

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

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

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

Что добавляет web3: модель угроз для операций с денежными средствами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Веб- и 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: Безопасность реестра биржи: пути хищения и логика плоскости данных

Основная страница по тестированию на проникновение в блокчейн предоставляет обзор на уровне заданий.

Источники

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

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