Атака клонов: исследование форков Биткойна

Адаптированный перевод отчета, опубликованного исследователями из Samsung Research, Технологического института Джорджии (США) и Кембриджского университета.

(За полной версией отчета, включая все библиографические ссылки, обращайтесь к источнику.)

С момента запуска Биткойна в 2009 году появилось уже более 6000 различных криптовалютных проектов. Криптовалюты — возможно, единственная технология, где настолько огромное количество конкурирующих проектов предлагают аналогичные услуги, при этом заявляя о своих уникальных преимуществах, таких как масштабируемость, безопасность и быстрые транзакции.

Но действительно ли эти проекты предлагают уникальные функции и значительные улучшения по сравнению с конкурентами? Чтобы ответить на этот вопрос, мы провели масштабный эмпирический анализ сопровождения кода, оригинальности и безопасности 592 криптовалютных проектов и обнаружили, что около половины из них не обновлялись последние шесть месяцев перед исследованием, а за последние два года около 75% из них прекратили существование либо были объявлены мошенническими.

Мы также проверили форки Биткойна на предмет того, были ли в них исправлены 11 уязвимостей, исправленных в Биткойне за время существования. И обнаружили, что около 80% из 510 проектов на языке C имеют по меньшей мере одну незакрытую уязвимость, а среднее время, затрачиваемое на закрытие одной уязвимости, составляет в них 237,8 дня. Из этих 510 альткойнов, по меньшей мере 157 были созданы путем форка от Биткойна и примерно треть из них содержит лишь незначительные изменения по сравнению с той версией Биткойна, от которой они клонировались.

В качестве практических примеров мы подробно изучили 20 альткойнов (включая Litecoin, FujiCoin и Feathercoin) с высокой степенью сходства их кодовой базы с той версией Биткойна, от которой они были клонированы. Около половины из этих 20 проектов не внесли в клонированный код никаких технически значимых изменений и не выполнили публичных обещаний из собственных уайтпейпер (например, о переходе на proof-of-stake).

Введение

На конец 2021 года более 6000 криптовалют доступны для торговли на рынке и привлекли внимание регуляторов по ценным бумагам. Однако многие криптовалютные проекты либо полностью остановили разработку, либо крайне редко производят какие-либо обновления кода. Хуже того, похоже, что после получения финансирования (особенно через ICO) у многих проектов не наблюдается достаточной мотивации для внедрения обещанного функционала или оперативного устранения уязвимостей, поскольку обычным инвесторам трудно проверить реализацию заявленных функций или анонсированные обновления по коммитам в репозиториях.

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

Коротко наш вклад описывается следующим образом:

Метод

Начнем с описания фреймворка, который мы использовали для:

1. 1. оценки активности сопровождения кодовой базы криптопроектов,
   2. выявления уязвимостей и определения сроков их исправления,
   3. определения степени сходства с родительским проектом.

(Или сразу к результатам.)

Анализ сопровождения кодовой базы проектов

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

Чтобы определить активность сопровождения кодовой базы, мы использовали 32 метрики из GitHub (подробная информация в приложении A), которые можно разделить на три группы:

1. вовлеченности разработчиков,
2. популярности репозитория и
3. обновлений кода.

Для оценки вовлеченности разработчиков мы использовали статистику коммитов, веток, релизов, контрибьюторов репозитория, пулл-реквестов и средней вовлеченности разработчиков.

Популярность проекта оценивали по количеству просмотров репозиториев, добавления в избранное (stars), форков, открытых и закрытых тикетов (issues).

Cтатус обновления кода мы определяли на основе добавлений и удалений строк кода, а также временных интервалов между коммитами. Использовали средние значения и стандартные отклонения от этих показателей за 3, 6 и 12 месяцев для оценки сопровождения кода краткосрочной, среднесрочной и долгосрочной перспективе соответственно.

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

Анализ наличия уязвимостей

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

Мы проверяли исходный код на наличие известных уязвимостей и отмечали, когда каждая из обнаруженных уязвимостей была исправлена. Было бы неэффективно загружать из git-репозиториев все предыдущие версии кодовой базы альткойнов и искать по ним. Общий размер кодовой базы всех предыдущих версий исследуемых криптопроектов составлял более 10,2 ТБ.

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

Анализ сходства кода

Чтобы выявить активное использование чужого кода без добавления нового функционала, мы сравнивали между собой исходный код проектов и измеряли степень их сходства. Скажем, если код проекта П1 имеет высокую степень сходства с кодом проекта П2 и релиз П1 состоялся позже, мы оценивали, была ли значительная часть кода П1 скопирована из П2 без изменений.

