Поиск уязвимостей. Обучение. Первые итоги. Часть 4

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

После следующей части обучения, скорее всего этот список будет расширен.

P.S. Я предполагаю, что перед прочтением последующих пунктов, вы уже будете знать о наиболее популярных атаках, типа reentrancy или dos.

9. Области видимости функций: public, external или internal. Если область не указана, то по умолчанию это public. Уже были много задач, да и взломов, когда в важной функции забывали указывать видимость, и она могла быть вызвана любым пользователем.

10. Модификаторы. Обращаем внимание: подключаются ли они из внешних контрактов (типа ownable от openzeppelin) или из данного контракта. Смотрим его условия и возможность обхода.

11. Доступы. Да, чаще всего доступы к исполнению функции прописываются в модификаторах, но иногда и в самой функции. Нужно проверить, кто из пользователей может ее вызывать: только админ, только модераторы, только владельцы токена, только другие функции по условиям (типа ДАО) или вообще все пользователи.

12. Require. Внутренние проверки функции. Можно или как-то обойти их?

13. Расчеты. Больная тема всех контрактов. Чаще всего уязвимость скрывается в неправильном определении долей / бонусов / наград, особенно, когда в них используются несколько контрактов.

14. Переводы. Обращаем внимание на функции типа transfer(), send() и другие, которые переводят токены или эфир. Есть ли проверка успешности выполнения? Возможен ли reentrancy? Когда обновляются маппинги и массивы?

15. Низкоуровневые вызовы. Call, delegatecall, callcode - особенно пристально смотрим на эти вызовы: есть ли проверка успешности вызова, куда идет ответ, что передается?

16. Аргументы функции. Я хотел поставить этот пункт вначале списка, но решил, что будет логичнее сделать его после low-level calls, и вот почему. Иногда в аргументы функции передают тип данных bytes. В байтах иногда шифруются функции и условия для низкоуровневых вызовов. И если такое есть в функции, то есть вероятность использовать байты для взлома.

17. Изменения переменных памяти. Проверяем, какие действия изменяют основные переменные, ведь это могут быть и права доступа владельца!

18. Валидация аргументов, адресов и токенов. Есть ли достаточная проверка всех данных, которые передает пользователь? Предусмотрены ли все случаи, когда пользователь может ввести нарочно некорректные данные.

Далее пара слов о defi.   

#security #audit

Поиск уязвимостей. Обучение. Первые итоги. Часть 5

С defi и dao, признаться честно, у меня получилась какая-то однообразная практика. По сути, все задачи, которые мне давались, преследовали следующие уязвимости:

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

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

21. Ликвидность пула или манипулирование ценой одного из токенов в пуле. Тут все просто: можно ли с помощью займа изменить баланс в пуле и получить тем самым бонус в контракте.

22. Незащищенные mint или reward. Также порой в контрактах эти две функции могут быть вызваны любым пользователем, или при доступных условиях, например, если у вас достаточно токенов. Тут необходимы дополнительные проверки.

23. Доступ к proposal. Также возможна недостаточная защита функции, которая добавляет предложения в dao. Хакер может сделать свое предложение и забрать весь пул.

И пара слов в конце. 

#security #audit

Поиск уязвимостей. Обучение. Первые итоги. Часть 6

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

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

Что дальше в планах?

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

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

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

Также интересно погружение в нюансы работы EVM и кода Solidity.

Думаю, до нового года я еще посижу с задачами, хочу поразбирать крутые задачи от Paradigm 2021/2022 годов, а уже после - приступить к bug bounties на популярных площадках Immunefi, code4arena и sherlock.

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

#security #audit

Разбор байткода, opcodes, деплой

У Ильи на канале вышел новый урок про дебаггинг кода. Я уже на канале описывал этот процесс, но у лектора это все прекрасно показано и описано, что поймет даже новичок!

Видео урок.

Для тех, кто любит "мясные" уроки, это прям один из них! Крайне рекомендую к просмотру!

#debug #opcode #remix

Повторение - мать учения

