1721
Проблемы безопасности ЦФА и трансграничных платежей на основе блокчейн-технологий
30 июля 2024 года в России был принят закон, допускающий иностранные ЦФА к обращению в российской инфраструктуре. При этом разрешается работа с российскими ЦФА иностранных номинальных держателей. Все это фактически приближает возможность использования ЦФА (в том числе и отечественных) в качестве средства для трансграничных платежей. И вот тут стоит вспомнить, что многие из операторов информационных систем цифровых финансовых активов используют блокчейн-технологии. Ситуацию комментирует Игорь Агиевич.
В основном используются следующие блокчейны: Hyperledger Fabric, Мастерчейн, Waves. В свою очередь, Сбербанк использует собственную блокчейн-разработку - "Блокчейн-платформа Сбера". Более того, даже цифровые валюты центробанков разных стран используют в своей основе блокчейн (Беларусь, Нигерия и др.). При этом вопросы безопасности блокчейна еще не так хорошо решены, как хотелось бы.
Этому способствует целый ряд факторов, ключевыми из которых являются:
• нежелание разработчиков признавать проблемы безопасности, выявленные сторонними исследователями;
• специалисты по тестированию сетевой инфраструктуры игнорируют элементы блокчейна в связи с отсутствием прикладных знаний в этой области;
• средства анализа сетевого трафика также не заточены на атаки на элементы блокчейна;
• элементы блокчейна часто вне списка баг-баунти программ;
• малое количество специалистов по безопасности в области блокчейна;
• безопасность блокчейна исторически ограничена только его частью: смарт-контрактами;
• отсутствие блокчейна в составе киберполигонов;
• влияние геополитики на трансграничные платежи: потенциальная фильтрация трансграничного трафика в недружественных странах.
О непризнании проблем безопасности разработчиками
Некоторые разработчики полагают, что лишь они сами могут решать: что является уязвимостью в том или ином их продукте. При этом они полностью игнорируют сложившуюся многолетнюю практику в кибербезопасности, согласно которой независимый исследователь может обратиться в независимую международную компанию и добиться подтверждения наличия уязвимости.
Буквально на днях у автора настоящей статьи произошел показательный случай. Я нашел уязвимость в одном из блокчейнов и немедленно связался с разработчиками через специализированную платформу подачи информации об уязвимостях. Разработчики внесли исправления в бета-версию, а в стабильные версии… не внесли. При этом они не признали наличие уязвимости. Тогда я самостоятельно обратился в международную организацию MITRE для получения уникального идентификатора уязвимости, описав атаку и возможные последствия. В MITRE изучили мое обращение и выдали идентификатор уязвимости.
Интересна реакция разработчиков блокчейна: узнав об этом, они сначала предлагали мне самому отозвать идентификатор уязвимости. А после моего предложения самим напрямую связаться с MITRE и донести свою позицию – стали пытаться оспорить уязвимость.
Ясно, что страдают от такого «конструктивного» подхода прежде всего пользователи, которые работают с уязвимой версией и даже не в курсе, что уязвимость присутствует (и тем более – как ее можно нивелировать).
Тестирование на проникновение для сетевой инфраструктуры
Довольно часто крупные фирмы заказывают тестирование на проникновение (пентест). При этом они полагают, что раз элементы блокчейна находятся внутри тестируемой сети, то при наличии уязвимостей в блокчейне это будет отображено в отчете. На деле же, если в отчете специально не упомянуто про блокчейн, то и проблемы тоже как бы нет.
Основная ошибка, которую совершают заказчики – отсутствие проверки компетентности исполнителя на наличие профильных знаний именно по блокчейну и именно в сетевой его части. В итоге в отчет не попадает информация об уязвимостях в блокчейне не потому, что их нет, а потому, что исполнители не имеют должной квалификации.
Кстати, это большая проблема – найти подходящую компанию для пентеста. Я проходил собеседования в несколько крупных структурах, специализирующихся в тестировании на проникновение. Во всех компаниях мне сказали, что блокчейна пока не встречали. Что довольно странно, учитывая, что я находил элементы блокчейна в крупных компаниях самостоятельно. Однажды при собеседовании оказалось, что я и руководитель отдела хорошо знакомы с одной и той же инфраструктурой конкретного заказчика. Руководитель мне признался, что видел сервис, о котором я говорю, но в отчет он не попал «т. к. мы вообще не поняли, что это». А это был уязвимый сервис, атака на который потенциально приводила к остановке бизнес-процесса.
В другой компании по тестированию на проникновение руководитель заявил мне, что они одинаково хорошо тестируют все, что есть в сети заказчика, и им не нужны узкие специалисты. При этом ни одного отчета, где был блокчейн, он вспомнить не смог. Это как если бы врач-терапевт утверждал, что готов дать экспертное заключение вместо невролога: дать-то он даст, но, насколько такое заключение окажется компетентным?
Отсутствие блокчейна в составе киберполигонов
Как известно, киберполигоны – это специальные макеты, имитирующие сеть предприятия. На таких полигонах одни специалисты учатся проводить атаки на уязвимое оборудование, а другие – обнаруживать и предотвращать атаки. Некоторые киберполигоны продаются как услуга заказчикам: чтоб их специалисты по защите набрались опыта, необходимого для использования в реальной промышленной сети предприятия.
Основная проблема заключается в следующем: киберполигоны зачастую делают те же компании, которые предоставляют услуги по тестированию на проникновение. И, как уже было показано ранее – специалистов по блокчейну чаще всего в их командах нет. Собственно, и сами элементы блокчейна в киберполигоне найти сложно.
Средства анализа сетевого трафика «не заточены» на атаки на элементы блокчейна
Существуют разные типы решений для защиты от атак на сетевую инфраструктуру компаний: NTA (система анализа трафика), NGFW (межсетевой экран нового поколения), WAF (система защиты веб приложений). Но, все они не заточены под целенаправленные атаки на блокчейн узлы. Например, для блокчейна Hyperldeger Fabric в публичных источниках доступна информация о шести разных типах атак на сетевом уровне. При этом в публичном поле не содержится информации, какое решение для защиты от атак на сетевую инфраструктуру способно их предотвратить. Да, как минимум часть решений технически может быть дополнена информацией о подобных атаках таким образом, чтобы начать их блокировать. Но работу по обновлению данных об атаке обязан кто-то сделать. И этот «кто-то» должен быть в этом компетентен.
Элементы блокчейна – вне списка баг-баунти-программ
Программа Bug Bounty – это программа, предлагаемая некоторыми веб-сайтами и разработчиками программного обеспечения, с помощью которой люди могут получить признание и вознаграждение за нахождение ошибок, особенно тех, которые касаются эксплойтов и уязвимостей. Эти программы позволяют разработчикам обнаружить и устранить ошибки, прежде чем широкая общественность узнает о них, предотвращая злоупотребления. И такие программы уже прочно вошли в жизнь крупных компаний.
Это действительно хороший способ повысить защищенность компаний при помощи независимых исследователей. Проблема в том, что зачастую элементы блокчейна не входят в список багбаунти программ. Т. е. у исследователя, нашедшего возможность остановить бизнес-процесс, нет экономического стимула сообщать об этой проблеме производителю.
Безопасность блокчейна ограничена только смарт-контрактами
Корпоративные блокчейны стали развиваться в основном после популярности общедоступных блокчейнов (вроде Ethereum). По этой причине корпоративные блокчейны начали перенимать и модели угроз открытых блокчейнов. В упрощенном виде вся модель угроз открытых блокчейнов сводилась к смарт-контрактам. Это было обосновано в т. ч. тем, что в открытых блокчейнах очень много узлов (т. е. элементов). И владелец сам заинтересован в поддержании работоспособного каждого узла. И если даже множество узлов выйдут из строя – это будет приемлемо и не скажется на работе всего блокчейна (если только не будет найдена уязвимость на уровне протокола всего блокчейна, которая остановит всю сеть).
Однако этот подход нельзя напрямую переносить в корпоративные блокчейны: в отличие от открытых блокчейнов (где речь идет о тысячах узлов), количество участников в корпоративных блокчейнах сильно ограничено. А это значительно упрощает задачу злоумышленника по выведению из строя блокчейн-сети, организуя атаку на выявленные элементы.
Для примера посмотрим на схему небольшой сети блокчейна Hyperledger Fabric (см. рис. 1).
Рис. 1. Схема сети блокчейна Hyperledger Fabric
Источник: https://hyperledger-fabric.readthedocs.io/ru/latest/network/network.html
Тут представлены:
· С1 – канал,
· P1, P2 – пир-узлы
· O4 – служба упорядочивания
· L1, L2 – копии реестра
· S5 – смарт-контракт
· А1, А2, А3 – приложения
· R1, R2, R4 – организации
· CA (1,2,4) – центры сертификации
И безопасностью всех этих составляющих следует заниматься.
Влияние геополитики
Отметим также, что могут возникать ситуации, когда для трансграничного платежа трафик должен передаваться от узла блокчейна на территории одного государства до узла на территории другого. Тут следует учитывать влияние геополитики: технически такой трафик может быть выделен (на фоне другого трафика) и заблокирован. Мой опыт показывает, что это самый большой вопрос, который труднее всего дается интеграторам блокчейн решений. В основном заблуждения связаны с:
· отсутствием понимания: как можно выделить часть трафика и заблокировать только его;
· верой, что при блокировке одного пути будет работать другой;
· безграничная надежда на VPN, который должен решить все проблемы.
Что такое блокировка части трафика? Тут подойдет прекрасный пример с YouTube в РФ: проблемы с ним возникли почти у всех абонентов проводных провайдеров. А все остальное – работает.
В части обходных путей – все так, но есть нюанс: есть ли путь трафика из РФ на, скажем, Кубу, в обход недружественных стран? Его нет (если не говорить о спутниковых каналах, где всплывает очень много технических нюансов и проблем). Если говорить про VPN – тут самая главная проблема в том, что корпоративные блокчейны «из коробки» его не поддерживают. Т. е. нет никаких гарантий, что внедренный (еще вопрос – кем?) VPN не скажется на работоспособности и сохранении заявленных изначально технических характеристик блокчейна.
Дефицит профильных специалистов по безопасности в области корпоративных блокчейнов
Даже если сосредоточиться только на специалистах по исследованию смарт-контрактов корпоративных блокчейнов, таковых очень мало. Более того: спроса на рынке труда в РФ на них также невелик.
Бывают попытки замены такого специалиста на специалиста по безопасности кода нужного языка смарт-контракта. Например, если смарт-контракт написан на Golang – найти специалиста по анализу кода на Golang. Но это приводит к тому, что проблемы безопасности, специфичные конкретному блокчейн решению, таким специалистом выявлены не будут.
Например, я имел опыт анализа смарт-контрактов для разных блокчейнов. И могу сказать, что даже у разных блокчейнов есть свои особенности. Поэтому взять специалиста по анализу смарт-контракта одного блокчейна и дать ему исследовать смарт-контракт другого блокчейна (при этом не давая возможности изучить особенности нового для него блокчейна) – не самая хорошая идея.
Поэтому все эти вопросы, учитывая дефицит кадров на рынке информационной и кибер- безопасности в России, с каждым днем становятся все более актуальными.