Поскольку большинство проектов (надеюсь) обновляются со временем, может быть некорректно определять оригинальность альткойна по отношению к родительскому проекту по сравнению в какой-то один случайный момент времени. Проекты могут показаться очень разными и вследствие доработки родительского проекта, даже если дочерний при этом практически не менялся. Например, код Carboncoin (образован путем форка от Биткойна 8 марта 2014 года) будет сильно отличаться от снапшота кода Биткойна от 4 сентября 2019 года (сходство 33,5%), притом что код Carboncoin был доработан лишь слегка. Объясняется это регулярным обновлением и значительной доработке за тот же период кода Биткойна.

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

Эвристика 1: Если проект образован путем форка исходного проекта, то его история коммитов до форка будет идентична родительскому проекту. Однако после форка история коммитов этих проектов, вероятно, будет отличаться. Поэтому сначала мы определяли, является ли данный проект форком от другого проекта путем сравнения их первых коммитов. Затем искали первое различие в истории коммитов двух проектов и на основе этого определяли момент форка.

Эвристика 2: Мы обратили внимание, что некоторые криптопроекты были созданы через внешнюю загрузку файлов с исходным кодом от другого проекта. Для таких проектов наша первая эвристика не работает, поскольку нет возможности сравнить историю первых коммитов. Но в таких случаях часто можно наблюдать явное одномоментное добавление или обновление наибольшего количества файлов с кодом родительского проекта. Поэтому в таких случаях мы сначала определяли, какой коммит содержит наибольшее количество добавленных файлов и/или изменений. Этот коммит мы отмечали в качестве вероятного момента форка (Пфорк) от родительского проекта (Пориг). Затем мы последовательно вычисляли сходство между кодом Пфорк на момент форка и предыдущими версиями (до форка) исходного кода Пориг, чтобы найти версию Пориг с наибольшим сходством. Дело в том, что проект-форк зачастую может быть образован от более старой версии своего родительского проекта. То есть в принципе нам нужно было бы изучить все предыдущие (до форка) версии Пориг и найти среди них ту, что даст максимальное сходство между Пфорк и Пориг. Однако чтобы снизить вычислительную сложность, мы рассматривали версии только за предыдущие 6 месяцев от гипотетического момента форка. Наконец, если уровень сходства найденного максимально схожего коммита превышал заданное пороговое значение, мы заключали, что проект Пфорк был образован путем форка от Пориг.

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

Набор данных

Первоначально мы отобрали для анализа 1627 криптопроектов, включенных в рейтинг CoinMarketCap на июль 2018 года. Но поскольку нас интересовали исключительно проекты, работающие независимо на собственных блокчейнах, мы не включали в исследование токены ERC-20, ERC-223, ERC-721 и т. п. В итоге мы отобрали 592 криптопроекта (полный список), зарегистрированных как независимые блокчейн-платформы, для которых были доступны официальные URL на GitHub.

Мы начали со списка криптовалют, зарегистрированных на 22 июля 2018, но загрузили для них последнюю версию файлов перед 3 сентября 2019 года. Имея целью изучить долгосрочную (1–2 года) активность по разработке и сопровождению кодовой базы проектов, а также общие для криптопроектов тенденции, мы отобрали проекты, созданные около 2018 года, и проанализировали их данные за следующие 1–2 года.

Кроме того, нам нужна была достоверная информация о выживаемости проектов (т. е. о том, были ли они в конечном счете объявлены мошенническими, неактивными или продолжали функционировать), чтобы исследовать взаимосвязь между активностью по сопровождению кода и некоторой формой достоверной информации о жизнеспособности криптопроектов.

Криптопроекты реализуются на самых разных языках программирования, включая C, Go, Python и Java. Но мы обнаружили, что 511 (86,3%) из отобранных нами 592 криптопроектов были написаны на C либо C++. И поскольку архетипический криптопроект — Биткойн — тоже написан на C/C++, именно на этих 511 проектах мы и сосредоточились в своем анализе наличия уязвимостей и сходства кода.

При этом для анализа сопровождения кода мы использовали статистику всех 592 проектов, поскольку активность сопровождения может быть не особенно связана с базовым языком программирования проекта.

Результаты

Анализ сопровождения кодовой базы криптопроектов

Здесь мы представляем результаты анализа сопровождения кода по методу, описанному выше.

Мы использовали алгоритм кластеризации методом k-средних для классификации 592 криптопроектов на k-группы по активности сопровождения кода, чтобы идентифицировать плохо поддерживаемый код или неактивную разработку проектов. В нашем наборе данных наилучшие результаты кластеризации были получены при k = 4 (см. приложение C). Результаты кластеризации обобщены в таблице 1.

