Необычный тест для участников
Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.
Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.
Ответы пишем в комментариях с функцией "спойлер" (на телефонах в приложении выделить текст, нажать на три точки в правом вернем углу и выбрать опцию Спойлер. На компьютере: выделить текст, нажать правую кнопку мыши и выбрать опцию Спойлер).
Ответы я напишу в конце дня также в комментариях.
Для просмотра контракта вам потребуется скачать файл выше.
1. В данном контракте:
а) Не стандартное значение decimals;
б) Не стандартные decreaseAllowance и increaseAllowance;
в) Не стандартный transfer;
г) Ничего из перечисленного;
2. В данном контракте:
а) decimals() могут быть pure вместо view;
б) _burn() может быть external вместо internal;
в) _mint() должен быть internal вместо external;
г) Ничего из перечисленного;
3. В функции transferFrom():
а) Есть вероятность integer underflow;
б) Не правильная проверка allowance;
в) Есть вероятность неограниченных approvals;
г) Ничего из перечисленного;
4. В данном контракте:
а) В increaseAllowance есть вероятность integer overflow;
б) В decreaseAllowance есть вероятность integer overflow;
в) В decreaseAllowance не возможно нулевой allowance;
г) decreaseAllowance может быть оптимизирован с unchecked{};
5. В функции _transfer():
а) Отсутствует проверка на нулевой адрес;
б) Есть вероятность integer overflow;
в) Есть вероятность integer overflow;
г) Ничего из перечисленного;
6. В функции _mint():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
7. В функции _burn():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
8. В функции _approve():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное сообщение об ошибке;
в) Не правильное обновление allowance аккаунта;
г) Ничего из перечисленного;
Первый тест довольно простой и больше на внимательность. Дальше будет интереснее.
#test
Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.
Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.
Ответы пишем в комментариях с функцией "спойлер" (на телефонах в приложении выделить текст, нажать на три точки в правом вернем углу и выбрать опцию Спойлер. На компьютере: выделить текст, нажать правую кнопку мыши и выбрать опцию Спойлер).
Ответы я напишу в конце дня также в комментариях.
Для просмотра контракта вам потребуется скачать файл выше.
1. В данном контракте:
а) Не стандартное значение decimals;
б) Не стандартные decreaseAllowance и increaseAllowance;
в) Не стандартный transfer;
г) Ничего из перечисленного;
2. В данном контракте:
а) decimals() могут быть pure вместо view;
б) _burn() может быть external вместо internal;
в) _mint() должен быть internal вместо external;
г) Ничего из перечисленного;
3. В функции transferFrom():
а) Есть вероятность integer underflow;
б) Не правильная проверка allowance;
в) Есть вероятность неограниченных approvals;
г) Ничего из перечисленного;
4. В данном контракте:
а) В increaseAllowance есть вероятность integer overflow;
б) В decreaseAllowance есть вероятность integer overflow;
в) В decreaseAllowance не возможно нулевой allowance;
г) decreaseAllowance может быть оптимизирован с unchecked{};
5. В функции _transfer():
а) Отсутствует проверка на нулевой адрес;
б) Есть вероятность integer overflow;
в) Есть вероятность integer overflow;
г) Ничего из перечисленного;
6. В функции _mint():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
7. В функции _burn():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;
8. В функции _approve():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное сообщение об ошибке;
в) Не правильное обновление allowance аккаунта;
г) Ничего из перечисленного;
Первый тест довольно простой и больше на внимательность. Дальше будет интереснее.
#test
🔥5❤1
Немного о переменных
В смарт контракте можно указать только 16 локальных переменных. Если их будет больше, то возникнет ошибка StackTooDeepException. Для того, чтобы избежать этого можно использовать так называемые block scoping.
Вообще, scope в Solidity это область видимости, которых, как мы знаем, может быть четыре: internal, external, private, public.
А block scoping - это такая техника, которая позволяет создать новый scope внутри функции, чтобы сократить число локальных переменных в стеке функции.
На скрине выше вы можете увидеть пример block scoping.
Переменные указанные в фигурных скобках не будут доступны для действий внутри функции вне блока, однако в самом блоке можно использовать переменные функции, например, для каких-либо расчетов.
Чуть больше об этом можно прочитать в официальной документации Solidity, а реальный пример посмотреть тут, в контракте Uniswap.
#variable
В смарт контракте можно указать только 16 локальных переменных. Если их будет больше, то возникнет ошибка StackTooDeepException. Для того, чтобы избежать этого можно использовать так называемые block scoping.
Вообще, scope в Solidity это область видимости, которых, как мы знаем, может быть четыре: internal, external, private, public.
А block scoping - это такая техника, которая позволяет создать новый scope внутри функции, чтобы сократить число локальных переменных в стеке функции.
На скрине выше вы можете увидеть пример block scoping.
Переменные указанные в фигурных скобках не будут доступны для действий внутри функции вне блока, однако в самом блоке можно использовать переменные функции, например, для каких-либо расчетов.
Чуть больше об этом можно прочитать в официальной документации Solidity, а реальный пример посмотреть тут, в контракте Uniswap.
#variable
👍6❤4🔥1
Тест 2 (ERC-1155)
Предлагаю к вниманию второй тест для самостоятельной проверки. На этот раз для разбора стандарта ERC-1155.
Вообще, сегодня я выложу 3 поста для проверки своих знаний: текущий тест, пример экзамена для аудитора и контракты из реального собеседования, где нужно будет найти все возможные ошибки.
На выходных вы сможете в спокойной обстановке проверить свои знания.
Итак, вопросы для второго теста. Сам контракт можно скачать выше.
1. В данном контракте функция balanceOf():
а) Может быть оптимизирована кэшированием переменной состояния в локальную переменную;
б) Может быть оптимизирована изменением с view на pure;
в) Может быть оптимизирована изменением на external;
г) Ничего из перечисленного;
2. В данном контракте проверка array lengths mismatch отсутствует в функциях:
а) balanceOfBatch();
б) _safeBatchTransferFrom();
в) _mintBatch();
г) _burnBatch();
3. Проблемы в безопасности функции _safeTransferFrom():
а) Не правильная область видимости;
б) Возможность integer underflow;
в) Отсутствие проверки на нулевой адрес;
г) Ничего из перечисленного;
4. Проблемы в безопасности функции _safeBatchTransferFrom():
а) Отсутствие проверки array lengths mismatch;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
5. Проблемы в безопасности функции _mintBatch():
а) Отсутствие проверки array lengths mismatch;
б) Не правильное порождение события;
в) Возможность сжигания токенов;
г) Ничего из перечисленного;
6. Проблемы в безопасности функции _burn():
а) Отсутствие проверки на нулевой адрес;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
7. Проблемы в безопасности функции _doSafeTransferAcceptanceCheck():
а) Не правильная проверка адреса в isContract;
б) Не правильная проверка значения return;
в) Не правильй call вызов в isContract;
г) Ничего из перечисленного;
8. Проблемы в безопасности функции isContract():
а) Не правильная видимость;
б) Не правильный оператор сравнения;
в) Проблем нет, так как в Ethereum есть только адреса контрактов;
г) Ничего из перечисленного;
Как обычно ответы для этого теста выложу в конце дня.
Свои ответы вы можете писать в комментариях, но под функцией "Спойлер".
#test
Предлагаю к вниманию второй тест для самостоятельной проверки. На этот раз для разбора стандарта ERC-1155.
Вообще, сегодня я выложу 3 поста для проверки своих знаний: текущий тест, пример экзамена для аудитора и контракты из реального собеседования, где нужно будет найти все возможные ошибки.
На выходных вы сможете в спокойной обстановке проверить свои знания.
Итак, вопросы для второго теста. Сам контракт можно скачать выше.
1. В данном контракте функция balanceOf():
а) Может быть оптимизирована кэшированием переменной состояния в локальную переменную;
б) Может быть оптимизирована изменением с view на pure;
в) Может быть оптимизирована изменением на external;
г) Ничего из перечисленного;
2. В данном контракте проверка array lengths mismatch отсутствует в функциях:
а) balanceOfBatch();
б) _safeBatchTransferFrom();
в) _mintBatch();
г) _burnBatch();
3. Проблемы в безопасности функции _safeTransferFrom():
а) Не правильная область видимости;
б) Возможность integer underflow;
в) Отсутствие проверки на нулевой адрес;
г) Ничего из перечисленного;
4. Проблемы в безопасности функции _safeBatchTransferFrom():
а) Отсутствие проверки array lengths mismatch;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
5. Проблемы в безопасности функции _mintBatch():
а) Отсутствие проверки array lengths mismatch;
б) Не правильное порождение события;
в) Возможность сжигания токенов;
г) Ничего из перечисленного;
6. Проблемы в безопасности функции _burn():
а) Отсутствие проверки на нулевой адрес;
б) Возможность integer underflow;
в) Не правильное обновление баланса;
г) Ничего из перечисленного;
7. Проблемы в безопасности функции _doSafeTransferAcceptanceCheck():
а) Не правильная проверка адреса в isContract;
б) Не правильная проверка значения return;
в) Не правильй call вызов в isContract;
г) Ничего из перечисленного;
8. Проблемы в безопасности функции isContract():
а) Не правильная видимость;
б) Не правильный оператор сравнения;
в) Проблем нет, так как в Ethereum есть только адреса контрактов;
г) Ничего из перечисленного;
Как обычно ответы для этого теста выложу в конце дня.
Свои ответы вы можете писать в комментариях, но под функцией "Спойлер".
#test
👍2❤1
Экзамен для аудитора
В Дискорд сообществе Solidity Lab есть интересный мини экзамен для проверки навыков аудитора. Состоит всего из нескольких вопросов, но на выполнение отводится 1 час 20 минут.
Предлагаю и вам попробовать свои силы. При этом, если вы не состоите в сообществе, то НЕ ОТПРАВЛЯЙТЕ ФОРМУ! Посмотрите задания, решите их за отведенное время.
Я не уверен еще, как работают ссылки приглашения в Дискорде, но можете попробовать эту ссылку, чтобы вступить в группу. Если захотите позже, вы сможете отправить свои ответы и получить результаты.
Как проходить экзамен:
1) Открываете ссылку экзамена;
2) Вписываете свой ник (если вы в сообществе, пишите ник в Дискорде);
3) Нажимаете старт и просматриваете вопросы;
4) Повторюсь, НЕ ОТПРАВЛЯЙТЕ ОТВЕТЫ, если вы не в сообществе;
Экзамен для аудитора.
Тут каждый сам за себя, поэтому свои ответы и вопросы не рекомендуется писать в комментах к посту. Но ваши впечатления буду рад услышать.
Приятного экзамена.
#test #audit
В Дискорд сообществе Solidity Lab есть интересный мини экзамен для проверки навыков аудитора. Состоит всего из нескольких вопросов, но на выполнение отводится 1 час 20 минут.
Предлагаю и вам попробовать свои силы. При этом, если вы не состоите в сообществе, то НЕ ОТПРАВЛЯЙТЕ ФОРМУ! Посмотрите задания, решите их за отведенное время.
Я не уверен еще, как работают ссылки приглашения в Дискорде, но можете попробовать эту ссылку, чтобы вступить в группу. Если захотите позже, вы сможете отправить свои ответы и получить результаты.
Как проходить экзамен:
1) Открываете ссылку экзамена;
2) Вписываете свой ник (если вы в сообществе, пишите ник в Дискорде);
3) Нажимаете старт и просматриваете вопросы;
4) Повторюсь, НЕ ОТПРАВЛЯЙТЕ ОТВЕТЫ, если вы не в сообществе;
Экзамен для аудитора.
Тут каждый сам за себя, поэтому свои ответы и вопросы не рекомендуется писать в комментах к посту. Но ваши впечатления буду рад услышать.
Приятного экзамена.
#test #audit
👍2❤1
Контракт из собеседования
В конце сегодняшнего дня предлагаю вам заняться поиском проблем в контракте из реального собеседования.
Если вы также проходили его, то, прошу, не пишите об этом в комментариях, не называйте компанию и не говорить о проблемах в контракте. Позвольте участникам нашего канала самим попрактиковаться.
Думаю, будет здорово, если позже мы устроим небольшой голосовой чат, где обсудим данные контракты и тесты.
Все, что могу сказать по данному заданию это то, что тут есть три серьезные уязвимости, несколько средних и также пара мелких замечаний.
Приятного обучения!
#test #audit
В конце сегодняшнего дня предлагаю вам заняться поиском проблем в контракте из реального собеседования.
Если вы также проходили его, то, прошу, не пишите об этом в комментариях, не называйте компанию и не говорить о проблемах в контракте. Позвольте участникам нашего канала самим попрактиковаться.
Думаю, будет здорово, если позже мы устроим небольшой голосовой чат, где обсудим данные контракты и тесты.
Все, что могу сказать по данному заданию это то, что тут есть три серьезные уязвимости, несколько средних и также пара мелких замечаний.
Приятного обучения!
#test #audit
❤5
Я в пути, не теряйтесь
Уже третий день в дороге. С перебоями инета не получается сделать нормальные посты для канала.
Не теряйтесь, скоро продолжим. Для тех, кому понравились тесты, то поищите Secureum Race Test. В их Дискорде выложены с 4 по 14. В последнем из них pashov, популярный аудитор, занял первое место.
Кстати, поделитесь в комментах, какими программами для аудита и смарт контрактов вы пользуетесь. За исключением популярных, типа Inline bookmarks, Solidity Visual Developer, Surya, Slither и Solhint (который у меня почему-то не срабатывает).
Всем приятного дня!
Уже третий день в дороге. С перебоями инета не получается сделать нормальные посты для канала.
Не теряйтесь, скоро продолжим. Для тех, кому понравились тесты, то поищите Secureum Race Test. В их Дискорде выложены с 4 по 14. В последнем из них pashov, популярный аудитор, занял первое место.
Кстати, поделитесь в комментах, какими программами для аудита и смарт контрактов вы пользуетесь. За исключением популярных, типа Inline bookmarks, Solidity Visual Developer, Surya, Slither и Solhint (который у меня почему-то не срабатывает).
Всем приятного дня!
👍7❤5🔥3
Ошибки в смарт контрактах
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit
Я все еще нахожусь в дороге и надеюсь на следующей неделе уже вернуться к регулярному ведению канала. А пока что, я читаю много аудиторских отчетов и примеров взломов. Для себя выделил несколько типов ошибок, которые присутствуют в контрактах.
1. Типичные low/gas ошибки
Такие баги находятся проще всего, даже при беглом изучении кода. Примером может случить простая потеря indexed в событиях, не нужные чтения переменных из памяти или использование calldata вместо memory.
2. Ошибки при делении
Одни из самых популярных ошибок в смарт контрактах. Начисление бонусных токенов, расчет долей, свапы - везде может быть проблема с округлением, decimals или логическими расчетами.
3. Ошибки "на внимательность"
Такие ошибки часто попадаются в раздел Med Risk issues в отчетах. Тут уже не получится бегло просмотреть код и потребуется время на его изучение, чтобы понять действия, которые в нем совершаются.
4. Ошибки непредвиденных действий
Самые сложные для нахождения баги, так как чаще всего с кодом все в порядке: т.е. он написан правильно и с необходимыми проверками. Однако, чтобы выявить этот баг аудитору нужно иметь хороший опыт и воображение. Привести пример тут достаточно сложно, так как для каждого проекта они будут индивидуальными.
На что нужно обращать внимание при аудите?
1. Проверки if, require и модификаторы
Иногда такие проверки оказываются недостаточными, что позволяет обходить их с определенными условиями. Обращайте на них внимание с позиции "а как их можно обойти?";
2. Память и ее обновления
Также в некоторых отчетах я встречал баги, которые основывались на недостаточном / некорректном / избыточном обновлении в памяти контракта. Тут могут быть и ошибки с маппингами, и memory-storage, да и обычные обновления переменных. Для меня в этом случае бывает полезным контроль слотов и понимание логики функции.
3. Действующие лица
Редко встречается этот пункт в каких-либо статьях или постах в Твиттере. Аудитору нужно понимать, что в смарт контрактах не два уникальных действующих лица: разработчик и пользователь. Их может быть много, в зависимости от направления проекта, как например: разработчик, администратор, модератор, заемщик средств, заниматель средств, инвестор в пул, продавец токена, покупатель токена, мошенник и т.д. При хорошем аудите нужно рассматривать код на предмет взлома от каждого из действующих лиц.
4. Возможные атаки
Составляйте свой список атак в начале аудита после прочтения документации. Постарайтесь вспомнить все атаки, которые вы встречали в подобных проектах. Это помогает увидеть более развернутую картину потенциальных атак и позже прицельно смотреть в контракт, который аудируете.
Вот такой длиннопост получился по итогам моего чтения отчетов. Надеюсь и вам поможет взглянуть на этот процесс аудита с новой стороны.
Приятного обучения и практики!
#audit
👍6❤2🔥1
Нас уже 501!
Я вернулся с поездки, захожу на канал и вижу, что нас уже 501 участник! Здорово, что этот канал находят все больше людей, которые хотят войти в web3 и получить новые знания!
Напомню, что фокус канал сейчас смещен в сторону аудита и безопасности смарт контрактов. Я верю, что эта профессия станет одной из самых нужных в ближайшие несколько лет. Даже в русскоговорящих странах начинает расти интерес в web3, проводятся митапы, конференции и хакатоны. Будет появляться все больше разработчиков и компаний со своими проектами, которым будет необходим аудит перед публичным запуском.
До этого мы решали задачи, читали отчеты и познавали различные нюансы языка, а теперь я хочу сделать акцент именно на практической части аудита.
Когда, во время поездки, я читал отчеты, меня не покидала мысль, как профессиональные аудиторы могут находить логические баги, или знают места, в которые нужно смотреть в первую очередь. Опыт - само собой. Но нужно еще понимать, как правильно просматривать код.
В общем, по ходу событий вы поймете, что я имею ввиду.
А на сегодня у нас по плану пара задач и небольшой пост.
Всем приятной недели и легкого обучения!
#intro
Я вернулся с поездки, захожу на канал и вижу, что нас уже 501 участник! Здорово, что этот канал находят все больше людей, которые хотят войти в web3 и получить новые знания!
Напомню, что фокус канал сейчас смещен в сторону аудита и безопасности смарт контрактов. Я верю, что эта профессия станет одной из самых нужных в ближайшие несколько лет. Даже в русскоговорящих странах начинает расти интерес в web3, проводятся митапы, конференции и хакатоны. Будет появляться все больше разработчиков и компаний со своими проектами, которым будет необходим аудит перед публичным запуском.
До этого мы решали задачи, читали отчеты и познавали различные нюансы языка, а теперь я хочу сделать акцент именно на практической части аудита.
Когда, во время поездки, я читал отчеты, меня не покидала мысль, как профессиональные аудиторы могут находить логические баги, или знают места, в которые нужно смотреть в первую очередь. Опыт - само собой. Но нужно еще понимать, как правильно просматривать код.
В общем, по ходу событий вы поймете, что я имею ввиду.
А на сегодня у нас по плану пара задач и небольшой пост.
Всем приятной недели и легкого обучения!
#intro
❤12👍2🐳1
Задача 38
И первая задача на сегодня из задачника Quill CTF. Если вы решали задачи Damn Vulnerable Defi, то скорее всего сможете быстро понять, в чем тут дело.
Если же нет, то маленькой подсказкой будет: не полагайтесь на баланс контракта в таких действиях.
Решение
UPD. Изначальное решение было не правильным. Смотрите обновленный пост ниже.
#task
И первая задача на сегодня из задачника Quill CTF. Если вы решали задачи Damn Vulnerable Defi, то скорее всего сможете быстро понять, в чем тут дело.
Если же нет, то маленькой подсказкой будет: не полагайтесь на баланс контракта в таких действиях.
Решение
UPD. Изначальное решение было не правильным. Смотрите обновленный пост ниже.
#task
👍4❤2👎1
Задача с shares
Достаточно распространенная проблема в контрактах. Как я помню, немного похожая задача уже была на канале ранее. Вряд ли ее сможет понять или решить новичок, так как тут уже нужно знать про возможную проблему.
Решение
По сути это очередная задача, где первый депозитор может сломать всю систему минта новых shares. Из-за того, что расчет самых первых shares идет по формуле Math.sqrt(baseTokenAmount * fractionalTokenAmount), хакер может добавить вначале, например, по 1 baseToken и 1 quoteToken, в итоге минт будет всего 1, исходя из формулы. Затем хакер добавляет 1е9 токенов каждого вида, из чего получает стоимость 1 wei LP токена равную 1е9 токенов base или quote.
И если нормальный пользователь захочет добавить свои токены в пул, то ему нужно будет указывать количество не менее 1е9 токенов, чтобы получить минт больше 0.
В таких случаях, при первом добавлении в пул рекомендуют делать минт 1000 токенов на нулевой адрес, чтобы избежать данной уязвимости.
#task
Достаточно распространенная проблема в контрактах. Как я помню, немного похожая задача уже была на канале ранее. Вряд ли ее сможет понять или решить новичок, так как тут уже нужно знать про возможную проблему.
Решение
И если нормальный пользователь захочет добавить свои токены в пул, то ему нужно будет указывать количество не менее 1е9 токенов, чтобы получить минт больше 0.
В таких случаях, при первом добавлении в пул рекомендуют делать минт 1000 токенов на нулевой адрес, чтобы избежать данной уязвимости.
❤4
Комментарий к задаче 38 от Quill CTF
Спасибо @SovaSlava за бдительность в решении задач на канале! В задаче 38, та, в которой я решил, что уязвимость в флеш займе, однако все оказалось куда сложнее.
Я сначала решил, что это просто выжимка из задачи, но оказалось, что это полноценный контракт для практики взлома, где по условию на контракте были 10 Эфиров, а у вас 1, и нужно было забрать все себе. Вот ссылка на задачу.
Даже не знаю, нужно ли расписывать все решение по шагам. Оставлю пока на самостоятельное изучение. Мало ли, кто-то проходит данный задачник сам и не хочет получить готовое решение.
Для остальных подсказка под спойлером.
Уязвимость здесь скрывается не в функции execute, как можно подумать при первом взгляде, а в withdrawAll. Грубо говоря, нам сначала нужно написать контракт атаки, с функциями receive() и отправки эфира обратно владельцу. Далее, делая депозит в 1 эфир и "жонглируя апрувами и перекидыванием баланса эфира" с нашего адреса на контракт атаки и обратно, получить весь баланс weth после нескольких итераций. Звучит немного запутано, но понять вы сможете только после хорошего вникания в задачу.
#ctf #quill #task
Спасибо @SovaSlava за бдительность в решении задач на канале! В задаче 38, та, в которой я решил, что уязвимость в флеш займе, однако все оказалось куда сложнее.
Я сначала решил, что это просто выжимка из задачи, но оказалось, что это полноценный контракт для практики взлома, где по условию на контракте были 10 Эфиров, а у вас 1, и нужно было забрать все себе. Вот ссылка на задачу.
Даже не знаю, нужно ли расписывать все решение по шагам. Оставлю пока на самостоятельное изучение. Мало ли, кто-то проходит данный задачник сам и не хочет получить готовое решение.
Для остальных подсказка под спойлером.
❤5
Странные ERC20
Нашел интересный репо, где описываются все странные и не стандартные реализации токенов ERC20. Привожу краткий перевод.
1. Reentrant Calls. Некоторые токены позволяют делать reentrancy в функции перевода, например ERC777.
2. Missing Return Values. Некоторые токены, типа USDT, BNB, OMG не возвращают булево значение. Здесь можно найти весь список таких токенов.
Также есть токены, типа BNB, которые возвращают булево значение для одних методов, и НЕ возвращают для других.
Другие токены, типа Tether Gold, хоть и заявляют про возврат булево значения, но на самом деле возвращают false, даже когда транзакция проходит успешно.
3. Fee on Transfer. Токена, типа STA, PAXG берут комиссию за перевод.
4. Balance Modifications Outside of Transfers (rebasing / airdrops). Некоторые токены могут делать изменения в балансе без вызова функции transfer.
5. Upgradable Tokens. Токены, типа USDC, USDT являются обновляемыми, т.е. администраторы могут менять логику исполнения некоторых функций в любой момент.
6. Flash Mintable Tokens. Токены, типа DAI, пользователи могут минтить для выполнения какой-либо одной транзакции.
7. Tokens with Blocklists. Токены, типа USDC, USDT, имеют свои функции добавления пользователей в черный список. Если адрес заблокирован, то транзакция будет постоянно откатываться.
8. Pausable Tokens. Токены, типа BNB, ZIL, могут быть приостановлены администраторами, что делает их перевод невозможным.
9. Approval Race Protections. Токены, типа USDT, KNC, имеют защиту от фронтрана функции approve.
10. Revert on Approval To Zero Address. Токены, типа OpenZeppelin, будут откатывать транзакцию, если approve вызывается на нулевой адрес.
11. Revert on Zero Value Transfers. Токены LEND откатывают транзакции, если указано нулевое количество токенов.
12. Multiple Token Addresses. Некоторые токены используют прокси контракты, что открывает путь для атак double entry point.
13. Low Decimals. Некоторые токены имеют маленькое количество decimals (USDC - 6, Gemini USD - 2).
14. High Decimals. Другие токены, наоборот, очень большое количество decimals (YAM-V2 - 24).
15. transferFrom with src == msg.sender. Некоторые токены, типа DSToken, не будут пытаться уменьшить allowance пользователя, если они использует свой адрес в transferFrom(), другие, типа OpenZeppelin, Uniswap-v2, наоборот.
16. Non string metadata. Токены, типа MKR, шифруют свои name/symbol в bytes32, вместо string.
17. Revert on Transfer to the Zero Address. Некоторые токены откатывают транзакцию, если перевод идет на нулевой адрес.
18. No Revert on Failure. Токены, типа ZRX, не откатят вашу транзакцию, если она провалится, а просто вернут false.
19. Revert on Large Approvals & Transfers. Токены, типа UNI, COMP, откатят транзакцию, если число при approve или transfer будет больше чем uint96.
20. Code Injection Via Token Name. Некоторые вредоносные токены могут включать специальные JavaScript код в атрибуте name, которые позволяет хакерам вытягивать приватные ключи пользователей, которые взаимодействуют с токенами через фронтенд.
21. Unusual Permit Function. Токены, типа (DAI, RAI, GLM, STAKE, CHAI, HAKKA, USDFL, HNY, имеют permit() функцию, которая не следует стандарту EIP2612.
Надеюсь, вы тоже узнали сегодня о токенах чуточку больше.
#token #erc20
Нашел интересный репо, где описываются все странные и не стандартные реализации токенов ERC20. Привожу краткий перевод.
1. Reentrant Calls. Некоторые токены позволяют делать reentrancy в функции перевода, например ERC777.
2. Missing Return Values. Некоторые токены, типа USDT, BNB, OMG не возвращают булево значение. Здесь можно найти весь список таких токенов.
Также есть токены, типа BNB, которые возвращают булево значение для одних методов, и НЕ возвращают для других.
Другие токены, типа Tether Gold, хоть и заявляют про возврат булево значения, но на самом деле возвращают false, даже когда транзакция проходит успешно.
3. Fee on Transfer. Токена, типа STA, PAXG берут комиссию за перевод.
4. Balance Modifications Outside of Transfers (rebasing / airdrops). Некоторые токены могут делать изменения в балансе без вызова функции transfer.
5. Upgradable Tokens. Токены, типа USDC, USDT являются обновляемыми, т.е. администраторы могут менять логику исполнения некоторых функций в любой момент.
6. Flash Mintable Tokens. Токены, типа DAI, пользователи могут минтить для выполнения какой-либо одной транзакции.
7. Tokens with Blocklists. Токены, типа USDC, USDT, имеют свои функции добавления пользователей в черный список. Если адрес заблокирован, то транзакция будет постоянно откатываться.
8. Pausable Tokens. Токены, типа BNB, ZIL, могут быть приостановлены администраторами, что делает их перевод невозможным.
9. Approval Race Protections. Токены, типа USDT, KNC, имеют защиту от фронтрана функции approve.
10. Revert on Approval To Zero Address. Токены, типа OpenZeppelin, будут откатывать транзакцию, если approve вызывается на нулевой адрес.
11. Revert on Zero Value Transfers. Токены LEND откатывают транзакции, если указано нулевое количество токенов.
12. Multiple Token Addresses. Некоторые токены используют прокси контракты, что открывает путь для атак double entry point.
13. Low Decimals. Некоторые токены имеют маленькое количество decimals (USDC - 6, Gemini USD - 2).
14. High Decimals. Другие токены, наоборот, очень большое количество decimals (YAM-V2 - 24).
15. transferFrom with src == msg.sender. Некоторые токены, типа DSToken, не будут пытаться уменьшить allowance пользователя, если они использует свой адрес в transferFrom(), другие, типа OpenZeppelin, Uniswap-v2, наоборот.
16. Non string metadata. Токены, типа MKR, шифруют свои name/symbol в bytes32, вместо string.
17. Revert on Transfer to the Zero Address. Некоторые токены откатывают транзакцию, если перевод идет на нулевой адрес.
18. No Revert on Failure. Токены, типа ZRX, не откатят вашу транзакцию, если она провалится, а просто вернут false.
19. Revert on Large Approvals & Transfers. Токены, типа UNI, COMP, откатят транзакцию, если число при approve или transfer будет больше чем uint96.
20. Code Injection Via Token Name. Некоторые вредоносные токены могут включать специальные JavaScript код в атрибуте name, которые позволяет хакерам вытягивать приватные ключи пользователей, которые взаимодействуют с токенами через фронтенд.
21. Unusual Permit Function. Токены, типа (DAI, RAI, GLM, STAKE, CHAI, HAKKA, USDFL, HNY, имеют permit() функцию, которая не следует стандарту EIP2612.
Надеюсь, вы тоже узнали сегодня о токенах чуточку больше.
#token #erc20
❤7👍2🔥1
Запрет на delegatecall
Небольшой сниппет кода, который позволяет запретить другим контрактам делать delegate call в вашем контракте с помощью простого модификатора.
Этот способ используется в Uniswap V3.
#nodelegate #delegate
Небольшой сниппет кода, который позволяет запретить другим контрактам делать delegate call в вашем контракте с помощью простого модификатора.
Этот способ используется в Uniswap V3.
#nodelegate #delegate
👍7❤1
Пример упаковки структур в маппинге
В отчетах можно часто найти информационный пункт о том, что переменные в структурах следует правильно паковать. В этом примере автор решил пойти дальше и еще больше оптимизировать хранение структуру в контракте.
С помощью двух функций, упаковки и распаковки, и побитовых операций переменные в структуре размещаются в uint256, который в свою очередь сохраняется в маппинге с ключом адресата.
Не уверен, что с практической точки зрения это может быть часто применимо, однако вполне вероятно такой способ упаковки можно будет встретить в проектах при аудите.
#mapping #struct
В отчетах можно часто найти информационный пункт о том, что переменные в структурах следует правильно паковать. В этом примере автор решил пойти дальше и еще больше оптимизировать хранение структуру в контракте.
С помощью двух функций, упаковки и распаковки, и побитовых операций переменные в структуре размещаются в uint256, который в свою очередь сохраняется в маппинге с ключом адресата.
Не уверен, что с практической точки зрения это может быть часто применимо, однако вполне вероятно такой способ упаковки можно будет встретить в проектах при аудите.
#mapping #struct
❤2👍1
Немного о фантомных функциях
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
❤3
Аудит вживую
Сейчас на Шерлоке проходит конкурсный аудит для проекта GMX. Один из аудиторов, Owen Thurm из Solidity Lab, уже ранее работал с этой компанией и сейчас выкладывает некоторые свои наработки в помощь участникам.
Он также записал небольшое видео, как происходит аудит одной из функций контракта. В нем Owen показывает ход своих мыслей и обращает внимание зрителей на некоторые моменты, которые кажутся ему наиболее интересными.
В общем, рекомендую всем начинающим аудиторам.
Смотрим видео вместе.
Кстати, кто-нибудь из участников участвует в данном конкурсе?
#audit
Сейчас на Шерлоке проходит конкурсный аудит для проекта GMX. Один из аудиторов, Owen Thurm из Solidity Lab, уже ранее работал с этой компанией и сейчас выкладывает некоторые свои наработки в помощь участникам.
Он также записал небольшое видео, как происходит аудит одной из функций контракта. В нем Owen показывает ход своих мыслей и обращает внимание зрителей на некоторые моменты, которые кажутся ему наиболее интересными.
В общем, рекомендую всем начинающим аудиторам.
Смотрим видео вместе.
Кстати, кто-нибудь из участников участвует в данном конкурсе?
#audit
YouTube
Live Audit Of GMX V2 | Withdrawals
Interested in getting hands-on training to become an expert security researcher in a matter of months?
Get the guide to becoming a senior auditor in 6 months here: https://www.intogateway.com/guide
Looking for a Smart Contract Audit? Apply to work with the…
Get the guide to becoming a senior auditor in 6 months here: https://www.intogateway.com/guide
Looking for a Smart Contract Audit? Apply to work with the…
❤5🔥2
Аудит вне рамок - 0
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox
Хочу сделать некоторую серию постов, в которых будут описаны не столько уязвимости в коде, сколько моменты, на которые стоит акцентировать внимание при проведении аудита.
Через данные посты я хочу сформировать такой метод проведения аудита, в котором у проверяющего с самого начала будет видна общая картина проекта, и он сможет понимать вектор потенциальных атак.
Возможно, это звучит несколько сумбурно, но я попытаюсь объяснить, что хочу сделать.
На канале однажды была задача, в которой уязвимость крылась в том, что разработчик забыл обновить данные в маппинге, что позволяло вызывать withdraw() несколько раз и опустошить таким образом пул.
В задаче, на 20-30 строк кода, это понять достаточно просто. Но когда дело касается проекта, где обновление информации в маппинге может быть в совсем другом контракте - заметить это будет проблематично.
И вот я хочу, чтобы у меня, или у любого другого начинающего аудитора, с самого начала проведения аудита в памяти фиксировалось: "Ага, вот маппинг отвечающий за состояние счета владельца. Он должен обновляться в ключевых функциях". И потом в течение всего периода исследований, это держалось в голове.
Это самый банальный пример логического бага в контракте, когда код кажется написанным верно, но все равно есть проблемы.
В общем, надеюсь в таких постах вы тоже сможете найти для себя много нового.
#audit #outofbox
❤2👍2