Bybit. Взлом. Дополнения

Когда прочитал посты, о которых пойдёт речь, было около 00:10. Сейчас уже 00:38 и это дело всё ещё крутится у меня в голове. Почему? Потому что кучка не компетентных чуваков решило задавить весь рынок, который должен принять, что они ни в чём не виноваты. Хотя виноваты они и больше никто.

Нет, хакеры виноваты тоже, но в своём векторе. А вот в халатном отношении виноваты сотрудники Bybit и прежде всего - их улыбающийся вечно CEO.

Данные №01

Взяты здесь: https://x.com/AuditUrContract/status/1894494912818942234. Идём по пунктам:

1. Некоторые интересные сведения от @Bybit_Official после взлома. Во-первых, 2 из 3 ключей подписи (0x1F4E.2211 и 0x3Cc3..C21A) до недавнего времени использовались редко. Вы можете самостоятельно проанализировать данные здесь: github.com/audityourcontracts/secure-decoder/blob/main/notebook/bybit-transactions.csv
2. Похоже, что в течение последнего года (12 операций назад) был внедрён новый процесс подписания. Сначала идёт 0x1F4E.2211, затем 0x3Cc3..C21A, а затем @benbybit с 0xe3dF..5a9E. Как заявил Бен: (он) обычно подписывает (транзакции) последним.
3. 0x1F4E.2211 и 0x3Cc3..C21A были добавлены в кворум 236 и 554 дня назад соответственно. @WazirXIndia был взломан 222 дня назад, так что кошельки hw не были заменены после взлома WazirX. Помните, ByBit - это почти повторение WazirX https://etherscan.io/tx/0x1425b4dad07b6812d356a00919f6fca35c7f67dda1476581fabe06820101c888 (ЭТОТ ПУНКТ ВЕСЬМА ВАЖЕН, т.к. подтверждает халатность Bybit).
4. На блоке 21895237: 6 ключей могли подписать любую транзакцию при пороге в 3 необходимых. Мне нравится большой пул потенциальных подписантов, но я считаю, что порог низковат. У WazirX был 4/6 и потребовал от Lazarus найти уязвимость в соподписанте Liminal. Очевидность 20/20 и т. д.
5. Интересен эпизод с Беном. Он раскрывает свою позицию подписи и то, что он использовал Ledger и, вероятно, слепую подпись. Позже Safe показал, что Bybit использовал нативный интерфейс Ledger (не Metamask) https://x.com/i/spaces/1OdKrDlkonXJX & https://x.com/safe/status/1893797070236188729. Существует разумная вероятность того, что все устройства подписывались вслепую. (Menaskop: ЭТОТ ПУНКТ ТАКЖЕ важен, поскольку тоже подтверждает халатность Bybit).
6. Если бы данные EIP-712 были видны подписывающим на аппаратном устройстве, они должны были бы быстро определить, что транзакция является вредоносной. Операция operation была установлена на 1 или на вызов делегата. Селектор функции был 0xa9059cbb, чтобы имитировать transfer(address,uint256), но поле to было непроверенным (!!!).
7. Небольшое отличие от атаки WazirX заключается в использовании хорошо известного селектора функций 0xa9059cbb. В атаке WazirX Lazarus использовал 0x804e1f0a, который не найден в большинстве баз данных сигнатур. Большинство “сигнатурщиков” обучены проверять поле данных и, в частности, селектор функции.
8. Поле данных транзакции Safe было 0xa9059cbb000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025be2969516000000000000000000000000000000000000000000000000000000000000000000. Я думаю, что подписывающему разумно определить селектор функции, адрес и быть предупреждённым о том, что адрес был неизвестен, а значение на самом деле 0.
9. Интересно, что холодный кошелек ByBit никогда не использовал перевод до 42 дней назад. Кошелек всегда переводит ETH, поле данных которого равно 0x. Единственные переводы ERC-20 были сделаны для mETH и затем фальшивый перевод в атаке. См.: https://etherscan.io/tx/0xf356b8a8b3dcd1530ef7ee3d2a896e5f0035ea9833cdf6f0fbea6f7b4369c813
10. Если подписывающие использовали Ledger Flex или Trezor One, у них был шанс увидеть эти данные EIP-712. Они должны были знать, что нужно искать операцию, установленную на 1, а также что ни один из адресов в to или функции передачи не был известен ERC-20, проверенным контрактам или горячим кошелькам ByBit.
11. Что произошло? (Ничего не поменялось в использовании) Ledger Nano … после атаки WazirX. Бен (CEO Bybit) использовал свой рабочий ноутбук для подписания транзакций (другие подписанты могли делать то же самое). Это открыло их для (через) фишинг. Они подписывали вслепую и должны были знать, что (согласно взломам) WazirX и Radiant, сайтам Safe и Tenderly нельзя доверять полностью. У них не было возможности проверить поля EIP-712 на устройстве, подписывающем транзакции.
12. Как сделать это правильно? Специальные устройства для подписи, Chromebooks или iOS. Hw-кошельки, отображающие данные EIP-712, например Trezor One или Ledger Flex. Разделите про-позиционирование и подписание. Часто подписывающие лица менее технически грамотны/подкованны, и если только предлагающие могут предлагать, а подписывающие - подписывать, вы можете применить дополнительные средства контроля на этапе предложения. Это также означает, что противнику необходимо скомпрометировать всех действительных предлагающих, а затем скомпрометировать большинство подписывающих. Безопасная защита также обеспечит смягчение последствий на цепи.

Данные №02

См. здесь: https://x.com/koeppelmann/status/1894355700341526971

Пишу на английском и русском, т.к. часть текста - на скриншоте:

Цитата: This is the ‘safe transaction» that 3 Bybit owners signed and that led to this catastrophic loss. Operation «1» (instead of 0) needs to always ring alarm bells, as it means «delegate call», meaning the Safe performs the code of «to» on its own state instead of just calling it.

Перевод: Это «безопасная транзакция», которую подписали 3 владельца Bybit и которая привела к катастрофическому (взлому/проигрышу). Операция «1» (вместо 0) всегда должна вызывать тревогу, поскольку она означает «вызов делегата», то есть Safe выполняет код «to» на своем собственном состоянии, а не просто вызывает его.

Цитата: If such a transaction  is proposed on the Safe interface, it will show you a big, fat warning. Because the Bybit team credibly reported that this was not the case, the Safe team took the drastic decision to take the interface down. However, there are other possible explanations- mainly that the machine(s) of the Bybit team may have been compromised. The Safe team checked every bit they could and did not find anything suspicious, so they will bring back the interface with enhanced

Перевод: Если такая транзакция будет предложена в интерфейсе Safe, он покажет вам большое и жирное предупреждение. Поскольку команда Bybit достоверно сообщила, что это не так (!!!), команда Safe приняла радикальное решение отключить интерфейс. Однако есть и другие возможные объяснения - в основном это то, что машина (машины) команды Bybit могла быть взломана. Команда Safe проверила все, что только можно, и не нашла ничего подозрительного, поэтому они вернут интерфейс с улучшенными возможностями.

Выводы

Bybit виновны:

1. В слепой подписи
2. В подборе некомпетентного персонала
3. В отсутствии доп. проверки переводов
4. В переводах с ошибками
5. В хранении средств на 1 мультисиге

(А ещё они дампят рынок вместе с ММ и не стесняются). Поэтому выводы у меня те же, что и раньше: уверенности в них - ещё больше.

До!