ScaleBit Глубокий анализ: Подробный разбор уязвимостей безопасности и списка поверхностей атаки в экосистеме блокчейна

Хотя технология блокчейн демонстрирует огромный потенциал в области децентрализации, безопасности и механизмов доверия, ее экосистема все еще скрывает разнообразные риски безопасности. От различных уязвимостей в межсетевой коммуникации L1/L2 (например, неучет отката блоков, неправильная обработка неудачных транзакций, дефекты верификации легких клиентов) до скрытых угроз в цепочках приложений Cosmos в отношении порядка модулей, использования случайных чисел и отката транзакций, а также рисков, возникающих в расширенной экосистеме Bitcoin из-за конструкции скриптов, обработки UTXO и откатов — все это создает серьезные вызовы для блокчейн-приложений. В то же время такие ошибки, как переполнение целочисленного типа, бесконечные циклы, состояния гонки и аварийные сбои,常见的 в смарт-контрактах или языках общего программирования, также серьезно угрожают доступности и безопасности системы.

Кроме того, уязвимость архитектуры сети P2P (например, атаки Сибил, атаки затмения) и атаки DoS同样 могут ограничивать эффективность и надежность блокчейн-систем, в то время как уязвимости криптографии (небезопасные алгоритмы хеширования, слабые алгоритмы подписи, небезопасная генерация случайных чисел и т. д.) ставят под угрозу конфиденциальность и целостность данных. Неправильная обработка пула памяти транзакций, сиротских блоков и деревьев Меркла на уровне реестра может привести к несогласованности данных в цепочке или рискам для активов. Наконец, недостаточная проработка моделей экономики и механизмов управления может привести к дисбалансу сетевых стимулов или даже расколу, чем могут воспользоваться злоумышленники, влияя на стабильность системы.

Обобщая вышеупомянутые риски, только глубокое понимание и принятие строгих мер профилактики могут обеспечить безопасность и устойчивое развитие в постоянно эволюционирующей блокчейн-экосистеме. В конце 2024 года материнский бренд ScaleBit, BitsLab, опубликовал «Отчет о панорамном观察新兴生态公链 и безопасности за 2024 год». В этом отчете подробно анализируются различные существующие уязвимости безопасности и поверхности атак, содержание богато и практично. В этой статье мы выбрали часть содержания отчета, чтобы сосредоточиться на ключевых типах уязвимостей безопасности в блокчейн-экосистеме, помогая читателям подготовиться заранее и совместно способствовать безопасности и здоровому развитию отрасли.

Читать оригинал отчета：https://bitslab.xyz/reports-page

1）Список типов уязвимостей безопасности

1.1 Уязвимости межсетевой коммуникации L2/L1

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

L2 не учитывает откат блоков L1

При отправке транзакций L1 или получении данных в цепочке L1, если не учитывать эту ситуацию, это может привести к потере активов.

L2 не проверяет успешность отправки транзакций в L1

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

Подделка событий в цепочке

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

Одна транзакция содержит несколько событий в цепочке

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

Уязвимости верификации легкого клиента

1. Цепи PoW не учитывают атаки приватного майнинга

2. Не используются алгоритмы, рекомендованные официально

Перехват человеком посередине

В межсетевой коммуникации L2/L1 механизм передачи сообщений имеет решающее значение, необходимо确保 целостность и конфиденциальность сообщений в процессе передачи. Передача сообщений между разными цепочками может столкнуться с риском篡改或 прослушивания, поэтому необходимо использовать средства шифрования для защиты безопасности информации. Кроме того, обеспечение неотказуемости при пересылке сообщений между цепочками также является ключевым моментом для предотвращения злонамеренного篡改 информации.

Проблемы задержки и окончательности

Межсетевая коммуникация часто сталкивается с проблемами задержки и окончательности. Из-за различных механизмов консенсуса и времени подтверждения в разных цепочках время подтверждения межсетевых транзакций может быть несогласованным, что приводит к задержке обновления состояния, тем самым увеличивая потенциальные риски безопасности. При проектировании межсетевых протоколов необходимо четко определить понятие окончательности, обеспечить согласованность состояния транзакций и предотвратить атаки двойного spending или проблемы несогласованности состояния из-за задержки подтверждения.

1.2 Уязвимости цепочек приложений Cosmos

Cosmos как экосистема, ориентированная на интероперабельность блокчейнов, позволяет различным блокчейнам соединяться через IBC (протокол межсетевой коммуникации). Однако в процессе реализации цепочки приложений Cosmos также могут существовать некоторые уязвимости и скрытые угрозы безопасности. Вот основные моменты, на которые следует обратить внимание:

