Децентрализованные финансы () — одно из самых крупных и быстрорастущих приложений блокчейна и технологии смарт-контрактов. Способность произвести революцию в финансовом секторе, предложив децентрализованные альтернативы традиционным финансовым услугам на основе блокчейна, привела к значительным инвестициям в эту сферу.
Сегодня общая рыночная капитализация проектов DeFi составляет 55 миллиардов долларов. Однако, большая стоимость, вложенная в смарт-контракты DeFi, также делает их частыми объектами атак. Смарт-контракты DeFi можно использовать различными способами, используя уязвимости на разных уровнях экосистемы блокчейна. В этой статье мы рассмотрим распространенные уязвимости в контрактах DeFi, связанные с управлением данными и безопасностью.
Уязвимости безопасности данных
Управление данными и уязвимости безопасности в DeFi
По своей сути, блокчейн и технология смарт-контрактов представляют собой системы обработки и хранения данных. Блокчейн поддерживает неизменяемый цифровой реестр для хранения данных транзакций, а смарт-контракты выполняются поверх этого реестра и обрабатывают хранящиеся в нем данные. Ошибки в управлении данными и безопасности могут оказать значительное влияние на смарт-контракты в целом и смарт-контракты DeFi в частности.
Основные ошибки управления
В системах блокчейна закрытый ключ, управляющий учетной записью блокчейна, является наиболее важной частью данных, которую необходимо защитить. Любой, у кого есть доступ к закрытому ключу учетной записи, может создавать цифровые подписи и транзакции от имени этой учетной записи. Скомпрометированный закрытый ключ может привести к потере криптовалюты и злоупотреблению разрешениями учетной записи на контракты DeFi.
Закрытые ключи блокчейна могут быть скомпрометированы различными способами. Вот некоторые распространенные примеры:
- Использование слабых неслучайных ключей
- Фишинговые атаки
- Небезопасное стороннее хранилище ключей
Уязвимости PRICE ORACLE
Одной из основных возможностей проектов DeFi является обмен токенами разных типов. Например, пользователь блокчейна может захотеть обменять ETH на BNB, чтобы использовать определенные функции в смарт-контракте, использующем BNB, или воспользоваться возможностью арбитража.
Чтобы проекты DeFi поддерживали торги, им нужна информация об обменном курсе между разными токенами. В некоторых случаях, контракты DeFi будут рассчитывать это (внутренне) на основе относительного предложения каждого токена. Например, если в контракте содержится большое количество ETH, он может обеспечить более высокую ставку для тех, кто покупает ETH, чем продает его.
Расчеты значений токенов в цепочке, уязвимы для манипуляций с ценовыми оракулами. Если оценка токена зависит от количества этого токена, доступного для контракта, то этим значением можно манипулировать с помощью атаки flashloan, которая предоставляет злоумышленнику доступ к достаточному количеству токенов, чтобы значительно изменить предложение этого токена, доступного для смарт-контракта.
Многие протоколы DeFi стали жертвами атак с манипулированием ценовыми оракулами, включая Pancake Bunny, Alpha Finance и Spartan Protocol, и это лишь некоторые из них. Эти уязвимости можно смягчить, используя источники информации о ценах токенов вне сети, такие как Chainlink.
Уязвимости сериализации и десериализации
Смарт-контракты предназначены для связи с другими смарт-контрактами. Часто это включает в себя отправку набора переменных, содержащих информацию о состоянии, которую хочет передать контракт.
Вместо того, чтобы отправлять переменные по отдельности, может сериализовать данные в единый поток битов. С другой стороны, получатель может десериализовать эти данные на основе понимания исходного формата данных. Например, зная, что сериализованное значение содержит четыре целых числа, получатель может извлечь эти четыре целых числа.
Сериализация/десериализация данных становится проблемой только в том случае, если код десериализации содержит уязвимости, которые можно использовать (например, уязвимость целочисленного переполнения/опустошения или переполнения буфера), или если сериализованные данные можно интерпретировать несколькими способами. В случае взлома Superfluid уязвимость сериализации данных позволила злоумышленнику украсть 13 миллионов долларов из проекта.
Консенсусные уязвимости
Проекты децентрализованных финансов (DeFi) являются частой целью атак из-за огромной ценности, которую они несут. Токены DeFi имеют общую рыночную капитализацию более 50 миллиардов долларов, а взломы DeFi оцениваются в миллионы. Если злоумышленнику сойдет с рук заработанная нечестным путем прибыль, то проектов DeFi может быть очень прибыльным.
Ранее мы обсуждали уязвимости безопасности данных и их влияние на проекты DeFi. А сейчас мы рассмотрим безопасность алгоритма консенсуса для DeFi.
Добавление блоков в регистр
Многие атаки на консенсус блокчейна и цифровой реестр используют способ добавления транзакций в реестр. Вместо подхода «первым пришел – первым обслужен», большинство блокчейнов реализуют подход «плата за приоритет».
При создании транзакции в блокчейне, пользователь может отправить комиссию вместе с этой транзакцией. Эти сборы идут производителю блока, который в конечном итоге содержит эту транзакцию, поэтому у производителей блоков есть стимул отдавать приоритет транзакциям, которые содержат более высокие комиссии за транзакции.
В результате, транзакция блокчейна, созданная позже, может быть обработана и добавлена в реестр раньше, чем другая транзакция. Кроме того, структура стимулов вокруг комиссий за транзакции может создавать извращенные стимулы для производителей блоков.
Злоупотребление для прибыли
Платный порядок транзакций в блокчейне предоставляет средства для определения того, как транзакции должны быть упорядочены в блоках, когда транзакции могут иметь ненадежные временные метки. Однако, такая конструкция также создает потенциал для злоупотреблений. Два способа, с помощью которых пользователи и узлы блокчейна могут представлять угрозу для консенсуса блокчейна и неизменности реестра, являются опережающими и заставляют форки извлекать максимальную извлекаемую ценность (MEV) из процесса создания блока.
Фронтальные атаки
Фронтальные атаки используют тот факт, что данные транзакций являются общедоступными задолго до того, как они будут добавлены в реестр. Транзакции блокчейна публично транслируются через одноранговую сеть и добавляются в мемпулы узлов для последующего включения в блоки.
Лидеры, которые часто являются автоматическими ботами, сканируют эти неподтвержденные транзакции в поисках тех, которые дают возможность для получения прибыли. Например, предвидение предстоящей сделки может позволить фавориту провести сэндвич-атаку, в которой он совершает сделку до и после незавершенной сделки для получения гарантированной прибыли.
Максимальная извлекаемая ценность (MEV) и разветвление
Пользователи блокчейна платят комиссию производителям блоков за включение транзакций в свои следующие блоки. Эта структура поощрения предназначена для обеспечения справедливого порядка размещения токенов в блоках и предоставления пользователям возможности платить за приоритетность их транзакций.
Теоретически, производители блоков должны учитывать наиболее ценные неподтвержденные транзакции при создании новых блоков. На практике, некоторые производители блоков могут пойти еще дальше.
Неизменяемость блокчейна основана на предположении, что кто-то не может построить конкурирующую версию блокчейна быстрее, чем остальная часть сети. В зрелой цепочке блоков, попытка заменить более чем пару блоков требует большей вычислительной мощности, доли и т. д., чем это возможно для узла или пула.
Однако, перезапись отдельного блока возможна и потенциально выгодна для некоторых узлов. Если ранее созданный блок содержит транзакции с высокими комиссиями, узлу может быть целесообразно разветвить блокчейн. Собирая все недавние дорогостоящие транзакции в созданный ими блок, узел или пул, они могут получить существенную прибыль. Если их версия блокчейна в конце концов выиграет, то они сохранят прибыль.
Эта практика вредит блокчейну и его пользователям, потому что подрывает неизменность цифровой книги блокчейна. Если производители блоков могут переупорядочивать транзакции DeFi, это подрывает доверие к платформе и затрудняет для трейдеров получение прибыли от своих транзакций.
Зашита от консенсусных эффектов
Форки Frontrunning и MEV используют структуру блокчейна, но можно предпринять шаги для управления рисками, которые они представляют. Смарт-контракты DeFi могут ограничить влияние опережения, по возможности сводя к минимуму зависимость от порядка транзакций. Блокчейны могут защититься от форков MEV, наказывая производителей блоков, которые часто создают форки и реорганизации.
Смарт-контракты DeFi являются важными целями для злоумышленников. Однако области разработки смарт-контрактов и DeFi относительно молоды. В результате количество опытных разработчиков ограничено, а некоторые смарт-контракты могут быть написаны людьми без четкого понимания потенциальных рисков безопасности и передового опыта.
Распространенные уязвимости смарт-контрактов
Смарт-контракты, работающие только на платформе Ethereum, могут содержать широкий спектр уязвимостей, которые можно использовать, и несколько блокчейнов поддерживают смарт-контракты. Это некоторые из наиболее распространенных уязвимостей смарт-контрактов, которые влияют на безопасность проектов DeFi.
Арифметические уязвимости
Арифметические уязвимости, такие как целочисленные переполнения и потери значимости, возникают из-за того, что целочисленные типы переменных имеют фиксированный размер в памяти. Эти ограничения размера ограничивают диапазон значений, которые может содержать переменная каждого типа.
Уязвимости целочисленного переполнения возникают, когда значение, которое должно быть сохранено в переменной, превышает ее максимальное значение, в результате чего оно «переворачивается» и интерпретируется как гораздо меньшее значение. Точно так же, целочисленные уязвимости потери значимости возникают, когда значение, которое нужно сохранить, падает ниже минимального значения, в результате чего оно интерпретируется как меньшее значение. Эти события могут возникать в результате арифметических операций (сложение, вычитание, умножение и т. д.) или небезопасного приведения типов (int к uint и т. д.).
Арифметические уязвимости представляют собой серьезную проблему для смарт-контрактов DeFi, поскольку они могут позволить злоумышленнику обойти проверки действительности операции. Например, оператор require(balances[msg.sender] – amount > 0) проблематичен с целыми числами без знака, поскольку результат вычитания всегда будет интерпретироваться как положительное число.
Несоблюдение стандарта ERC-20
Стандарт ERC-20 определяет основные функции, которые должны реализовывать контракты токенов ERC-20. Это включает их ожидаемое поведение и типы данных, включая их возвращаемые значения и то, как они обрабатывают ошибки.
Не все смарт-контракты соответствуют требованиям стандарта ERC-20 по обработке ошибок. Функция смарт-контракта может указать на ошибку одним из двух способов:
- Генерация исключения
- Возвращает ложь
Если вызываемая функция выдает исключение, вызывающая сторона может обработать ошибку, позволив транзакции вернуться, что не требует кода обработки ошибок. Однако, возвращаемое значение false не приводит к возврату, и отсутствие проверки возвращаемых значений может привести к тому, что вызывающий объект продолжит работу, ошибочно предполагая, что передача прошла успешно.
В пространстве DeFi проблемы возникают, когда контракт токена возвращает false после неудачной передачи токена, а контракт DeFi предполагает, что он вернется. Это может позволить злоумышленнику намеренно внести неудачный депозит в контракт и получить взамен токены вознаграждения.
Принудительная отправка Эфириума
В Solidity передача эфира в запускает его резервную функцию. Это позволяет контракту выполнять некоторый код, например обновлять свой внутренний баланс или отправлять токены вознаграждения в ответ.
Резервную функцию также можно использовать для отмены нежелательных передач токенов. Это можно использовать для использования уязвимых контрактов отправки или для управления балансом смарт-контракта.
Однако, если контракт полагается на свою способность отменять транзакции (т. е. имеет логику, которая проверяет, строго ли баланс контракта равен значению), то он может быть уязвим для атаки. Эфир может быть принужден к контракту с помощью самоуничтожающегося контракта, отправки вознаграждений за блок на его адрес или отправки значения на предсказуемый адрес контракта до того, как контракт будет развернут.
Повторный вход
Повторный вход — одна из самых известных уязвимостей смарт-контрактов на платформе Ethereum. Это было причиной печально известного взлома и многих других крупных взломов с тех пор.
Атаки с повторным входом используют функции, которые выполняют следующие шаги в указанном порядке:
- Убедитесь, что транзакция (например, снятие средств) действительна.
- Отправьте эфир на указанный адрес
- Обновление внутреннего отслеживания баланса
- Этот логический поток проблематичен из-за существования резервных функций в Solidity.
На шаге 2 отправка эфира в смарт-контракт вызовет его резервную функцию, что позволит запустить код. Если резервная функция вызывает уязвимую функцию, она повторно входит до того, как произойдет обновление состояния на шаге 3. В результате, злоумышленник может выполнить второй недопустимый вывод средств, поскольку при проверке на шаге 1 используется устаревшее значение.
Уязвимости, связанной с повторным входом, можно избежать, используя шаблон проверки-эффектов-взаимодействия (поменяв местами шаги 2 и 3). Выполнение обновлений состояния перед передачей гарантирует, что значения, используемые на шаге 1, будут актуальными, если вредоносный контракт попытается повторно войти в функцию.
Непроверенные внешние звонки
Как упоминалось ранее, Solidity позволяет функциям смарт-контрактов указывать ошибки несколькими способами. Они могут либо выдать исключение, либо вернуть false.
Это становится проблематичным, если вызывающая функция предполагает, что вызываемая функция вернется. Если функция возвращает false и вызывающий объект не проверяет возвращаемое значение, тогда вызывающий объект может продолжить работу с недопустимым состоянием.
Использование TX.ORIGIN
Значение tx.origin содержит адрес, по которому была выполнена данная транзакция. Сюда входят вызовы функций смарт-контракта, которые могут использовать это значение для управления доступом.
Однако использование tx.origin для управления доступом может сделать смарт-контракт уязвимым для атак. Если злоумышленник может заставить доверенный смарт-контракт выполнить вызов от его имени, то адрес доверенного контракта будет сохранен в tx.origin, что позволит злоумышленнику обойти контроль доступа и получить доступ к ограниченным функциям.
Этот список лишь поверхностно описывает типы уязвимостей, которые могут существовать в смарт-контракте DeFi. В дополнение к этим и другим общим уязвимостям смарт-контрактов контракты DeFi могут также содержать уязвимости, специфичные для DeFi, такие как манипулирование ценовым оракулом. Но, мы надеемся, что теперь наши читателя имеют более глубокое представление о проблемах, связанных с безопасностью в DeFi.
