Технический анализ уязвимости multisig-контракта от Parity

Интересная новость, печальная (у меня открыт счет в satoshi.fund), но интересная. Давайте разберемся в деталях.

Стоит начать с того, что поиск уязвимостей дело сложное. Алгоритм программы (в нашем случае - смарт-контракта) - очень часто ступенчатый и логически обоснован. Для того, чтобы понять, в чем суть проблемы - я приведу пример уязвимости веб-сервера при классическом DOS. Если вспомнить, что было лет 10 назад - во времена сервера Apache и php, то можно на этом примере разобрать, как происходит поиск и использование уязвимости.

Цель DOS атак всегда одна - вывести из строя часть системы, которая может отвечать за что-то важное. Как это сделать - повысить нагрузку на узкое место в системе. Давайте посмотрим, что происходило при DOS на сервера Apache, и его ступенчатый алгоритм работы.

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

Чрезмерная нагрузка на подобный сервер вызывал DOS, в следствие чего не работала последняя цепочка (такое случалось не всегда, мог упасть сам apache, а не php, в таком случае злоумышленники прекращали атаку и ждали, когда сервер оживет, чтобы предпринять новую попытку его "утопить"). Когда удавалось этого достичь, происходил сбой в логике работы - результат был не тот, который ожидался владельцами сервера.

Как итог - Apache просто "показывал" код php файла (без обработки интерпретатором). Вместе с этим злоумышленник мог получить php файл с настройками, в котором хранились пароли от MySQL сервера (базы данных). Далее злоумышленник подключался к серверу и забирал таблицу с хэшами паролей всех пользователей сайта (например, такое случилось с форумом EarnMoney более 12 лет назад).

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

Что произошло сейчас - аналогичная ситуация, но уже связана с смарт-контрактами (и крипто-валютой Ефириум). Давайте разберемся, как была использована уязвимость (а точнее, "возможность", глазами Хакеров). Учитывая, что уже выпущен патч, можно изучить его, и понять - где же была "дыра".

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

Кто за этим стоит? Мне кажется - никто не узнает. Слишком "тупая" ошибка, если подумать. В этом есть определенные риски, и риски эти ложатся на "открытый" код и отсутствие аудита. Позвольте отвечу, почему я так считаю:

1. Программисты пишут код, логически обоснованный.
2. Большинство программистов мыслят линейно, в рамках задачи.
3. Хакеры - те же программисты, но которые осознают опасность (а точнее важность!) программы.
4. Хакеров меньше чем программистов (намного). По поводу этого можно написать целую книгу, но суть в том, что не каждый программист - хакер, но каждый хакер - программист.
5. Рост отрасли (в нашем случае смарт-контрактов) вызывает рост программистов в ней. А значит и хакеров, которые будут относиться к коду с осторожностью и осознанием опасностей, которые код может содержать.
6. Открытый код позволяет заглянуть под капот программы. Чаще - убедиться в честности, а не в надежности(!). Надежность должны оценивать специалисты, они же аудиторы. Кто такие аудиторы безопасности? Зачастую это профессиональные программисты - те же хакеры, которые сделали поиск уязвимостей своим бизнесом. Только на другом уровне.

Там где нет хакеров - нет ауидиторов безопасности кода (так как в этом нет необходимости). Соответственно все подобные прецеденты развивают рынок. Люди начинают понимать - доверять коду и быть убежденным в его надежности - не одно и тоже. Открытый код хорош тем, что его может бегло просмотреть каждый и убедиться - код выполняет определенную цель. Но разобрать каждую ступень кода, понять, что они не шатаются, не подвержены уязвимостям - совершенно другое дело.

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

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