Мосты снова горят: IoTeX bridge хак и что делать пользователю

Дисклеймер: материал носит информационный характер и не является инвестрекомендацией.

На прошлой неделе в ленте снова всплыло то, что рынок обычно вспоминает только после потерь: мосты — это не транзакция между сетями, а отдельная зона доверия. В кейсе IoTeX/ ioTube обсуждают компрометацию приватного ключа и оценки ущерба от $2 млн до $8+ млн — в зависимости от методики подсчёта. 

Эта статья — про то, почему мосты ломаются именно так, может ли атакующий продолжать вывод, и что можно сделать, чтобы не стать статистикой.

Что известно про взлом IoTeX ioTube

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

Почему оценки потерь расходятся:

• часть источников считает только подтверждённо украденные активы (это даёт меньшую цифру, около $2 млн); 
• часть считает шире — включая дополнительные эффекты/движения активов и возможные производные потери на мостовой инфраструктуре (вплоть до $8+ млн).

Отдельно в новостях фигурирует реакция команды: обсуждались шаги по сдерживанию и публичные предложения white-hat формата (бонус за возврат средств) — это типичная антикризисная практика после bridge-инцидентов. 

Почему компрометация приватного ключа — одна из самых неприятных причин взломов

Когда ломают смарт-контракт, у вас есть шанс сказать: это баг в коде, его закрыли.

Когда ломают приватный ключ, проблема в другом:

• это не ошибка логики, а ошибка операционной безопасности (хранение ключа, доступы, устройства, процессы);
• атакующий может получить админ-права: обновить контракт, изменить параметры, обойти проверки, провести разрешённые действия;
• расследование часто сложнее: вы не всегда сразу понимаете, какие полномочия реально были у ключа.

Для пользователя это означает: мост может быть аудирован, но это не защищает от компрометации ключей.

Может ли атакующий продолжать вывод?

Зависит от трёх вещей:

Сохранил ли атакующий доступ к ключу/админ-контролю

Если контроль не отозван и не заменён (ротация ключей/контракта), риск повторных действий остаётся.

Есть ли у протокола быстрые предохранители

Пауза (pause), лимиты на вывод, rate-limits, блокировка адресов на уровне нод/контрактов, отключение маршрутов — всё это может резко снизить ущерб.

Удалось ли перехватить деньги на выходе

Часть средств иногда пытаются заморозить через централизованные площадки/эмитентов стейблкоинов, но это работает не всегда и не по всем активам. 

6 вещей, которые нужно сделать, если вы пользовались этим мостом

1) Перестаньте взаимодействовать с мостом до официального «all clear»

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

2) Проверьте approvals/allowances и сделайте revoke

После bridge-историй всегда всплывают фишинговые claim/verify, которые заканчиваются approve. Разрешения — это отдельная плоскость риска, даже если вы не потеряли деньги на самом взломе.

3) Если держали активы на адресе для бриджей — перенесите остатки на чистый адрес

Если вы подключали кошелёк к куче dApp’ов, лучше иметь отдельный адрес под риск-активности. Это снижает вероятность цепной потери.

4) Не верьте саппорту в личке

«Мы вернём средства, подтвердите кошелёк» — главный шаблон после любых инцидентов.

5) Соберите доказательства

Tx-hash’и, скриншоты, время, сети, активы — пригодится для заявок в поддержку/расследований и просто для собственной налоговой истории.

6) Следите только за первоисточниками

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

Как безопасно пользоваться мостами

Если бридж сейчас — необходимость, используйте правила снижения ущерба:

• отдельный адрес под бриджи и dApp’ы;
• минимальные approvals (не unlimited);
• тестовая транзакция;
• не бриджить в первые часы после громких новостей/обновлений — там самый высокий процент ошибок и фишинга.

IoTeX bridge hack снова напомнил: самая частая проблема мостов — не сложный баг в математике, а компрометация ключей и прав доступа. Мост — это отдельный риск-слой, который нужно проверять так же внимательно, как биржу или кошелёк.