Таблица 1: Результаты кластеризации криптовалют по сопровождению кодовой базы в течение 2018 года. Примеры отобраны по рыночной капитализации.

Ключевые атрибуты результатов кластеризации определяли с помощью поиска по первому наилучшему совпадению. На рис. 1 показаны результаты сравнения кластеров по этим ключевым атрибутам, таким как количество добавленных строк кода и интервал между коммитами.

Кодовая база проектов в кластере 4 регулярно обслуживалась и обновлялась, тогда как проекты в кластерах 1, 2 и 3 редко обновлялись в последние 12, 6 и 3 месяца соответственно. К нашему удивлению, 288 из 592 (48,6%) криптопроектов, включенных в кластеры 1 и 2, не получили ни одного обновления за последние шесть месяцев. То есть около половины криптопроектов из выборки получали плохое сопровождение или вовсе были заброшены.

Чтобы показать актуальность результатов кластеризации, мы сравнили выживаемость проектов в каждом кластере с долей исчезнувших с рынка либо объявленных неактивными или мошенническими проектов. Неактивными мы считали проекты, не включенные в рейтинг CoinMarketCap или с недоступным URL-адресом GitHub-репозитория. Стоит заметить, что криптопроект включается в рейтинг CoinMarketCap только в том случае, если он доступен для торговли на публичной бирже и имеет ненулевой объем торгов. Мы также считали мошенническими проекты из списков Deadcoins и Coinopsy.

Результаты выживаемости представлены в таблице 2 и говорят о том, что всего за два года большинство (59,1%) криптопроектов исчезли с рынка либо были объявлены неактивными или мошенническими.

Таблица 2: Доля неактивных/мошеннических криптопроектов в каждом из кластеров

Кроме того, похоже, что активность сопровождения кодовой базы можно использовать как сигнал о жизнеспособности проекта: кластер часто обновляемых криптопроектов (4-й) имеет наименьшую (38,3%) долю неактивных проектов, тогда как среди редко обновляемых проектов в кластерах 1, 2 и 3 мошенническими или неактивными, по-видимому, являются 76,8%, 74,1% и 62,3% соответственно.

Анализ наличия уязвимостей в коде криптопроектов

Здесь мы представляем результаты анализа уязвимостей в кодовой базе криптопроектов по методу, описанному выше.

Чтобы оценить, насколько оперативно разработчики устраняли уязвимости, для начала мы изучили, были ли исправлены известные уязвимости Биткойна в 510 криптопроектах из нашей выборки. Мы изучили все 39 известных уязвимостей Биткойна с 2011 года (более ранние в данном случае нерелевантны, так как первый альткойн появился в середине 2011 года). Однако из git-сообщений Биткойна мы смогли получить информацию о коде только для 11 уязвимостей (подробнее об этих уязвимостях в приложении D). Для каждой из них мы получили версии исходного кода до и после возникновения уязвимости, что позволило нам извлечь образцы уязвимого и исправленного кода на основе результатов сравнения. Корректность образцов кода проверяли вручную.

Пример исправления уязвимого фрагмента кода для CVE-2013-4627 приведен в приложении E. То, были ли эти 11 уязвимостей надлежащим образом исправлены, мы определяли, основываясь на таких парах фрагментов кода.

Таблица 3: Доля криптопроектов, содержащих уязвимости в кодовой базе

Полученные результаты обобщены в таблице 3 и говорят о том, что в значительном числе криптопроектов часть уязвимостей остаются незакрытыми. 294 (57,7%) криптовалют из нашей выборки уязвимы к CVE-2013-4627, имеющей оценку 5,0 баллов по стандарту Common Vulnerability Scoring System (CVSS). То есть во многих криптопроектах память узлов блокчейна может быть исчерпана намеренно созданными фиктивными транзакциями.

176 (34,5%) криптовалют из выборки уязвимы к CVE-2014-0224 (“CCS Injection”, 5,8 балла CVSS). Эта уязвимость берет начало в OpenSSL, широко используемой криптографической библиотеке с открытым исходным кодом и позволяет выполнять атаки типа man-in-the-middle для перехвата сессий и кражи конфиденциальной информации с помощью специально созданного TLS-подтверждения.

Влияние CCS Injection на криптопроекты может быть довольно ограниченным, поскольку в большинстве реализаций SSL/TLS не используются напрямую в качестве протоколов связи. Однако это показывает, что сопровождение кода — и, вероятно, уровень осведомленности разработчиков в вопросах безопасности — в большинстве криптовалют оставляют желать лучшего, поскольку исправленная версия OpenSSL была выпущена еще в июне 2014 года. В Биткойне этот баг был немедленно исправлен путем обновления OpenSSL.

