Правильные уроки из взлома Bybit, или безопасность Safe и аппаратных кошельков

Bybit взлом

Введение

Безопасность - то, с чем мне приходится сталкиваться последние 15-17 лет. И сколько бы ты ни знал, всегда есть те, кто умнее, быстрее, сильнее. И всё же есть набор правил и принципов, которые точно не стоит нарушать.

В частности, опыт Bybit для меня стал показательным, т.к. в нём сотрудники биржи пренебрегли всеми значимыми подходами к безопасности: начиная с принципиальных, т.е. наиболее абстрактных, заканчивая вполне конкретными и детальными.

Поэтому попробую рассмотреть ряд важных аспектов на базе этого взлома.

Нулевой принцип безопасности

Для себя много лет назад сформулировал его так: “Взломать можно любую систему. Вопрос всегда лишь во времени, деньгах и приложенных усилиях”. В том смысле, что если после взлома вашей системы злоумышленнику достанется $1M, а потратит он на хак $10k, то систему точно взломают, а вот если надо будет потратить $1.1M на взлом, то уже вопрос, зачем ломать такую систему? Разве что насолить конкуренту или провести атаку на вражеское государство.

Собственно, этот принцип и был нарушен сотрудниками Bybit: они считали, исходя из из первичных интервью, что их система абсолютно защищена и против неё нет орудия. Но цена в $1.4B сделала своё дело.

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

Зная это, идём дальше…

Аппаратный кошелёк + мультисиг - это безопасно?

И да, и нет. Всегда были атаки на аппаратные кошельки: пример Ledger, пример Trezor. Про другие даже не заикаюсь, потому что там всё гораздо хуже.

Но можно всегда уменьшить вред и негативное воздействие при использовании аппаратных кошельков. Вот несколько рекомендаций, которые скомпоновал от исследователей и из своего опыта:

Убедитесь, что то, что вы читаете, это и есть то, с чем вы работаете: подписываете, переводите и т.д. Если вы видите любое расхождение - остановитесь, сделайте паузу и оцените ситуацию детальней.
Соединение аппаратного кошелька с браузерным - куда лучше простого (прямого) подключения. Почему? Браузерные кошельки давно собирают базы самых разных контрактов и дают порой ложные срабатывания, но в целом подсвечивают взаимодействие с новыми контрактами и тем более - не верифицированными (а в рассматриваемом случае так оно и вышло).
Обязательно следует проверять обновление вашего кошелька и устанавливать только официальную прошивку (кроме тех редких случаев, когда вы сами занимаетесь белым хакингом). Опять же - проверить всегда можно и на сайте производителя, и через хеш-сумму.
Выполняйте моделирование транзакций до подписания любой транзакции. Делайте прерывание при (любых) неожиданных изменениях. Ключевые слова: до и прерывание.
Используйте альтернативные источники проверки. В разных случаях это может быть etherscan.io/inputdatadecoder или app.palmeradao.xyz/welcome: первая ссылка предоставляет возможность декодинга и была представлена как положительная практика после взлома Radiant, а вторая - после взлома именно Bybit командой SAFE как альтернативной “морды” для их dAPP. Также сейчас представлен инструмент от энтузиаста, который тоже помогает в проверке: koeppelmann.github.io/CirclesTools/SafeViewer.html (поиянения по инструменту см. по ссылке).
Сам SAFE представил следующие альтернативные интерфейсы:

Не стоит забывать и про API, по которому также можно узнать доп. данные про ваш сейф и переводы: safe-transaction-mainnet.safe.global/#/owners/owners_safes_retrieve.
И, наконец, не стоит пренебрегать изучением документации: docs.safe.global/advanced/cli-overview.

Это, конечно, далеко не всё. Но давайте сравним это с выводами, к которым пришли исследователи после взлома Radiant:

Многоуровневая проверка подписей: Внедрить слой управления, при котором, если хотя бы один из подписантов сталкивается с проблемами или аномалиями, процесс приостанавливается для дополнительной проверки. Это должно срабатывать, даже если ошибка кажется незначительной (например, транзакция, которая должна была быть одобрена, не проходит).
Независимое устройство для проверки: Использовать независимое устройство для проверки данных транзакции перед подписанием. Оно должно генерировать код проверки подписи, который соответствует данным, представленным на аппаратном кошельке.
Усиленная безопасность Ledger/Trezor: Избегать слепой подписи для критически важных транзакций. Если это неизбежно, обеспечить наличие отдельного уровня видимой проверки, например, отображения данных транзакции в читаемом формате непосредственно на аппаратном кошельке.
Аудит при повторяющихся ошибках: Интегрировать механизм, при котором повторяющиеся ошибки или сбои транзакций автоматически запускают полный аудит транзакции перед выполнением дополнительных попыток подписания.
Ручная проверка данных транзакции: При выводе запроса на подпись из провайдера кошелька (например, Metamask, Rabby), выгружать данные транзакции и декодировать их через [Etherscan Input Data Decoder]. Убедиться, что вызываемая функция и адрес совпадают с ожидаемым поведением. Если устройство было скомпрометировано, данные могут не декодироваться, вызывать другую функцию или содержать некорректный адрес владельца.
Также рекомендуется дважды подтверждать каждый хэш сообщения на аппаратных кошельках с использованием Gnosis [Инструкция по проверке транзакций на аппаратном кошельке].

Было ли что-то из этого внедрено Bybit? По имеющимся данным - нет.

Человек - самое слабое звено

Это означает, что обычный спам, фишинг, социальная инженерия могут заменить 80% технологичных взломов. Собственно, в делах Radiant & Bybit это наиболе заметно.

Поэтому первое, что нужно сделать, это распределить роли:

Если у вас 2-3 и более подписанта, они должны иметь резервные каналы связи, чтобы подтвердить (верифицировать) любую транзакцию;
Любая смена владельцев должна быть более сложной процедурой, чем подписание транзакции;
Кошельки, даже холодные, не должны содержать больше возможных потерь: $1.5B - явный перебор даже для крупной биржи;
Любые неточности при переводе должны трактоваться не в пользу его завершения, а в пользу отмены;
Персонал должен проходить обучение по последним взломам: хотя бы ежемесячно, т.к. паттерны поведения тоже важны;
Иметь хотя бы одного верификатора из отдела безопасности, который будет обладать более глубоким опытом в работе с мультисиг-кошельками и другими средствами защиты.

Опять же, из публичных данных подтвердить хотя бы применение части подобных пунктов в Bybit нельзя.

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

Их довольно много, поэтому публикую лишь выборочную подборку:

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

Поэтому я бы рекомендовал прямо сейчас всем изучить ещё раз дела Radiant, WazirX и подобные им, поскольку скрипт-киддисы явно взяли технику на вооружение и теперь под атакой будут далеко не только биржи.

До!