О чем статья
Обсуждаем проблемы безопасности финансовых решений на базе блокчейн-технологий. Рассмотрим распространенные заблуждения и факторы риска, связанные с корпоративными блокчейнами.
Мне довелось пообщаться с рядом разработчиков и исследовать архитектуру некоторых корпоративных блокчейнов. В процессе я часто сталкивался с устоявшимися заблуждениями и выделил ряд проблем, а также факторов риска, характерных для большинства корпоративных решений.
До 500 млрд. руб. вырастет российский рынок ЦФА в ближайшие три года.
11 компаний включены реестр операторов ИС, в которых осуществляется выпуск ЦФА. Большинство из них используют для этого блокчейн-технологии.
Нежелание разработчиков признавать проблемы
Свежая история из личного опыта: я обнаружил уязвимость в блокчейне Hyperledger Fabric и обратился к разработчикам через HackerOne. Они выпустили исправление, но не стали присваивать багу CVE-идентификатор. В итоге я самостоятельно добился его назначения (CVE-2024-45244), хотя разработчики попытались это оспорить (не удалось). Их позиция понятна: все работает, инцидентов не было, значит и проблемы как таковой нет. Проще говоря, доказывать что либо здесь бесполезно — нужно заниматься назначением CVE.
Отмечу, что сейчас исправление недоступно для стабильных версий (фикс присутствует только в ветке main), при этом разработчики так и не проинформировали пользователей об уязвимости (в списке не значится). Не нашел я и рекомендаций: что делать тем, кто использует версию без исправлений? Некоторые разработчики считают, будто только они вправе определять, что является уязвимостью, а что нет. По сути, они игнорируют сложившуюся практику взаимодействия исследователей безопасности с MITRE.
А теперь давайте представим: сколько потенциальных отчетов об уязвимостях уже отклонили разработчики? И все ли авторы таких отчетов не растерялись и довели дело до присвоения багам статуса CVE?
Неадаптированная модель угроз
Часто встречаю мнение, что у корпоративных и открытых блокчейнов одинаковые проблемы в части кибербезопасности. При этом даже профильные специалисты нередко считают, что все внимание нужно уделять смарт контрактам (они становятся целью большинства атак), а сам блокчейн безопасен, раз столько времени работает и до сих пор жив.
Проблема в том, что если в открытых блокчейнах и появляются небольшие ошибки, их быстро исправляют. Кроме того, они могут состоять из тысяч узлов — даже если некоторые элементы выйдут из строя, это не скажется на работе всей системы. В свою очередь, в корпоративных блокчейнах количество узлов сильно ограничено. Это упрощает задачу злоумышленнику: можно организовать атаку на выявленные элементы и тем самым вывести из строя весь блокчейн.
В качестве примера рассмотрим схему Hyperledger Fabric (см. рис. 1).
На рисунке представлены: С1 — канал; P1, P2 — пир-узлы; O4 — служба упорядочивания; L1, L2 — копии реестра (т. е. база данных); S5 — смарт контракт; А1, А2, А3 — приложения; R1, R2, R4 — организации; CA (1, 2, 4) — центры сертификации и др.
Я нашел в открытом доступе разные элементы Hyperledger Fabric: пиры, службы упорядочивания, даже базы данных (в том числе устаревших версий). Что мешает злоумышленникам воспользоваться этими данными и провести атаку на компанию, использующую Hyperledger Fabric? Раз уж речь идет о конечном количестве узлов, взаимодействующих друг с другом, как минимум стоит подумать о списке доступа (ACL). А если вам сложно поддерживать его в актуальном состоянии, можно воспользоваться динамическим вариантом.
Пентестеры игнорируют блокчейн
Когда крупные компании заказывают пентесты, они полагают, что раз элементы блокчейна находятся внутри тестируемой сети, то и их уязвимости будут отображены в отчете. В этом заключается главная ошибка бизнеса: вполне возможно, у исполнителей просто нет компетенций в блокчейне (особенно в сетевой его части), поэтому они ничего и не находят.
Расскажу забавную историю. Я проходил собеседования в нескольких крупных компаниях, специализирующихся на пентестах. Руководители отделов часто говорили, что не встречали элементов блокчейна в своих проектах, хотя мы обсуждали инфраструктуру компаний, в которых они точно есть (я сам находил их в интернете). Один из собеседников все-таки признался, что блокчейн-сервис, о котором я рассказывал, просто не попал в отчет, потому что «мы вообще не поняли, что это». При этом атака на него потенциально может привести к остановке бизнес‑процесса.
В другой компании мне сказали, что у них принято одинаково хорошо тестировать все элементы сетей заказчиков, поэтому выделенные блокчейн-специалисты им не нужны. При этом ни одного отчета, в котором фигурировали бы блокчейн-уязвимости, он не вспомнил... Это как если бы терапевт сказал, что готов дать экспертное заключение за невролога. Дать‑то он даст, но насколько оно будет экспертным :)
Отсутствие блокчейна в составе киберполигонов
Киберполигоны — это макеты, имитирующие инфраструктуру компаний из разных отраслей. С их помощью одни специалисты учатся проводить атаки, а другие — обнаруживать и предотвращать. Так безопасники получают навыки, необходимые им в повседневной работе.
Проблема в том, что зачастую киберполигоны разрабатывают те же компании, которые предоставляют услуги по тестированию на проникновение. Как мы уже выяснили, специалистов по блокчейну в них обычно нет, поэтому и элементы блокчейна на киберполигонах найти сложно. Руководитель одной крупной российской платформы честно признался мне, что никогда не сталкивался ни с блокчейном, ни с интересом заказчиков к этой теме.
Современные СЗИ не заточены под атаки на блокчейн-узлы
В первую очередь речь идет об NTA, NGFW, WAF и других средствах контроля и анализа сетевого трафика. В публичном доступе можно найти информацию о шести способах проведения сетевых атак на тот же Hyperldeger Fabric, а как их предотвратить — неизвестно. Как минимум стоит дополнить указанные выше СЗИ данными о подобных угрозах, чтобы фиксировать и блокировать их. Но эту работу должен кто то сделать, и этот кто то должен быть компетентен в блокчейне.
Блокчейн не входит в программы багбаунти
Багбаунти — хороший способ повысить защищенность компании за счет независимых исследователей. Проблема в том, что элементы блокчейна зачастую не входят в состав таких программ, а значит, у исследователей просто нет стимула (читай: финансовой мотивации) погружаться в это направление и сообщать о проблемах.
Нехватка компетентных специалистов
Причин здесь несколько, например:
- Кадровый голод в сочетании с низким спросом на профильных специалистов (эдакий оксюморон).
- Нехватка обучающих ресурсов по защите блокчейна (в основном встречаются курсы по безопасности смарт‑контрактов).
- Неверные ожидания работодателей от кандидатов.
- Нехватка профильных конференций и площадок для обмена опытом.
Как результат, на рынке мало специалистов с практическим опытом защиты элементов блокчейна, отличных от смарт контрактов. Для наглядности я провел опрос (см. рис. 2) в закрытой группе Stronghold: чтобы в нее вступить, нужно пройти курсы по безопасности смарт контрактов MixBytes Farm.
Оказалось, что всего один человек нашел в блокчейне уязвимость, которой присвоен номер CVE, и это был я :) Почти треть вообще не знает, что такое CVE...
***
На мой взгляд, ситуация с безопасностью корпоративных блокчейнов во многом повторяет кейс с безопасностью промышленных устройств: сначала интереса не было, а потом грянул Stuxnet и все резко вспомнили про ИБ. Компаниям, заинтересованным в комплексной безопасности блокчейн-сетей, есть о чем подумать...