Уязвимости сбоя BeginBlocker и EndBlocker

BeginBlocker и EndBlocker — это опциональные методы, которые разработчики модулей могут реализовать в своих модулях. Они触发 в начале и в конце каждого блока соответственно. Использование паники для обработки ошибок в методах BeginBlock и EndBlock может привести к остановке работы цепочки при возникновении ошибок.

Неправильное использование локального времени

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

Справочные материалы:

Источник изображения 

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319

Неправильное использование случайных чисел

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

Неправильное использование функции итерации Map

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

Проблемы, вызванные неразумным порядком модулей

Цепочки приложений Cosmos состоят из нескольких модулей, в некоторых обработках событий между модулями существует порядок. Если порядок установлен неразумно, это может привести к проблемам безопасности.

Транзакция не удалась, но данные не откатились

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

Неверная верификация состояния

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

Безопасность передачи межсетевых сообщений

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

Проблемы обновления контрактов и управления версиями

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

Экономическая модель и механизмы стимулирования

Дизайн экономической модели в экосистеме Cosmos напрямую влияет на безопасность и стабильность цепочки. Если механизмы стимулирования установлены неразумно, это может привести к дисбалансу поведения участников, возникновению злонамеренного поведения или экономических атак. Необходимо провести всестороннюю оценку экономической модели, чтобы确保, что механизмы стимулирования могут эффективно поддерживать безопасность и здоровье сети.

Уязвимости механизмов управления

Механизмы управления цепочек приложений Cosmos позволяют держателям токенов участвовать в принятии решений цепочки, но если механизм управления разработан неправильно, это может привести к атакам на управление или проблемам централизации. Следует обеспечить справедливость и прозрачность механизма управления, чтобы предотвратить манипулирование процессом принятия решений цепочки少数人.

1.3 Уязвимости расширенной экосистемы Bitcoin

Уязвимости конструкции скриптов Bitcoin

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

Уязвимости, вызванные неучетом производных активов

Распространенными производными активами Bitcoin являются инскрипции и руны, если L2 при操作 активами пользователей учитывает только нативный BTC, не учитывая производные активы, это приведет к потере активов пользователей.

Уязвимости错误 расчета суммы UTXO

1. Ошибки при расчете комиссии за транзакцию

2. Ошибки при расчете суммы сдачи

Например, в следующем коде реализация расчета вывода сдачи включает условие: вывод сдачи добавляется только тогда, когда сумма сдачи больше или равна 546 сатоши. Это значение соответствует лимиту пыли для традиционных транзакций P2PKH. Однако лимиты пыли для разных типов адресов отличаются. В частности, для адресов Taproot лимит пыли составляет 330 сатоши.

Это жестко закодированное значение не учитывает более низкий лимит пыли для адресов Taproot, что может привести к потере небольших сумм активов в транзакциях,涉及 адресов Taproot. Подробную информацию о лимитах пыли для различных типов адресов можно найти в исходном коде Bitcoin Core и обсуждениях на форуме BitcoinTalk.

https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L26

https://bitcointalk.org/index.php?topic=5453107.msg62262343#msg62262343

Не проверяется, содержит ли UTXO "op_return"

UTXO с "op_return"不可花费.

Уязвимости верификации SPV

1. Не проверяется временная метка заголовка блока

2. Не проверяется доказательство работы заголовка блока

Неучет ситуации отката

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

Не учитывается, была ли отправлена транзакция Bitcoin успешно

Транзакция Bitcoin после отправки не обязательно будет упакована майнерами, поэтому необходимо проверять, успешно ли транзакция попала в цепочку. В то же время третьи стороны могут构造 транзакции с более высокой комиссией, чтобы транзакции, отправленные L2, оставались в пуле памяти транзакций в течение длительного времени, а не упаковывались.

Уязвимость путаницы абсолютных и относительных временных锁定

При конструкции скриптов Bitcoin, если перепутать эти 2 вида времени, в серьезных случаях это приведет к потере активов.

Неразумная установка времени в контрактах哈希 времени锁定 (HTLC)

Распространенные ситуации следующие 3 вида:

1. Время установлено слишком большим

2. Время установлено слишком маленьким

3. Время L1 и L2 не синхронизировано

1.4 Распространенные типы уязвимостей языков программирования

1.4.1 Переполнение целочисленного типа

Переполнение целочисленного типа происходит, когда数值 выходит за пределы диапазона,表示емого типом, что приводит к wraparound数值或逻辑错误, влияя на точность данных программы. Rust автоматически обнаруживает переполнение в режиме отладки, а Go требует ручного добавления проверок границ.

1.4.2 Бесконечный цикл