Очень часто в контрактах используются контракты от openzeppelin. Однако мы привыкли просто импортировать их, особо не задумываясь, какие функции и как они реализуют. Предлагаю сегодня, в свободное время, еще раз ка;дому просмотреть их контракты и вспомнить, как они работают.

В подборку я включил контракты, которые встречал в задачах и аудитах.  Сохраните себе или сделайте репост, чтобы не потерять.


Контракты ERC20

ERC20

IERC20

SafeERC20

ERC20Pausable

ERC20Burnable

ERC20Permit

ERC20Snapshot

IERC20Metadata

TokenTimelock


Контракты ERC721

ERC721

IERC721

IERC721Metadata

IERC721Receiver

ERC721Burnable

ERC721Enumerable

ERC721Pausable

ERC721Votes


Контракты ERC777

ERC777

IERC777

IERC777Recipient

IERC777Sender


Контракты ERC1155

ERC1155

IERC1155

IERC1155Receiver

ERC1155Burnable

ERC1155Pausable

IERC1155MetadataURI

ERC1155Receiver


Контракты контроля доступа

AccessControl

Ownable

Governor

Pausable

ReentrancyGuard


Прокси контракты

Proxy

BeaconProxy

UpgradeableBeacon

ProxyAdmin - transparent

TransparentUpgradeableProxy

Initializable

UUPSUpgradeable


Библиотеки

Address

Context

Counters

Create2

Strings

ECDSA

SafeMath

Этот пост просто, как напоминалка с быстрым доступом к контрактам. Не нужно искать в гугле или GitHub, кликните тут по ссылке и изучайте.

Советую прочитывать пару контрактов в день для повторения.

#openzeppelin #contract #lib

Проект для портфолио?

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

Хочу спросить у вас всех, хотел бы кто-нибудь присоединиться? По ролям я виду так:

1) Дизайнер
2) Фроентенд (react)
3) Фронтенд (ether.js)
4) Тестировщик ( с тестами coverage на 100%)
5) Разработчик смарт контрактов

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

Домен и хостинг с меня.

Если никто не захочет, буду делать сам, это без проблем.

Что думаете?

Планы до НГ

Взял небольшой перерыв от обучения на три дня, так как казалось, что слегка "перезанимался и уже не лезет". Знаете, как это бывает: вот кажется, что уже начинаешь все учить по третьему разу, интерес пропадает и хочется заняться чем-то другим. Короче, мне нужно было немного посидеть, пообщаться с коллегами, оценить планы и т.д. И вот к чему пришел.

Прежде всего по проекту в web3. Я рад, что несколько человек захотели присоединиться ко мне в этой задумке. Хочу уточнить, что это не быстрое мероприятие, и занять это все может пару месяцев, так как я стараюсь делать все на хорошем уровне и с предварительными тестами. Поэтому подумайте, будете ли вы готовы заниматься им и оставаться на связи 3-4 месяца. Если все таки найдётся несколько участников, то начнем сразу после НГ праздников.

Далее по профессии аудитора. Я ниже прикрепил видео от лектора, который недавно нашел работу в качестве аудитора и рассказывает про свое резюме, что там должно быть и на что смотрят при собеседовании. Основной упор там сделан не столько на портфолио, сколько на результатах с популярных проектов bug bounties. Поэтому до НГ я планирую разбирать задачи и кейсы, а после - попробовать зайти на эти проекты по аудиту.

Также до НГ, возможно, получится написать небольшой пет-проект для новичков и середнячков в разработке смарт контрактов и их аудите. В том плане, чтобы разрабы выкладывали свои контракты на аудит кода, а вторые - тренировались бы находить там уязвимости. Типа как бесплатная bug bounty прокачка для новичков.

И немного сбавлю обороты в "поглощении" материала и обучения. Не хочу в один момент перегореть.

А пока смотрим видео.

Хорошей недели и легкого обучения!

Проблемы контракта USDT

Нашел ветку твитов от Pashov, прекрасного начинающего аудитора, который описал несколько неочевидных нюансов контракта USDT. Предлагаю их перевод.

А сам контракт можно посмотреть тут.