Что касается реальных угроз безопасности, 149 криптопроектов (29,2%) из выборки оказались уязвимы для атаки Heartbleed (CVE-2014-0160, 5,0 баллов CVSS). Как и в случае CVE-2014-0224, эта уязвимость берет начало в OpenSSL.

113 (22,2%) проектов оказались уязвимы для CVE-2019-6250 (9,0 баллов CVSS). Эта уязвимость связана с ZeroMQ libzmq (известной также как 0MQ), библиотекой высокопроизводительного асинхронного обмена сообщениями. Для некоторых проектов она может быть критичной, поскольку успешный эксплойт может позволить злоумышленнику перезаписать произвольное количество байтов за пределами буфера, что можно использовать для запуска произвольного кода в целевой системе.

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

Отметим, что наиболее серьезные уязвимости — CVE-2014-0224, CVE-2014-0160 и CVE-2019-6250 — представляют собой уязвимости в сторонних библиотеках, импортируемых в криптопроекты. И учитывая, что использование сторонних библиотек стало обычной практикой в индустрии криптовалют, важно поддерживать их в актуальном состоянии. Ведь известно, что они зачастую могут содержать серьезные ошибки.

По таблице 3 видно, что ни один из исследуемых криптопроектов не содержал уязвимостей CVE-2012-1909 [24], CVE-2012-3789 [27], CVE-2012-1910 [25] и CVE-2012-2459 [26], обнаруженных в 2012 году. Мы полагаем, что причина состоит в том, что все изученные нами криптопроекты, кроме 24, были образованы путем форка после июня 2012.

Мы также подсчитали количество уязвимостей, оставшихся в каждом из исследуемых криптопроектов. Эти данные суммированы в таблице 4: по меньшей мере одну известную уязвимость имеют 411 (80,6%) из 510 проектов.

Таблица 4: Доли неактивных/мошеннических проектов и количество обнаруженных уязвимостей в исследуемых криптопроектах

Чтобы убедиться, коррелирует ли выживаемость этих альткойнов с количеством найденных в них уязвимостей, мы проанализировали долю неактивных/мошеннических проектов с незакрытыми уязвимостями способом, описанным в предыдущем разделе. Результаты представлены в таблице 4 и, по-видимому, подтверждают, что количество уязвимостей действительно коррелирует с жизнеспособностью проектов. 84,0% альткойнов с 4 и более уязвимостями исчезли с рынка либо были объявлены мошенническими или неактивными, в то время как среди проектов без уязвимостей эта участь постигла 54,5%.

Чтобы оценить время, требовавшееся разработчикам альткойнов для исправления 11 анализируемых уязвимостей, мы вычисляли время, прошедшее между (а) моментом, когда исправление выпускал Биткойн, и (б) когда альткойны применяли этот патч к своему коду.

На рис. 2 показаны медианные и средние значения времени на исправление, которые составили 16 и 237,8 дней (со стандартным отклонением 453,6 дня). Большой разрыв между медианным и средним значениями говорит о том, что около половины уязвимостей были исправлены довольно быстро — 56,6% в течение 16 дней после выпуска соответствующего патча в Биткойне, — тогда как исправление остальных заняло недели, месяцы и даже годы.

Чтобы подтвердить подразумеваемую взаимосвязь между активностью сопровождения кодовой базы и устранением уязвимостей, мы сравнивали количество оставшихся в каждом проекте уязвимостей между кластерами 1, 2, 3 и 4. Для кластера 1 медианное и среднее значения составили 2,0 и 1,80 соответственно (со стандартным отклонением 1,20); для кластера 2 — 1,5 и 1,73 (стандартное отклонение 1,30); для кластера 3 — 1,0 и 1,28 (стандартное отклонение 1,09); для кластера 4 — 1,0 и 1,60 (стандартное отклонение 0,98). Вывод: между четырьмя кластерами существует статистически значимая разница (р < 0,0002, критерий Краскела – Уоллиса).

Анализ сходства кода

Здесь мы представляем результаты анализа сходства исходного кода криптопроектов по методу, описанному выше.

Анализ сходства между альткойнами и Биткойном

Чтобы определить, добились ли альткойны значительных улучшений по сравнению с родительским проектом, мы сосредоточились на Биткойне и производных от него криптовалютах, поскольку многие альткойны позиционировались на рынке как устраняющие те или иные ограничения Биткойна. А значит, такой анализ имеет определяющее значение для оценки не только способности криптопроектов к качественному сопровождению собственной кодовой базы, но и в целом обоснованности их создания, а также правдивости риторики, используемой в их продвижении.