Бесконечный цикл означает, что программа входит в бесконечный цикл при определенных условиях, потребляя системные ресурсы, что приводит к зависанию программы или отсутствию ответа. Ключом к избеганию этой проблемы является установка разумных условий выхода из цикла и использование механизма тайм-аута Rust или пакета context Go для контроля долго_running циклов.

1.4.3 Бесконечный рекурсивный вызов

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

Rust отобразит ошибку переполнения стека в отладочной информации, аналогично следующему выводу:

1.4.4 Состояние гонки

Когда несколько потоков访问共享资源 без синхронизации, происходит гонка данных, что приводит к несогласованности данных. Rust избегает состояний гонки через механизм владения и потокобезопасные библиотеки, а Go предоставляет поддержку конкурентности через channel и пакет sync.

Следующий пример Unsafe Rust демонстрирует, как два потока одновременно访问 и修改 одну и ту же共享 переменную, что приводит к неопределенному поведению. Этот код вызовет гонку данных, потому что не используется никакой механизм синхронизации для защиты共享资源:

Хотя Safe Rust предотвращает гонку данных, логические гонки все еще могут происходить. Логическое состояние гонки (Race Condition) относится к тому, что код может产生 непредвиденное поведение при определенном порядке выполнения, это ситуация логической гонки. Например, в следующих сценариях:

1. Операции, чувствительные ко времени: порядок операций между двумя потоками может влиять на конечный логический результат. Например:

a. Один поток проверяет, выполняется ли определенное условие, в то время как другой поток修改 это условие в этот период. В Rust это можно координировать顺序 доступа через такие механизмы синхронизации, как Arc<Mutex<T>>, но это не может предотвратить логическое состояние гонки.

2. Двойная проверка блокировки (Double-Checked Locking): если несколько потоков пытаются инициализировать共享资源 и都认为资源 не инициализирована, это может привести к логической ошибке. В этом случае, хотя гонка данных не произойдет, могут возникнуть неожиданные логические ошибки.

3. Неправильный порядок блокировок: если используется несколько блокировок, потоки могут获取 блокировки в несогласованном порядке, что может привести к взаимной блокировке. Система типов Rust не может предотвратить этот тип состояния гонки взаимной блокировки.

Ниже приведена демонстрация уязвимости состояния гонки Safe Rust. В этом примере:

●Два потока分别 увеличивают共享 переменную data на 1. Каждый поток будет блокировать data, а затем увеличивать其 значение.

●Поскольку операция выполняется пошагово, даже если данные защищены Mutex, порядок выполнения потока 1 и потока 2 повлияет на конечный результат печати. Теоретически, конечное значение должно быть 2, но конкретный порядок вывода печати потока может быть не固定.

1.4.5 Аварийный сбой

Аварийный сбой обычно вызывается необработанными ошибками, что приводит к неожиданному завершению программы. Go использует defer/panic/recover для捕获 исключений, а Rust использует систему типов Result и Option, предоставляя более надежную обработку ошибок.

Ниже приведен пример, где не捕获 panic приводит к сбою программы:

1.4.6 Уязвимость деления на 0

Уязвимость деления на 0 означает, что программа выполняет операцию деления, когда знаменатель равен нулю, что может вызвать исключение или сбой. Рекомендуется проверять значение знаменателя перед выполнением деления, предотвращая操作 с нулевым значением и обеспечивая стабильность программы.

1.4.7 Преобразование типов

Ошибки преобразования типов обычно вызваны небезопасным или несовместимым преобразованием, что может привести к непредсказуемому поведению. Go и Rust提示 несовместимость типов при преобразовании, Rust более строг в преобразовании, требуется использовать оператор "as" для явного выполнения.

В следующем примере кода пользователь добавляет ликвидность токенов в количестве amount, затем система записывает其 количество ликвидности. Если amount = (u128::MAX << 64) | 1, то фактически оплачен только 1 токен, но баланс ликвидности записан как 340282366920938463444927863358058659841.

1.4.8 Выход за границы массива

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

Следующий пример кода демонстрирует выход за границы массива, приводящий к сбою программы:

1.5 Уязвимости сети p2p

Сеть P2P (peer-to-peer) в блокчейн-системах используется для прямого соединения и коммуникации между распределенными узлами. Хотя сеть P2P обеспечивает сетевую основу для децентрализованных систем, она также сталкивается с рядом уязвимостей безопасности и рисков атак.

С точки зрения безопасности типы сетей p2p можно разделить на 2 вида: один вид без разрешений, это используется больше на L1. Другой вид с разрешениями, это больше на L2.

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

Распространенные типы уязвимостей сети P2p следующие:

1. Уязвимость атаки异形:

