Задача с assembly

Еще одна задача Medium risk, но на этот раз с использованием assembly. Все же умеют читать его?

Решение

selfbalance() равно address(this).balance. Другими словами, в данном случае пользователь сможет вернуть не только свой остаток после переводов (называют это dust), но и весь баланс контракта опустошить! 

#task

Задача на внимательность

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

Решение

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

#task

Посложнее?

Следующая задача была помечена как High Risk. Если вы сможете понять в чем тут дело, то вы вполне можете начинать свои первые конкурсные аудиты.

Решение

Модификатор не защищает от reentrancy. При использовании токенов, написанных не на стандарте ERC20, а, например, ERC777, хакер может повторно заходить в функцию несколько раз и минтить токены сверх меры.

Вот тут можно почитать описание этого бага.

#task

Или, может, подлиннее?

Эта задача на знание особенностей Solidity и EVM. Вообще, проблема отсюда часто встречается в базовых описаниях уязвимостей смарт контрактов, и была даже в одной из задач Ethernaut! Поняли, где тут проблема?

Решение

А проблема в том, чот каждый майнер имеет доступ к переменной index. Другими словами, генерацией случайного числа тут можно управлять благодаря block.difficulty и block.timestamp.

Больше информации можно получить тут.

#task

И последняя на вечер

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

Решение

Во-первых, нет проверки на вводимый адрес to. В-вторых, админ может пересылать деньги от имени другого пользователя. В-третьих, с _data админ может делать исполнение функций в контрактах других пользователей, если таковые имеются. Ну, и самое главное, что я не увидел, это банальное отсутствие payable в to. Другими словами, функция всегда будет откатываться, если msg.value > 0.

Будьте внимательны со своим кодом!

#task

День задач на канале!

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

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

Первая задача на сегодня довольно сложная. Здесь представлена именно логическая уязвимость. Сможете понять какая?

Решение

passThruGate() проверяет, чтобы пользователь отправил сумму большую, чем gate.ethCost. Однако остатки от требуемой суммы никак не обрабатываются и не возвращаются пользователю, поэтому они остаются заблокированными на контракте. Это считается High risk issue на code4rena.

#task

Задача от Immunefi

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

Решение

Из-за того, что в коде пропущено обновление listings.deposit в функции withdraw(), пользователь может вызывать ее сколько угодно раз, пока контракт не будет опустошен.

#task

Задача от code4rena

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

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

Решение

Тут показан пример DoS атаки. Если хакер создаст слишком большой массив withddrawals, то цикл может просто израсходовать весь газ и прервать выполнение функции.

#task

Простая, но опасная

Задача была помечена, как High Risk. Достаточно прочитать код внимательно, чтобы понять, в чем тут дело.

Решение

А решение уместиться в три слова: memory не storage. Обновление данных во временных переменных, не приводит к их обновлениям в основной памяти.

#task

Задача с двумя проблемами

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

Решение

Официальный баг тот, что значение to не было проверено на нулевой адрес. В принципе популярная проблема. Вторая более сложная и заметить ее могут только опытные разработчики. Дело в незащищенном преобразовании (casting) с uint256 в uint96, из-за чего итоговая сумма может быть не такой, как планировалось.

#task