Взлом в 8,2 млн. Долл. США и слепое пятно в проверке умного контракта Ethereum
15 июля 2025 г.Таблица ссылок
Аннотация и 1. Введение
Фон
2.1 Ethereum Primer
2.2 Проверка адреса белого списка
2.3 Анализ Taint по интеллектуальным контрактам и 2,4 модели угрозы
Мотивирующий пример и проблемы
3.1 Мотивирующий пример
3.2 Проблемы
3.3 Ограничения существующих инструментов
Дизайн Avverifier и 4.1 Обзор
4.2 обозначения
4.3 Компонент № 1: График кода
4.4 Компонент № 2: симулятор EVM
4.5 Компонент № 3: детектор уязвимости
Оценка
5.1 Экспериментальная настройка и исследовательские вопросы
5.2 RQ1: эффективность и эффективность
5.3 RQ2: характеристики уязвимых контрактов реального мира
5.4 RQ3: обнаружение в реальном времени
Дискуссия
6.1 Угрозы для достоверности и 6.2 ограничения
6.3 Этическое рассмотрение
Связанная работа
Заключение, доступность и ссылки
3 мотивирующие пример и проблемы
3.1 Мотивирующий пример
В листинге 3 показан умный контракт, принадлежащий Fisor Finance, который уязвим к уязвимости проверки адреса. Он подвергся нападению 21 декабря 2021 года [11], что привело к 8,2 миллионам финансовых потерь. Как мы видим, функция депозита принимает три аргумента, а именно: количество токенов, которые должны быть депонированы (visrdeposit), плательщика (от) и бенефициара (до). От L6 до L8 он выполняет чеки здравомыслия, то есть допустимая сумма депозита и действительные адреса как для плательщика, так и для получателя. После этого он переводит депозит в акции в соответствии с TotalSupply () (L11 в L14), выполняет соответствующую передачу токена от от адреса до самого себя (L16 до L22) и приносит некоторые токены VVISR к адресу (L24). Уязвимость скрыта в блоке кода IF
в L16. В частности, он позволяет отдать адрес в качестве контракта и рассматривает, возвращает ли его функция владельца адрес инициатора транзакции (L17). Если утверждение проходит, то оно вызывает функцию DelegatedTransfererc20, определенную из. Вспоминая модель угроз, упомянутую в §2.4, злоумышленники могут развернуть контракты и произвольно инициировать транзакции. Более конкретно, если из -за некоторых злонамеренных, они могут контролировать поведение L17 и L18. С этой целью поток управления будет успешно направлен на L24, где VVISR, наконец, выпускает токены, которые также контролируются злоумышленниками, не получая ни каких токенов от этого, которые ожидают разработчиками Finance Finance.
Через этот пример мы можем суммировать три принципа, связанные с уязвимостью проверки адреса:
П1Уязвимая функция принимает адрес в качестве параметра и выполняет недостаточный экзамен на авторизацию по этому адресу.Благодаря адресу, злоумышленники могут пройти самостоятельные и несанкционированные контракты.
П2АдресвП1принимается как цель внешнего вызова.Благодаря внешнему вызову поток управления передается злоумышленникам. Таким образом, они могут полностью контролировать поведение внешнего вызова, включая возвратное значение.
P3Состояния на цепь, которые зависят от потока контроля от возврата, упомянутого вП2обновляются.С этой целью, благодаря несанкционированному потоку управления, противники могут получать прибыль, косвенно манипулируя состояниями в цепочке, например, инициируя внешний вызов или обновление баланса.
3.2 Проблемы
В ответ на уязвимость проверки адреса, как указано в суммированных принципах и мотивирующем примере в §3.1, мы определяем следующие проблемы.
C1: Отсутствие семантики.Сложно точно определить, если бы адрес упомянулся вП1достаточно проверен из -за отсутствия семантики в байт -коде. Согласно статистике [59], более 99% контрактов Ethereum не опубликовали свой исходный код. Формат Bytecode довольно нечитаем и содержит небольшую семантическую информацию. Более того, нет никакой информации отладки, чтобы помочь восстановить семантику. Традиционные инструменты анализа на основе байт-кодов обычно требуют некоторых методов для преодоления этой проблемы, таких как символическое выполнение [70].
C2: межпроцедурный анализ по потоку управления и потоку данных.Обнаружение этой уязвимости требует точного извлечения потока управления и зависимостей потока данных межпроцедурально. В частности, вП2, есть внешний призыв к адресу, который передается через аргумент. Между внешним вызовом и записью функции он будет распространяться несколько раз из -за проверки авторизации. Таким образом, мы должны точно определить, является ли адрес Callee одним из аргументов посредством потока данных. Более того, вP3, обновление состояния внедорожного состояния зависит от возвращаемого значения внешнего вызова вП2С точки зрения потока управления, который требует от нас идентифицировать зависимости потока управления среди переменных. Кроме того, из листинга 2 мы можем сделать вывод, что некоторые разрешения проверены в других функциях, которые требуют межпроцедурного анализа.
Авторы:
(1) Tianle Sun, Университет науки и техники Хуажонга;
(2) Ningyu HE, Peking University;
(3) Цзян Сяо, Университет науки и техники Хуажонга;
(4) Yinliang Yue, лаборатория Zhongguancun;
(5) Сяпу Луо, Гонконгский политехнический университет;
(6) Хаою Ван, Университет науки и техники Хуажонга.
Эта статья есть
Оригинал