Обсуждаем безопасность смарт-контрактов в интервью с директором Psy Labs

Консалтинговая компания Psy Labs специализируется на работе со смарт-контрактами для DEX и CEX, DeFi-протоколов, NFT-проектов, трейдинговых ботов и прочих. Ребята создают смарт-контракты в блокчейн-сетях Ethereum, Sui, Cardano, Polkadot, Near Protocol, Ripple, Solana и Holochain. 

В команде Psy Labs работают бывшие сотрудники Meta, McKinsey, Binance, Kaspersky и других отраслевых гигантов, разрабатывая криптографические решения с нуля и до полного развертывания. Но что оказалось важнее в контексте нашего знакомства, специалисты Psy Labs обеспечивают также безопасность своих и сторонних смарт-контрактов, что особенно актуально в свете многомиллионных потерь, которые испытывает Web3-индустрия в результате хакерских атак. 

На вопросы редакции CP Media ответил сооснователь и технический директор Psy Labs, Михаил Белоус. Своими знаниями в обеспечении безопасности смарт-контрактов он поделился на основе опыта использования программного обеспечения SmartSafe, разработанного командой Psy Labs в качестве аутсорс-продукта. Но начали мы, как и полагается, немного издалека…

Почему вы решили заняться разработкой смарт-контрактов?

Разработка смарт-контрактов — наиболее популярная услуга в нашей сфере, так как они являются основной составляющей подавляющего большинства криптопроектов.

В какой момент возник запрос на разработку системы обнаружения уязвимостей для смарт-контрактов? 

Появились новости о крупных взломах смарт-контрактов, таких как взлом The DAO. Эти инциденты показали уязвимость даже хорошо финансируемых проектов и заставили всех немного понервничать.

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

Что вы думаете об уровне безопасности смарт-контрактов сегодня?

Сегодня разработчики имеют доступ к современным инструментам и платформам, созданным специально для обеспечения безопасности смарт-контрактов. Например, для математического доказательства корректности контрактов используются инструменты формальной верификации, что было не так распространено еще несколько лет назад. Кроме того, заметна тенденция к внедрению в платформы смарт-контрактов более безопасных языков программирования, например Vyper для Ethereum, призванных уменьшить потенциальные лазейки в системе безопасности (в тот период времени, когда готовилось интервью, уязвимости нашлись и в Vyper, прим. ред.).

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

Что вам кажется наиболее проблематичным в этом вопросе? 

В области безопасности смарт-контрактов одной из наиболее актуальных проблем является неизменяемость блокчейна. После развертывания смарт-контракта он не может быть изменен. Таким образом, любая уязвимость или недостаток в контракте остается навсегда, подвергая его потенциальной эксплуатации. Упомянутый уже печально известный взлом The DAO на платформе Ethereum, в результате которого было потеряно около $60 млн, стал ярким напоминанием об этой проблеме.

Кроме того, стремительное развитие сектора DeFi привело к возникновению сложных взаимодействий между смарт-контрактами. Иногда это может привести к появлению непредвиденных уязвимостей. В качестве примера можно привести атаку на платформу bZx, в ходе которой злоумышленники ловко манипулировали протоколом через серию DeFi-транзакций, что привело к значительным финансовым потерям.

Могли бы вы рассказать про пять наиболее распространенных типов уязвимостей, с которыми вы сталкиваетесь?

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

1. Атаки реентерабельности. Эта атака, пожалуй, наиболее известна как раз благодаря взлому The DAO. В двух словах, она позволяет злоумышленнику повторно войти в функцию и выполнить ее несколько раз до завершения ее первоначального вызова. Это похоже на пропуск пластинки на проигрывателе, когда одна и та же строка проигрывается снова и снова, прежде чем перейти к следующему действию.
2. Неконтролируемое переполнение и недополнение целых чисел. Здесь числа могут выходить за установленные пределы. Представьте себе автомобильный одометр, который сбрасывается на ноль после достижения максимального показателя. В мире смарт-контрактов это может привести к ситуации, когда, например, при вычитании из низкого баланса получается не отрицательное, а очень большое число.
3. Открытые функции. Иногда разработчики случайно оставляют функции, известные как публичные или внешние — это означает, что любой может их вызвать. Это сродни тому, как если бы вы оставили входную дверь своего дома открытой, и любой проходящий мимо человек мог бы просто зайти.
4. Проблемы с лимитом газа. Контракты, требующие больше газа, чем установлено в блоке, могут безвозвратно застрять. Это можно сравнить с попыткой запитать целый город от одной батарейки AA. Хотя это не всегда является вектором атаки, но может привести к блокировке средств или невозможности использования контрактов.
5. Неадекватное протоколирование событий. Может показаться, что это не совсем типичная уязвимость, но для dApp она крайне важна. Без надлежащего ведения журналов событий dApp может отображаться или работать некорректно, и пользователи могут остаться в неведении. Это похоже на приборную панель автомобиля, на которой не отображается скорость или уровень топлива, в итоге водитель едет вслепую.

