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

Адаптированный перевод результатам.)

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

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

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

вовлеченности разработчиков,



популярности репозитория и



обновлений кода.

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

Популярность проекта оценивали по количеству просмотров репозиториев, добавления в избранное (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 месяцев от гипотетического момента форка. Наконец, если уровень сходства найденного максимально схожего коммита превышал заданное пороговое значение, мы заключали, что проект Пфорк был образован путем форка от Пориг.

Сходство кода мы оценивали с помощью системы выше.

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

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

ID



#



Примеры



Свойства



1



207



DGB, LSK, XZC, LBC, GAP



редко обновлялись в последние 12 месяца



2



81



RDD, FST, TTC, MOON, SUMO



редко обновлялись в последние 6 месяцев



3



61



XEM, SC, PZM, UNO, SLS



редко обновлялись в последние 3 месяца



4



243



BTC, ETH, XRP, LTC, ADA



часто обновлялись во все периоды

Ключевые атрибуты результатов кластеризации определяли с помощью выше.

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

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

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

ID уязвимости



Тип



CVSS



Количество (%)



CVE-2012-1909



DoS



5,0



0 (0,0%)



CVE-2012-3789



DoS



5,0



0 (0,0%)



CVE-2012-1910



DoS, исполняемый код



7,5



0 (0,0%)



CVE-2012-2459



DoS



5,0



0 (0,0%)



CVE-2014-0160



Переполнение, получение информации



5,0



149 (29,2%)



CVE-2013-4627



DoS



5,0



294 (57,7%)



CVE-2013-4165



Получение информации



4,3



43 (8,4%)



CVE-2014-0224



Получение информации



5,8



176 (34,5%)



CVE-2018-12356



Исполняемый код



7,5



0 (0,0%)



CVE-2018-17144



DoS



5,0



27 (5,3%)



CVE-2019-6250



Исполняемый код, переполнение



9,0



113 (22,2%)

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

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

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

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

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

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

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

Сходство кода



Количество (%)



Не представлены на CoinMarketCap



Не представлены на GitHub



Coinopsy



Deadcoins



Всего



≥ 95%



34 (21,7%)



16 (47,1%)



0 (0,0%)



12 (35,3%)



11 (32,4%)



24 (70,6%)



≥ 90%



53 (33,8%)



25 (47,2%)



0 (0,0%)



17 (32,1%)



17 (32,1%)



38 (71,7%)



≥ 80%



66 (42,0%)



31 (47,0%)



1 (1,5%)



19 (28,8%)



17 (25,8%)



46 (69,7%)



≥ 60%



95 (60,5%)



36 (37,9%)



1 (1,1%)



24 (25,3%)



22 (23,2%)



57 (60,0%)



< 50%



43 (27,4%)



11 (25,6%)



1 (2,3%)



10 (23,3%)



5 (11,6%)



18 (41,9%)



Всего



157 (100,0%)



52 (33,8%)



4 (2,5%)



36 (22,9%)



29 (18,5%)



82 (52,2%)

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

приложение 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 кластеру. Однако большая часть изученных нами коммитов содержат изменения в комментариях к коду, иконках, блоке генезиса и общем объеме эмиссии. Единственным обнаруженным нами значимым изменением в коде проекта была замена хеш-функции практических примеров. Чтобы определить альткойны, не реализовавшие заявленные в своих уайтпейпер функции, нам пришлось вручную просмотреть эти уайтпейпер. Чтобы свести предвзятость к минимуму, три исследователя по отдельности прочитали все уайтпейпер, определили требования к реализованному функционалу и проверили исходный код на соответствие этим требованиям. После независимого проведения такого анализа авторы обсудили сделанные выводы, пока не пришли к консенсусу.

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

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

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

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

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

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

Заключение

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

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

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

Приложение

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

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

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

Группа



Показатель



Описание



5 показателей уровня вовлеченности разработчиков (k = 3, 6 и 12 мес.)



Commits



Создание коммитов — одно из наиболее частых действий разработчика при использовании GitHub. Коммит — это как «сохранение» обновленного состояния файла в папку назначения.



Branches



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



Releases



Релизы — это способ GitHub упаковывать и доставлять ПО пользователям.



Contributors



Контрибьютор — это тот, кто внес свой вклад в проект в виде принятого и «замёрдженного» пулл-реквеста, но не имеет доступа уровня соавтора к репозиторию.



Pull requests



Пулл-реквест — это внесенное пользователем предложение по изменению кода проекта. Администраторы репозитория могут это предложение принять или отклонить. Как и issues (задачи, ожидающие решения), пулл-реквесты имеют собственный форум для обсуждения предлагаемых изменений кода.



MDE (n = k)



MDE (n = k) — это метрика средней вовлеченности разработчиков (от Mean Developer Engagement), указывающая на среднее количество контрибьюторов в каждый k период в течение 12 мес.



6 показателей популярности репозитория



Watch



«Следить» за репозиторием означает, что пользователь получает уведомления всякий раз, когда в код репозитория вносятся какие-либо изменения. Значение Watch — это количество пользователей, которые подписались на отслеживание изменений в проекте.



Star



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

Другие пользователи могут просматривать репозитории или темы, добавленные вами в избранное, перейдя на соответствующую страницу в вашем профиле.



Fork



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



Issues



Issues — это предложенные, но пока нереализованные задачи, связанные с репозиторием. «Ишьюсы» могут создаваться кем угодно и модерируются администраторами репозитория.



Open Issues



Открытые issues = количество актуальных «ишьюсов». Если разработчик считает, что задача решена, он закрывает соответствующий ишью.



Closed Issues



Закрытые issues = количество решенных «ишьюсов».



21 показатель обновлений кодовой базы

(k = 3, 6 и 12 мес.)



Ср. кол-во добавлений в k мес.



Среднее количество добавленных строк кода за последние k месяцев.



Ст. кол-во добавлений в k мес.



Стандартное отклонение для добавленных строк за последние k месяцев.



Ср. кол-во удалений в k мес.



Среднее количество удаленных строк кода за последние k месяцев.



Ст. о. для удалений в k мес.



Стандартное отклонение для удаленных строк за последние k месяцев.



Ср. интервал между коммитами за k мес.



Средний интервал времени между коммитами за последние k месяцев.



Ст. о. для интервала между коммитами за k мес.



Стандартное отклонение для интервалов между коммитами за последние k месяцев.

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

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

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

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

Мы загружали для проверки из Git новейшую версию исходного кода криптопроекта, удаляли все пробелы и с помощью алгоритма сопоставления строк искали фрагменты кода, связанные с определенной уязвимостью. Найдя совпадение, помечали проект как открытый для этой конкретной уязвимости и завершали процесс — наличие уязвимого кода указывает на то, что исправления кода для ее закрытия в проекте выпущено не было. Если поиск такого совпадения не давал, мы заключали, что данная уязвимость в проекте не существовала либо уже была исправлена и переходили к шагу 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, мы разделили проекты на две группы.

Рисунок 5: Значения силуэта при k от 2 до 20

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

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

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

CVE-ID



Описание



CVSS



CVE-2012-1909



Тип: отказ в обслуживании (нерасходуемая транзакция). Используя возможность создания дубликата coinbase-транзакции, уязвимость позволяет злоумышленникам удаленно ее использовать, поскольку протокол Биткойна (bitcoind, wxBitcoin, Bitcoin-Qt и прочие программы) не обрабатывает несколько транзакций с одним и тем же идентификатором.



5,0



CVE-2012-1910



Тип: отказ в обслуживании (сбой приложения) или выполнение произвольного кода. Благодаря манипулируемым сообщениям протокола Bitcoin, уязвимость в Bitcoin-Qt позволяет удаленному злоумышленнику использовать ее, поскольку Bitcoin-Qt для Windows не осуществляет многопоточную обработку исключений.



7.5



CVE-2012-3789



Тип: отказ в обслуживании (зависание процесса). Из-за неизвестного поведения в сети Биткойна, неопределенная уязвимость в bitcoind и Bitcoin-Qt позволяют удаленному злоумышленнику их использовать.



5,0



CVE-2012-2459



Тип: отказ в обслуживании (сбой в обработке блоков и некорректный счет блоков). Из-за неизвестного поведения в сети Биткойна, неопределенная уязвимость в bitcoind и Bitcoin-Qt позволяют удаленному злоумышленнику их использовать.



5,0



CVE-2013-4165



Эта уязвимость представляет собой синхронизированную атаку по сторонним каналам. Когда аутентификация завершается неудачей при обнаружении первого неправильного байта пароля, в функции HTTPAuthorized в файле bitcoinrpc.cpp bitcoind версии 0.8.1 происходит утечка информации, упрощающая для удаленного атакующего определение паролей.



4,3



CVE-2013-4627



Уязвимость в bitcoind и Bitcoin-Qt 0.8.x позволяет удаленным злоумышленникам проводить DoS-атаку посредством данных сообщения транзакции, приводя к чрезмерному потреблению памяти.



5,0



CVE-2014-0160



И TLS, и DTLS реализации в OpenSSL 1.0.1 до версии 1.0.1g содержат уязвимость, связанную с Heartbleed. Специально созданные пакеты позволяют удаленным атакующим инициировать повторное чтение буфера и получить доступ к конфиденциальной информации, в некоторых случаях включая и закрытые ключи.



5,0



CVE-2014-0224



Версии OpenSSL до 0.9.8za, 1.0.0 до 1.0.0m и 1.0.1 до 1.0.1h подвержены уязвимости “CCS Injection”, не ограничивая должным образом сообщения ChangeCipherSpec. В атаке типа man-in-the-middle злоумышленники в некоторых случаях могут заставить SSL использовать мастер-ключ нулевой длины, что позволяет злоумышленникам получить контроль над сеансами SSL либо доступ к конфиденциальной информации.



6,8



CVE-2018-12356



Simple Password Store версий 1.7.x до 1.7.2 имеет уязвимость, в которой процедура проверки подписи парсит выходные данные GnuPG с неполным регулярным выражением. Затем злоумышленники могут удаленно изменить конфигурационный файл, добавив в него дополнительные, контролируемые ими ключи шифрования. Через эту уязвимость злоумышленники могут украсть пароли или изменить скрипты расширения для выполнения атак выполнением произвольного кода.



7,5



CVE-2018-17144



Эта уязвимость представляет собой отказ в обслуживании (сбой приложения). Bitcoin Core и Bitcoin Knots позволяют удаленным злоумышленникам использовать дублирование ввода майнерами.



7,5



CVE-2019-6250



ZeroMQ libzmq (aka 0MQ) версий 4.2.x и 4.3.x до 4.3.1 содержит переполнение указателя с выполнением кода, что позволяет аутентифицированному атакующему перезаписать произвольное количество байтов за пределами буфера. Структура памяти позволяет злоумышленнику вводить команды операционной системы в структуру данных, расположенную сразу после проблемного буфера, и таким образом проводить атаки выполнением произвольного кода.



9,0



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

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

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

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

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

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

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

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

Символ



ID



Капитализация (ранг)



Схожесть

(форк)



Схожесть

(посл. версия)



Длительность

(дней)



Функции в уайтпейпер



Кол-во коммитов



Кол-во уязв.



Дата посл. коммита



R1



R2



R3



ARY



1



–



99,4%



72,6%



612



Управление цепочками поставок



2



2



дек. 2017



–



✓



✓



MNC



3



–



99,3%



64,8%



927



CPU-майнинг



232



1



сент. 2019



✓



–



–



BET



1



–



99,2%



29,3%



2140



–



12



2



апр. 2014



–



✓



–



ACOIN



1



$28 тыс. (2509)



98,9%



33,2%



1828



–



3



1



окт. 2014



–



✓



–



GAP



1



–



98,4%



33,2%



1943



CPU-майнинг



51



0



янв. 2015



✓



–



–



XCT



1



–



98,2%



57,9%



833



–



11



1



сент. 2017



–



✓



–



LTC



4



$15,018 млн (12)



98,0%



57,9%



386



CPU-майнинг



2009



0



июнь 2021



✓



–



–



FRC



4



$416 тыс. (1827)



97,6%



33,5%



1943



Токенизация



165



0



окт 2018



–



✓



✓



PLNC



2



$9 тыс. (2602)



97,5%



62,5%



927



CPU-майнинг



191



2



июль 2021



✓



–



–



CHIPS



4



–



97,5%



69,2%



754



–



57



1



окт 2018



–



✓



–



DEUS



1



–



97,1%



53,1%



896



Новый PoW



15



1



ноябрь 2017



–



✓



✓



FLO



4



–



97,1%



70,2%



749



Хранение данных



192



2



фев. 2020



✓



–



–



MNX



3



–



97,0%



62,1%



774



Стабильная цена



65



2



апр. 2019



✓



–



✓



RIC



1



–



96,9%



33,1%



2008



CPU-майнинг



402



1



июнь 2016



✓



–



–



FJC



4



$1,904 млн (1558)



96,9%



90,4%



185



CPU-майнинг



3817



0



авг. 2021



✓



–



–



BLU



1



$594 тыс. (1942)



96,8%



62,5%



723



PoS



9



2



окт. 2017



–



✓



✓



SRC



1



–



96,8%



28,6%



2196



Несколько алгоритмов хеширования



2



4



авг. 2013



–



✓



✓



FTC



4



$6,116 млн (1155)



96,6%



90,5%



185



CPU-майнинг



188



0



июль 2021



✓



–



–



888



1



–



96,5%



40,4%



1726



CPU-майнинг



342



0



апр. 2016



✓



–



–



UFO



4



$2,987 млн. (4746)



96,4%



90,3%



185



CPU-майнинг



153



0



март 2021



✓



–



–

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

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

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