Smart contract auditor: from zero to hero

About MixBytes

Сергей Прилуцкий — founder и CRO компании Mixbytes, которая с 2017 года занимается разработкой проектов в блокчейне, образовательными активностями и, в первую очередь, аудитом смарт-контрактов. Среди клиентов Mixbytes крупные defi-протоколы. Сергей рассказал про профессию аудитора и её подводные камни.

Про сложности жизни таких компаний

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

Web3 разработка

Методологии тестирования

Web3 разработка сильно отличается от web2. В web3 никто не пишет бэкенд, не выставляет наружу API и если что-то внутри сломалось, то это нельзя просто тихо починить. В web3 если где-то в коде разработчики допустили ошибку, то это видно, любой баг воспроизводится с предельной точностью. Воспроизвести можно и через два года, ведь блокчейн все помнит. Это накладывает требования очень качественной разработки. Разработчикам приходится работать чуть-чуть больше: не просто решить задачку и закоммитить код, а задокументировать его, оформить так, чтобы его могли читать другие люди на Github.

Правильные протоколы управляются при помощи DAO и Governance. Если web3 аудиторы видят проект, который управляется с одного адреса, то они понимают, что один адрес может сломать весь протокол — это считается уязвимостью. Также если есть multisig-кошелек, и в нем есть только один участник, это тоже считается уязвимостью. Governance говорит о том, что изменения в этих протоколах накатываются с помощью голосований стейкхолдеров. Какие-то изменения в протоколе — это форумы, обсуждения, совместное принятие решений, затем выкатывание предварительных изменений и их тестирование. В этом всегда участвуют аудиторы.

То же самое касается bugfixes & hacks — на все это должна следовать серьезная реакция самой команды, об этом знают все главные стейкхолдеры. Они начинают разбираться почему так произошло, дают пресс-релизы в Твиттере о том, что их взломали, объясняют как и почему это случилось. Многие современные проекты даже заранее формируют фонд, который будет использован в случае взлома.

Сейчас становятся популярными различные проекты, которые занимаются bug bounty грантами на разработку. Это очень круто потому, что есть возможность получить bounty за находку серьёзных багов и аудиторы получали за нахождение критических уязвимостей вознаграждения, просто изучив протокол без заказа с их стороны. Но тем не менее человечество учится работать с open source кодом, оно учится работать с кодом, который писала коммерческая компания, но выдала в пользование всем. Таким кодом, кончено, нельзя пользоваться без того, чтобы другие совершенно независимые команды, критически настроенные не проаудирвали его. Публичные аудиты в этом вопросе занимают такое же важное место.

Хороший протокол проходит два-три аудита и здесь важную роль играет репутация компании.

Стек знаний аудитора

Сергей Прилуцкий отвечает за рост аудиторов в команде Mixbytes, но даже ему трудно сказать, какой специалист станет хорошим аудитором. Это может быть человек, который занимался финансами, трейдингом и он прекрасно видит финансовые паттерны и находит много уязвимостей, а может быть безопасник, тестер, который до этого работал в Web2. Профили совершенно разные и крутыми аудиторами становятся разные люди, но главное в этой профессии — критическое мышление. У разработчика задача сделать так, чтобы код работал, а аудитор должен понять, как сделать так, чтобы код не работал.

Следующее по значимости качество для хорошего аудитора — ответственность. Он должен вместе с командой клиента чувствовать ответственность за результат, также хотеть, чтобы эти протоколы были секьюрными, чтобы все баги были найдены.

Помимо этого, есть универсальный набор знаний — алгоритмы структуры данных и криптография. Надо понимать, как строятся протоколы безопасности, например, как ваш брелок машины «общается» с машиной когда открывает дверь. Вы должны иметь возможность прочитать спеку и понять суть этого протокола. Математика, финансы, экономика, модели данных и все то, что позволит аудитору понять проект верхнего уровня: кто куда пошел, какие деньги положил, какие проценты ему начислялись, в какие моменты он их может вынимать, перезакладывать, как взаимодействовать с другими протоколами. А также, как вычисляется количество долей, реварды, как работают округления. Information Security, pentesting, анализ кода— это тоже будет очень полезным. High-load системы, знания как строятся операционные системы, системы базы данных - это всё нужно для того, чтобы хорошо понимать как это работает.

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

Техническая составляющая

С технической точки зрения работа аудитора — изучение кода на Solidity или Viper, но в голове надо держать довольно низкоуровневый код типа C#, ведь каждые действия проводят какие-то операции с памятью: выделяет память, читают из нее, записывают туда, взаимодействие со storage. Поэтому знания по классическому C# здорово помогают. Из хорошего — это то, что в смарт-контрактах вы будете иметь дело с ограниченным набором инструкций и небольшим кодом. Например, 1000 строк — это уже считается большим контрактом. Но и внимания к каждой строчке требуется больше.

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

Аудит внутри

