Умные колонки, ТВ, камеры и другие устройства с ИИ-ассистентом сегодня — это уже не просто бытовая электроника повседневной жизни. С точки зрения безопасности это распределённая система, в которой граница доверия проходит через несколько уровней — от аппаратных механизмов до серверной логики, поэтому и подход к защите должен быть разносторонний.

Меня зовут Никита, и мне как инженеру по информационной безопасности Алисы и Умных Устройств Яндекса приходится быть по обе стороны баррикад: думать, как сделать устройства безопасными и знать, как их «ломать». Всегда нужно рассматривать потенциальные векторы атак и способы защиты от них. В этом во многом помогает наша программа «Охота за ошибками». А сегодня я расскажу о том, как смотреть на смарт-девайсы с точки зрения информационной безопасности, какие есть реальные риски и как их минимизировать.

Как и зачем мы защищаем устройства

В базовой модели защиты девайсов есть несколько уровней: само устройство (аппаратный уровень) → загрузчики (низкоуровневые ОС) → пользовательская ОС. Рассмотрим каждый из них подробней.

Аппаратный уровень

Когда мы анализируем защищённость устройства, первым делом смотрим на процесс загрузки. Механизм Secure Boot защищает процесс инициализации системы, проверяя подлинность и целостность прошивки на каждом этапе. Он предотвращает выполнение вредоносной или модифицированной прошивки, обеспечивая выполнение только доверенного кода. Это фундаментальный механизм безопасности, без которого говорить о последующих слоях защиты просто бессмысленно.

Ниже — примерная схема доверенной загрузки устройства, при которой каждый этап загрузки проверяет следующий, начиная с неизменяемого аппаратного кода (BootROM).

Как это работает:

1. BootROM (аппаратный, защищённый от модификации) проверяет подпись первого загрузчика (Bootloader).

2. Bootloader проверяет UBoot.

3. UBoot проверяет ядро ОС и драйверы.

4. Ядро проверяет пользовательские приложения.

Вознаграждение обхода доверенной загрузки девайса на «Охоте за ошибками» доходит до 750 000 рублей. Одного из исследователей мы наградили в феврале.  

Реальный пример закрытия аппаратной уязвимости

Один из ярких примеров критических уязвимостей, которые требовалось закрывать, — уязвимость, обнаруженная в чипах Amlogic. Это главный процессор в наших устройствах. 

Проблема была в BootROM — самом первом коде, который запускается при включении устройства. Он хранится прямо в процессоре и не поддаётся программным обновлениям. В этом коде есть режим загрузки по USB, который используется на заводе при производстве. Оказалось, если отправить в этот режим специально испорченную команду, загрузчик падал. Тем самым он позволял обойти механизм Secure Boot и загружать произвольный, неподписанный код, который мог использоваться в различных неблагоприятных сценариях для пользователей.

Для исправления этой уязвимости требовалось добавить USB-пароль для каждого устройства в защищённую область памяти — eFuse. 

Конечно, это понятно и несложно сделать при производстве устройств или при непосредственном контакте с устройством, а вот как поступить с уже выпущенными девайсами у пользователей? Готового механизма «дошить» пароль не было. Мы пробовали установить пароль из UBoot, из основной операционной системы прямой записью в регистры и через своё Trusted App, но везде были свои нюансы и проблемы.

Подробно о своём решении мы рассказывали на прошлогодней конференции «Я Железо». Если кратко, то исправить код в процессоре было невозможно. Поэтому мы пошли другим путём: через служебный микроконтроллер сделали уникальный USB-пароль на каждое устройство. Этот пароль встаёт перед уязвимым кодом и просто не пускает к нему.

Вот как изменилась опасная цепочка после реализации нашего решения:

А если ужать схемы «до» и «после» до одной строки, то получится так:

Такие уязвимости особенно ценятся в программе Bug Bounty, поскольку они демонстрируют фундаментальные проблемы в архитектуре безопасности и требуют комплексного подхода к исправлению, затрагивающего как аппаратную, так и программную части системы.

Низкоуровневые операционные системы

Следующий уровень — аппаратная изоляция. В устройствах на базе ARM (Advanced RISC Machine) используется TrustZone (доверенный контур). Он разделяет обычную среду выполнения и защищённую область. Таким образом, у нас получается два разделённых контура исполнения операций. С инженерной точки зрения это способ локализовать риски: даже если часть системы оказывается уязвимой, критичные операции и данные остаются в отдельном защищённом контуре.

Пример взаимодействия в TrustZone:

Если исследователь найдёт способ компрометации криптографических ключей из защищённого элемента, то по правилам программы Bug Bounty он получит вознаграждение до 750 000 рублей.

Пользовательская операционная система

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

Реальный пример взаимодействия нескольких технологий: TrustZone и передача данных по зашифрованным каналам.

Обнаружение подобного рода проблем в сетевом взаимодействии уже попадает в общую категорию «Инфраструктура и сервисы Яндекса».

Какие уязвимости считаются принципиально значимыми

Zero-click RCE

