Хакери вкрали 9,400 SOL з гаманців ботів, і винуватцем вважається скопійований ключ

Звіт про реконструкцію Bitquery повідомляє, що 48 гаманців, пов'язаних з Bloom, автоматизованою торговою службою, втратили 9,408 SOL через перекази, підписані власними ключами гаманців.

Bloom документує блокування, яке запобігає змінам адреси виведення користувача, проте скопійований ключ може авторизувати перекази за межами цього інтерфейсу служби.

У оновленні від 26 жовтня Bloom заперечив, що приватні ключі були доступні або скомпрометовані. Обліковий запис пов'язав інцидент з вразливістю виконання віддаленого коду в сторонньому модулі і заявив, що неушкоджені гаманці були в безпеці.

Пізніше 26 жовтня Bloom оголосив, що всі дев'ять постраждалих користувачів були повністю відшкодовані, стверджуючи про загальну суму 9,408 SOL і пов'язуючи дев'ять транзакцій.

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

Що контролює блокування виведення

Часті запитання Bloom радять користувачам зберігати свою адресу виведення заблокованою, стверджуючи, що адресу не можна змінити, поки вона заблокована, і що розблокування починає 24-годинний період охолодження перед дозволом на зміни.

Посібник з виведення розміщує "Встановити адресу", "Заблокувати адресу" та "Розблокувати адресу" в меню Виведення, доступному з домашнього екрану або через команду /withdraw. Документований захист затримує заміну призначення, використаного в цьому процесі.

Блокування надає особі з скомпрометованим обліковим записом служби бар'єр проти перенаправлення виведення через цей процес.

Домашня сторінка продукту Bloom описує продукти Extension, Manager та Telegram як такі, що ділять один і той же механізм виконання. Коли той же ключ гаманця використовується через інший інтерфейс, він зберігає ті ж повноваження над коштами.

Bitquery повідомляє, що повні зливи відбувалися з 01:03:07 до 01:04:41 UTC 26 жовтня. Він описує кожен як простий переказ SOL, підписаний лише ключем постраждалого гаманця, без другого підписувача або схвалення токена.

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

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

24-годинне блокування виведення Bloom блокує зміни адреси, але скопійований приватний ключ все ще може авторизувати перекази з звичайного гаманця.

Посібник Solana розрізняє утримання локального ключа від запиту підписів через бекенд управління ключами або керованого гаманця. Дійсний підпис власника-ключа може бути узгодженим зі скопійованим матеріалом ключа або зловживанням шляхом підписання.

Підписи власника-ключа, описані Bitquery, стоять поряд із запереченням Bloom про компрометацію приватного ключа. Визначення, який шлях підписання був зловжитий, визначить, чи був інцидент пов'язаний зі скопійованим секретом або доступом до системи, яка могла б підписати з ним.

Де зберігаються повноваження підписання

Вік постраждалих гаманців надає інциденту наслідки, що виходять за межі активних користувачів ботів. Bitquery виявив, що 24 з 48 гаманців не сплатили жодної комісії за торгівлю Bloom за попередній місяць, тоді як п'ять востаннє сплатили її між січнем і травнем 2025 року.

Bitquery пов'язав усі 48 гаманців з Bloom через попередні платежі комісій і об'єднав їх у дев'ять трейдерів. Він визнав, що дві з цих груп в основному покладаються на порядок зливу.

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

Окремий злив TradeWiz пропонує застарілий приклад постійного підписного впливу, не встановлюючи спільну причину з Bloom. Bitquery датував основний злив 30 вересня і підрахував 20,793 гаманців, з яких було вкрадено SOL.

Торгові угоди з оплатою комісії зупинилися через 41 хвилину після зливу, але Bitquery повідомляє, що бот забрав 73% основного зливу SOL після цього.

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

Якщо єдиний контролюючий ключ втік, переміщення активів до нового гаманця, яким керує не скомпрометований ключ, виводить ці активи з-під контролю старого ключа.

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

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

У своїй обіцянці про відшкодування Bloom заявив, що кошти підуть на безпечні гаманці, призначені постраждалими користувачами, а його пізніше оголошення говорить, що він завершив повернення.

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