Атака异形 также называется загрязнением пула адресов, это метод атаки, побуждающий узлы同类 цепочки взаимно вторгаться и загрязнять, основная причина уязвимости в том, что система коммуникации протокола同类 цепочки не делает идентификацию для не同类 узлов.

Подобные уязвимости ранее появлялись в некоторых同类 цепочках Ethereum.同类 цепочки Ethereum (конкретно говоря, публичные链, использующие протокол обнаружения узлов Ethereum P2P discv4, включая Ethereum, Ethereum Classic) из-за использования совместимого протокола рукопожатия не могут различить, принадлежит ли узел к одной цепочке, что приводит к взаимному загрязнению пула адресов, снижению производительности коммуникации узлов, в конечном итоге вызывая блокировку узлов.

Процесс атаки показан на рисунке ниже:

2. Отсутствие механизма модели доверия

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

3. Отсутствие механизма ограничения количества узлов

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

4. Проблемы алгоритма обнаружения узлов

Алгоритм обнаружения и выбора узлов отвечает за定位 новых узлов и установление соединений в сети P2P. Если алгоритм разработан неразумно, например, алгоритм расстояния несбалансирован, это легко приводит к дисбалансу топологии сети, перегрузке部分 узлов. Необходимо обеспечить сбалансированность и непредсказуемость алгоритма, чтобы повысить безопасность распределения узлов и устойчивость сети к атакам.

Следующее изображение показывает крайнюю ситуацию дисбаланса сетевой топологии:

5. Легко атакуемый механизм выбора узлов

Если узел использует легко атакуемый механизм выбора узлов, то все другие узлы, к которым он подключен, могут быть злонамеренными узлами, что приводит к атаке Eclipse. Ниже приведены распространенные механизмы безопасности выбора узлов:

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

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

6. Отсутствие аутентификации

В сети p2p с разрешениями необходимо进行 аутентификацию идентичности узлов

7. Отсутствие механизма регулярного обновления таблицы маршрутизации

Если обнаружено, что данные, возвращаемые узлом, являются нелегальными, нужно рассмотреть, следует ли удалить其 запись в таблице маршрутизации

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

8. Уязвимость перехвата человеком посередине

Данные p2p в процессе передачи должны поддерживать целостность данных. Если используемый алгоритм шифрования неправилен или имеет уязвимости, это может позволить данным быть篡改.

1.6 Уязвимости DoS

Уязвимости DoS (отказ в обслуживании) приведут к исчерпанию системных ресурсов, препятствуя нормальному доступу легальных пользователей, ниже приведены ключевые типы:

1. Атака исчерпания памяти

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

Одной из распространенных атак исчерпания памяти является "zip-бомба". Основной принцип zip-бомбы заключается в том, что мы генерируем очень большой файл, содержание которого все 0 (или другие значения), затем сжимаем его в zip-файл, поскольку коэффициент сжатия файлов с одинаковым содержанием очень велик, в это время生成的 zip-файл очень мал. Цель атаки после распаковки zip-файла должна потреблять очень много памяти для хранения распакованного файла, память будет быстро исчерпана, цель崩溃 из-за OOM.

Другие алгоритмы сжатия также столкнутся с той же проблемой. Ниже приведен список коэффициентов сжатия распространенных алгоритмов для сжатия файла размером 1 ГБ, содержание которого все 0:

2. Атака исчерпания жесткого диска: запись бесполезных данных для заполнения пространства хранения, предотвращение нехватки ресурсов через управление квотами диска.

Атака исчерпания жесткого диска обычно имеет следующие 2 ситуации:

1. Zip-бомба. Метод атаки такой же, как выше "атака исчерпания памяти", только целевая программа распаковывает zip на диск, а не напрямую в память.

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

3. Атака исчерпания дескрипторов ядра: большое количество запросов ресурсов исчерпывает дескрипторы, рекомендуется контролировать распределение дескрипторов и监控 аномалии.

Приблизительный принцип этой атаки: злоумышленник через уязвимость заставляет дескрипторы ядра целевого узла исчерпаться или接近 исчерпанию, делая其 неспособным отвечать на нормальные бизнес-запросы.

Распространенным видом атаки является "Атака давления Socket". Если целевой узел не ограничил количество соединений и количество конкурентных операций, то злоумышленник может отправить и поддерживать большое количество запросов соединений, исчерпывая системные ресурсы Socket.

4. Постоянная утечка памяти: память не может быть нормально освобождена, приводя к истощению ресурсов, необходимо регулярно检测 использование памяти, чтобы предотвратить ухудшение проблемы.

Утечка памяти в обычных условиях не считается уязвимостью безопасности. Но если злоумышленник может активно触发 утечку памяти целевого узла и может повторять эту операцию, со временем программа целевого узла崩溃 из-за нехватки памяти.