Представим, что вы работаете в команде аудиторов. Менеджмент согласовал с клиентом скол — конкретный набор файлов. Аудитор получает себе для работы скол, зафиксированный коммитами, и работает с ним. Затем проходит высокоуровневый обзор протокола, когда аудиторы меняются информацией о том, как проект устроен, чтобы не осталось ни одного аудитора, который не понимает как это протокол работает. Ведь самые серьезные баги ловятся несколькими аудитами. После этого проверяются all strategies, чаще всего с помощью чек-листов. Затем аудитор формирует файдинг (список ошибок), в котором идёт описание и рекомендации. После происходит ревью багов. Здесь соединяются все баги всех аудиторов, обозначается их классификация и всё это отправляется клиенту. Клиент фиксит все эти уязвимости и отправляет отчет обратно с комментариями о том, каким образом он это сделал. А дальше происходит апофеоз аудита — публичный репорт о том, что компания подписалась, проверила и подтверждает, что эта версия протокола безопасная.

Аудит снаружи

Как это выглядит со стороны компании, которая заказывает аудит. Сначала идёт согласование скола. Затем оценка. В Mixbytes учитывается количество строк и различные усложнения задачи. После этого начинается аудит. Позже формируется промежуточный репорт, а после этого начинается “пинг-понг” с клиентом: ему отправляемся репорт, начинается спор по поводу того какие файндинги присутствуют от critical до low. Затем этап так называемого реута, то есть перепроверка действительно ли фиксы эту проблему лечат. И в конце отчет, в котором хорошие аудиторы пишут рекомендации как фиксить различные проблемы. Это продолжается до тех пор, пока все баги не получат статус «fixed».

Виды аудитов

Full-featured audit — самый качественный аудит проекта с получение публичного репортаж от команды с лучшей репутацией.

Diff audit — в Mixbytes появился недавно, потому что появилось большое количество проектов, которые делают форк известного протокола и добавляют туда несколько своих features. Суть заключается в том, что большая составляющая проекта уже аудировалась, то есть он безопасный, проверить нужно только 100 новых строчек кода. Это не всегда работает, потому что есть примеры хаков, когда изменения в паре строк проекта, полностью рушат его безопасность. Поэтому в данном случае, мы беремся делать аудит применяя diff поменьше, нежели полный аудит. И обязательно в репорте пишем, что основываемся на том, что часть кода безопасна, и уже была проаудирована другой компанией, тем самым снимая с себя часть ответственности.

Code review — это случай, когда мы не даём публичного отчёта, мы просто выделяем команду аудиторов, который вместе с разработчиками постоянно сидят над проектом, каждый коммит аудирует, советует как поступить в той или иной ситуации.

Setup/deploy continuous support — в случаях, когда возникают хаки связанные с тем, что разработчики допустили простую ошибку, типа: перепутали количество нулей или при деплое забыли контракт инициализировать.

Audit contests/bounty programs — очень интересный формат, что-то между полным высококачественным коммерческим аудитом и crowd аудитом за bounty, потому что у одного и другого способа есть свои и недостатки преимущества одновременно.

Как правильно аудировать

1. Нужно быть готовым к тому, что вам придется потратить много, ради решения какой-то простой задачи, а также пытаясь запустить тесты, которые вам прислали в каком-то непонятном фреймворке;

2. Ко всему подходить с критическим мышлением;

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

Кто аудирует

1. Аудиторские эксперт-команды;

2. Культовые секьюрити ресерчеры, которые нашли классные баги, например https://twitter.com/samczsun и https://twitter.com/Mudit__Gupta;

3. Баунти программы. Это хорошо работает потому, что проекту это удобно, но у такого аудита есть проблема в количестве мусорных файдингов. Их надо разгребать и классифицировать.

Как войти в аудит

1. Пройти обучение в компании MixBytes;

2. Изучать аудит самостоятельно. Для этого вам потребуется глубокое понимание того, как работает эфир, как проходят транзакции и как они применяется к стейту, чтобы понимать, как делается фронтраннинг, перехват транзакций, формируются блоки, какие у них есть параметры. Должно быть понимание блокчейна. Нужно знать, как работает внутри EVM, ее инструкции, стек машины, как она работает с памятью, передает параметры, как контракт вызывает контракт, как контракт деплоит контракт, как контракты уничтожаются, как они работают с балансами эфира, со счетчиками. То есть нужно глубокое погружение в Solidity и EVM. Затем “high level patterns”. Нужно хорошо знать ERC-20 токены, топовые протоколы, которые считаются мастодонтами, стейблкоины. Помимо этого, необходимо разбирать типовые уязвимости, потому что многие становятся через некоторое время не актуальными на данный момент. Надо много читать про уязвимости и ревью хаков. Ну и, конечно, пройти тестовый аудит для того, чтобы почувствовать себя в этой роли, понять, что конечный продукт — репорт, и его надо сделать корректно. Его должны понять разработчики и его нужно защитить. После этого набора скилов вы уже можете считаться хорошим аудитором.

