Злам Bybit на 1,4 мільярда: компанії пропонують рішення для безпеки після атаки Лазаря

Отримання прибутку з катастрофи: компанії прагнуть скористатися зламу Bybit

Це фрагмент з повідомлення 0xResearch. Щоб читати повні випуски, підпишіться.

Злам Bybit на 1,4 мільярда доларів викликав передбачувану реакцію: наплив компаній з безпеки та інфраструктури, які стверджують, що їх технологія могла запобігти атаці.

ФБР підтвердило, що злам був справою групи Лазаря з Північної Кореї, яка націлилася на систему Safe{Wallet} Bybit. Ключовою деталлю, озвученою вчора, є те, що скомпрометована була машина розробника Safe, а не інфраструктура Bybit, що дозволило зловмисникам вводити шкідливий код у інтерфейс підписання транзакцій.

Обман призвів до того, що підписувачі Bybit сліпо схвалили шахрайську транзакцію, що призвело до виведення коштів з їх найбільшого гаманця Ethereum.

Дослідник безпеки Тейлор Монахан підкреслила, що ця атака була повністю передбачуваною, враховуючи тривалу проблему сліпого підписання в криптоіндустрії. Як вона зазначила: `Немає жодної організації в цій галузі, яка достатньо серйозно ставиться до безпеки, щоб захистити від відданого, постійного, мотивованого противника, як Лазар.`

Основні висновки включають:

• UI Safe{Wallet} був скомпрометований — інтерфейс Bybit показував очікувану транзакцію, але підписувачі неусвідомлено схвалили зовсім іншу транзакцію.
• Сліпе підписання на пристроях Ledger стало остаточною невдачею — останній підписувач Bybit, Бен Чжоу, визнав, що не перевірив транзакцію повністю на своєму апаратному гаманці Ledger перед її схваленням.
• Атака націлилася на людський контроль — Лазарю не потрібно було експлуатувати смарт-контракти або порушувати криптографічну безпеку; вони просто використали довіру до інтерфейсу.

Колишній CEO Binance CZ критикував відповідь Safe, ставлячи критичні питання, такі як: чому машина одного розробника мала доступ до процесу транзакцій Bybit? Як процес підписання Ledger не зміг запобігти цьому? Які уроки з безпеки слід винести індустрії?

Це все хороші питання, на які знадобиться час, щоб повністю відповісти. Хвиля компаній вривається у простір.

З кожним високопрофільним зламом компанії заповнюють простір, стверджуючи, що їхній продукт міг би його зупинити. Деякі вирішують конкретну проблему — безпечну перевірку транзакцій — в той час як інші підхоплюють наратив для маркетингу.

Приклади компаній:

• OISY (гаманці на основі Dfinity):
  Стверджує, що розширення браузерів і управління приватними ключами є слабкими ланками. OISY усуває їх, працюючи повністю на ланцюгу.
  Реальність: Атака не пов`язана з розширеннями браузера або витоком приватних ключів — це було сліпе підписання.
• Impossible Cloud Network (децентралізоване зберігання в хмарі):
  Стверджує, що централізовані хмарні сервіси (як AWS) були коренем проблеми.
  Реальність: Хоча декомплексне зберігання може зменшити площу атак, Bybit не був зламаний через AWS.
• Cubist (безпека підписання на основі апаратури):
  Стверджує, що суворі політики підписання блокували б цей напад.
  Реальність: Це дійсно актуально. Якщо б Bybit запровадив обмеження на підписання, Лазар не зміг би обманути їх у сліпому підписанні.
• Fireblocks (основи безпеки на основі MPC):
  Стверджує, що модель безпеки Bybit була фундаментально несправною.
  Реальність: Ця заява є однією з більш дійсних відповідей.

Проте є й ризик, як зазначила Тейлор Монахан у своєму характерному стилі: `Розкішний мультипідпис, напів-кастодіальна, MPC, бла-бла-бла продукт… робить вашу область атаки БІЛЬШОЮ, а не меншою.`

Справжній урок: довіра до інтерфейсу є найбільшою прогалиною в безпеці. Атака на Bybit не була про смарт-контракти, децентралізацію або безпеку приватних ключів — це була про сліпу довіру до скомпрометованого інтерфейсу.

• Суворі політики підписання транзакцій
• Обов`язкова перевірка транзакцій на апаратних гаманцях
• Затримки в управлінні та багатошарові схвалення