Автор: imToken
Аппаратный кошелек с нетронутыми оригинальными чипами, подлинной прошивкой и даже способностью успешно пройти официальную проверку Genuine Check — могут ли активы внутри все еще быть украдены хакерами?
Недавний инцидент безопасности с Ledger как раз и обнажил этот, казалось бы, невозможный риск.
Согласно результатам расследования, впоследствии обнародованным командой безопасности Ledger, злоумышленник внедрил внутрь затронутого устройства дополнительную вредоносную схему, которая была способна перехватывать мнемоническую фразу, отображаемую на экране, и отправлять ее злоумышленнику через сети мобильной связи.
Иными словами, оригинальный чип безопасности не был скомпрометирован, но мнемоническая фраза, возможно, уже попала в руки хакера в тот момент, когда она впервые была отображена на экране.
Более того, это не единственный инцидент безопасности, заслуживающий внимания в последнее время.
С сентября — от Bitget, столкнувшегося с эксплуатацией уязвимости стороннего продукта безопасности, до взлома поставщика услуг электронной почты Trezor компании Brevo, до проблем безопасности, появившихся в части инфраструктуры MetaMask, — череда инцидентов напоминает нам, что по мере того, как криптопродукты становятся все более сложными, безопасность больше не сводится только к защите приватных ключей и избежанию уязвимостей смарт-контрактов.
Риски, скрытые в обороте устройств, сторонних сервисах, внутренних разрешениях и коммуникациях с пользователями, равным образом могут стать точками входа, которые ищут злоумышленники.
I. Новый сигнал тревоги по «безопасности цепочки поставок», прозвучавший от Ledger
Давайте сначала разберем, что произошло с Ledger на этот раз.
При покупке аппаратного кошелька люди обычно остерегаются двух вещей: покупки подделки или получения устройства, которое было предварительно инициализировано кем-то другим.
Самый распространенный трюк в ранние годы заключался в том, что злонамеренные посредники сначала генерировали мнемоническую фразу, печатали ее на скретч-карте и вкладывали обратно в упаковку, рассчитывая на то, что начинающие пользователи не поймут правил и напрямую внесут средства на нее.
Хотя эта мошенническая схема опасна, логика защиты очень ясна — используйте легальные каналы, проверяйте состояние устройства, следите за тем, чтобы устройство само генерировало новую мнемоническую фразу, и никогда не используйте готовую мнемоническую фразу из коробки.
Но эта атака против Ledger явно вывела методы на новый уровень. Хакер встроил внутрь корпуса дополнительный электронный модуль с микроконтроллером, eSIM и возможностями сотовой связи. Когда пользователи впервые инициализируют кошелек, им в конечном итоге потребуется прочитать мнемоническую фразу с экрана и записать ее.
Иными словами, внедренная вредоносная схема вовсе не вмешивается в процесс генерации мнемонической фразы; она лишь отслеживает мнемоническую фразу и напрямую передает ее наружу. Именно поэтому тот факт, что «приватный ключ не был напрямую извлечен из чипа безопасности», не означает, что информация для восстановления кошелька пользователя все еще в безопасности.
Что еще более проблематично, даже если устройство проходит официальную проверку Genuine Check, оно может быть не в состоянии выявить это дополнительное оборудование, поскольку проверка подлинности в основном подтверждает идентичность чипа безопасности и надежность прошивки.
Таким образом, этот инцидент действительно обнажил серьезный «риск цепочки поставок», который легко упускается из виду в повседневной жизни: безопасность аппаратного кошелька зависит не только от чипа и прошивки, но и от всего процесса доставки от завода-изготовителя до рук пользователя.
В конце концов, устройство может пройти через множество звеньев, таких как региональные дистрибьюторы, сторонние склады, логистика и розничные продавцы. Любой участник, имеющий возможность физического доступа к устройству, может стать точкой риска, требующей дополнительной оценки.
II. От Trezor к Bitget: как злоумышленники обходят основные рубежи безопасности?
Поняв проблему Ledger, если затем посмотреть на инциденты безопасности, с которыми Bitget и Trezor столкнулись один за другим в последнее время, мы обнаружим, что лежащая в их основе логика поразительно схожа: злоумышленники точно так же избегали самой сильной лобовой линии обороны и вместо этого проникали через периферийные «сторонние сервисы».
Сначала рассмотрим Trezor.
В начале сентября некоторые пользователи Trezor получили электронное письмо с темой «Критическое предупреждение безопасности: уязвимость энтропии STM32», в котором утверждалось, что аппаратный кошелёк имеет серьёзную уязвимость безопасности и что необходимо немедленно принять меры.
Такие письма легко заставляют пользователей нервничать. В конце концов, когда речь идёт об аппаратных кошельках и уязвимостях безопасности, никто не хочет, чтобы его активы пострадали из-за этого.
Именно это и произошло: злоумышленник использовал Brevo — стороннюю платформу email-маркетинга, используемую Trezor, — чтобы вредоносный контент попадал в почтовые ящики пользователей через обычную инфраструктуру отправки электронной почты.
Согласно последующему отчёту Brevo об инциденте, злоумышленник использовал flaws границ разрешений в своей системе единого входа, чтобы получить несанкционированный доступ к другим клиентским аккаунтам, что в конечном итоге затронуло 138 клиентских аккаунтов, некоторые из которых использовались для отправки фишинговых писем или экспорта контактных данных.
Trezor впоследствии подтвердила, что в ходе инцидента было экспортировано 347 149 контактных адресов электронной почты для маркетинга, а атакующие письма пытались побудить пользователей загрузить вредоносные приложения и ввести информацию для резервного копирования кошелька.
Следует отметить, что в этом инциденте нет доказательств того, что аппаратные кошельки Trezor или системы защиты приватных ключей были скомпрометированы. Злоумышленник сначала получил пользовательскую информацию и возможность злоупотреблять официальными каналами связи.
Но для обычных пользователей, получивших эти письма, выявление риска стало ещё сложнее, поскольку письма могли приходить с знакомого официального домена и также могли проходить обычные проверки аутентификации электронной почты, в то время как содержимое уже было заменено злоумышленником на фишинговую информацию.
Если пользователи по этой причине добровольно введут свою мнемоническую фразу, то то, что изначально было лишь проблемой стороннего почтового сервиса, может далее перерасти в реальные потери активов.
Теперь посмотрим на Bitget.
24 сентября в некоторых горячих и тёплых кошельках Bitget произошли несанкционированные переводы активов, которые в конечном итоге были подтверждены как затрагивающие примерно 388 миллионов долларов США.
Согласно результатам расследования, официально объявленным Bitget, злоумышленник использовал уязвимость в стороннем продукте безопасности, чтобы получить учётные данные с высокими привилегиями внутри биржи, затем проник в бэкенд-системы, связанные с кошельками, подделал инструкции на вывод средств, обошёл исходные проверки риск-контроля и обеспечил попадание аномальных переводов в нормальный процесс исполнения.
Bitget заявила, что в этом инциденте не было обнаружено утечки приватных ключей, и холодные кошельки не пострадали. Это звучит несколько противоречиво: если приватные ключи не были украдены, почему деньги всё же могли быть переведены?
На самом деле это нетрудно понять.
Для кастодиальных платформ, таких как биржи, после того как пользователь инициирует вывод средств, дело обстоит не так, что человек каждый раз вручную подписывает каждую транзакцию приватным ключом. Вместо этого необходимо пройти через целый набор внутренних процессов, таких как проверка аккаунта, проверка риск-контроля, генерация транзакции и подписание кошельком.
Это похоже на банковское хранилище. Даже если ключ от хранилища хранится очень строго, если кто-то может выдать себя за внутреннюю личность с высокими привилегиями и подделать платёжное поручение, проходящее одобрение, средства в хранилище всё равно могут быть ошибочно переведены наружу.
То, что Bitget обнажила на этот раз, — это именно то, как риск далее распространяется на систему исполнения активов после отказа вышестоящих разрешений и проверки инструкций. Поэтому «приватный ключ не был утёк» и «средства не будут незаконно переведены» — на самом деле две разные вещи.
Что касается инцидента безопасности инфраструктуры, раскрытого MetaMask в конце сентября, то он представляет собой ещё одно измерение операционного риска.
В то время MetaMask приняла превентивные меры и заранее вывела некоторые затронутые стейкинг-валидаторы. Согласно обновлённой информации официального расследования от 1 октября, не обнаружено признаков того, что кошельки MetaMask или средства клиентов были затронуты, а соответствующий стейкинг-бизнес не управляет ключами вывода от имени клиентов.
Однако это не означает, что проблемы инфраструктуры не окажут иного влияния. Некастодиальные решения в основном решают вопрос контроля над активами, но они не могут автоматически устранить операционные риски внешней инфраструктуры.
Сложив эти события вместе, цепочка на самом деле очень ясна:
- То, что выявил Ledger, — это риск физического вмешательства в процесс обращения аппаратного обеспечения, который в конечном итоге может привести к краже мнемонических фраз;
- То, что выявили Trezor / Brevo, — это риск утечки пользовательской информации и злоупотребления официальными каналами связи, что не означает, что сам кошелёк был скомпрометирован;
- То, что выявил Bitget, — это риск передачи уязвимостей сторонних продуктов во внутренние системы с высокими привилегиями, что может напрямую повлиять на исполнение операций с средствами;
- MetaMask, в свою очередь, напоминает нам, что контроль над активами и риск эксплуатации сервиса — это не одно и то же понятие.
В целом, сегодняшние криптопродукты уже не являются изолированными островами.
Кошельки полагаются на внешние RPC-узлы для чтения данных ончейн и на агрегационные интерфейсы для получения рыночных котировок; биржи не могут обойтись без внешнего мониторинга безопасности, KYC-верификации и компонентов риск-контроля; а если копнуть ещё дальше, есть также операторы узлов, облачные провайдеры, тикеты службы поддержки и почтовые системы вроде Brevo.
Эти внешние сервисы делают работу продуктов более эффективной и также улучшают пользовательский опыт, но в то же время каждый раз, когда вводится новая внешняя зависимость, продукт приобретает ещё один слой доверительных отношений, которыми необходимо управлять:
К чему могут получить доступ третьи стороны, каким объёмом полномочий они обладают и, если они скомпрометированы, будет ли риск передаваться дальше в другие ключевые системы?
III. Как должны защищаться продукты и пользователи?
Столкнувшись со всё более сложными рисками зависимостей от третьих сторон и взаимосвязанными зависимостями, ожидать, что продуктовые команды отступят к первобытному состоянию «не полагаться ни на какие внешние сервисы», очевидно нереалистично и не соответствует рыночным правилам.
Что действительно проверяет мастерство архитектуры безопасности, так это минимизация каждой возможной подверженности риску.
Например, почему SaaS-провайдер, который занимается только маркетинговыми рассылками, должен долгосрочно хранить контактные данные всех пользователей? Почему инструменты стороннего мониторинга безопасности могут получать доступ к основной производственной среде без независимой многоуровневой авторизации? Особенно в случае чувствительных действий, связанных с переводом средств, внутренние системы ни в коем случае не должны применять «доверие по умолчанию» и обязаны внедрять строгую изоляцию полномочий и независимую перекрёстную проверку.
Это также то, что в архитектуре безопасности часто называют «наименьшими привилегиями» и «разделением обязанностей»: платформа для отправки электронной почты должна обладать только полномочиями, необходимыми для отправки писем, инструменты мониторинга безопасности не должны иметь возможности произвольно выполнять переводы средств, а крупный вывод средств не должен одобряться напрямую исключительно на основании инструкции, переданной из какой-либо внутренней системы.
Инцидент с Ledger дополнительно напоминает производителям аппаратных кошельков, что управление безопасностью должно распространяться даже на процесс физического обращения продукта.
От отгрузки с завода, складского хранения, логистики до передачи дилеру — как выстроить прослеживаемый процесс управления, как обнаружить аномальную разборку или замену устройств и как после возникновения проблемы локализовать затронутые партии и пользователей — всё это не должно рассматриваться как обычная работа по управлению каналами сбыта.
Потому что для аппаратного устройства, защищающего приватные ключи, сам процесс доставки является частью системы безопасности.
Конечно, для обычных пользователей мы не можем ни провести аудит программной цепочки поставок кошелька, ни расследовать каждое звено складского хранения и логистики аппаратного кошелька по отдельности.
Но это не означает, что мы можем лишь пассивно нести риск. По крайней мере, есть несколько вещей, которые стоит превратить в привычку в повседневном использовании.
Во-первых, минимизируйте ненужных посредников в процессе покупки аппаратного кошелька.
Если позволяют условия, в первую очередь заказывайте на официальном сайте бренда и организуйте доставку напрямую с завода-изготовителя или с официального склада, что обычно снижает вероятность того, что устройство после выхода из-под контроля завода-изготовителя будет кем-то вскрыто, разобрано или заменено третьими лицами.
С точки зрения управления рисками, чем больше независимых сторон контактирует с устройством, тем больше звеньев требуют дополнительного доверия; кроме того, после получения устройства всё равно следует проверить упаковку и внешний вид на наличие отклонений, использовать официальное программное обеспечение для завершения проверки и строго соблюдать процедуру инициализации.
Во-вторых, необходимо заново осмыслить, заслуживают ли доверия «официальные сообщения».
Инцидент с Trezor уже показал, что даже если письмо действительно отправлено через официально используемую сервисную платформу, это не означает, что ссылки и требования к действиям в нём обязательно безопасны.
Особенно когда речь идёт о таких чувствительных операциях, как обновление кошелька, заморозка аккаунта, миграция активов и устранение уязвимостей, лучше не переходить по ссылкам в сообщении напрямую, а самостоятельно проверить через сохранённый вами адрес официального сайта или уже установленное официальное приложение.
Для некастодиальных кошельков, таких как imToken, пользователям также необходимо определять официальные каналы, использовать token.im как основу для загрузки и установки, а при обнаружении подозрительной информации в первую очередь проверять через официальные входы, такие как «Помощь и обратная связь» в приложении.
Независимо от того, называет ли себя другая сторона официальной службой поддержки, командой безопасности или предоставляет, казалось бы, весьма профессиональное объяснение уязвимости, вы никогда не должны раскрывать ей свою мнемоническую фразу или закрытый ключ.
Наконец, необходимо различать фактическое влияние различных инцидентов безопасности на вас самих.
Утечка адреса электронной почты в основном означает, что в будущем вы можете столкнуться с более целенаправленным фишингом; переход по подозрительной ссылке требует дальнейшего подтверждения того, были ли загружены или запущены вредоносные программы; если мнемоническая фраза уже была введена, это следует немедленно рассматривать как утрату контроля над кошельком.
Если были подписаны подозрительные транзакции или авторизации, также необходимо в сочетании с конкретными операциями в блокчейне определить, существует ли риск сохраняющейся авторизации контракта.
Что касается сбоев сторонних сервисов или аномалий инфраструктуры, то тем более необходимо обратиться к официально раскрытому масштабу влияния, чтобы определить, затрагивает ли это ваши активы, доступность сервисов или доходность.
Нельзя по умолчанию делать вывод о компрометации закрытого ключа только потому, что вы услышали об «инциденте безопасности кошелька», и тем более не следует опрометчиво переводить активы на незнакомые адреса из-за так называемых срочных уведомлений о безопасности.
В конце концов, во многих случаях злоумышленники на самом деле рассчитывают не на прорыв самой сильной технической линии защиты, а на то, чтобы заставить пользователей в панике добровольно сделать последний шаг (Дополнительное чтение: «ИИ «бросает вызов» криптографии? Web3 должен готовиться к дождливым дням, но ни в коем случае не должен спешить с миграцией»).
Заключительные мысли
В прошлом фраза, которую чаще всего подчёркивали в индустрии Crypto, была «Not your keys, not your coins».
Эта фраза по-прежнему важна, потому что контроль над закрытым ключом определяет, могут ли пользователи действительно самостоятельно контролировать свои активы.
Но по мере того, как кошельки, биржи и ончейн-финансовые продукты постепенно становятся зрелыми, нам также нужно осознать, что защита закрытого ключа — это лишь часть всей системы безопасности.
Подлинный аппаратный кошелёк всё ещё может быть физически подменён при доставке; уведомление, действительно отправленное из официальной системы электронной почты, также может быть использовано злоумышленниками; а набор сторонних инструментов, изначально предназначенных для усиления безопасности, может даже стать входом в основную систему фондов.
Эти случаи не означают, что мы должны потерять доверие ко всем кошелькам и внешним сервисам. Напротив, они напоминают всей отрасли, что безопасность должна быть расширена с рамок отдельного продукта на весь процесс цепочки поставок, управления разрешениями, коммуникации с пользователями и реагирования на чрезвычайные ситуации.
В конце концов, по-настоящему зрелая система безопасности Crypto должна не только гарантировать, что закрытые ключи не будут легко скомпрометированы, но и обеспечивать, насколько это возможно, чтобы даже в случае сбоя какого-либо внешнего звена весь механизм всё же мог твёрдо остановить риск на полпути и не позволить ему перейти последнюю красную черту, защищающую активы пользователей.