Можете ли вы более подробно описать ваш анализатор смарт-контрактов? Какие методы он использует для выявления уязвимостей?

Анализатор смарт-контрактов является стержнем нашей системы обнаружения уязвимостей. Позвольте мне рассказать про его основные компоненты:

1. Разбор абстрактного синтаксического дерева (AST). По своей сути AST помогает нам понять структуру и иерархию кода смарт-контракта. Представьте, что вы берете сложное предложение и разбиваете его на составные части речи. Именно это и делает AST, но только для кода. Анализируя эту структуру, мы можем выявить участки, которые могут быть подвержены определенным уязвимостям.
2. Анализ потока управления. Здесь рассматриваются возможные пути прохождения транзакции от ее начала до завершения. Это можно сравнить с составлением схемы всех возможных маршрутов, по которым можно отправиться в путешествие, чтобы выявить потенциальные опасности и препятствия на каждом из них.
3. Анализ потоков данных. Этот метод позволяет проследить, как данные перемещаются и изменяются в рамках контракта. Представьте себе, что вода течет по ряду взаимосвязанных труб, и вы хотите отслеживать ее движение и места возможного загрязнения.
4. Интеграция с Rule Engine. Наш анализатор работает в связке с Rule Engine, который содержит набор предопределенных правил, полученных на основе известных уязвимостей и наших исследований. Представьте себе, что у вас есть контрольный список того, что не следует делать — Rule Engine имеет этот список и сопоставляет его с результатами анализа AST, управления и потоков данных.
5. Компонент машинного обучения. Со временем, по мере того как наша система просматривает все больше контрактов, она учится на основе выявленных закономерностей. Так, если в экосистеме появляется новый паттерн уязвимости, наш анализатор может обнаружить его, даже если он еще не был формально определен в нашем механизме правил. Представьте, что это самообновляющаяся энциклопедия, которая становится тем умнее, чем больше она читает.

Какова роль и механизм работы Rule Engine в вашей системе?

По своей сути Rule Engine — это обширная библиотека, содержащая предопределенные правила или шаблоны, которые соответствуют известным уязвимостям. Рассматривайте его как справочник по тому, что не следует делать при написании смарт-контракта.

Как происходит интеграция вашего фреймворка с другими инструментами разработки смарт-контрактов?

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

1. Поддержка интерфейса командной строки (CLI). На самом базовом уровне наш фреймворк предлагает инструмент CLI. Он позволяет разработчикам выполнять проверку уязвимостей прямо из привычной среды командной строки. Это можно сравнить с инструментом проверки грамматики, который можно быстро запустить в документе, только для уязвимостей смарт-контрактов.
2. Совместимость с конвейером CI/CD. Непрерывная интеграция и непрерывное развертывание (CI/CD) являются основой современной доставки программного обеспечения. Наш фреймворк идеально вписывается в эти конвейеры, обеспечивая проверку уязвимостей на всех этапах процесса разработки и развертывания. Представьте себе, что это контрольная точка контроля качества на сборочном конвейере.
3. Подключаемые модули для IDE. Мы понимаем, что разработчики проводят много времени в своих интегрированных средах разработки (IDE). Поэтому мы разрабатываем подключаемые модули, которые интегрируются непосредственно с популярными IDE. Это позволяет получать обратную связь в реальном времени, когда разработчики пишут или изменяют код смарт-контракта, почти как красные подчеркивания под неправильно написанными словами при наборе текста в текстовом редакторе.

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

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

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

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

Какие у вас планы на развитие вашей системы? Есть ли новые функции или улучшения, которые вы планируете внедрить?

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

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

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

Не будем забывать и о совместной работе. Мы, внутри Psy Labs, часто обсуждаем способы превращения нашей системы в центр взаимодействия, где различные заинтересованные стороны могут собираться вместе, обмениваться мнениями и совместно работать над решениями.