Вопросы и ответы:

Какую ответственность несут аудиторы, если протокол хакнут и уведут средства?

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

Как понять, что проект уже под прицелом хакера и уже идут атаки?

Здесь все хуже, чем в Web2. Здесь к твоему сайту «принюхиваются» так, что ты об этом не знаешь. У атакующего есть полная копия блокчейна, полная копия твоего проекта до последнего, и он у себя на компьютере проигрывает будущие сценарии атаки. Определить это невозможно.

Почему аудиторам просто не пойти в хак протоколов, профит же выше?

Вы сходите на лекции, обучитесь, сможете хакать протоколы, но многие люди выбирают для себя путь “White Hack”. Так можно зарабатывать делая доброе дело, а не красть деньги и зарабатывать не сильно меньше, например, получив bounty. И в целом — это стремно, выводить краденые деньги через какой-то миксер, ведь есть большая вероятность, через 10 лет это будет деанонимизированная сеть, где каждого можно будет вычислить, ведь блокчейн все помнит.

Есть ли Статический анализ кода для Solidity?

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

Какие инструменты вы используете для тестирования смарт контрактов и создания proof-of-concept?

Зачастую это определяется клиентом. Мы используем все, в чем работают клиенты. В основном — Hardhat, Brauni и сейчас популярный — Foundry. Tenderly используем для трассирования транзакций. Для небольших задач используем Remix. Мы используем автоматические анализаторы, используем Layzer, используем Ехидна. Используем Mithril для массового аудита.

Как становятся аудитором? И какие уровни есть у аудитора?

1. Устроится в аудиторскую компанию. Внутри команды ты больше растешь.
2. Попытаться поковырять на разные протоколы, и найти баги и получить bounty.
3. Есть люди, которые проработав 10 лет в IT не становятся аудиторами, а есть студенты окончившие университет и с головой погрузившись в изучение кода, становятся аудиторами.

У нас в компании есть junior, middle, middle+, senior и team lead. Переход от грейда к грейду происходит в течении месяцев. При переходе к middle должно быть понимание основных defi-протоколов. Аудитор должен поработать в аудитах, и найти какие-то баги. Middle+ должен знать десятки протоколов и вдобавок с более серьезными математическими принципами, почувствовать в сложных, больших аудитах, у него уже должна быть собственная методология аудита. Senior — то же самое, но еще и управляет junior и middle аудиторами. Team lead больше отвечают за организационную часть и принимают основные решения в команде.

Как оценивать эффективность аудитора?

До middle+ аудитор должен знать теоретическую часть, уметь описать правильно неисправности и хаки с чек-листа, уметь объяснить и показать. В дальнейшем развитии в основном идет практическая часть, сколько аудитов прошел, сколько и какой сложности багов нашел.

Как понять, какому аудитору можно доверять?

Исторически в крипте — это сарафанное радио.

Какие проекты сейчас — самый лакомый кусочек для хакеров?

Это, конечно же, бриджи, потому что они держат огромные балансы с одной и с другой стороны. А так, по вероятности распределения багов, на первом месте: miss-configuration access controls (простыми словами, где что-то забыли прописать), манипуляция oracle price — всевозможные lending протоколы (в частности, где лежат токены с малой ликвидностью или токены, которые предоставляет сам пользователь), манипуляции ревардами — баги в вычислении разных наград, это в основном farming и yield протоколы.

Есть ли такая услуга, как аудитор токеномики?

К нам с таким не приходят, только с полным аудитом проекта. Аудит токеномики входит туда. Если говорить об отдельной отрасли, то такой нет.

Есть ли аудиторы со специализацией по платформам Ethereum и Polkadot?

EVM стала технологическим стандартам, и вы это встретите в многих проектах. Скилы аудиторов на Solidity точно так же пригодятся везде, где встречаются смарт-контракты c очень похожей структурой алгоритмов данных. На данный момент аудит, к примеру, в Polkadot и Solana не развит, и эта ниша пуста.

Какая перспектива у профессии на 2-5 лет, стоит ли учиться, не поздно ли начинать?

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

У вас в компании “пинг-понгом” с клиентом занимается менеджер или аудитор?

До определенного уровня менеджмент, после подключаются аудиторы.

Расскажи, над чем ты сейчас лично работаешь, что исследуешь, какие приоритеты в компании у тебя лично?

Весь последний год я работал над Mixbytes Farm. Моя цель — сделать самый лучший курс по безопасности смарт-контрактов. Задача — готовить крутых аудиторов, которые после этого смогут находить крутые баги и растить их в компании. Второе — тестированием различных гипотез, попытка запустить какой-нибудь инструмент. Наблюдаю за технической командой, есть ли в работе возникают какие-то проблемы, я об этом говорю коллегам. Слежу за наполнением чек-листов, базы знаний. Также моя задача — проход junior-аудиторов до middle+.