Для определения производных от Биткойна криптопроектов и времени их форка мы использовали эвристические правила, описанные выше. При использовании эвристики 2, чтобы определить, является ли проект форком от Биткойна, мы использовали порог сходства 92,9%. Это значение было получено исходя из среднего показателя сходства (99,4%) между Биткойном и его альткойнами минус три стандартных отклонения (6,5%), полученных с помощью эвристики 1. В эвристике 2, если показатель сходства между кодом альткойна и использованной в форке версией Биткойна превышает 92,9%, мы предполагали, что альткойн является форком Биткойна, даже если его репозиторий не был «форкнут» явным образом через GitHub.

Мы обнаружили, что из 510 исследуемых криптопроектов, 157 по заданным критериям являются форками Биткойна. Из этих альткойнов, 154 к началу исследования запустили «мэйннеты», один ещё находится в фазе тестовой сети, статус еще двух мы не можем с уверенностью определить.

127 альткойнов были определены по эвристике 1, 30 — по эвристике 2. В таблице 5 представлена суммарная статистика для этих проектов по степени сходства кода. Видно, что из этих 157 альткойнов, по-видимому, образованных путем форка от Биткойна, около трети по-прежнему имеют 90% и более сходства кода с исходной версией Биткойна.

Таблица 5: Доли неактивных/мошеннических криптопроектов и суммарные результаты анализа сходства кода

Чтобы убедиться в корректности определения проектов-форков по нашим эвристическим правилам, мы сравнили полученный список со списком известных «прямых потомков» Биткойна. Из 175 криптовалют, активных на декабрь 2017 года, мы выбрали для проверки 68, включенных в наш набор данных (далее будем называть их «известным списком»). Большая часть оставшихся проектов уже не функционировали на момент начала сбора данных (22 июня 2018). Для объективного сравнения, среди 157 криптовалют, идентифицированных по нашему методу как форки Биткойна, мы также рассмотрели 139 тех, что были форкнуты до декабря 2017 года (далее — «наш список»).

Сравнив наш список с «известным», мы обнаружили пересечение всего в 33 проекта. То есть по нашему методу мы идентифицировали дополнительные 106 проектов, ведущих родословную от Биткойна и отсутствующих в «известном списке». Однако наш метод не определил как форки оставшиеся 35 альткойнов из известного списка. Проверив эти кейсы вручную, мы обнаружили, что эти альткойны были образованы путем внешней загрузки в репозиторий старых версий Биткойна под видом новых файлов. Хотя наша эвристика 2 и предназначена для обнаружения таких случаев, она тоже может давать ложноотрицательные результаты, поскольку из соображений производительности в ней проверяются не все старые версии Биткойна. Об этом ограничении мы подробно рассказываем ниже.

На рис. 3 показана кумулятивная функция распределения (синяя пунктирная линия) значений сходства кода между Биткойном и производными от него криптовалютами. Только 6 (3,8%) из 157 криптопроектов, образованных путем форка от Биткойна, имеют 90% и более сходство кода с последней версией Биткойна. Но из этих результатов еще нельзя сделать вывод о том, что альткойны заметно изменились со временем, поскольку значительные изменения претерпел и сам Биткойн.

Поэтому, чтобы определить, насколько альткойн-форк изменился по сравнению с Биткойном, мы рассчитали показатель сходства между последней версией исходного кода альткойн-форка и версией Биткойна на момент форка. Функция распределения значений для такого сравнения показана на рис. 3 сплошной красной линией. Среди 157 проектов-форков, 21,7% пар имеют сходство кода 95% и более; 33,8% пар — 90% и более; 42% пар — 80% и более; 60,5% пар — 60% и более.

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

Чтобы подтвердить релевантность анализа сходства кода, мы проанализировали взаимосвязь между значениями сходства кода и выживаемостью проектов. Как показано в таблице 5 выше, проекты с высокими показателями сходства кода с наибольшей вероятностью исчезнут с рынка либо будут объявлены мошенническими или неактивными: эта участь постигла 70,6% альткойнов со сходством кода 95% и более, по сравнению с 41,9% альткойнов со сходством менее 50%.

Практические примеры

Чтобы определить альткойны, не реализовавшие публично заявленные уникальные функции, мы исследовали исходный код и содержание уайтпейпер для 20 альткойнов, имеющих наибольшее сходство с родительской версией Биткойна (см. приложение F).

Из этих альткойнов, MinCoin (MNC), GapCoin (GAP), Litecoin (LTC) (дата первого форка — 13 октября 2011, но старый проект был заброшен, и 13 августа 2018 был сделан новый форк под тем же названием), Platincoin (PLC), Florincoin (FLO), MinexCoin (MNX), Riecoin (RIC), Fujicoin (FJC), Feathercoin (FTC), Octocoin (888) и Uniform Fiscal Object (UFO) — все они представляют собой варианты Биткойна с небольшими изменениями в используемых для proof-of-work криптографических алгоритмах и базовых параметрах работы сети (объем эмиссии, интервал между блоками и т. п.).

