Всем привет, с вами @kyoukisu (кёкису). В этот раз мы рассмотрим детально атаку reentrancy на более сложном примере. Данная статья является вольным переводом+редактурой информации с Cross-Contract Reentrancy Attack.

Если вам что-то непонятно, тыкайте по встроенным ссылкам, они здесь не просто так.

Перед прочтением обязательно ознакомьтесь с моей первой статьей про reentrancy.

Исходники кода будут ссылками под картинками.

Еще один вид Reentrancy?

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

Cross-Contract Reentrancy возможна, когда соблюдаются следующие условия:

1. Есть места передачи потока управления.
2. Состояния одного контракта используются в другом контракте.
3. Неграмотное построение взаимодействия контрактов.

Пример Cross-Contract Reentrancy

Первый контракт

Рассмотрим простенький ERC20 контракт VaultToken (далее $VT). Обычный ровный токен, имеет свое хранилище бля обеспечения, почти стейбл. В нем используется интерфейс UniswapV2 роутера для того, чтобы свапать сторонние токены, на что-то более надежное, чтобы не стать холдером $LUNA и $UST. Инфу о UniswapV2 роутере можно глянуть в доках юнисвапа.

Vault.sol

Некоторые особенности:

• При создании контракта в конструкторе (18 строчка) мы указываем _router или же интерфейс UniswapV2, а также _baseToken сторонний токен, который будет вноситься пользователями и храниться в контракте, чаще всего это стейбл или эфир.
• В коде можно заметить _burn, _mint, totalSupply; это стандартизированные функции ERC20.sol, от которого мы наследуемся.
• Выдача токена $VT напрямую зависит от доли юзера в общих активах baseToken контракта. Расчеты относительно этой доли происходят в функциях shareToAmount и amountToShare (23 и 27 строчки соответственно).

Что происходит в контракте?

Юзеры вносят какие-то токены _srcToken, неважно какие, пока они сделаны по стандарту ERC20 и имеют ликвидность на Uniswap'e, чтоб контракт мог их сбыть по флору через функцию swapAndDeposit. Потом юзеры жмут deposit и минтят $VT, при вызове withdraw происходит все с точностью да наоборот - сжигают $VT и выводят baseToken, на свои скам токены юзер сам будет менять его.

На каждой функции контракта Vault, которая изменяет его стейт, висит модификатор nonReentrant из контракта ReentrancyGuard.sol, что обеспечивает защиту от повторного входа в данную функцию.

ReentrancyGuard.sol

Второй контракт

Предположим, что у нас есть еще один контракт, некий ICOGov, позволяющий юзерам обменивать $VT на новый токен $GOV - какая-то донная P2E игрушка, проводит ICO, IGO на платформе токена $VT (можете представить здесь панкейк) и хочет бабок. Количество получаемых токенов определяется числом инвестированных $VT и курсом обмена tokenPrice.

ICOGov.sol

При создании контракта в конструктор передаются токен $GOV, токен $VT, _treasury адрес, куда будут скидываться все токены $VT при обмене, а также цену токена.

Функция buyToken как раз таки отвечает за обмен токенов, и, как мы видим, на ней тоже висит модификатор nonReentrant.

Находим уязвимость

Первая вещь, которую мы должны заметить в контракте Vault, это то, что есть передача потока управления контракту _srcToken в функции swapAndDeposit.

Вторая заключается в функции buyToken контракта ICOGov, т.к. она использует стейт Vault'а, обращаясь к нему за shareToAmount.

shareToAmount, в свою очередь, рассчитывает количество выдаваемых токенов. Исходя из этой формулы, становится ясным, что чем больше baseToken на аккаунте Vault и меньше totalSupply, тем больше мы получим токенов $GOV.

Вспомнив условия Cross-Contract Reentrancy и учтя два факта выше, мы можем написать свой scam контракт-токен для _srcToken и использовать его при вызове функции swapAndDeposit в местах передачи потока управления для того, чтобы как можно сильнее раздуть баланс baseToken на контракте Vault и оставить totalSupply неизменным на время атаки - минтим кучу $VT (надо быть китом) и меняем по старому курсу на $GOV (лутаем миллионы).

Вот схема того, что будет происходить во время атаки:

Непосредственно атака

Теперь посмотрим, как можно реализовать контракт-токен для атаки. Для этого мы также, как и в предыдущих контрактах должны унаследоваться от ERC20.sol.

EvilERC20.sol

