Перевод
Это вольный перевод: consensys.github.io/smart-contract-best-practices/attacks/oracle-manipulation
Манипулирование оракулом
Для корректной работы протоколов иногда требуется дополнительная информация извне блокчейна. Такая оффчейн информация предоставляется оракулами, которые часто сами являются смарт-контрактами.
Уязвимость возникает, когда протоколы, полагающиеся на оракулы, автоматически выполняют действия, даже если предоставленные оракулом данные неверны.
Оракул с устаревшим или даже вредоносным содержимым может иметь катастрофические последствия для всех процессов, подключенных к каналу данных. На практике манипулирование данными может нанести значительный ущерб — от необоснованных ликвидаций до злонамеренных арбитражных сделок. В следующих разделах приведены примеры, иллюстрирующие распространенные уязвимости и неисправности, связанные с оракулами.
Манипуляция спотовыми ценами
Классическая уязвимость приходит из мира ончейн ценовых оракулов: доверие к спотовой цене децентрализованной биржи.
Сценарий прост. Смарт-контракту необходимо определить цену актива, например, когда пользователь вносит ETH в его систему. Для определения цены протокол обращается к соответствующему пулу Uniswap в качестве источника. Эксплуатируя это поведение, злоумышленник может взять флэш-кредит, чтобы опустошить одну из сторон пула Uniswap. Из-за отсутствия разнообразия источников данных, внутренняя цена протокола напрямую манипулируется, например, в 100 раз больше первоначального значения. Теперь злоумышленник может выполнить действие, чтобы захватить эту дополнительную стоимость. Например, можно заключить арбитражную сделку на основе вновь созданной разницы цен или занять выгодную позицию в системе.
Проблемы носят двоякий характер:
- Использование смарт-контракта с единым источником ценового фида позволяет легко манипулировать на цепочке с помощью флэш-кредитов.
- Несмотря на заметную аномалию, смарт-контракты, потребляющие ценовую информацию, продолжают работать на манипулируемых данных.
Более конкретный пример приведён в Visor Hack. При пополнении счета информация о цене берется непосредственно из Uniswap:
uint160 sqrtPrice = TickMath.getSqrtRatioAtTick(currentTick());
uint256 price = FullMath.mulDiv(uint256(sqrtPrice).mul(uint256(sqrtPrice)), PRECISION, 2**(96 * 2));
Здесь функция currentTick() напрямую извлекает текущий тик цены из пула Uniswap:
// @return tick Текущий ценовой тик пула Uniswap
function currentTick() public view returns (int24 tick) {
(, tick, , , , , ) = pool.slot0();
}
Поскольку эти ценовые данные извлекаются из ончейн-зависимости, а данные о цене определяются в контексте текущей транзакции, этой спот-ценой можно манипулировать в той же транзакции.
- Злоумышленник может взять флэш-кредит на входящий актив А и на соответствующем пуле Uniswap обменять актив А на актив В с большим объёмом.
- Эта сделка приведет к повышению цены актива В (увеличение спроса) и снижению стоимости актива А (увеличение предложения).
- Когда актив B вносится в вышеуказанную функцию, его цена все еще повышается за счёт флэш-кредита.
- Следовательно, актив B дает злоумышленнику слишком большое количество акций.
- Эти акции могут быть изъяты, что даст атакующему равные части актива A и актива B из пула
- Повторение этого процесса приведет к тому, что уязвимый пул лишится всех средств
- На деньги, полученные от изъятия своих акций, злоумышленник может погасить флэш-кредит.
Предупреждение! Ни в коем случае не используйте спот-цену децентрализованной биржи непосредственно для определения цены. Безопасный расчёт цены может быть выполнен, например, с помощью средневзвешенных по времени цен (TWAPs) на более длительных временных интервалах. При условии достаточной ликвидности это значительно увеличивает стоимость атаки на манипулирование ценами, делая ее неосуществимой. Примером для облегчения безопасного обнаружения цен является Uniswap V3 OracleLibrary.
Оффчейн инфраструктура
По определению, канал данных, передающий информацию вне цепи в смарт-контракт, требует традиционного программного обеспечения для работы. От сенсорного оборудования или ручного ввода до аутентифицированных API, передающих данные на цепочку, нередко задействуется множество программного обеспечения.
В зависимости от конкретной реализации могут быть осуществлены атаки на контроль доступа, криптографическую реализацию, транспорт, безопасность баз данных и т.д. В результате программное обеспечение, предоставляющее услуги оракула, должно быть усилено и придерживаться лучших практик безопасности, таких как OWASP Secure Coding Practices. Особенно должны быть защищены оракулы, которые не предлагают фазу спора, управляемую сообществом, поскольку их компрометация будет напрямую влиять на зависимые приложения.
Информация (дополнительная)
Эскандари и др. разделили концепцию оракула на следующие шесть модулей:
- Истина
- Источники данных
- Наполнители данных
- Выбор источников данных
- Агрегация
- Фаза спора (арбитража)
В их публикации можно прочитать о принципах проектирования, атаках и мерах по их устранению.
Отличным примером оффчейн-неисправности компонентов, влияющей на передачу данных оракула на цепочке, является инцидент с Synthetix sKRW. Synthetix объединяет несколько связанных прайс-фидов для точного определения цены их производных и выводит совокупность на поверхность через смарт-контракт на цепочке. При ошибочном сообщении значения, в 1000 раз превышающего исходное, цена корейской воны была сообщена значительно выше, даже несмотря на агрегацию. Арбитражный бот использовал этот эффект, что быстро принесло ему прибыль в размере более 1B USD. В то время как агрегация ончейн и отчёт о цене работали правильно, к инциденту привёл отказ компонента оффчейн (поставщиков).
Информация (дополнительная)
Samczsun написал отличную статью в блоге Paradigm, в которой подробно описывается этот инцидент и другие инциденты, связанные с ценовыми оракулами.
Централизованные оракулы и Trust
Проекты также могут выбрать реализацию централизованного оракула. Метод обновления такого смарт-контракта может, например, быть защищён модификатором onlyOwner и требовать от пользователей доверия к правильности и своевременности предоставления данных. В зависимости от размера и структуры системы, такое централизованное доверие может привести к тому, что авторизованный(ые) пользователь(и) получит(ут) стимул для представления вредоносных данных и злоупотребления своим положением.
Кроме того, такие централизованные системы могут нести в себе риск, связанный с компрометацией закрытых ключей.
Безопасность децентрализованных оракулов
Децентрализованные оракулы нацелены на диверсификацию группы сборщиков данных до такой степени, что нарушение кворума участников становится невыполнимой задачей для злоумышленника. В децентрализованном сценарии дополнительные соображения безопасности связаны с тем, как стимулируются участники и какого рода проступки остаются безнаказанными. Участники, предоставляющие (достоверные) данные системе оракула, получают экономическое вознаграждение. Стремясь максимизировать свою прибыль, участники стимулируются предоставлять как можно более дешёвую версию своей услуги.
Freeloading
“Атаки на халяву” — простейшая форма экономии работы и максимизации прибыли.
Узел может использовать другой оракул или оффчейн-компонент (например, API) и просто копировать значения без проверки. Например, оракул, предоставляющий данные о погоде, может ожидать от поставщиков данных измерения температуры и скорости ветра в определённом месте. Однако у узлов есть стимул использовать общедоступный API погодных данных и просто передавать свои данные в систему.
Помимо очевидной проблемы централизации источника данных, атаки такого рода в масштабе могут также серьёзно повлиять на корректность данных. Этот эффект наиболее заметен, когда частота выборки различна, например, ончейн-оракул ожидает частоту выборки в 10 минут, а узлы-халявщики предоставляют данные из API, которые обновляются раз в час.
[Прим. Menaskop: это очередной и явный пример темпографии].
Халява на децентрализованных оракульных рынках данных может усилить ценовую гонку , поскольку халява требует исключительно простого поиска (и отбора).
В то же время надлежащее предоставление данных может потребовать более значительных вычислительных затрат. При меньшей конкуренции в более дешевых ценовых диапазонах несколько узлов-халявщиков могут даже захватить канал данных. Атаки халявщиков могут быть легко предотвращены для более сложных каналов данных путем внедрения схемы фиксации-разоблачения. Эта мера безопасности не позволит участникам системы oracle подглядывать в данные друг друга. Для более простого представления данных можно реализовать проверку согласованности, наказывающую ноды, которые явно копируют данные из известных публичных сервисов.
Сборщики данных, способствующие централизации общего сервиса, будут де-стимулированы.
Решения
В настоящее время самым простым способом решения проблемы оракулов являются децентрализованные оракулы, такие как:
- Chainlink — крупнейший поставщик децентрализованных оракулов, который может быть использован для передачи децентрализованных данных ончейн.
- Tellor — оракул, который предоставляет данные, устойчивые к цензуре, защищённые экономическими стимулами, гарантирующими, что данные могут быть предоставлены кем угодно, в любое время и проверены всеми.
- Witnet использует самые современные криптографические и экономические стимулы для обеспечения смарт-контрактов оффчейн-данными.
Использование медианы из нескольких оракулов обеспечивает повышенную безопасность, поскольку атаковать различные оракулы сложнее и дороже. Это также гарантирует, что смарт-контракт получит необходимые ему данные, даже если один оракул или вызов API не удастся.
Другим стандартным решением является использование средневзвешенной по времени подачи цены, так что цена усредняется за X периодов и из нескольких источников. Это не только предотвращает манипуляции оракула, но и снижает вероятность опережения, так как ордер, исполненный непосредственно перед этим, не может оказать столь сильного влияния на цену. Это условие не относится к низколиквидным активам, которыми обычно дешевле манипулировать, даже в течение длительного времени.
На этом всё и
До!