Классно, что ты попробовал решить задание EtherHack не реверс с помощью manticore, символическое исполнение позволяет найти пинкоды без какого-либо ручного анализа. Я пробовал с Mythril, но с ним не получилось.
Еще добавлю:
MAIAN — еще одна реализация символического исполнения EVM, которая позволяет в отличие от Mythril искать уязвимости, для которых требуется больше одной транзакции, а также способная подтверждать уязвимости на приватном блокчейне с целью снижения фолзов.
А для сложных типов, например, массивов, используется хеширование.
Тут нужно уточнить, что только для динамических массивов. Массивы с фиксированной длиной будут раполагаться в storage последовательно. Этот кейс был использован в контракте Doug Hoyte на Underhanded Solidity Contest: https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte
Кстати, а почему "S in Ethereum stands for Security"? Ethereum же не аббревиатура :)
Для поиска уязвимостей в PRNG реализациях на Solidity можно использовать простое правило: если случайное число получается в той же транзакции, когда определяется победитель, то такой алгоритм определенно уязвим.
В PT Application Firewall проблема с парсингом JSON уже устранена. Мы тщательно заботимся о выявлении таких обходов, поэтому каждый год проводим конкурс WAF Bypass ([1], [2], [3], [4]) в рамках конференции Positive Hack Days. Приглашаем принять участие в следующем году.
В функции accountBalance небезопасно вычитается agingBalanceOf[_address][0] из balances[_address]. Если в какой-то момент agingBalanceOf[_address][0] станет больше balances[_address], произойдет переполнение и balances[_address] станет близким к 2**256.
На днях kickico выпустили обновленную версию токена, в которой, кроме прочего, был исправлен эпик критикал баг, который не увидел ни я до ICO, ни сторонние аудиторы.
Текст как будто перевели с помощью PROMT 97. Не сказано про главную особенность — необходимо, чтобы один из параметров запроса выводился в ответе, т.е. атакующий должен иметь возможность вставить свой текст в ответ.
HEIST также эффективен против HTTP/2
Не просто эффективен, HTTP/2 снимает ограничение выше, для эксплуатации атакующему не требуется вывод параметра в ответе.
В статье ничего не сказано про защиту. Проблема в том, что Fetch API позволяет отправлять запросы на сторонние сайты с авторизационными куками (режим no-cors). Сейчас прорабатывается стандарт для атрибута кук SameSite. Он позволяет задать политику использования кук только в пределах сайта, что тем самым ограничивает отправку кук со сторонних сайтов и нейтрализует данную атаку. Хром >51 уже поддерживает SameSite-куки.
Во-первых, разработчики Joomla допустили инъекцию в строку сериализованной сессии, так как не проверяют входящие данные, во-вторых, они не разбираются в особенностях работы базы данных. Другое дело, если бы это была уязвимость в самой базе данных.
В Joomla используется кодировка utf8, нужно использовать utf8mb4. Мой посыл в том, что необходимо знать, как правильно пользоваться инструментами, которые ты выбрал; сам инструмент не виноват, если его используют неправильно.
При STRICT_TRANS_TABLES=1 MySQL будет выдавать ошибку. Начиная с версии 5.7.5 строгий режим включен по умолчанию. И нельзя не отметить разработчиков Joomla, использующих неправильную кодировку для таблиц. Кстати, похожий баг был в WordPress: vagosec.org/2013/09/wordpress-php-object-injection
Классно, что ты попробовал решить задание EtherHack не реверс с помощью manticore, символическое исполнение позволяет найти пинкоды без какого-либо ручного анализа. Я пробовал с Mythril, но с ним не получилось.
Еще добавлю:
Это не сработает.
Тут нужно уточнить, что только для динамических массивов. Массивы с фиксированной длиной будут раполагаться в storage последовательно. Этот кейс был использован в контракте Doug Hoyte на Underhanded Solidity Contest: https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte
Кстати, а почему "S in Ethereum stands for Security"? Ethereum же не аббревиатура :)
Спасибо за статью, ждем последующие части. К теме front-running в биржах можно добавить хороший пример такой проблемы в Bancor: https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798.
Для поиска уязвимостей в PRNG реализациях на Solidity можно использовать простое правило: если случайное число получается в той же транзакции, когда определяется победитель, то такой алгоритм определенно уязвим.
В PT Application Firewall проблема с парсингом JSON уже устранена. Мы тщательно заботимся о выявлении таких обходов, поэтому каждый год проводим конкурс WAF Bypass ([1], [2], [3], [4]) в рамках конференции Positive Hack Days. Приглашаем принять участие в следующем году.
Это грамматика, которую мы и сделали :)
Спасибо!
0x3dA04a48CF4647c1916A9C9b1cB87D83A5118dA7
Тогда предположу, что функция transfer перестанет работать после 30.09.2019 09:00:00, так как в dividends не будет 25го элемента.
В функции
accountBalance
небезопасно вычитаетсяagingBalanceOf[_address][0]
изbalances[_address]
. Если в какой-то моментagingBalanceOf[_address][0]
станет большеbalances[_address]
, произойдет переполнение иbalances[_address]
станет близким к 2**256.Есть детали?
Шелл был закомичен ;)
Такой универсальной техники нет, все зависит от приложения.
Куки нельзя, только данные в теле ответа.
Текст как будто перевели с помощью PROMT 97. Не сказано про главную особенность — необходимо, чтобы один из параметров запроса выводился в ответе, т.е. атакующий должен иметь возможность вставить свой текст в ответ.
Не просто эффективен, HTTP/2 снимает ограничение выше, для эксплуатации атакующему не требуется вывод параметра в ответе.
В статье ничего не сказано про защиту. Проблема в том, что Fetch API позволяет отправлять запросы на сторонние сайты с авторизационными куками (режим no-cors). Сейчас прорабатывается стандарт для атрибута кук SameSite. Он позволяет задать политику использования кук только в пределах сайта, что тем самым ограничивает отправку кук со сторонних сайтов и нейтрализует данную атаку. Хром >51 уже поддерживает SameSite-куки.