При создании токена $EVIL мы передаем адреса на Vault.sol, ICOGov.sol и GovToken.sol, чтобы знать куда бить. Также в конструкторе мы минтим владельцу очень много токена $EVIL для того, чтобы он смог создать ликвидность на Uniswap перед атакой, чтоб Vault мог обменивать его на стейбл, не подозревая подвоха.

Заключение

Таким образом, злоумышленнику для атаки требуется:

1. Задеплоить свой контракт токена с измененным approve
2. Добавить ликвидность на пару $EVIL-baseToken на Uniswap'е
3. Получить первоначальное количество токенов $VT на свой контракт
4. Осуществить вызов swapAndDeposit

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

Чтобы такое не произошло с вашим контрактом:

• Убедитесь, что все внутренние изменения состояния выполнены до передачи потока управления - шаблон Checks-Effects-Interactions.
• Предотвращайте запуск неизвестного кода - добавьте whitelist адресов контрактов (токенов).
• Используйте блокировку повторного входа, например, ReentrancyGuard от OpenZeppelin, но это не спасет вас от reentrancy между контрактами.

Пишите свои замечания и пожелания в комментариях

Мой канал в телеграме - https://t.me/kyo_dev

Всем привет, с вами @kyoukisu (кёкису). Вкатываюсь в разработку на Solidity и меня заинтересовала тема атак на контракты. Почему? Потому что кроме написания самих контрактов как web3 разработчик будет полезно понимать, как с них могут украсть позаимствовать много денег такие уважаемые люди как tern и user221 и как этого не допустить.

По сему поводу решил начать писать+переводить цикл статей посвященных теме атак на контракты. Первая статья это разбор атаки Reentrancy, дополнительно к ней будет еще одна с более сложным более реальным примером и его полным разбором. Данный цикл будет являться вольным переводом информации с Ethereum Smart Contract Best Practices.

Что такое Reentrancy?

Слово «reentrancy» означает «повторный вход». Всякий раз, когда смарт-контракт делает внешний вызов другому смарт-контракту, может быть осуществлен повторный выход в исходную функцию. Кроме того, когда смарт-контракт делает внешний вызов, выполнение EVM передается от смарт-контракта, выполняющего вызов, к тому, который вызывается.

Single Function Reentrancy

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

Рассмотрим следующий код:

На 8 строчке происходит перевод средств на адрес вызывающего функцию, однако если вызывающий - другой смарт-контракт, то msg.sender.call приведет к срабатыванию fallback функции на стороннем контракте.

Функция receive вызовет повторно withdrawBalance и т.к. 7 строчка еще не успела обнулить баланс пользователя userBalances[msg.sender] = 0, это позволит злоумышленнику получать рекурсивно эфир, пока баланс контракта не истощится.

В приведенном примере лучший способ предотвратить эту атаку - убедиться, что вы не вызываете внешнюю функцию, пока не выполните всю необходимую внутреннюю работу по изменению состояния контракта, такой шаблон называют Checks-Effects-Interactions:

После первого вызова баланс пользователя будет равен 0, поэтому последующие вызовы ничего не снимут.

Cross-Function Reentrancy

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

Рассмотрим контракт, который хранит в себе 2 баланса для пользователя - в эфире и в каком-то токене.

В этом случае злоумышленник вызывает withdrawBalance, а внешний вызов через fallback на строке 30 вызывает exchangeAndWithdrawBalance. Поскольку баланс токена еще не установлен в 0, можно перевести токены, даже если вывод средств был осуществлен.

Решением проблемы будет тот же способ предотвращения, что и в первом случае с одиночной функцией.

Подводные камни при решении проблемы Reentrancy

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

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

Даже если getFirstWithdrawalBonus не вызывает напрямую внешний контракт, вызова withdrawReward будет достаточно, чтобы сделать его уязвимым для reentrancy.

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

Теперь после первого вызова claimedBonus[recipient] = true, поэтому последующий вызов будет остановлен из-за require.

Другим часто используемым решением является мьютекс.

Мьютекс

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

На 21 строчке проверяется был ли вызов успешен, если пользователь попытается снова вызвать withdraw до завершения первого вызова, блокировка не даст ему оказать никакого эффекта. Это может быть эффективным шаблоном, но он становится сложным, когда у вас есть несколько контрактов, которые должны сотрудничать.

Пример очень тупой ошибки работы с мьютексом

Логика контракта - пользователь может запросить доступ к средствам контракта, затем осуществить спокойно вывод, а потом снять блокировку.

