С этой статьи мы начинаем цикл, посвященный типичным уязвимостям, атакам и проблемным местам, присущим смарт-контрактам на языке Solidity, и платформе Ethereum в целом. В первой части мы поговорим вот о чем:
- почему сложно реализовать децентрализованную биржу на смарт-контрактах
- как сгенерировать случайное число
- как вывести из строя всю Proof-of-Authority сеть
Почему сложно реализовать децентрализованную биржу на смарт-контрактах
Disclaimer: О front-running attack мы уже рассказывали в разборе конкурса для ZeroNights 2017. Поэтому те, кто читал, могут сразу переходить к следующему пункту.
Термин front-running появился уже давно, и означает возможность манипуляции на рынке за счет обладания закрытой информацией о транзакциях в состоянии ожидания (pending). Если мошенник в курсе того, что грядет большая закупка, он может быстро скупить предмет торга по дешевке, таким образом гарантируя себе выгоду.
В криптовалютах, и в Ethereum в частности, все транзакции сначала помещаются в пул неподтвержденных (pending pool или mempool или backlog), где ожидают, пока майнер возьмет их оттуда и добавит в блок. Однако, в отличие от классических бирж, где такая информация доступна очень узкому кругу лиц, pending pool в Ethereum могут видеть все участники сети. И, поскольку среднее время, через которое новая транзакция попадет в блок, составляет ~14 секунд, у атакующего достаточно времени, чтобы проанализировать поведение рынка и послать собственную транзакцию, учитывающую это поведение. Последнее — как атакующий может гарантировать, что его транзакция будет обработана в первую очередь? Ответ кроется в размере комиссии за транзакцию — чем она больше, тем быстрее транзакция попадет в блок. Однако, в Ethereum понятие комиссии немного сложнее, чем обычно, и высчитывается следующим образом:
где gas — это некая единица топлива для EVM, которая расходуется при исполнении смарт-контракта и сохранении данных в блокчейн. Таким образом, на самом деле атакующий может, манипулируя ценой за единцу газа (gasPrice), добиться того, чтобы для биржи его транзакция была первой. Тут и тут есть пример проведения такой атаки против смарт-контракта.
В качестве mitigation от этой атаки смарт-контракт может анализировать свойство транзакции tx.gasprice. Однако, это не будет полным решением проблемы, поскольку майнер на самом деле не обязан сортировать транзакции по убыванию gasPrice — это лишь экономический стимул. Если вдруг появится вариант более значительного стабильного выигрыша, кто знает, чем займется майнер :)
Чтобы хоть как-то защититься от этого, можно использовать криптографию — например, посылать сначала хеш от желаемого действия (покупка или продажа) с количеством токенов. А в следующем блоке уже отправлять сами данные. Хотя схема тоже не лишена недостатков, как минимум, она более сложная — требует проводить в два раза больше транзакций.
Как сгенерировать случайное число
Ethereum по своему дизайну — детерминированный механизм, поэтому внутри него очень сложно где-либо черпать энтропию. Однако не все разработчики на Solidity являются искушенными во внутреннем устройстве, а видят перед собой лишь описание синтаксиса языка, и пытаются применить его так, как они это делали в других языках программирования.
Итак, откуда нельзя брать энтропию:
- присылать в открытом виде вместе с вызовом функции
- из значений глобальных переменных: difficulty, timestamp и др.
Исключение составляет функция block.blockhash(uint blockNumber), которая возвращает хеш блока по его номеру. Однако, применять ее нужно, держа в уме две вещи:
- надо учитывать, что случайным является только хеш блока строго в будущем. И то с некоторой оговоркой — перед тем, как отправить блок в сеть, майнер уже будет знать его хеш, и может использовать это в своих целях, например, не отправлять блок в сеть вовсе, если он заведомо уверен, что проиграет в каком-то конкурирующем процессе. Для уменьшения вероятности появления такого нечестного майнера можно использовать не один блок, а цепочку из нескольких;
- второе условие — при получении хеша (средствами смарт-контакта) нужно учитывать, что на это есть только последние 256 блока, после этого функция начнет возвращать 0.
Примеры неправильного использования blockhash и эксплоиты к ним можно посмотреть тут и тут.
Другой вариант — схема commit-reveal, которую использует RANDAO. В первой фазе в течение M блоков N участников загадывают случайное число и отправляют смарт-контракту хеш от него с некоторым депозитом. Во второй фазе участники посылают свои загаданные числа смарт-контракту, а тот проверяет число, взяв от него хеш. После того, как все отправили числа, контракт использует их как seed для PRNG. Если участник в заданное время не присылает свое число, он лишается того депозита, который внес, а раунд отменяется (остальные получают свой депозит назад). Недостаток схемы очевиден — она подвержена DOS, поэтому если случайные числа нужны постоянно и незамедлительно, такая схема в чистом виде вряд ли подойдет. Стоит присмотреться к дополнительным правилам для этой схемы, как предлагают сами RANDAO или придумать свою на ее основе, как Виталик. А можно объединить идею с хешом блока и схемой commit-reveal.
Еще один вариант, заслуживающий внимания — Signidice. Схема хороша, когда участников немного, поэтому мы рассмотрим ее на примере игры в рулетку. Итак, есть два участника — казино и игрок, а так же смарт-контракт, который реализует логику игры. На подготовительном этапе казино генерирует пару приватный-открытый ключ и отправляет публичный смарт-контракт. На этом подготовка окончена, можно играть. Поехали:
- игрок делает новую ставку — присылает загаданное число и некий депозит
- казино берет загаданное число у смарт-контракта, подписывает с помощью приватного ключа, сгенерированного на подготавительном этапе, и присылает подпись назад
- смарт-контракт проверяет, что подпись валидна — подписывалось именно то число и именно с помощью того приватного ключа, публичная пара которого известна смарт-контракту
- если все проверки пройдены, сама подпись используется в качестве seed для PRNG. А он, в свою очередь, дает ту самую цифру, "на которой остановился шарик".
Самый большой недостаток, который останавливает от того, чтобы брать и применять схему прямо сейчас, — это то, что алгоритм подписи у Ethereum — ECDSA. И если использовать его, то у казино всегда будет возможность читерить. Согласну алгоритму, на третьем шаге выбирается случайное k. Этот параметр напрямую влияет на итоговую подпись, причем нельзя использовать одно и то же k, иначе, имея две подписи, можно будет восстановить приватный ключ казино (раскрывать k нельзя по той же причине). Поэтому казино может менять k до тех пор, пока не получит такую подпись, с которой оно выиграет. Вот тут есть пример такого казино.
К тому же (отбросим предыдущую проблему), необходимо решить вопрос с тем, как быть, если участник загадает то же самое число. При условии, что казино использует те же параметры для подписи (в том числе, k), она будет идентична предыдущей, а значит, не случайна. Поэтому нужен запрет на переиспользование загадываемого числа или генерация новой пары ключей каждый раунд.
"Светом в конце тоннеля" для Signidice является EIP-198 о добавлении операции взятие по модулю. Это делает возможным реализацию проверки подписи для RSA. При использовании RSA читерить казино не удастся.
На самом деле, подходов к решению задачи получения случайных чисел много, за бортом остались варианты с получением энтропии off-chain (Oraclize) и эксперименты с whisper.
Как вывести из строя Proof-of-Authority сеть
В этом блоке мы не будем касаться смарт-контрактов, однако рассмотрим одну особенность permissioned blockchain — валидаторы всегда известны. Как пример, сеть с Proof-of-Authority консенсусом. Proof-of-Authority — это частный случай сети с Proof-of-work консенсусом, только майнить могут лишь избранные ноды (валидаторы). Яркий пример таких сетей — это тестовые сети для разработчиков Kovan и Rinkbey. Придуман такой консенсус главным образом для того, чтобы избежать спам атак. Когда злонамеренный майнер, имея преимущество в мощности (за счет использования GPU), добывает новые блоки быстрее остальной сети, он консолидирует в своих руках большое количество ether. В то время как обычные участники сети не могут больше добывать ether самостоятельно — они осушают "краны", которые ранее пополнялись добросовестными майнерами. Все это приводит к тому, что новые разработчкики не могут пользоваться сетью из-за отсутсвия ether. Для тех, у кого эфир все же есть, нормальная работа в такой сети тоже не представляется возможной. Майнер способен замусорить сеть бессмысленными, но дорогими транзакциями, что, в свою очередь, сделает добавление в блок транзакций нормальных участников сети затруднительным и долгим.
Так вот, Proof-of-Authority подход с избранными валидаторами может применяться не только для тестовых сетей, но так же для permissioned-сетей. Например PoA network — публично доступная сеть, в которой валидаторами являются юридически закрепленные участники. Избавляет ли PoA эти сети от возможности проведения DOS атак? И да, и нет.
На уровне сети интернет все еще есть возможность сгенерировать большой объем трафика на порт 30303, на котором слушает майнер. И тем самым сделать его недоступным для остальной сети. Далее очевидно — нет валидатора, никто не добывает блоки, транзакции копятся, сеть стоит. Но как же вычислить майнера в сети? Ведь он использует точно такой же клиент для сети, как и остальные.
Алгоритм на самом деле прост:
- подключаемся к сети тем же самым клиентом (в данном примере Parity)
- получаем подключенных к нам участников сети через RPC интерфейс:
curl --data '{"method":"parity_netPeers","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545 -s | jq '.result.peers[]' | jq '.network.remoteAddress' | cut -d """ -f 2 | cut -d ":" -f 1Если их более 25, то придется принудительно рвать соединения до известных IP, например, с помощью iptables, и так собрать их все.
Далее все, что нужно, — это отслеживать, с каких IP первыми приходят новые блоки. Эти IP и будут майнеры.
На этом пока что все. В следующей части перейдем непосредственно к проблемам, которые могут встретиться в смарт-контрактах.
Автор: p4lex