1.7 Уязвимости криптографии

Уязвимости криптографии нарушат конфиденциальность и целостность данных, принося системе потенциальные угрозы безопасности. Ниже приведены основные типы уязвимостей криптографии:

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

Алгоритмы хеширования используются для генерации уникального идентификатора данных,确保 целостность не будет篡改. Распространенные алгоритмы хеширования, такие как MD5 и SHA-1, уже доказаны存在 риски коллизий, которые могут быть использованы злонамеренными атакующими. Поэтому рекомендуется использовать более безопасные современные алгоритмы хеширования, такие как SHA-256 или SHA-3, и поддерживать обновление алгоритмов, избегая рисков целостности данных,带来的 старыми алгоритмами, которые легко взломать.

Использование небезопасных自定义 алгоритмов хеширования

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

Например, в процессе аудита мы столкнулись со следующим自定义 алгоритмом хеширования:

Функция `hashCode` не является криптографической хеш-функцией и极易发生 коллизии. Она выполняет только очень простые побитовые и аддитивные операции. Кроме того, длина входа и длина выхода этой функции следуют четкому и предсказуемому паттерну, делая ее легко обратной解析 и взлому. Из-за этого слабого механизма хеширования атакующие могут легко генерировать ключи, приводящие к одинаковому значению `CONST_KEY_HASH`, тем самым ставя под угрозу безопасность процесса авторизации API.

Ниже приведен код доказательства концепции (PoC), демонстрирующий, как использовать уязвимость этого слабого хеширования:

Коллизии хеширования, вызванные небезопасным использованием

Одной из распространенных ситуаций является HASH(A+B+C)=HASH(D+E), причина этой ситуации в том, что A+B+C=D+E, поскольку 'A+B+C' и 'D+E'完全 одинаковы, но ABCDE各自不一样.

Использование небезопасных алгоритмов цифровой подписи

Алгоритмы цифровой подписи используются для верификации подлинности и источника данных, предотвращая篡改 данных. Ранние алгоритмы подписи, такие как DSA и RSA, могут失效 под угрозой квантовых вычислений. Использование современных алгоритмов подписи, таких как ECDSA или EdDSA, может обеспечить более сильную безопасность, защищая легитимность и анти-подделочную способность данных. Особенно в распределенных системах и смарт-контрактах,确保 надежность алгоритмов подписи至关重要.

Использование небезопасных алгоритмов шифрования

Сила алгоритмов шифрования напрямую влияет на конфиденциальность данных, слабые алгоритмы шифрования (например, DES) могут быть легко взломаны атакующими. Рекомендуется использовать симметричные алгоритмы шифрования с более высоким битом, такие как AES-256, и внедрять сквозное шифрование (например, TLS) в процессе коммуникации, чтобы保障 безопасность передачи данных, предотвращая прослушивание или篡改. Кроме того,确保 управление ключами на месте, предотвращая утечку ключей.

Использование небезопасных алгоритмов генерации случайных чисел

Генератор случайных чисел является основой многих криптографических операций, особенно при генерации ключей, IV (вектор инициализации) и важных параметров в асимметричном шифровании,确保其 непредсказуемость至关重要. Ниже приведены распространенные проблемы безопасности:

1. Небезопасные алгоритмы генерации случайных чисел приводят к тому, что случайные числа предсказуемы или даже манипулируемы;

2. Алгоритмы случайных чисел на публичных链 в основном все存在 риски предсказания случайных чисел, потому что информация все открыта и прозрачна, поэтому случайные числа могут быть предсказаны.

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

Использование небезопасных семян случайных чисел

Утечка семян случайных чисел или возможность brute force приводит к утечке семян случайных чисел,进而 приводит к тому, что случайные числа предсказуемы;

Атаки по侧信道 в криптографии

Атаки по侧信道 получают конфиденциальную информацию через мониторинг физических характеристик системы (например, потребление энергии, время выполнения, кэш и т. д.). Этот тип атаки обходит безопасность самого алгоритма, особенно распространен в аппаратных устройствах и встроенных системах. Средства защиты включают оптимизацию реализации алгоритма, делая время выполнения и потребление энергии постоянными, уменьшая характеристики, которые могут быть утечены. Кроме того, снижать вероятность утечки информации по侧信道 через такие техники, как маскирование и обфускация.

Расширяемость подписи