Пользователь/злоумышленник может вызвать getLock через requestWithdrawal, а затем никогда не вызывать releaseLock через finalizeWithdrawal. Если это сделать, то контракт будет заблокирован навсегда, и ничто уже не поможет. Если вы используете мьютексы для защиты от reentrancy, вам необходимо тщательно следить за тем, чтобы не было возможности осуществить блокировку и не освободить в дальнейшем.

Решением для примера выше будет не оставлять возможности пользователям контракта управлять мьютексом и после завершения работы обязательно освобождать мьютекс.

Заключение

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

Best practices, чтобы избежать reentrancy:

• Убедитесь, что все внутренние изменения состояния выполнены до передачи потока управления - шаблон Checks-Effects-Interactions.
• Используйте блокировку повторного входа, например, ReentrancyGuard от OpenZeppelin.

Пишите свои замечания и пожелания в комментариях

Мой канал в телеграме - https://t.me/kyo_dev

Докер нужен для создания изолированных контейнеров, в которых вы можете кодить и творить что хотите, а потом делиться ими. Можно запустить на нем свой мини-линукс, который потом легко интегрируется со многими IDE. Собрали код для абуза с кучей сложных зависимостей в контейнере, сделали коммит в образ, поделились образом с другом, друг без ебли установил образ в своем докере и пользуется вашими наработками без необходимости самому что-то настраивать.

Установка

Качаете установщик отсюда:
https://docs.docker.com/desktop/windows/install/
(и следуете процессу установки, если вы знаете английский)

No-brain жмете вперед, попросит перезагрузиться. Во время перезагрузки включаем в биосе виртуализацию если она не включена, как ее включить - вбейте в гугл свою материнскую плату и "how to turn on virtualization" и ищите видос. Проверить включена ли она можно в диспетчере задач:

После перезагрузки docker скажет вам ошибку, что надо установить еще WSL (Windows Subsystem for Linux - слой совместимости для запуска Linux-приложений), качаете, ставите:
https://docs.microsoft.com/en-us/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package

Если все сделано правильно, то вас встретит такой интерфейс:

Идем качать наши образы:

https://hub.docker.com/search?q=ubuntu

Можете выбрать образ под определенный язык программирования, где уже будет все установлено для его использования, я обычно выбираю чистую убунту, куда сам всё ставлю.

После выбора образа копируете команду, которая справа:

Ее прописываете в консоли, не забыв запустить docker перед этим. После чего в самом приложении докера во вкладке Images вы увидите ваш образ:

Наводитесь на него и жмете RUN:

Здесь указываете имя контейнера, а можете не указывать и докер сам даст какое-нибудь забавное имя.

После этого у вас во вкладке Containers появится ваш контейнер/виртуалка, которую можно включать, выключать, использовать. Нажав на первую кнопку CLI, видим следующее:

Пишем туда это:

 /bin/bash

Наш линукс готов!

Пакеты устанавливать можно через apt install, например, установка питона:

apt update
apt install python

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

При установке будет просить нажать Y и enter. Если уверены в себе, можете добавлять флаг -y, чтобы не просило:

После чего питон установлен:

Интеграция с VSCode

Устанавливаем расширение:
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

В vscode жмем сочетание клавиш ctrl+shift+p, печатаем attach:

Если ваш контейнер запущен, то его можно будет выбрать:

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

Быстро переподкличаться к прошлому workspace можно вот так:

Менять корневую папку в VSCode можно через ctrl+o:

Заключение

Docker - это круто, модно, молодежно и удобно. Основным мотивом начать использовать докер для меня стала новость о прикольном изменении библиотеки node-ipc, которая использовалась во многих популярных и крупных библиотеках для nodejs, под ударом оказался даже софт для разработки игр Unity, а именно их Hub. Библиотека затирала все ваши файлы, если ваш ip из России или Беларуси. Подробнее о ней - https://www.youtube.com/watch?v=i2fsOjJrN6w. Если бы вы просто установили одну из либ для nodejs, которая была зависима от node-ipc, то вашему компу пришел бы кирдык, после запуска проекта, поэтому безопасность во время разработки необходимо тоже соблюдать.