1. Во-первых, у USDT нет комиссии за перевод токенов. Однако это можно легко исправить, вызвав нужную функцию админами. Это может поломать некоторые dapp приложения, которые не предусмотрели этого.

2. Во-вторых, он имеет встроенную защиту approval race condition. Другими словами, если у вас есть ненулевое allowance и вы попробуете вызвать erc20:approve, то ваша транзакция откатится, что может привести к dos в вашем контракте.

3. Transfer, transferFrom and approve - не возвращают булево значение, что не соответствует стандартам erc20.

4. Decimals. В USDT их 6, что может приводить к некорректным расчетам в контрактах.

5. Черный список. Если в вашем контракте есть "push" функция, которая рассылает адресатам токены, и один из этих адресатов в черном списке, то возникнет dos.

#usdt #security

Подборка инструментов для web3

Прекрасная подборка от аудиторской компании Quill Audits включает в себя: Blockchain Explorers, декомпиляторы, раcширения для браузера, проверки на rug pull, визуализаторы транзакций и много чего еще.

Сохраните себе, чтобы не потерять.

#tools #toolbox

Небольшая дата для канала

Сегодня ровно пять месяцев, как был создан этот канал! Я даже не думал тогда, что он продержится так долго, учитывая что я никогда не вел блоги, а изначальная задумка была просто выучить солидити в компании единомышленников.

На канале вышло более 550 постов!
Выложено более 50 уроков!
Расписано огромное количество материала!
Освещены практически все темы, которые можно найти на популярных курсах!
В нашей компании 143 участника!

Это невероятно круто! Спасибо, что вы с нами! Ваша поддержка и комментарии очень сильно помогают мне не бросать канал и двигаться дальше!

🥳🥳🥳🥳🥳🥳🥳🥳🥳

Задачи на уязвимости

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

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

Вообще я заметил, что есть некая пропасть между задачками стартового уровня и профессионального. Нет, такого знаете ли, середнячка.

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

Итак, популярные сборники задач:

Capture the Ether

The Ethernaut

CryptoZombies

Damn Vulnerable DeFi

DeFiHack

CryptoHack

EtherHack

Cipher Shastra

Speedrun Ethereum

CTF Blockchain Challenges

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

#security #challenges #task

Новая задача

Давно что-то не было новых задач на поиск уязвимостей. Попробуйте решить вот эту. Достаточно простая и скорее тренирует наблюдательность.

Подсказка

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

#task #challenge

И еще одна задача

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

Подсказка

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

#task #challenge

И последняя на сегодня

Забавная и легкая задача. особенно для тех, кто проходил Capture The Ether. Как можно взломать этот контракт?

Подсказка

Вспомните, за что отвечает unchecked.

#task #challenge

Следующая ступень аудитора

В общем, мне немного надоело решать задачи и читать аудиты, а заниматься этим каждый день до Нового года перестало казаться хорошим планом. И я решил пойти чуть дальше и зарегистрироваться на bug bounty площадках: code4rena, sherlock и Immunefi.

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

Более того, если сможешь найти баг, то тебе заплатят за него, что не может не радовать.

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

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

С code4rena чуть сложнее. Вы идете на сайт, заполняете анкету, затем присоединяетесь к их Дискорд каналу, в определенной ветке пишите что-то типа I-want-to-be-a-warden, и админ проверяет данные. Если все ок, то через пару часов доступ будет открыт.

Как я понял, найденные баги оформляются на специальной форме на сайте, при этом обязательно написать PoC - Proof of Concept - доказательство бага. Это может быть простое пошаговое описание действий взлома, тест в hh или foundry.

Сегодня хочу немного "покрутить" контесты, понять, как подготовить рабочую зону, как все устроено при скачивании контрактов и т.д.

Также, не могу объяснить, но в сообществе началась какая-то повальная любовь к foundry. Хочу почитать про него чуть больше. Если будет что-то интересно, то выложу здесь.

Всем приятного дня и легкого обучения!

Как искать уязвимости

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

Вот смотрите вы на свою функцию или на ту, что в контракте аудита, и начинаете:

А что если... :