Расширяемость подписи означает, что не изменяя содержание подписи, можно вывести и вычислить другую действительную подпись через известную действительную подпись. Один из значительных рисков,带来的 этой характеристикой, является расширяемость транзакции, расширяемость транзакции позволяет злонамеренным пользователям использовать разные варианты подписи для воспроизведения транзакции, воспроизведенная транзакция имеет разные значения hash из-за разной подписи, путая суждение пользователя о состоянии транзакции в процессе подтверждения транзакции, тем самым реализуя двойное spending.

1.8 Уязвимости безопасности реестра

Уязвимости пула памяти транзакций

1. Транзакции могут быть воспроизведены

2. Неудачные транзакции не вычитают комиссию

Уязвимости коллизии хеша блока

Если способ конструкции блока有问题, то произойдет коллизия.

Уязвимости логики обработки сиротских блоков

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

Уязвимости коллизии хеша дерева Меркла

Если способ конструкции листовых узлов дерева Меркла有问题, то произойдет коллизия.

Проблемы обработки суммы транзакции

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

Проблемы обработки комиссии за транзакцию

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

Время верификации блока и транзакции слишком чувствительно

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

Проблемы в логике подписания прав транзакции

В основном включает следующие 2 аспекта:

1. Обход подделки идентичности

2. Ошибка проверки прав

1.9 Уязвимости экономической модели

Экономическая модель играет至关重要的 роль в блокчейне и распределенных системах, влияя на механизмы стимулирования сети, структуру управления и общую устойчивость. Ниже приведены основные моменты, на которые следует обратить внимание:

Экономическая модель цепочки приложений Cosmos (на примере UniChain)

Цепочки приложений Cosmos приняли экономическую модель, ориентированную на интероперабельность блокчейнов и масштабируемость. На примере UniChain, дизайн экономической модели не только учитывает циркуляцию и использование токенов в цепочке, но и учитывает потребности разных сценариев применения. Используя Cosmos SDK, UniChain может создавать блокчейны, специфичные для приложений, и реализовывать межсетевую коммуникацию, способствуя обмену ресурсами и流动 ценности между разными цепочками. Экономическая модель должна关注 объем выпуска токенов, уровень инфляции, структуру комиссий за транзакции и механизмы управления в цепочке, чтобы确保 стабильность и процветание экосистемы.

Разумны ли механизмы стимулирования

Механизмы стимулирования являются核心 частью экономической модели, напрямую влияя на участие пользователей и узлов. Разумные механизмы стимулирования должны确保, что все участники (например, майнеры, валидаторы, разработчики и пользователи) могут получить справедливое вознаграждение. Необходимо оценить устойчивость структуры стимулирования,确保, что она может эффективно предотвращать злонамеренное поведение и тенденции централизации. Кроме того, механизмы стимулирования также должны адаптироваться к изменениям рынка, корректируясь с成熟ностью сети и эволюцией потребностей пользователей. Например, установлены ли подходящие механизмы вознаграждения и наказания, как балансировать краткосрочные и долгосрочные стимулы и т. д., все это вопросы, требующие глубокого анализа.

Устойчивость сетевой экономики

Экономическая модель также должна关注 долгосрочную устойчивость сети, включая управление экономическим стимулированием всех сторон в экосистеме, созданием ценности и其 распределением. Необходимо оценить, существует ли экономический дисбаланс или расточительство ресурсов,确保, что все участники могут получить разумную ценность в сети. Кроме того, необходимо анализировать внешние факторы, которые могут влиять на стабильность сети, такие как колебания рынка и изменения поведения пользователей.

Механизм обратной связи рынка

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

Влияние структуры управления

Дизайн экономической модели должен быть结合 со структурой управления,确保, что пользователи могут участвовать в экономических решениях в процессе управления, тем самым усиливая чувство участия и принадлежности сообщества. Разумные механизмы управления могут способствовать самовосстановлению и постоянной оптимизации экономической модели, повышая общее здоровье сети.

После глубокого понимания различных типов уязвимостей безопасности, существующих в блокчейн-экосистеме, следующим шагом является обсуждение конкретных поверхностей атак, которые могут быть использованы этими уязвимостями. Поверхность атаки относится к входам и путям системы, которые могут быть использованы потенциальными атакующими, через идентификацию и анализ этих поверхностей атак можно более эффективно оценивать риски и разрабатывать соответствующие стратегии защиты. Поэтому всестороннее овладение relationship между типами уязвимостей и поверхностями атак至关重要 для построения稳固 линии обороны безопасности блокчейна. Ниже будет подробно перечислены распространенные поверхности атак в текущей блокчейн-экосистеме, помогая читателям лучше понять конкретные способы реализации угроз.

2. Список поверхностей атак

Ниже приведен список распространенных поверхностей атак:

4.1 Виртуальная машина

