Web3 Безопасность: Новая игра "Кошки-мышки" на цепи, Снайперские боты нацеливаются на налогоплательщиков

Фон

В предыдущей статье CertiK под названием "Раскрытие масштабной схемы RugPull, нацеленной на новых роботов на цепи", был обнародован адрес автоматической машины для сбора урожая 0xdf1a для крупномасштабного мошенничества (известного как RugPull), который завершил более 200 RugPulls всего за два месяца. Однако эта группа не использовала только одну технику RugPull.

В предыдущей статье был использован токен MUMI в качестве примера для описания техники RugPull группы, стоящей за этим адресом: путем прямого изменения баланса токена адреса сбора налогов через кодовую заднюю дверь, без изменения общего объема токенов или отправки события Transfer, что делает невозможным для пользователей, просматривающих etherscan, обнаружить секретное монетизирование токенов команды проекта.

В сегодняшней статье анализируется еще одна техника RugPull группы, использующей токен "ZhongHua" в качестве примера: маскировка функции передачи, которая может быть использована для RugPull, сложной логикой налоговой функциональности. Далее мы проанализируем детали еще одной техники RugPull адреса 0xdf1a на примере токена "ZhongHua".

Глубокое погружение в мошенничество

В данном случае команда проекта обменяла общее количество 9,99 триллиона ZhongHua на приблизительно 5,884 WETH, истощив ликвидность пула. Чтобы погрузиться глубже во всю схему RugPull, давайте рассмотрим события с самого начала.

Развертывание токена

В 1:40 ночи 18 января (время UTC, такое же ниже), адрес атакующего (😈0x74fc) развернул токен ERC20 под названием ZhongHua (🪙0x71d7) и предварительно добыл 10 миллиардов токенов для отправки на адрес атакующего (😈0x74fcfc).

Предварительно добытое количество токенов соответствует количеству, определенному в исходном коде контракта.

Добавление ликвидности

В 1:50 (через 10 минут после создания токена) адрес атакующего (😈0x74fc) предоставил разрешение маршрутизатору Uniswap V2 для токена ZhongHua для подготовки к добавлению ликвидности.

Через минуту адрес атакующего (😈0x74fc) вызвал функцию addLiquidityETH в маршрутизаторе для добавления ликвидности для создания пула ликвидности ZhongHua-WETH (🦄0x5c8b), добавив все предварительно добытые токены и 1,5 ETH в пул ликвидности, в итоге получив приблизительно 1,225 токенов LP.

Из записей выше о передаче токенов видно, что одна передача - это отправка атакующим (😈0x74fc) 0 токенов самому контракту токена ZhongHua.

Эта передача не является обычной передачей для добавления ликвидности. Изучив исходный код контракта токена, было обнаружено, что есть функция _getAmount, ответственная за вычет с адреса отправителя и расчет комиссии, которую нужно взять, затем отправить комиссию на адрес токена и вызвать событие Transfer, указывающее, что адрес токена получил комиссию.

Функция _getAmount будет проверять, является ли отправитель передачи _owner, и если да, то устанавливать комиссию в 0. _Owner назначается при развертывании контракта Ownable входным параметром функции конструктора.

Контракт токена ZhongHua наследует контракт Ownable и назначает адрес отправителя развертывающего контракт msg.sender в качестве входного параметра функции конструктора Ownable при развертывании.

Следовательно, адрес атакующего (😈0x74fc) является _owner контракта токена. 0 токенов

n transfer during liquidity addition is sent through the _getAmount function because _getAmount is called within the transfer and transferFrom functions.

Постоянная блокировка ликвидности

В 1:51 (в течение 1 минуты после создания пула ликвидности) злоумышленный адрес (😈0x74fc) напрямую отправил все 1.225 токенов LP, полученных при добавлении ликвидности, на адрес 0xdead для постоянной блокировки токенов LP.

Аналогично случаю с токеном MUMI, после блокировки LP теоретически злоумышленный адрес (😈0x74fc) больше не имеет возможности совершить RugPull, удалив ликвидность. В мошенничестве RugPull, нацеленном на новых роботов под управлением адреса 0xdf1a, этот шаг в основном используется для обмана анти-мошеннических скриптов новых роботов.

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

RugPull

В 2:10 утра (примерно через 30 минут после создания токена ZhongHua) злоумышленный адрес 2 (👹0x5100) развернул атакующий контракт (🔪0xc403) специально для RugPull.

Аналогично случаю с токеном MUMI, команда проекта не использовала адрес атаки, развернувший контракт токена ZhongHua, а контракт атаки, используемый для RugPull, не является открытым исходным кодом. Цель - увеличить сложность отслеживания техническим персоналом, общее свойство большинства мошеннических схем RugPull.

В 7:46 утра (примерно через 6 часов после создания контракта токена) злоумышленный адрес 2 (👹0x5100) осуществил RugPull.