Uniform Fiscal Object часто обновлялся — в среднем каждые 0,1 дня. По этому признаку он отнесен к 4 кластеру. Однако большая часть изученных нами коммитов содержат изменения в комментариях к коду, иконках, блоке генезиса и общем объеме эмиссии. Единственным обнаруженным нами значимым изменением в коде проекта была замена хеш-функции SHA-256 на NeoScrypt.

Остальные девять криптопроектов тоже не содержат каких-либо существенных изменений кода. А самые частые модификации касались просто смены названия криптовалюты. Например, Acoin — это копия с Биткойна, в которую после форка не было добавлено вообще никаких заметных изменений. Единственные изменения, которые мы смогли определить, это замена “bitcoin” на “acoin” в некоторых фрагментах кода (см. рис. 4).

Еще большее беспокойство внушает то, что шесть криптопроектов не реализовали должным образом функции, публично заявленные создателями в уайтпейпер проектов. Например, согласно уайтпейпер (PDF) проекта Block Array (ARY), он был создан для облегчения разработки логистических протоколов. В документе также была представлена дорожная карта проекта со сроками реализации различных этапов до 2020 года. Но в репозитории Block Array мы обнаружили всего два коммита: один — с загрузкой файлов Биткойна, второй — создание README.md 29 декабря 2017 года. Block Array просто переиспользовал исходный код Биткойна без каких-либо изменений и в уайтпейпер проекта это никак не объясняется. Даже официальный сайт проекта попросту недоступен.

Наконец, шестнадцать проектов исчезли с рынка либо к сентябрю 2021 года были объявлены мошенническими или неактивными. Половина из них уже были известным как мошеннические: GapCoin, Freicoin, PLNcoin, MinexCoin, Riecoin, SecureCoin и OctoCoin были отмечены как скам на Coinopsy, а Betacoin, Freicoin, PLNcoin, MinexCoin, Riecoin, FujiCoin, SecureCoin и Uniform Fiscal Object имели аналогичную отметку на Deadcoins.

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

Обсуждение

Является ли крипторынок в целом «рынком лимонов»?

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

Мы обнаружили, что команды нескольких проектов (например, Block Array и Acoin), сосредоточились исключительно на создании красивых уайтпейпер и вебсайтов, а не реализации обещанного функционала. А наивные инвесторы могут быть неспособны отличить такие проекты-однодневки от качественных и системно поддерживаемых.

Чтобы проанализировать взаимосвязь между ценой альткойна и качеством его кода, мы рассчитали коэффициенты корреляции между рыночной капитализацией криптопроектов (количество монет в обращении, помноженное на цену) и их активностью в сопровождении кода, безопасностью и оригинальностью кода соответственно. Результаты показали, что корреляция между капитализацией и активностью сопровождения кодовой базы проекта отсутствует (r = 0,05, p = 0,44). Выявить корреляцию между капитализацией и уровнем сходства кодовой базы проектов с исходной версией Биткойна тоже не удалось (r = 0,11, p = 0,29). Однако количество уязвимостей в коде проекта имело слабую отрицательную корреляцию с капитализацией (r = 0,14, p < 0,05). Эти результаты показывают, что качество кода альткойнов зачастую никак не связано с его рыночной стоимостью: низкое качество кода не обязательно означает, что альткойн стоит сравнительно дешево, и наоборот.

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

Ограничения исследования

Угрозы достоверности

Одна из угроз внешней достоверности заключается в том, достаточно ли репрезентативные криптопроекты были отобраны для исследования. Некоторая предвзятость могла быть допущена, поскольку на предмет уязвимостей и оригинальности кода мы анализировали только проекты на языке C. Но надо заметить, что большинство отобранных криптопроектов (86,3%) были написаны на C/С++.

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

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

Определение точек восстановления

Чтобы определить дату форка того или иного проекта, мы разработали две эвристики. Однако наши методы могут не выявить факт форка или не определить точного его времени, если старая версия Биткойна загружается в репозиторий как новые файлы, вместо использования кнопки Fork на GitHub. Решить эту проблему можно было бы сравнением кода со всеми прошлыми версиями исходного проекта.

Анализ активности сопровождения кода по сообщениям в Git

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

Мы обнаружили, что 22 проекта в кластере 4, несмотря на частые обновления, сохраняют чрезвычайно высокое сходство кода (90% и более) с родительским проектом. Мы предполагаем, что в таких проектах разработчики могут периодически загружать бессмысленный код и добавлять необязательные комментарии, чтобы создать иллюзию активной работы над проектом.

