Атака Unibot раскрывает какие проблемы безопасности Bot-подобных продуктов?
31 октября Unibot подвергся атаке, и в официальном сообщении Unibot говорилось: "Причиной атаки стала уязвимость в утверждении токенов в новом маршрутизаторе, и любые потери средств из-за ошибки в новом маршрутизаторе будут компенсированы; ключ и кошелек пользователя находятся в безопасности".
Известно, что в результате атаки было потеряно более 600 тыс. долл. Хотя команда обещала все выплатить. Но атака обнажила проблемы с Unibot, да и с самим Telegram Bot как неким продуктом.
Некоторые специалисты отмечают, что эта атака была больше похожа на преднамеренный акт "крота": поскольку контракт не был с открытым исходным кодом, хакеры легко нашли уязвимость, и через неделю после запуска Unibot хакеры осуществили развертывание атаки, пролежавшей в спящем режиме полгода для этой атаки.
Из этого инцидента мы видим, что сам Telegram Bot также имеет большие проблемы с безопасностью, особенно в отношении денег, транзакций, ведь требования к безопасности очень высоки, но есть и широко распространенные проблемы, такие как код не является открытым исходным кодом, закрытый ключ не локализован для хранения.
Общие проблемы, выявляемые Unibot
Атаки на Unibot кажутся вполне ожидаемыми. Инсайдеры отрасли сходятся во мнении: не стоит вкладывать в него слишком много денег, поскольку аналогичный Telegram Bot не выглядит безопасным.
В криптоиндустрии на данный момент сложились, по сути, две логики и пути развития с точки зрения безопасности. Первый похож на централизованные биржи, которые используют гарантии активов и подлежат государственному регулированию. Доверие общества по-прежнему обусловлено репутацией крупных компаний и государственных органов, которые их регулируют.
Другой путь - это децентрализованные продукты, такие как Defi и самораспространяющиеся кошельки. Контракты и код, проверяемые на всех уровнях, используются для того, чтобы максимально обезопасить активы пользователей. Конечно, более важным аспектом этого пути является то, что пользователи сами несут ответственность за себя и обладают знаниями о безопасности в индустрии блокчейна.
Но для такого продукта, как Unibot, который фактически выступает в качестве инструмента, соединяющего миры Web2 и Web3, как можно гарантировать его безопасность для продукта Web2.5?
Давайте сначала разберемся, что не так в самом Unibot. Во-первых, есть проблемы с самим контрактом Unibot. Те же Telegram-транзакции в бот-стартапе Джерри рассказал Golden Finance, что атака проста - хакер манипулирует контрактом Unibot, а в самом контракте есть авторизация токена пользователя, поэтому хакер манипулирует контрактом, чтобы перевести токен пользователя на свой счет.
Эта уязвимость должна была быть исключена в ходе предыдущего аудита безопасности. А проекту не следовало проводить строгий аудит, в открытой информации не было новостей об аудите контракта. И не с открытым исходным кодом.
В дополнение к обнародованным на сегодняшний день проблемам, Unibot, сам продукт, также имеет массу проблем, например, с безопасностью закрытого ключа пользователя. Когда пользователи используют Unibot, их приватные ключи отправляются непосредственно в диалоговое окно в Telegram. Любой человек, обладающий хоть каплей здравого смысла в этой отрасли, знает, что приватные ключи никогда не должны выкладываться в открытый доступ.
Пользователи понимают, что после отправки ключа в диалоговое окно Unibot может фактически завладеть закрытым ключом пользователя. Если у владельца проекта есть воля, он может творить зло.
Чтобы избежать подобной ситуации, такие боты должны хранить свои закрытые ключи локально. Конечно, под таким подходом к размещению закрытых ключей можно понимать и класс торговых роботов Unibot. Поскольку этот способ может представлять собой диалоговый тип взаимодействия, пользовательский транзакционный опыт будет плавным, что не обязательно, как в маленьком лисьем кошельке, каждую транзакцию необходимо подписывать авторизацией.