Поверхность атаки: Виртуальная машина отвечает за выполнение смарт-контрактов и обработку байт-кода, обычно несет большую сложную логику,存在 потенциальные риски, такие как атаки повторного входа, переполнение целочисленного типа и переполнение памяти. Кроме того, смарт-контракты с высоким потреблением вычислений могут вызвать атаки DoS, приводя к исчерпанию ресурсов. Кроме того, если байт-код смарт-контракта содержит неаудированные уязвимости, легко вызвать риски выполнения произвольного кода и повышения прав.

4.2 Модуль обнаружения узлов P2P и синхронизации данных

Поверхность атаки: Если функции обнаружения и синхронизации узлов P2P разработаны неправильно, легко столкнуться с атакой Сибил (Sybil Attack), контролируя сеть через подделку большого количества ложных узлов, приводя к снижению производительности сети или даже失效. Загрязнение таблицы маршрутизации в процессе синхронизации данных узлов повлияет на качество соединения между узлами, делая部分 узлов недоступными. Кроме того, в пакетах данных могут存在 подделанные или злонамеренные данные, приводя к тому, что узлы получают错误 информацию,进而 влияя на синхронизацию и консенсус.

4.3 Модуль парсинга блоков

Поверхность атаки: Парсинг блоков涉及 большую обработку данных, если в коде парсинга存在 переполнение или错误 обработки, это может быть атаковано злонамеренными блоками, приводя к сбою сервиса или отказу в обслуживании (DoS). Кроме того, неправильная верификация формата блока может привести к тому, что блоки, передаваемые по сети, будут篡改 и не могут быть识别,进而 влияя на согласованность всей сети.

4.4 Модуль парсинга транзакций

Поверхность атаки: Парсинг транзакций涉及 верификацию структуры транзакций и подписи, если неправильно обрабатывать подделанные форматы транзакций, злонамеренные данные или аномальные подписи, это может привести к прохождению ложных транзакций, потребляя системные ресурсы. Кроме того, если в парсинге транзакций存在 проблемы переполнения границ, это также может быть использовано для выполнения атак инъекции памяти.

4.5 Пул памяти транзакций

Поверхность атаки: Пул памяти является временной зоной хранения перед входом транзакций в цепочку, может быть злоупотреблен для вставки большого количества недействительных транзакций или злонамеренных транзакций, приводя к атаке占用 памяти, делая узлы неспособными отвечать на нормальные запросы. Кроме того, злонамеренные атакующие могут использовать пул памяти транзакций для вставки повторных или высокочастотных транзакций,进一步 вызывая истощение ресурсов и риски DoS.

4.6 Модуль протокола консенсуса

Поверхность атаки: Когда механизм консенсуса разработан несовершенно или манипулируется, может столкнуться с проблемами атак двойного spending, эгоистичного майнинга, атак 51% и т. д. Атакующие могут выполнять злонамеренные форки через контроль более половины вычислительной мощности, влияя на легитимность записей транзакций. Кроме того, некоторые механизмы консенсуса при столкновении с высокой задержкой или разделенной сетью могут失效 из-за отсутствия явных механизмов отказоустойчивости.

4.7 Интерфейс RPC

Поверхность атаки: Интерфейс RPC является путем взаимодействия внешних систем с узлами блокчейна, если конфигурация прав доступа неправильна, это может привести к несанкционированному доступу и утечке данных. Если привилегированные интерфейсы RPC не защищены должным образом, атакующие могут подделывать запросы для выполнения операций с высокими правами,进一步 манипулируя данными в цепочке. Кроме того, интерфейсы RPC легко столкнуться с атаками наводнения запросами, приводя к перегрузке ответа узлов.

4.8 Модуль обработки логов

Поверхность атаки: Модуль логов отвечает за запись подробной информации о работе системы, если атакующие могут写入 подделанное содержание логов через инъекцию логов, это может привести к утечке конфиденциальной информации. Чрезмерно записанные логи также могут быть злонамеренно использованы, вызывая膨胀 логов, приводя к потреблению ресурсов хранения или даже недоступности системы.

4.9 Сетевое промежуточное ПО

Поверхность атаки: Если промежуточное ПО коммуникации сети блокчейна не имеет механизмов шифрования передачи и аутентификации идентичности, может столкнуться с атакой человек посередине (MITM), приводя к перехвату и篡改 пакетов данных. Кроме того, промежуточное ПО легко подвержено атакам трафика (например, DoS) и атакам злоупотребления протоколом, влияя на нормальную коммуникацию всей сети.

4.10 Алгоритмы шифрования

