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

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

Исследователи отметили неэффективность сканеров кода:

1. Сканеры кода способны выявить лишь самые примитивные ошибки программирования и не заменяют собой полноценный аудит и рефакторинг. 
2. Почти все автоматические системы онлайн-аудита смарт контрактов не более чем обработчики регулярных выражений, по которым ищут шаблонные уязвимости из списка собственной базы уязвимостей. 
3. Аудиторы, которые предлагают просто проверить код сканером, обычно умалчивают, что такая работа занимает всего лишь 10% времени, а 90% — это поиск и верификация уязвимостей, что и является самой большой ценностью аудита.

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

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. 

«Все меняется, и разработчик, скорее всего, случайно пропустил одну устаревшую функцию. По большому счету проблема решается использованием другой библиотеки», — указали в HackControl.

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

И не смарт-контрактом единым…

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

• основной сайт и личный кабинет пользователя;
• систему онлайн-платежей;
• API;
• шлюз взаимодействия со сторонними вендорами;
• мобильное приложение;
• внутреннюю сеть компании.

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

Подписывайтесь на новости ForkLog в Telegram: ForkLog Feed — вся лента новостей, ForkLog — самые важные новости и опросы.