- Ввести нулевой адрес;
- Ввести свой адрес;
- Не вносить вообще ничего;
- Не тому пользователю отправляются деньги;
- Повлиять на сумму в transfer;
- Деньги / токены / не дойдут;
- Вызвать переполнение;
- Получить права админа;
- Зайти в функцию дважды;
- Подменить логику;
- Нет белого списка;
- Остались апрувы;
- Взять флеш займ;
- Обнулить счет;
- Обойти require;

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

Надеюсь и вам поможет мой способ.

#hint #security

Чуть больше о Foundry

Ранее я упоминал, что Foundry становиться все более популярным у зарубежных разработчиков. И это действительно так.

Во-первых, для него не нужно учить дополнительный язык, типа javanoscript или python, все тесты и деплой происходит с помощью Solidity и встроенных опций.

Во-вторых, там уже есть свои крутые настройки, которые использовать намного легче, чем в hardhat.

В-третьих, я только сегодня узнал, что и сам hardhat можно встроить в foundry для локальных тестов в блокчейне.

Короче, крутая штука.

Вот еще одно интересное видео от Патрика Коллинса, который объясняет некоторые моменты foundry. Хоть оно и на английском, но по действиям на экране все предельно понятно.

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

#foundry #hardhat

Моя базовая настройка Foundry

Немного посидев с Foundry, и попробовав настроить изначальную среду для себя, я пришел к следующей последовательности действий.

P.S. Чуть позже хочу сделать так, чтобы настройка была еще быстрее. Уже есть представление, но нужна практика.

P.S.S. Полагаю, что к данному посту у вас уже будет установлен Foundry. Как это сделать - смотрите посты выше.


Итак идем по шагам.

1. Создаем папку проекта, например Project. Заходим в нее и открываем терминал. Я использую bash (можно и PowerShell).

2. Прописываем forge init и ждем пока установятся все файлы.

3. Пишем yarn init для создание json файла.

4. Далее yarn add hardhat. Он понадобится нам для деплоя контракта в тестовые и локальную сети.

5. npx hardhat и выбираем последний пункт с Create empty hardhat config. Я полностью в тестах перехожу на foundry, поэтому не требуется устанавливать js или ts проекты для дальнейших тестов.

6. yarn add dotenv - устанавливает зависимости для переменных среды. Удобно хранить приватные ключи и доступы к Alchemy.

7. touch remappings.txt (для bash или New-Item remappings.txt powershell) - создание файла для определения путей.

8. Открываем этой файл и прописываем:

@openzeppelin/=lib/openzeppelin-contracts/
@std=lib/forge-std/src/
@chainlink/=lib/chainlink-brownie-contracts/
forge-std/=lib/forge-std/src/

Это пути для файлов forge, и библиотек openzeppelin и chainlink, на случай, если они понадобятся вам в своем проекте.

9. Для установки библиотек прописываем forge install и название репозитария на github, например

forge install OpenZeppelin/openzeppelin-contracts

Все! Среда для написания контрактов, проведения тестов и аудитов готова.

Если захотите сделать деплой контракта в локальную сеть, то создайте узел hardhat через:

yarn hardhat node

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

forge create projectContract --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

или, если работаете с .env:

forge create projectContract --private-key PRIVATE-KEY

Если делаете деплой в сеть, то указываете, например, url Alchemy для этого так:

forge create projectContract --private-key PRIVATE-KEY --rpc-url http://bla.bla.bla


Надеюсь это поможет вам в обучении.

#foundry #hardhat

Вечерний опрос

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

В общем, кто учится кликаем ниже)

Что нужно для аудита на Code4rena?

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

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

Во-вторых, очень важно знать, как писать тесты и подтверждения своим находкам уязвимостей. Я, вероятно, смог найти две, но так и не понял, как протестировать свою гипотезу. Поэтому я подумываю потратить эту неделю на изучение тестов в foundry.

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

В-третьих, на ремикс не перекинешь. Точнее можешь, но "гемора" будет очень много, да и тесты для подтверждения, вроде как, не напишешь.

В общем, тесты - тесты - тесты. Вот, что самое сложное в работе аудитора.

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

Начинаем штудировать тесты в foundry.