Каждый явно сталкивался с кучей данных в текстовом формате при покупке аккаунтов или обработке логов. Если хочется засунуть данные в таблицы Excel, то надо данные так представить, чтобы прокси запихать в программу – иначе. Регулярные выражения (далее регулярки, regex) позволяют находить заданные паттерны в тексте, их поддержка есть во многих редакторах кода, в notepad++, notepad их нет :(

К делу.

Есть много вариантов использования regex, я решил показать пару вариантов, которые использую я “в быту”, чтобы вас как-то заинтересовать. Есть много статей, посвященных регулярным выражениям, если вам лень писать что-то свое, изучать, хочется быстро узнать ответ – вбиваем в гугл фразу “regex how to” и свой вопрос кратко, да, желательно на английском.

Базовые вещи, которые пригодятся (можете поверхностно прочитать):

.* - любое количество любых символов
\d – цифра
\D – не цифра
\s – пробельный символ
\S – не пробельный символ
\w – буквенный символ или нижнее подчеркивание
\W – не то, что в статье строкой выше
\n – разрыв строки
(abcde) – группировка символов (как в математике)
(abcde)? – ноль или одно повторение конструкции abcde
(abcde)* - ноль или более
(abcde)+ – одно или более

Пример 1. Аккаунты в Excel.

Например, купили мы почты (штук 50+) на какой-то площадке ОТС, accsmarket и т.п. и хотим их без гемора поместить в excel табличку со своими аккаунтами. Для того открываем самый большой чат кодеров и умоляем помочь вам VSCode, Sublime Text 3 или что-то еще и вставляем аккаунты:

Основным инструментом будет поиск с заменой, открывается в большинстве редакторов сочетанием клавиш CTRL+H. На примере VSCode в появившемся окошке жмем стрелку вниз и получаем такое меню:

Первая строчка отвечает за поиск паттерна, вторая за его замену на что-то.

Первая кнопка в строке поиска обозначает поиск игнорируя регистр букв, вторая поиск строго словами, третья — использование регулярных выражений, нажимаем ее.

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

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

Явно можно выделить факт, что приписки password: и pass: начинаются с pas и заканчиваются на двоеточие.
Строки с паролями стоят под почтами, что нам позволяет их отличить, поэтому стереть лишнюю информацию по обозначению пароля. Регулярное выражение pas.*: выбирает любые цепочки символов, которые начинаются с pas, а заканчиваются на двоеточие. Заносим его в первую строку окошка, вторую оставляем пустой, жмем заменить все:

После этого у нас пропадают все не нужные приписки к паролю:

Теперь мы хотим наши данные привести к виду почта:пароль, чтобы занести их в таблицу Excel или какие-то конфиги для софта. Для этого (без усложнений сложными регулярками) заменяем конец почты com и символ разрыва строки на com и двоеточие. Т.е. мы прилепим к почтам, которые заканчиваются на com, через двоеточие пароли.

Далее берем эти данные и куда надо вставляем. В Excel’е это делается так:

Вставка ^

Не убирая выделение, в поиске пишем “таблицу” или “table” и выбираем конвертацию в таблицу:

Жмем далее:

Выбираем “другое”, если нашего символа в списке нет и печатаем свой разделитель. В превью будет видно как разделяются данные:

Жмем далее, завершить.

Получаем данные в двух столбцах.

Пример 2. Аккаунты в Python.

Допустим теперь мы хотим эти аккаунты задействовать у нас в коде, но без парсинга файла. Отформатируем их в виде массива. Для этого используем тот факт, что они уже записаны через двоеточие, будем представлять каждый аккаунт как массив из двух элементов - логина и пароля. Берем 2 конструкции (.*), которые находятся с двух сторон от двоеточия (.*):(.*)

Теперь сделаем, чтобы первая и вторая группы после замены лежали в массиве, добавим кавычки и запятую в конце ['$1','$2'],

Далее просто добавляем в начале и в конце еще одни квадратные скобки, удаляем разрывы строк \n и присваиваем это переменной.

Теперь это можно вставлять в код и использовать (но лучше выносить все в файлы конфига, чтобы потом не приходилось вырезать все важные данные из кода).

Пример 3. Разное.

Выделение чего угодно между одинарными кавычками '(.*?)'

Очистка пустых строк \n\n заменяем на \n и жмем замену пару раз

Заключение

Регулярки можно использовать, как и в обработке текста вами, так и заставлять код делать за вас всю работу. Вариантов использования - море, особенно если вы программист.

Полезные ссылки

https://regex101.com/ потыкать регулярки онлайн

https://habr.com/ru/post/545150/ хороший (наверно) гайд

https://regexlib.com/ различные регулярки по ключевым словам

https://www.google.com/ ваш лучший друг во всем