25 апреля 2018 г. я анонимно в частном порядке сообщил о критической уязвимости Bitcoin Cash, одной из самых дорогостоящих криптовалют в мире, которую не стоит путать с Bitcoin. Успешное злоупотребление этой уязвимостью могло быть настолько разрушительным, что безопасные транзакции Bitcoin Cash больше не были бы возможны, что полностью уничтожило бы полезность (а следовательно, и стоимость) валюты. Но уязвимость была исправлена без инцидентов и предана огласке 7 мая 2018 г.
Короткое пояснение
Bitcoin Cash – криптовалюта, отличная от Биткойна и не совместимая с ним. Она носит такое название из-за своего происхождения от Биткойна. Исправленный на данный момент баг, описанный ниже, касался только Bitcoin Cash; единственная связь с Биткойном – похожее название.
Что касается меня и моих мотивов, то я работаю в составе Инициативы по цифровой валюте (Digital Currency Initiative) Медиа-лаборатории Массачусетского технологического института (MIT Media Lab), которая, как следует из названия, представляет собой группу, чья задача – исследование и разработка криптовалют. В частности, я помогаю разрабатывать и обслуживать Bitcoin Core, исходную программную реализацию Биткойна. В связи с этой работой меня часто спрашивают на конференциях и семинарах, что я считаю величайшим вызовом для Биткойна в будущем. Мой ответ всегда один и тот же: избежать катастрофических программных багов.
Выявление этого бага, который определённо мог привести к катастрофе, подтвердило моё убеждение в том, что угроза программных багов в криптовалютном мире сильно недооценивается. Я представляю подробный отчёт об этом инциденте не как выпад против Bitcoin Cash, но как реальный пример того, сколько ещё работы требуется, чтобы достичь изощрённого технического уровня, необходимого криптовалютам, и как предупреждение компаниям, которые адекватно не подготовились к подобным сценариям.
SIGHASH_BUG
Если кратко, то была переписана часть кода для верификации подписей транзакций, но в новом коде была упущена критическая проверка определённого бита в типе подписи. В своём сообщении я называю этот бит SIGHASH_BUG. Данное упущение позволяло определённым образом составленной транзакции разветвить блокчейн Bitcoin Cash на две несовместимых цепочки. В следующем разделе описывается значение такого раскола. Подробное описание бага и решения см. в тексте моего сообщения.
Чем особенны баги, раскалывающие блокчейн?
Большинство криптовалют, включая Биткойн и Bitcoin Cash, функционируют, распространяя реестр всех транзакций всем участникам. Чтобы потратить монеты, отправитель должен сначала создать транзакцию, соответствующую всем правилам системы. Большинство правил очевидны и прямолинейны, например, «нельзя потратить больше, чем у тебя есть», но есть и намного более утончённые и технические, особенно те, где описывается формат цифровых подписей. Но если криптовалюта децентрализована, кто устанавливает эти так называемые правила валидации?
Правила валидации устанавливают все вместе!
Правила системы таковы, какими их видят все, и следить за их соблюдением – задача программного обеспечения. Если участник попытается смошенничать и создать транзакцию, расходующую деньги, которых у него нет, ПО других участников просто отклонит такую транзакцию. Поэтому, чтобы транзакция была принята всеми, она должна следовать даже самым педантичным правилам.
ПО, следящее за соблюдением правил валидации, должно всё время развиваться. Постоянно вносятся изменения, чтобы улучшить работу, добавить новые опции, усовершенствовать безопасность и т. д. Но критически важно, чтобы во всех версиях контроль над соблюдением правил осуществлялся одинаково.
Что же происходит, когда из-за случайного программного бага в новой версии ПО транзакция считается действительной, тогда как все предыдущие версии ПО отклоняли её как недействительную? Результатом будет «раскол цепочки», и это значит, что лишь часть участников, которые обновили своё ПО, примут эту транзакцию. И так как транзакции и блоки объединены в цепочку, две группы участников будут расходиться во мнении насчёт всех последующих транзакций. Без быстрых действий со стороны разработчиков и кампании по группированию всех участников на одной из сторон развилки два лагеря участников так и не смогут достичь согласия. Тогда валюта фактически расколется на две несовместимых валюты – возвращение к прежнему положению дел невозможно.
При взвешивании потенциальных последствий подобных багов важнейшую роль играет своевременность. Если блокчейн расколот так, что на одной стороне 99% участников, а на другой – лишь 1%, то очевидный выход – всем примкнуть к большинству. Но если около 50% обновились до новой версии, простого выхода не существует.
Именно такой баг, раскалывающий блокчейн, я обнаружил в новой версии самой популярной реализации ПО Bitcoin Cash, но только после того, как до неё обновилась почти половина сети.
Обнаружение
Состоялся релиз новой версии клиента Bitcoin Core 0.16.1В качестве отправной точки для новых криптовалют часто используется Bitcoin Core, так как это бесплатное ПО с открытым кодом. Помимо преимущества в виде предшествующего многолетнего совершенствования, использование открытого кода означает, что не связанные друг с другом криптовалюты могут извлекать пользу из будущих усовершенствований друг друга. Исходная программная реализация Bitcoin Cash, носящая название Bitcoin ABC (что, опять же, вносит путаницу), – как раз одна из тех, что основаны на Bitcoin Core.
Учитывая использование больших кусков общего кода, такие производные проекты часто имеют схожие баги, а следовательно, и схожие решения этих багов. Однако не реалистично ожидать, что разработчики, работающие над какой-то одной валютой, будут активно делиться своими доработками с разработчиками, работающими над другими валютами, – даже поспевать за одним проектом – непростая задача. Поэтому я выработал привычку каждые несколько месяцев просматривать изменения некоторых таких проектов в поиске решений багов, которые могут быть актуальны для Bitcoin Core.
Просматривая в начале этого года журнал изменений Bitcoin ABC, я заметил, что одна из наиболее критичных частей валидации транзакций подверглась рефакторингу. Изменения сразу бросились мне в глаза, потому что они казались ненужными. Заинтересовавшись их причиной, я решил посмотреть, что об изменениях думает сообщество. Единственным аргументом была «инкапсуляция», рецензии были лишь от двух человек, и рецензирование кода длилось всего неделю до его принятия.
Основательный рефакторинг очень распространён и часто является хорошей практикой в обычном программировании. Однако крайне рискованно модифицировать код валидации криптовалют из-за постоянно существующей угрозы с необратимыми последствиями, когда блокчейн может расколоться.
Увидев, как мало рецензий получили изменения и как много строк было изменено, я посчитал вероятным, что мог прокрасться баг, и поэтому я приступил к его поиску. Чтобы найти SIGHASH_BUG, понадобилось меньше 10 минут.
Анонимное сообщение
Выше я упомянул, что моё сообщение о баге было анонимным. Мне хотелось бы объяснить причины, поскольку анонимность сыграла в процессе важную роль.
Убедившись, что багом запросто можно злоупотребить, я решил уведомить об этом разработчиков Bitcoin ABC – но быстро понял, что есть большая проблема. Это был баг в общедоступном, открытом ПО, и его уже мог обнаружить кто-нибудь ещё. Ничто не мешало любому человеку сделать такое же открытие и воспользоваться им, прежде чем ошибку смогут полностью устранить.
Что же могло произойти в худшем случае? Допустим, я бы сообщил о баге в частном порядке, используя своё имя, – а кто-то нашёл бы его самостоятельно и на следующий день анонимно воспользовался им. Так как я использовал в сообщении своё имя, будет существовать убедительное доказательство того, что у меня были необходимые знания и средства для атаки на сеть. Я не смог бы доказать, что злоумышленник – не я. Представьте, что в результате атаки были в общей сложности потеряны миллиарды долларов. Людей убивали и за намного меньшие суммы. Так что анонимность была не просто важна, а я считал её необходимой для собственной безопасности.
Пытаясь выяснить, возможно ли полностью анонимное сообщение, я стал спрашивать себя, стоит ли вообще в это впутываться. В конце концов, я не был обязан ничего сообщать. Но если бы кто-то обнаружил такой же неприятный баг в Bitcoin Core, я бы надеялся, что он обратит на него наше внимание с максимальной благоразумностью и безопасностью. Так что я решил так и поступить: создать сообщение, которое мне хотелось бы прочитать, и доставить его так, как я предпочёл бы его получить.
Первый шаг был очевидным – мне нужно было узнать о политике Bitcoin ABC в отношении ответственного сообщения об уязвимостях. Политика по обращению с подобными вопросами в наши дни – обычное дело и является обязательной для любого проекта, где критически важна безопасность. К сожалению, мне не удалось найти такую политику на сайте или в репозитории кода. Самое близкое, что мне удалось найти, – это экран при отправке сообщения в баг-трекере на GitHub:
Данный баг-трекер предназначен только для технических проблем, связанных с Bitcoin ABC.
Общие вопросы о Биткойне и/или запросы о поддержке лучше всего направлять на Bitcoin StackExchange
Для сообщения о проблемах безопасности, пожалуйста, свяжитесь с людьми в частном порядке.
Не то. Тогда я стал пытаться найти публичные ключи шифрования для связи с «людьми», известными как разработчики Bitcoin ABC. Шифрование сообщения гарантирует, что никто другой не сможет его просмотреть, – а следовательно, я бы меньше беспокоился о том, как доставить сообщение. Я не смог бы проверить личность владельцев ключей, но такой подход всё же был бы обоснованно безопасным и намного лучшим, чем отсутствие всякого шифрования.
Но я снова зашёл в тупик. Ни на публичных серверах PGP-ключей, где их обычно стоит искать, ни в репозитории кода никаких ключей для связи с главными разработчиками не было. Тогда у меня не оставалось других вариантов, кроме как анонимно запросить ключи посредством различных онлайн-каналов, используя Tor, чтобы максимально замаскировать свою личность.
Сначала я создал одноразовый аккаунт на GitHub и 25 апреля обратился к нескольким разработчикам Bitcoin ABC:
«Не могли бы вы здесь в комментариях написать публичные ключи GPG для ответственного сообщения о важной уязвимости Bitcoin ABC?»
К счастью, сработало! Примерно через 5 часов я получил ключ и быстро воспользовался им, написав в ответ подробное описание проблемы. Но когда я зашёл на следующий день, чтобы посмотреть, поступил ли ответ, GitHub заблокировал мой одноразовый аккаунт, возможно, из-за использования Tor. Так что дальнейший контакт этим способом был невозможен. Мне пришлось предположить, что сообщение не было получено.
Имея ключ шифрования, я решил испытать последний способ связи и отправил зашифрованное сообщение через баг-трекер Bitcoin ABC, также используя Tor и разовый аккаунт. Шесть часов спустя, не получив ответа, я написал на баг-трекере последнее отчаянное обращение:
«Приём. Это срочно, пожалуйста, уведомите о получении».
27 апреля, когда я прождал ответа на своё сообщение примерно 48 часов, был открыт запрос о включении изменений, чтобы незаметно исправить проблему в Bitcoin ABC. Очевидно, сообщение было получено. Успех!
Выводы
Обнаруженная мною уязвимость Bitcoin Cash была успешно сообщена и устранена и в итоге не оказала на криптовалюту заметного влияния. Но было бы нехорошо не дать экосистеме возможности проанализировать такое существенное упущение.
Разработчикам криптовалют следует задуматься и пересмотреть имеющиеся инструменты, а также используемую нами политику и процедуры. Пусть мы не можем устранить риск появления подобных багов, но зато можем извлечь урок, чтобы в будущем к ним лучше подготовиться.
https://bitnovosti.com/2018/09/21/otvetstvennoe-soobshhenie-ob-uyazvimostyah-v-eru-kriptovalyut/
Latest news: 
. 
. 
. 
. 
. 
. 
Shop
Topic: Ответственное сообщение об уязвимостях в эру криптовалют (Read 643 times)