Новости Хакерская «прожарка»: специалисты рассказали о тонкостях аудита смарт-контрактов

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

Исследователи отметили неэффективность сканеров кода. По их словам, сканеры способны выявить лишь самые примитивные ошибки программирования.

«Почти все автоматические системы онлайн-аудита смарт-контрактов являются не более чем обработчиками регулярных выражений, по которым ищут шаблонные уязвимости из списка собственной базы уязвимостей», — отметили в HackControl.
​

Среди наиболее распространенных уязвимостей смарт-контрактов исследователи выделили:

1. Reentrancy. Программа разработана таким образом, что одна и та же копия ее инструкции в памяти может быть одновременно использована несколькими пользователями или процессами. При этом пользователь может инициировать множество транзакций и потенциально превысить баланс своего счета, нанеся ущерб проекту.
2. Timestamp Dependence. Майнер может немного изменить метку времени блока. Количество блоков и среднее время на извлечение могут использоваться для оценки времени, но это не является надежным способом, так как время извлечения переменно.
3. Gas Limit and Loops. Каждый блок имеет верхнюю границу количества газа, которое можно потратить для выполнения компьютерных вычислений. Если израсходованный газ превышает лимит, транзакция не состоится. Это приводит к возможности эксплуатации нескольких векторов отказа в обслуживании. Также в случаях неправильной обработки газа возможно возникновение бесконечных циклов.

В HackControl также рассказали о часто встречающихся DoS- и DDoS-атаках:

• Transaction-Ordering Dependence. Майнер может оказаться злоумышленником:

«Когда вы покупаете товар по заявленной цене, вы ожидаете, что заплатите эту цену, но мошенник может изменить ее до того, как завершится транзакция. Таким мошенником может быть майнер», — объяснили специалисты.
​

• Уязвимость байтового массива (byte array vulnerability). Байтовый массив очень медленный и дорогостоящий, что влияет на быстродействие. Такой массив можно легко «положить» посредством DDoS, отправив ему большое количество запросов.
• Нарушение в API ERC. ERC 20 — это стандартный API для реализации токенов. Биржи и третьи стороны могут столкнуться с трудностями при интеграции токена, который ему не соответствует.
• Непроверенные внешние вызовы/непроверенная математика. Одна из основных опасностей вызова внешних контрактов заключается в том, что они могут взять на себя поток управления и внести изменения в данные, так как язык Solidity склонен к целочисленному переполнению и потере значимости. Переполнение приводит к неожиданным последствиям и к возможной потере средств в случае использования вредоносной учетной записи.
• Malicious libraries. Использовать непроверенные/нестандартизированные библиотеки заведомо небезопасно. Также важно использовать библиотеки с открытым исходным кодом.
• Unsafe type inference. Неявное определение типов переменных приводит к многочисленным ошибкам в коде. Часто полученное число выходит за рамки диапазона указанного типа.

«Очень хорошо, если компилятор вам об этом «скажет», иначе — «большой бум», переполнение буфера и отказ в обслуживании», — отметили специалисты.
​

• Implicit visibility level. Уровни видимости в смарт-контрактах по умолчанию публичные. Нужно явно определять видимость функций и интерфейсов во избежание путаницы и несанкционированного доступа.​

Лучше всего делать аудит контракта после рефакторинга — аудитор должен быть последним, кто вносит правки, подчеркнули в HackControl.

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

Проблема 1. «Все забывают о релизере»

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

«Как-то у другого клиента похожая ошибка привела к тому, что уже после проведения ICO «внезапно» оказалось, что смарт-контракт никто не проверял и абсолютно любой пользователь EТН может выпускать токен вместе с собственником», — рассказали в HackControl.
​

Проблема 2. safeTransfer вместо Transfer

TokenSplitter: 451 должен использовать safeTransfer из библиотеки SafeERC20.

Все найденные ошибки были исправлены.

***

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

Новость Хакерская «прожарка»: специалисты рассказали о тонкостях аудита смарт-контрактов на сайте CoinProject.info.