Вызвав метод "swapExactETHForTokens" контракта атаки (🔪0xc403), они обменяли примерно 9,99 триллиона токенов ZhongHua на примерно 5,884 ETH и истощили большую часть ликвидности в пуле.

Поскольку контракт атаки (🔪0xc403) не является открытым исходным кодом, мы декомпилировали его байткод, и результат следующий:

https://app.dedaub.com/ethereum/address/0xc40343c5d0e9744a7dfd8eb7cd311e9cec49bd2e/decompiled

Основная функция функции "swapExactETHForTokens" в контракте атаки (🔪0xc403) заключается в том, чтобы сначала предоставить UniswapV2 Router максимальное разрешение на передачу токенов ZhongHua, затем обменять указанное количество "xt" токенов ZhongHua (принадлежащих контракту атаки (🔪0xc403)) на ETH через Router и отправить его на объявленный в контракте атаки (🔪0xc403) адрес "rescue".

<img src="https://img.bitgetimg.com/multiLang/image/888f490a178</p> </div></div></div><p>Вы можете видеть, что адрес, соответствующий " _rescue", является развертывающим контракт атаки (🔪0xc403): адрес злоумышленника 2 (👹0x5100).< p>

Входной параметр xt этой транзакции RugPull составляет 999,000,000,000,000,000,000, что соответствует 9,99 миллиарда токенов ZhongHua (десятичное значение ZhongHua равно 9).

Наконец, команда проекта использовала 9,99 миллиарда токенов ZhongHua для истощения WETH в пуле ликвидности, завершив RugPull.

Аналогично случаю с MUMI в предыдущей статье, нам необходимо сначала подтвердить источник токенов ZhongHua в контракте атаки (🔪0xc403). Из предыдущего текста мы знаем, что общее количество токенов ZhongHua составляет 1 миллиард. Однако после RugPull мы обнаружили, что общее количество токенов ZhongHua, запрошенное в блоке explОрер все еще составляет 1 миллиард, но количество токенов, проданных атакующим контрактом (🔪0xc403), составляет 9,99 миллиарда, что в 999 раз превышает общее количество токенов, зарегистрированное в контракте. Откуда взялись эти токены, значительно превышающие общее количество? Мы изучили историю событий передачи ERC20 контракта и обнаружили, что, подобно случаю RugPull токена MUMI, в случае токена ZhongHua атакующий контракт (🔪0xc403) также не имел никаких событий передачи ERC20 токенов. В случае MUMI токена токены налогового контракта поступали непосредственно из изменения баланса в токен-контракте, что позволяло налоговому контракту непосредственно владеть токенами, значительно превышающими общее количество. Поскольку контракт токена MUMI не соответственно изменяет totalSupply токена при изменении баланса, и не вызывает событие Transfer, мы не можем увидеть запись о передаче токенов налоговому контракту в случае MUMI, как будто токены, использованные налоговым контрактом для RugPull, появились из воздуха. Возвращаясь к случаю ZhongHua, токены ZhongHua в атакующем контракте (🔪0xc403) также, кажется, появились из воздуха, поэтому мы также искали ключевое слово "баланс" в контракте токена ZhongHua. Результаты показывают, что во всем контракте токена есть только три изменения переменной баланса, в функциях "_getAmount", "_transferFrom" и "_transferBasic" соответственно. Среди них, "_getAmount" используется для обработки логики сбора комиссий за передачу, в то время как "_transferFrom" и "_transferBasic" используются для обработки логики передачи, без каких-либо явных утверждений о прямом изменении баланса, как это явно показано в случае токена MUMI на рисунке ниже. Более важно, в контракте токена ZhongHua, будь то в функциях "_getAmount", "_transferFrom" или "_transferBasic", после изменения баланса, они правильно вызывают событие Transfer. Это противоречит ситуации, когда мы не могли найти событие Transfer, связанное с передачей токенов в атакующий контракт (🔪0xc403) при запросе событий Transfer. Возможно ли, что, в отличие от случая MUMI, токены в атакующем контракте (🔪0xc403) на этот раз действительно появились из воздуха? **Методология Раскрыта** **Откуда взялись токены в атакующем контракте** Во время анализа случая, когда мы обнаружили, что каждое изменение баланса в контракте ZhongHua правильно вызывало событие Transfer, но мы все равно не могли найти никаких записей или событий Transfer, связанных с передачей токенов в атакующий контракт (🔪0xc403), нам нужно было найти новый аналитический подход. Мы просмотрели большое количество записей о передаче и даже рассмотрели функцию "performZhongSwap" в контракте как возможную точку входа. Эта функция отвечает за продажу токенов в токен-контракте, и во многих других случаях RugPull, которые мы анализировали, такие функции служат как бэкдоры RugPull. Несмотря на проверку других функций, мы так и не нашли ничего. Поэтому мы начали сосредотачиваться на самой функции "transfer". Независимо от того, как атакующий осуществляет RugPull, логика реализации функции "transfer" должна содержать наиболее важную информацию.

