Тема трансграничных платежей и цифровых финансовых активов (ЦФА) последние годы активно поселилась в медиасфере. К сожалению, обсуждение в основном сводится к оценке финансовой выгоды и юридическим проблемам. Тогда как, существует ещё и проблемы безопасности, которые на сегодняшний день, на мой взгляд, во многом недооценены (хотя, осознание проблемы понемногу уже происходит: об этом начинают говорить публично). В публичной плоскости мало конкретики о безопасности в этой сфере. Между тем, рынок ЦФА растёт: за 3 года ожидается почти 8-кратный рост в РФ (до 500 млрд. руб). А мирового — более 8 трлн $ к 2029. Поэтому вопросы безопасности становятся всё более актуальными. Мне довелось пообщаться с некоторыми разработчиками, исследовать архитектурные решения некоторых корпоративных блокчейнов. Также, я часто сталкивался с устоявшимися заблуждениями относительно факторов риска, которые хотел бы развеять. На основании всего этого, а также своего разнообразного опыта (пентест, разработка, code review, в т.ч. в сфере блокчейна) хочу поделиться своим мнением о текущем состоянии безопасности финансовых решений на основе блокчейн технологий. И тех причин, которые за этим стоят. В примерах для описания проблем будет использоваться блокчейн Hyperledger Fabric. Но, во многих случаях пример может быть общим и для других корпоративных блокчей нов.
Содержание:
нежелание разработчиков признавать проблемы безопасности, выявленные сторонними исследователями;
проблемы перенятия модели угроз от открытых блокчейнов без необходимой адаптации;
неготовность средств контроля и анализа сетевого трафика к атакам на элементы блокчейна;
малое количество профильных специалистов по безопасности в области блокчейна;
Место блокчейна в ЦФА и трансграничных платежах
Сначала зафиксируем, что блокчейн используется в ЦФА и трансграничных платежах. Согласно сайта ЦБ РФ, за 2022-2024 в реестр операторов информационных систем включены 11 компаний. Большинство из них используют для этого блокчейн. При этом активно развивается процесс использования ЦФА в качестве международных расчётов.
Блокчейн также активно используется в цифровых валютах центральных банков различных стран. А ещё SWIFT анонсировала создание инфраструктуры для операций с цифровыми активами и цифровыми валютами центробанков разных стран.
Дополнительно рекомендую ознакомиться со статьёй о пользе блокчейна в корпоративной среде. В ней объясняется, почему блокчейн стал удобным средством для корпоративного использования.
Нежелание разработчиков признавать проблемы безопасности
Теперь переходим к вопросам безопасности. Свежая история из моего личного опыта. Я обнаружил уязвимость в блокчейне Hyperledger Fabric (CVE-2024–45 244). После моего обращения через HackerOne, разработчики выпустили исправление. Но, не признали это уязвимостью: не стали назначать CVE идентификатор. В итоге, я самостоятельно добился назначения CVE. После того как я сообщил о назначении CVE разработчикам, они попытались оспорить это. Оспорить не удалось. Я так понял позицию разработчиков: всё работает как задумано. Кроме того, за уйму времени никаких инцидентов не было, так что проблемы как токовой и нет. Именно тогда я понял, что при таком подходе, доказывать что‑либо бесполезно, нужно заниматься назначением CVE.
Итог этой истории: исправление сейчас недоступно для стабильных версий: фикс присутствует лишь в ветке main. Какого‑либо информирования пользователей об уязвимости со стороны разработчиков я не нашёл (на странице проекта в github в списке уязвимостей не значится). Не нашёл и рекомендаций от разработчика: что делать пользователям, которые используют версию без исправлений? Лично у меня сложилось такое впечатление — некоторые разработчики считают, что только они вправе определять: что является уязвимостью, а что — нет. Игнорируя при этом сложившуюся практику взаимодействия исследователей безопасности с MITRE.
А теперь давайте представим: сколько потенциальных отчётов об уязвимостях могли быть не признаны различными разработчиками? И все ли авторы таких отчётов не растерялись, а добились присвоения CVE их уязвимостям?
Проблемы перенятия модели угроз от открытых блокчейнов без необходимой адаптации
Часто встречаюсь с мнением, что у корпоративных блокчейнов те же проблемы безопасности, что и у открытых блокчейнов. И, дабы, не изобретать велосипед — давайте просто ими и руководствоваться. При этом, даже в среде специалистов по безопасности блокчейнов устоялось мнение: всё внимание на смарт‑контракты, там могут быть различные ошибки, а сам блокчейн безопасен — раз столько времени работает и до сих пор жив (в отличие от смарт‑контрактов, которые часто становятся мишенью атак). Если и появляются какие‑либо небольшие ошибки — их быстро исправляют. Кроме того, в открытых блокчейнах очень много узлов (т. е. элементов). Каждый владелец сам заинтересован в поддержании работоспособного узла. И если даже множество узлов выйдут из строя — это будет приемлемо и не скажется работе всего блокчейна. Если только не будет найдена уязвимость на уровне протокола всего блокчейна, которая остановит всю сеть (но, тут мы снова возвращаемся в веру в безопасность блокчейна). Ну, и вся логика с финансами в смарт‑контрактах, зачем кому‑то атаковать инфраструктуру?
В предыдущем разделе я уже показал: как обстоят дела с отсутствием уязвимостей в блокчейне. В части Hyperledger Fabric оппоненты иногда ссылаются на отчёт по пентесту от 2021 года (который является не первым общедоступным отчётом по пентесту), где сказано, что «блокчейн достиг зрелого уровня безопасности и функциональности». На это я замечу: с 2021 года зарегистрировано 7 CVE (большинство из которых высокого уровня опасности). При чём часть из них (от 2021) существовала на момент пентеста, но, по какой‑то причине, не была обнаружена.
Что касается узлов (нод) блокчейна: в отличие от открытых блокчейнов (где могут быть тысячи узлов), количество участников в корпоративных сильно ограничено. Что сильно упрощает задачу злоумышленнику по выведению из строя блокчейн сети, организуя атаку на выявленные элементы. Для примера, взгляните на схему небольшой сети блокчейна Hyperledger Fabric.
Тут представлены:
С1 — канал;
P1,P2 — пир узлы;
O4 — служба упорядочивания;
L1,L2 — копии реестра (т. е. база данных);
S5 — смарт‑контракт;
А1,А2,А3 — приложения;
R1,R2,R4 — организации;
CA (1,2,4) — центры сертификации.
И безопасностью всех этих составляющих стоит заниматься. Я находил, доступные через интернет, различные элементы блокчейна Hyperledger Fabric: пиры, службы упорядочивания. И даже базы данных (мне сложно придумать, зачем БД должна быть доступна на весь интернет). В т.ч., устаревших версий. Что позволяло провести атаки и остановить бизнес‑процессы. Раз уж речь о конечном количестве узлов, взаимодействующих друг с другом, стоит подумать о списке доступа (ACL). Даже если представить ситуацию, в которой сложно поддерживать ACL в актуальном состоянии, можно воспользоваться динамическим ACL (я такой вариант делал).
Кроме того, не все обнаруживаемые уязвимости будут публично известны. Особенно учитывая, что область ЦФА и трансграничных платежей очень важна для государства. Об этом же говорил и директор департамента операционных рисков, информационной безопасности и непрерывности бизнеса Московской биржи Сергей Демидов. Тем более учитывая историю, когда хакерские инструменты ЦРУ (включая эксплоиты к ранее неизвестным уязвимостям) уже становились достоянием общественности.
Игнорирование элементов блокчейна специалистами по тестированию на проникновение
Довольно часто крупные фирмы заказывают тестирование на проникновение. При этом полагая, что раз элементы блокчейна находятся внутри тестируемой сети, то при наличии уязвимостей в блокчейне это будет отображено в отчёте. А если в отчёте нет про блокчейн — то и проблемы тоже нет. Основная ошибка, которую совершают закачики — отсутствие проверки компетентности исполнителя на наличие профильных знаний именно по блокчейну и именно в сетевой его части. В итоге, в отчёт не попадает информация об уязвимостях в блокейне не потому, что их нет, а потому, что исполнители не имеют должной квалификации. И это большая проблема — вообще найти подходящую компанию. Я собеседовался в несколько крупных компаний, специализирующихся на тестировании на проникновение, общался с руководителями отделов. Во всех компаниях мне сказали, что блокчейна не встречали. Что довольно странно, учитывая, что я находил в интернете элементы блокчейна в крупных компаниях самостоятельно. Однажды, при собеседовании оказалось, что я и руководитель отдела видели одну и ту же инфраструктуру одного заказчика. Руководитель мне признался, что видел сервис, о котором я говорю, но в отчёт он не попал т.к.: «мы вообще не поняли: что это». А это был уязвимый сервис, атака на который потенциально приводила к остановке бизнес‑процесса. В другой компании по тестированию на проникновение мне руководитель заявил, что они одинаково хорошо тестируют всё, что есть в сети заказчика и им не нужны узкие специалисты. При этом ни одного отчёта, где был блокчейн, вспомнить он не смог. Это примерно, как если терапевт говорит, что он готов дать экспертное заключение вместо невролога: дать‑то он даст. Но, насколько такое заключение действительно полезно?
Отсутствие блокчейна в составе киберполигонов
Киберполигоны — специальные макеты, имитирующие сеть предприятия. На таких полигонах: одни специалисты учатся проводить атаки на уязвимое оборудование, а другие — обнаруживать и предотвращать атаки. Некоторые киберполиногы продаются как услуга заказчикам: чтоб их специалисты по защите набрались навыков, необходимых для использования на реальной промышленной сети предприятия. Основная проблема: эти киберполигоны зачастую делают те же компании, которые предоставляют услуги по тестированию на проникновение. И, как уже было показано ранее, специалистов по блокчейну чаще всего нет. Собственно, и самих элементов бокчейна в киберполигоне сложно найти. Я общался с руководителем разработки киберполигона в одной крупной российской компании. И он честно признался, что никогда не сталкивался ни с блокчейном, ни с интересом заказчиков к нему.
Средства контроля и анализа сетевого трафика не заточены на атаки на элементы блокчейна
Существуют разные типы решений для защиты от атак на сетевую инфраструктуру компаний: NTA, NGFW, WAF. Но, все они не заточены под целенаправленные атаки на блокейн узлы. Например, для блокчейна Hyperldeger Fabric в публичных источниках доступна информация о 6 разных атаках на сетевом уровне. При этом, в публичном поле я не нашёл информации, какое решение для защиты от атак на сетевую инфраструктуру способно их предотвратить. Да, как минимум часть решений технически может быть дополнена информацией о подобных атаках таким образом, чтобы начать их блокировать. Но, работу по обновлению данных об атаке должен кто‑то сделать. И этот «кто‑то» должен быть в этом компетентен.
Элементы блокчейна часто вне списка багбаунти программ
Багбаунти программы уже прочно вошли в жизнь крупных компаний. И, это действительно хороший способ повысить защищённость компании за счёт независимых исследователей. Проблема в том, что зачастую элементы блокчейна не входят в список багбаунти программ. Т. е. у исследователя, нашедшего возможность остановить бизнес-процесс, нет экономического стимула сообщать об этой проблеме производителю.
Проблема со специалистами по безопасности
Сюда относится «кадровый голод» в сочетании с низким спросом на специалистов (эдакий оксюморон), неверные ожидания от кандидата и низкое количество площадок для обмена опытом такими специалистами. В ВУЗах страны уже преподают блокчейн как направление. Тяжело оценить полностью все программы по всем ВУЗах. Но, максимум, что я видел в программах в части безопасности — это криптография (+ вводная часть, что в архитектуре блокчейна уже подумали про безопасность). Если искать курсы по безопасности блокчейнов — в основном находятся по безопасности смарт‑контрактов. Конференции, где рассказывается про безопасность блокчейна, найти тяжело. В 2023 году я занимался организацией секции по безопасности блокчейну в рамках конференции PHDays. Самостоятельно подавшихся на доклад было мало. Мне стоило больших усилий наскрести доклады. Доходило до того, что я даже предлагал темы докладов потенциальным докладчикам. Бывали и обратные ситуации: когда на профильную конференцию по безопасности не брали мой доклад т.к. «слишком узкая тема».
Мне на собеседовании как‑то задавали вопросы будто я собеседуюсь не на «безопасника», а на администратора сети («сколько транзакций по‑умолчанию в блоке, где это настраивается» и т. д.). При этом, я не получил ответа, какое отношение к безопасности имеют такие вопросы. Зато понял, что собеседующий полагает, что «безопасник» — это тот, кто знает про блокчейн больше него. Поэтому и спрашивает, что знает. Такой подход, при выборе из нескольких кандидатов, может привести к приоритету для бывшего разработчика/администратора без опыта практической безопасности. По моему опыту, хорошие «безопасники» в таких случая — исключение из правил. Это как писатель и литературный критик: теоретически они могут друг друга заменять. Но, одинаково хорошо выполнять обе работы вряд ли получится. На одном из предыдущих мест работы, у меня как раз был тимлид без практического опыта по безопасности в какой‑либо области (до момента трудоустройства на эту должность). Он проигнорировал найденную мной потенциальную проблему. В итоге, я самостоятельно довёл до присвоения CVE (уже не работая там). Найти специалиста, который имеет практический опыт нахождения уязвимостей в частях блокчейна, отличных от смарт‑контрактов, довольно непросто. Для наглядности, я провёл опрос в закрытой группе Stronghold (для участия нужно завершить курсы по безопасности смарт‑контрактов — MixBytes Farm), в которой и сам состою. Всего проголосовало 33 человека. Результаты опроса ниже.
Да этот опрос не слишком масштабный по количеству людей. Но, и группа небольшая. И компаниям, заинтересованным в комплексной безопасности блокчейн сетей (а не только на уровне смарт‑контрактов), есть о чём подумать. Из проголосовавших уязвимость в блокчейне, которой присвоен номер CVE, нашёл 1 человек (это я). Почти треть не знает, что такое CVE.
Даже если сосредоточиться только на специалистах по исследованию смарт‑контрактов корпоративных блокчейнов — таких специалистов достаточно мало. Более того: и спроса на рынке труда в РФ на них немного. Бывают попытки замены такого специалиста на специалиста по безопасности кода нужного языка смарт‑контракта. Например, если смарт‑контракт написан на Golang — найти специалиста по анализу кода на Golang. Но, это приводит к тому, что проблемы безопасности, специфичные конкретному блокчейн решению, таким специалистом выявлены не будут. Более того, я имел опыт анализа смарт‑контрактов для разных блокчейнов. И могу сказать, что даже у разных блокчейнов есть свои особенности. Поэтому взять специалиста по анализу смарт‑контракта одного блокчейна и дать ему исследовать смарт‑контракт другого блокчейна (при этом, не давая возможности изучить особенности нового для него блокчейна) — не самая хорошая идея.
Влияние геополитики
Мой опыт показывает, что этот вопрос труднее всего даётся интеграторам блокчейн решений. Могут быть ситуации, когда для трансграничности платежа трафик должен передаваться от узла блокчейна в одной стране до узла в другой. И вот тут стоит уже учитывать влияние геополитики: технически такой трафик может быть выделен (на фоне другого трафика) и заблокирован. В основном заблуждения связаны с:
отсутствием понимания: как можно выделить часть трафика и заблокировать только его;
верой, что при блокировке одного пути будет работать другой;
безграничная надежда на VPN, который должен решить все проблемы.
Про блокировку только части трафика — прекрасный живой пример из настоящего с YouTube в РФ: проблемы с ним почти у всех абонентов проводных провайдеров. А всё остальное работает. Найти, что именно блокировать, тоже несложно: я нахожу в интернете элементы блокчейна, используя специализированные поисковики типа Shodan.
В части обходных путей — всё так, но есть нюанс: есть ли путь трафика из РФ на, скажем, Кубу в обход недружественных стран? Его нет, если не говорить о спутниках (и тут встают вопросы скорости/доступности соединения). И это, если считать, что сигнал спутника никто не будет глушить (в данном случае — рядом с Кубой). Про VPN. Тут самая главная проблема в том, что корпоративные блокчейны «из коробки» его не поддерживают (я не сталкивался с обратным). т. е., нет никаких гарантий, что внедрённый (ещё вопрос: кем?) VPN не скажется на работоспособности и сохранении заявленных изначально технических характеристиках блокчейна.
Взаимодействие со странами с общей границей выглядит более безопасным. Но, и тут, нужно учитывать некоторые риски, вроде повреждения подводной инфраструктуры. В некоторых странах уже задумались о бесперебойности финансовых транзакций в случаях повреждения кабеля.
Заключение
Буду краток. На мой взгляд, ситуация с безопасностью в корпоративных блокчейнах во многом повторяет ситуацию с безопасностью промышленных устройств: сначала не было интереса, а потом грянул Stuxnet — и «безопасники» резко потребовались.