Заключение

Многие альткойны были заброшены разработчиками или изначально были мошенническими проектами. Тем не менее люди продолжают ими торговать, пользоваться и даже инвестировать в эти монеты. Для расследования масштабных злоупотреблений нужны масштабируемые инструменты анализа. Поэтому мы создали полуавтоматический фреймворк для проверки уровня сопровождения кодовой базы и наличия известных уязвимостей в коде альткойнов.

Наш анализ показал, что многие альткойны не сопровождаются должным образом или вовсе заброшены, не реализуют функции, заявленные публичных меморандумах и дорожных картах проектов и даже не выпускают патчи на известные уязвимости. Около половины из исследованных нами 592 проектов не получали обновлений в последние шесть месяцев перед исследованием. Около трети проектов, образованных путем форка от Биткойна, имеют уровень сходства кода 90% и более с версией Биткойна, форком от которой они создавались. Но самое тревожное: более 80% из 510 проанализированных на предмет этого криптопроектов имеют по меньшей мере одну незакрытую известную уязвимость.

Если рынок альткойнов должен стать в меньшей степени «рынком лимонов», то участникам рынка нужны более эффективные способы сравнения оригинальности, жизнеспособности и безопасности проектов. И отчеты о систематическом анализе кода, подобные нашему, мы считаем необходимым первым шагом на этом пути.

Приложение

A. Показатели, использованные для оценки усилий по сопровождению кодовой базы проектов

В таблице 6 приведен список показателей, которые можно собрать из проекта на GitHub и использовать для оценки усилий по сопровождению кодовой базы. Мы разделили 32 показателя на 3 группы по их характеристикам.

Таблица 6: Список показателей сопровождения кодовой базы. Мы устанавливали k = 3, 6 и 12 мес. для показателей обновления кода, чтобы оценить соответственно краткосрочную, среднесрочную и долгосрочную активность по обновлению кодовой базы проектов.

В отличие от других показателей уровня вовлеченности разработчиков, MDE (средний уровень их вовлеченности) нельзя получить напрямую из GitHub, но его можно рассчитать исходя из количества контрибьюторов за тот или иной период времени. MDE был введен нашими коллегами в их исследованиях как показатель того, насколько эффективно (в среднем) проект с открытым исходным кодом использует доступные человеческие ресурсы. Он рассчитывается по следующему уравнению:

где n — это количество периодов, а contributori — количество уникальных контрибьюторов, совершавших коммиты в период времени i. Например, если количество контрибьюторов равно 6 для первого периода времени, 3 для второго, 6 для последнего, а общее количество уникальных контрибьюторов равно 12, то MDE равен 0,41, так как (6/12 + 3/12 + 6/12) / 3 ≈ 0,41.

B. Процесс анализа уязвимостей

Процесс обнаружения уязвимостей состоял из двух этапов.

1. Мы загружали для проверки из Git новейшую версию исходного кода криптопроекта, удаляли все пробелы и с помощью алгоритма сопоставления строк искали фрагменты кода, связанные с определенной уязвимостью. Найдя совпадение, помечали проект как открытый для этой конкретной уязвимости и завершали процесс — наличие уязвимого кода указывает на то, что исправления кода для ее закрытия в проекте выпущено не было. Если поиск такого совпадения не давал, мы заключали, что данная уязвимость в проекте не существовала либо уже была исправлена и переходили к шагу 2 для определения времени добавления уязвимого и исправленного кода соответственно.
2. Загружали история добавления и удаления строк кода из репозитория проекта на GitHub. Сначала проверяли, присутствовал ли ранее в проекте уязвимый код, используя результат diff для исходного кода до и после коммита. Однако GitHub не предоставляет информации об изменениях кода при изменении в одном коммите более чем 30 файлов. Поэтому в таких случаях мы загружали полную версию исходного кода для коммита и проводили поиск по нему. Найдя уязвимый фрагмент кода, регистрировали время его добавления и таким же образом выполняли поиск соответствующего исправления. Найдя соответствующий патч, регистрировали время его добавления. Не обнаружив в репозитории уязвимый фрагмент кода, мы предполагали, что проект либо был скопирован с версии Биткойна, где уязвимости уже были исправлены, либо код с соответствующей уязвимостью не был включен в код проекта с самого начала и до момента исследования.

Мы считаем, предложенный нами метод более эффективным, нежели сплошной поиск интересующего фрагмента кода во всех предыдущих версиях исходного кода того или иного альткойна. Для примера, в случае Carboncoin, загрузка и проверка всех предыдущих версий исходного кода проекта заняла около 18,1 секунды, а поиск по нашему методу — всего около 0,024 сек., в ~754,2 раза эффективнее, нежели «наивный» сплошной поиск.