Фатальный перевод

Функция "transfer" в контракте токена напрямую вызывает функцию "_transferFrom".

Похоже, что функция "transfer" выполняет операции по передаче токенов, и после завершения передачи вызывает событие Transfer.

Однако перед выполнением передачи токенов функция "transfer" сначала использует функцию "_isNotTax" для проверки, является ли отправитель передачи адресом, освобожденным от налогов: если нет, то использует функцию "_getAmount" для сбора налогов; если да, то налоги не взимаются, и токены отправляются непосредственно получателю. И вот в чем проблема.

Как упоминалось ранее, в реализации "_getAmount" контракт токена проверяет баланс отправителя, вычитает сумму у отправителя, а затем отправляет комиссию контракту токена.

Проблема заключается в том, что "_getAmount" вызывается только тогда, когда отправитель не является адресом, освобожденным от налогов. Когда отправитель является адресом, освобожденным от налогов, баланс получателя напрямую увеличивается на сумму.

На этом этапе проблема становится очень явной: когда адрес, освобожденный от налогов, действует в качестве отправителя для передачи, контракт токена не проверяет, достаточен ли баланс отправителя, или даже вычитает сумму из баланса отправителя. Это означает, что пока контракт токена определяет адрес как освобожденный от налогов, он может отправлять любое количество токенов на любой адрес. Вот почему атакующий контракт (🔪0xc403) смог передать токены в размере 999 раз общего объема.

При проверке было обнаружено, что контракт токена устанавливает только _taxReceipt как адрес, освобожденный от налогов, в конструкторе, и _taxReceipt соответствует адресу атакующего контракта (🔪0xc403).

Это подтверждает метод RugPull для токена ZhongHua: Атакующий использовал определенную логику для обхода проверки баланса привилегированных адресов, позволяя привилегированному адресу передавать токены из воздуха, тем самым завершая RugPull.

Как получить прибыль

Используя указанную уязвимость, атакующий адрес 2 (👹0x5100) напрямую вызвал атакующий контракт с привилегиями (🔪0xc403) для выполнения "swapExactETHForTokens" и завершения RugPull. В функции "swapExactETHForTokens" атакующий контракт (🔪0xc403) предоставил разрешение на передачу токенов Uniswap V2 Router, затем напрямую вызвал функцию обмена токенов Router, обменивая 9,99 миллиарда токенов ZhongHua на 5,88 ETH из пула.

Помимо упомянутой выше транзакции RugPull, командa проекта также продала токены 11 раз через атакующий контракт (🔪0xc403), накопив 9,64 ETH. Включая окончательную транзакцию RugPull, было получено всего 15,52 ETH. Стоимость составила всего 1,5 ETH за добавление ликвидности, небольшое количество комиссий за развертывание контрактов и небольшое количество ETH, потраченное на привлечение новых роботов-торгов и активных бирж.

В какой-то момент команда проекта даже использовала различные адреса EOA для вызова атакующего контракта (🔪0xc403) для продажи токенов, делая вид, что разные отправители продавали токены, чтобы замаскировать свои намерения постоянного вывода средств.

Итог

Проанализировав весь случай RugPull токена Zh

Токен ZhongHua, обнаружено, что сам метод довольно прост, просто отменяется проверка баланса токенов привилегированных адресов. Однако почему анализ этого случая был не таким гладким? Возможно, есть две основные причины:

1. Различные точки зрения на защиту безопасности и атаки. Для специалистов по безопасности проверка баланса в коде является самыми базовыми мерами безопасности, которые необходимо выполнить. Поэтому большинство специалистов по безопасности подсознательно предполагают, что функция "передачи" будет естественным образом проверять балансы пользователей, снижая бдительность против таких уязвимостей (или считая, что такие уязвимости слишком базовы для того, чтобы атакующие могли использовать).

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

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

Сравнивая методы RugPull команд для токенов MUMI и ZhongHua, обе использовали относительно скрытые методы, чтобы дать привилегированным адресам контроль над большим количеством токенов.

В случае RugPull токена MUMI, команда проекта напрямую изменяла балансы, не изменяя totalSupply или вызывая события Transfer, что делало пользователей неосведомленными о том, что у привилегированных адресов уже было большое количество токенов.

В случае токена ZhongHua, это было еще более тщательно, путем прямого не проверки баланса привилегированных адресов, что делало невозможным обнаружение через любые другие средства, кроме просмотра исходного кода, что у привилегированных адресов было неограниченное количество токенов (запрос balanceOf для привилегированного адреса показал бы баланс 0, но все равно можно было бы передать бесконечное количество токенов).

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