Децентрализованные финансы безопасность: распространенные уязвимости и меры предосторожности

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

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

Флеш-кредит

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

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

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

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

Манипуляция ценами

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

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

Атака повторного входа

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

Поскольку баланс пользователя устанавливается в 0 только в конце функции, второй вызов ( и последующие вызовы ) все равно будут успешными и будут снова и снова извлекать баланс.

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

1. Не только предотвращение проблемы повторного входа для одной функции;
2. Следуйте модели Checks-Effects-Interactions при кодировании;
3. Используйте проверенный временем модификатор защиты от повторного входа.

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

История уязвимости Omni Protocol --- Сражение между четырьмя хакерами

Мемпул Ethereum постоянно находится под наблюдением множества хакеров, которые анализируют транзакции и осуществляют фронт-раннинг прибыльных сделок для получения прибыли. Атакующая транзакция, представленная обнаружителем уязвимости Omni Protocol, была поймана двумя хакерами, которые использовали фронт-раннинг ботов для захвата 1200 ETH из протокола Omni Protocol через Flashbot, в то время как обнаруживший уязвимость атакующий получил только 480 ETH. В это время один хакер обнаружил атакующую транзакцию фронт-раннера, представленную в Flashbot, и воспользовался тем, что атакующая транзакция требует покупки токенов Doodle ERC20, чтобы провести сэндвич-атаку, что принесло прибыль в 151 ETH.

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

Рекомендации по безопасности

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

Советы по безопасности для проекта

1. Разработка контрактов соответствует лучшим практикам безопасности.

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

Три. Использование временной блокировки: Как в некоторых случаях, если есть временная блокировка, предположим, что она может быть завершена в течение 48 часов, в это время многие, кто следит, могут заметить, что создатель обновил метод mint, который может использовать любой, и наблюдатели поймут, что проект, вероятно, был взломан, и могут уведомить команду проекта о необходимости изменения. Даже если предположить, что уведомление было отправлено, и никто не реагирует, по крайней мере, можно сначала вывести свою часть денег, чтобы обеспечить свои доходы от потерь. Поэтому можно сказать, что если у проекта нет временной блокировки, теоретически увеличивается вероятность возникновения проблем.

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

Пять. Повышение уровня безопасности среди всех сотрудников: Повышение уровня безопасности не требует много технологий. В Twitter мы часто видим, как многие люди теряют NFT из-за фишинга, на самом деле методы фишинга используют человеческие слабости. Если бы мы были немного внимательнее, то не попались бы на это. В большом окружении Web3, если задать немного больше вопросов «почему» и подумать немного больше, можно избежать многих проблем.

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

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

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

Семь, безопасность третьих сторон: В качестве элемента экосистемы у проектов всегда есть свои вверх и вниз по цепочке. Существует принцип "по умолчанию все вверх и вниз по цепочке небезопасны". Необходимо проверять как верхние, так и нижние уровни. Мы очень сложно контролируем третьи стороны, поэтому риск безопасности на самом деле особенно велик, и необходимо уделять особое внимание введению третьих сторон. Контракт является открытым исходным кодом, его можно использовать и вызывать; если контракт не является открытым исходным кодом, его абсолютно нельзя использовать. Потому что мы не знаем, какая логика внутри, или сам контракт является контрактом, который можно обновить. В обычном использовании проблем не возникает, но мы не можем предсказать, не произойдет ли однажды обновление, которое превратит его в злонамеренный контракт, это невозможно контролировать.

Как пользователи/пулы ликвидности могут определить, безопасен ли смарт-контракт?

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

1. Открыт ли контракт: Мы категорически не работаем с проектами, контракты которых не открыты, потому что мы не можем узнать, что написано в контракте.

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

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

Четыре. Является ли контракт代理ным, может ли он быть обновлен, есть ли временная блокировка: Если контракт совершенно не может быть обновлен, то это слишком жестко, все же рекомендуется, чтобы контракт проекта был обновляемым. Однако обновление должно быть разумным, когда в обновлении есть содержание обновления или изменения важных параметров, должна быть временная блокировка, необходимо предоставить всем временное окно для оценки, действительно ли обновление вредно или полезно для пользователей, это также способ обеспечения открытости и прозрачности.

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

Во-вторых, необходимо обратить внимание на то, не слишком ли велики полномочия Owner. Например, в некоторых проектах, связанных с 貔恘盘, Owner может полностью контролировать средства пользователей. Если количество купленных токенов мало, то торговля проходит нормально, но если объем покупки токенов огромен, Owner может сразу же заблокировать их, и они не смогут быть проданы. То же самое касается и некоторых NFT проектов. У нормального проекта полномочия Owner должны быть контролируемыми, так не будет слишком много высокорисковых операций, и операции будут осуществляться с использованием временных замков, чтобы пользователи знали, что именно происходит. Особенно в плохие времена на рынке, когда появляются различные схемы обмана, поэтому всем следует уделять внимание полномочиям Owner.

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