C. Выбор k в кластеризации методом k-средних

Для реализации алгоритма кластеризации методом k-средних мы использовали Weka, широко используемую платформу машинного обучения. Для интерпретации и проверки согласованности внутри кластеров данных можно использовать коэффициент силуэта. Коэффициент силуэта рассчитывается по следующему уравнению:

где a(i) — это среднее расстояние кластера i и всех остальных точек данных в том же кластере, а b(i) — это наименьшее среднее расстояние кластера i до всех точек в любом другом кластере, к которому i не принадлежит. Если значение коэффициента близко к 1, значит, кластеры хорошо кластеризованы.

Чтобы определить оптимальное количество кластеров, мы вычисляли коэффициенты силуэта для результатов кластеризации, варьируя k в диапазоне от 2 до 20. На рисунке 5 показаны результаты коэффициента силуэта для алгоритма кластеризации методом k-средних. Поскольку алгоритм кластеризации дал наилучшее значение силуэта при k = 4, мы разделили проекты на две группы.

D. 11 распространенных уязвимостей

В таблице 7 приведены 11 распространенных уязвимостей (CVE), рассматриваемых в нашем исследовании.

Таблица 7: 11 уязвимостей Биткойна, рассматриваемых в этой работе. Common Vulnerability Scoring System (CVSS) — наиболее широко используемый стандарт для количественной оценки серьезности уязвимостей в системах безопасности.

E. Исправление фрагмента кода, уязвимого для CVE-2013-4627

Приведем пример уязвимого и исправленного фрагментов кода для CVE-2013-4627, уязвимости, связанной с возможностью проведения DoS-атаки (см. рис. 6). В исправленном коде были удалены строки, помеченные «-«, и добавлены строки, помеченные «+».

Когда биткойн-узел получает сообщения о транзакциях, транзакции должны временно храниться в памяти MapReplay узла, даже если они недействительны. Таким образом, сообщения, содержащие большое количество данных фиктивных транзакций, можно использовать для намеренного исчерпания памяти биткойн-узлов. Чтобы митигировать эту атаку, каждый биткойн-узел должен проверять, превышает ли размер полученных данных транзакции заданное пороговое значение (напр., 5000 байт), чтобы избежать крупных транзакций.

В уязвимом коде (см. удаленные в исправлении строки, выделенные красным) размер полученных данных транзакции может напрямую получен непосредственно из поля принятого сообщения vMsg. Следовательно, процедуру проверки размера сообщения можно обойти, присвоив полю размера сообщение произвольное небольшое значение (напр., менее 5000 байт), даже если фактические размеры содержащихся в сообщении транзакций значительно его превосходят. Чтобы устранить эту проблему, в исправленном коде (см. добавляемые строки, выделенные зеленым) узел сравнивает со своим пороговым значением фактические размеры транзакций, вычисленные с помощью GetSerializeSize.

F. Топ-20 альткойнов, имеющих наибольшее сходство с использованной для форка версией Биткойна

В таблице 8 приведена краткая информация о топ-20 альткойнах, имеющих наибольшее сходство с той версией Биткойна, форком от которой они были образованы. Интересно, что 7 (35%) из 20 альткойнов относятся при этом к кластеру 4, то есть к проектам с часто обновляемой кодовой базой.

Таблица 8: Краткая информационная сводка о топ-20 альткойнов, имеющих наибольшее сходство с той версией Биткойна, форком от которой они были образованы.

ID – здесь номер кластера, к которому относится проект согласно результатам кластеризации. «Капитализация (ранг)» — рыночная капитализация (и место в рейтинге) по состоянию на сентябрь 2021; «–» означает, что альткойн был исключен из рейтингов CoinMarketCap. «Схожесть (форк)» — уровень сходства кода между новейшей версией альткойна и той версией Биткойна, форком от которой он был образован. «Длительность» – это время, прошедшее между моментом форка и 3 сентября 2019 г. «Функции в уайтпейпер» — ключевые функции, прописанные в уайтпейпер каждого криптопроекта. «Кол-во коммитов» — количество коммитов после форка. «Кол-во уязв.» — количество неисправленных уязвимостей. «Дата посл. коммита» — дата последнего коммита на момент проведения исследования. R1 — указывает на наличие изменений в криптографических алгоритмах и значениях параметров политики. R2 — указывает на отсутствие существенных изменений. R3 — указывает на отсутствие в проекте кода, реализующего ключевые функции, указанные в уайтпейпер криптопроекта.

На основе источника

Источник: bitnovosti.com