В профессиональной оценке на первом месте стоят сценарии, которые потенциально дают контроль над устройством или подрывают механизмы доверия. Например, удалённое выполнение кода без участия пользователя (Zero-click RCE).

Вот в чём состоят отличия обычных атак от Zero-click RCE:

Подобные уязвимости меняют модель угроз для всей системы и требуют приоритетного внимания. Если говорить о конкретных примерах, то это может быть отправка специально подготовленных данных в приложения, запущенные на устройстве. При этом взаимодействие или участие пользователя в таких сценариях атаки не требуется. Такие уязвимости расцениваются максимально — до 1 500 000 рублей. За всю историю наших устройств исследователи ни разу не находили в них подобные уязвимости.

Ещё раз простыми словами: когда атакующий получает возможность выполнить произвольный код на вашем устройстве без вашего ведома, он, по сути, становится невидимым владельцем этого устройства. Он может читать данные с датчиков, подменять команды, использовать устройство как точку входа в вашу локальную сеть или просто сделать недоступным его в любой момент. Именно поэтому такой класс уязвимостей разрушает не одну функцию — он разрушает всю модель доверия к продукту целиком.

Чувствительные данные

Особое внимание уделяется обработке и хранению чувствительных данных. Любые данные, которые могут идентифицировать пользователя или дать доступ к его аккаунту, никогда не должны храниться на устройстве в открытом виде — только в зашифрованном. Это означает, что даже если злоумышленник получит физический доступ к накопителю устройства или базе данных, он увидит только зашифрованный набор данных — бесполезный без ключа расшифровки. 

Логи — это одна из самых частых точек утечки чувствительных данных. Разработчик пишет отладочный вывод, случайно включает в него содержимое запроса, а в запросе — токен авторизации или другие чувствительные данные. Сервис маскировки решает эту проблему автоматически. Он работает как «фильтр» на выходе любого лог-вызова: перед тем как данные попадают в файл или систему сбора логов, она проходит через набор паттернов (регулярных выражений). Если паттерн сработал — чувствительная часть строки заменяется на маску.

Почему важны и менее «громкие» сценарии

На практике критические уязвимости часто возникают не из одной ошибки, а из цепочки. Поэтому в фокусе остаются и сценарии, связанные с повышением привилегий, доступом к чувствительным данным или особенностями механизма обновления программного обеспечения. Анализируются и сетевые протоколы, и интерфейсы отладки — не как повседневный вектор угроз, а как способ проверить защищённость устройства в расширенных условиях.

При оценке всегда учитывается контекст эксплуатации: реалистичность сценария, требуемые условия и потенциальные последствия для пользователя. Это позволяет отделять теоретические возможности от практических рисков.

Охота за ошибками: роль внешних исследователей

Безопасность наших устройств — это живой процесс. Мы регулярно пересматриваем риски, обновляем защитные механизмы и проверяем, не появилось ли что-то новое, на что стоит обратить внимание. Часть этой работы делает наша внутренняя команда. Но когда долго работаешь с продуктом, глаз замыливается. Поэтому мы регулярно привлекаем независимых исследователей безопасности или внешние пентесты со стороны. Их задача — смотреть на устройство глазами того, кто хочет его взломать. Такой «взгляд со стороны» помогает нам постоянно совершенствовать безопасность.

Для умных устройств с Алисой этому посвящена отдельная категория в программе «Охота за ошибками». Я воспринимаю её как часть общей инженерной экосистемы безопасности вокруг устройств. Категория развивается вместе с технологиями: по мере усложнения архитектуры уточняются вектора и категории угроз и критерии оценки.

В этом году правила по категории были дополнены и структурированы более прозрачно — в первую очередь, с точки зрения того, какие типы уязвимостей считаются технически значимыми и как оценивается их влияние. Параллельно были повышены выплаты за наиболее критичные находки. С инженерной позиции это логичный шаг: чем выше потенциальный эффект уязвимости для экосистемы устройства, тем выше ценность её раннего обнаружения.

Безопасность — это не галочка, которую ставят один раз перед выпуском устройства. Угрозы меняются, появляются новые способы атак, исследователи находят уязвимости в похожих продуктах, меняется само окружение, в котором работает устройство. То, что было надёжным год назад, сегодня может требовать пересмотра. Именно поэтому мы не останавливаемся на моменте выпуска. 

Но даже сильная внутренняя команда безопасности не должна работать в изоляции. В моей профессиональной практике «Охота за ошибками» — это способ добавить к внутреннему взгляду внешний, независимый. Багхантеры смотрят на систему иначе, проверяют нестандартные гипотезы и помогают выявлять слабые места на ранних стадиях.

Но безопасность зависит не только от производителя, поэтому напомню простые правила: используйте сложные, уникальные пароли для устройства и связанных с ним аккаунтов, а также двухфакторную аутентификацию. А в остальном можете быть уверены: когда вы подключаете устройство к своей сети и встраиваете его в свой привычный день, за его надёжностью стоит не красивое описание на коробке, а реальная и постоянная работа. Мы не ждём, пока что-то пойдёт не так — мы стараемся убедиться, что не пойдёт.