Поверхность атаки: Дизайн и реализация алгоритмов шифрования напрямую относятся к безопасности данных. Если存在 уязвимости коллизии хеширования, это может привести к подделке содержания транзакций; если алгоритмы шифрования не следуют принципу сильной случайности, это может сделать ключи утекаемыми. Другие распространенные атаки также включают атаки по侧信道, например, получение конфиденциальной информации через观察 потребления энергии или электромагнитной утечки в процессе выполнения шифрования.

4.11 Экономическая модель

Поверхность атаки: Дизайн экономической модели блокчейна должен балансировать стимулы всех сторон, в противном случае это может привести к тому, что атакующие влияют на стабильность системы через манипулирование циркуляцией токенов, снижение вознаграждений майнеров и т. д. Неразумный дизайн стимулирования экономической модели может привести к тому, что майнеры (или узлы валидации) не выполняют поведение в соответствии с ожиданиями, принося риски экономических атак.

4.12 Модуль хранения данных

Поверхность атаки: Данные в цепочке и данные вне цепочки存储存在 риски несанкционированного доступа,篡改 и стойкости данных. Атакующие могут попробовать использовать недостаточные права базы данных или небезопасные механизмы хранения, напрямую修改 данные реестра или состояние смарт-контрактов. Кроме того, неразумная стратегия хранения данных может привести к膨胀 данных, влияя на производительность системы.

4.13 Модуль управления состоянием

Поверхность атаки: Управление состоянием блокчейна используется для записи ключевых данных, таких как баланс счетов, хранение контрактов и т. д. Если модуль управления состоянием разработан неправильно, это может быть использовано атакующими, вызывая ошибки баланса счетов или篡改 информации о состоянии. Злонамеренные атакующие также могут через构造特殊 транзакции вызывать захват состояния, вызывая блокировку ресурсов.

Заключение

Обобщая вышесказанное, хотя блокчейн-экосистема полна инноваций и потенциала развития, ее проблемы безопасности также нельзя игнорировать. В этой статье подробно обсуждаются типы уязвимостей безопасности в нескольких ключевых областях, от межсетевой коммуникации, цепочек приложений Cosmos, расширенной экосистемы Bitcoin до уязвимостей языков программирования, уязвимостей сети P2P, атак DoS, уязвимостей криптографии и безопасности реестра. Через систематический анализ и обобщение,旨在 помочь разработчикам и специалистам по безопасности идентифицировать потенциальные риски, принимать эффективные меры профилактики, повышая общий уровень безопасности. Столкнувшись с日益 сложными и разнообразными вызовами безопасности, только постоянно усиливая способности технической защиты, совершенствуя механизмы аудита безопасности и способствуя сотрудничеству и обмену внутри отрасли, можно确保 здоровье и устойчивое развитие технологии блокчейн. ScaleBit и其 материнская компания BitsLab будут постоянно стремиться к исследованиям безопасности блокчейна, предоставляя前瞻тивные решения безопасности, внося вклад в построение более稳固 и доверенной блокчейн-экосистемы.

Читать и скачивать «Отчет о панорамном观察新兴生态公链 и безопасности за 2024 год»：https://bitslab.xyz/reports-page

О ScaleBit

ScaleBit, суббренд под BitsLab, является командой безопасности блокчейна, предоставляющей решения безопасности для массового внедрения Web3. Опираясь на профессиональные способности в области технологий масштабирования, таких как блокчейн跨链 и доказательства с нулевым разглашением, мы в основном предоставляем тщательный и передовой аудит безопасности для ZKP, Bitcoin Layer 2 и跨链 приложений.

Команда ScaleBit состоит из экспертов по безопасности с богатым опытом в академических и корпоративных кругах, стремящихся提供安全保障 для масштабного применения масштабируемой блокчейн-экосистемы.

О BitsLab

BitsLab — это организация безопасности, стремящаяся защищать и строить新兴 Web3 экосистему, видение которой состоит в том, чтобы стать уважаемым институтом безопасности Web3 в отрасли и пользователями. Под ней有三子 бренда: MoveBit, ScaleBit и TonBit.

BitsLab фокусируется на разработке инфраструктуры и аудите безопасности新兴 экосистем, охватывая, но не ограничиваясь экосистемами Sui, Aptos, TON, Linea, BNB Chain, Soneium, Starknet, Movement, Monad, Internet Computer и Solana и т. д. В то же время BitsLab продемонстрировала глубокую профессиональную способность в аудите различных языков программирования, включая Circom, Halo2, Move, Cairo, Tact, FunC, Vyper и Solidity и т. д.

Команда BitsLab объединила нескольких顶级 экспертов по исследованиям уязвимостей, они多次荣获 международные награды CTF и обнаружили ключевые уязвимости в известных проектах, таких как TON, Aptos, Sui, Nervos, OKX и Cosmos и т. д.