Как мы исследовали безопасность робота для детей…

В современном мире нас окружает множество умных устройств, которые упрощают быт: умные колонки, роботы-пылесосы, автоматические кормушки для животных, целые умные дома. Производители детских игрушек стараются не отставать от общих тенденций и выпускают все больше моделей, которые также можно назвать «умными», например обучающих роботов, способных подключаться к интернету и совершать видеозвонки. Коллеги любезно предоставили нам для исследования такого робота, поскольку желали убедиться, что игрушка, с которой играет их ребенок, достаточно хорошо защищена от киберугроз. В ходе анализа мы обнаружили несколько уязвимостей, позволяющих злоумышленникам получать доступ к конфиденциальным данным и общаться с детьми без ведома их родителей.

Предмет исследования: обучающий робот

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

Возможные векторы атаки

Родительское приложение

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

Игрушка

Робот подключается к домашней сети Wi-Fi и взаимодействует с приложением через интернет. При первом включении и подключении к интернету робот требует обновить программное обеспечение до последней версии — без этого он не работает. Однако мы решили сразу не обновлять игрушку, чтобы посмотреть, что можно извлечь из более старой версии прошивки.

Обзор внутреннего устройства робота

Анализ схемотехники и компонентной базы

Хочется выразить отдельную благодарность производителю за помощь в проведении схемотехнического анализа электронной начинки робота: все разъемы, порты и тестовые площадки на платах были подписаны — такая степень детализации при маркировке элементов встречается редко. Среди всего многообразия разъемов нас в первую очередь заинтересовал разъем USB, подписанный как Android (см. фото платы управления периферией), а также ряд интерфейсов, обычно использующихся для отладки прошивки устройств.

Основная плата. Вид сверху

Плата управления периферией

Основная плата. Вид снизу

Первое включение робота и анализ сетевого трафика

При первом включении игрушка просит выбрать сеть Wi-Fi, привязать робота к мобильному устройству родителя и ввести минимальную информацию о ребенке, который будет пользоваться игрушкой (имя, возраст). При анализе трафика мы обнаружили, что эта информация передается по протоколу HTTP в открытом виде и, таким образом, ее можно перехватить с помощью программного обеспечения для анализа сетевого трафика.

Также некоторые сетевые запросы вызвали у нас особый интерес:

Запрос login_user для получения access_token с правильным паролем

Запрос на скриншоте выше возвращает токен доступа к API на основе следующих аутентификационных данных: имя пользователя, пароль и ключ.

Примечательно, что в ответе на запрос, содержащий заведомо неправильный пароль из произвольного набора символов, мы, тем не менее, получили действительный токен доступа. Это была первая обнаруженная нами проблема, связанная с безопасностью.

Запрос login_user для получения access_token с неправильным паролем

Следующий запрос возвращает параметры конфигурации для конкретной игрушки по ее уникальному идентификатору, состоящему из девяти символов. В случае нашего робота идентификатор всегда начинается с «M3».

Запрос GetAppConfiguration для получения конфигурационного файла робота

Идентификатор робота, используемый в запросах к API, имеет вид, схожий с напечатанным на корпусе робота буквенно-цифровым идентификатором P/N:

Robot IDs indicated on the case

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

Помимо данных о пользователе, в ответ на запрос конфигурации сервер присылает достаточно большое количество настроек, в том числе ключи доступа к API внешних сервисов (например, QuickBlocks, Azure, Linode), которые робот использует при работе. Полученные настройки робот сохраняет в файл во внутренней памяти. Мы еще вернемся к более детальному рассмотрению его содержимого.

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

Запрос checkAuthentication для проверки привязки робота к родительскому приложению

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

После того как программное обеспечение робота обновилось, указанные выше запросы, которые ранее передавались по незащищенному протоколу HTTP, стали отправляться по защищенному шифрованием протоколу HTTPS. Поэтому для продолжения анализа сетевого трафика возникла необходимость реализовать MitM-атаку.

Анализ файловой системы

Анализ содержимого eMMC Flash

Существуют разные способы проведения MitM-атак на сетевой трафик устройства. Мы решили воспользоваться Android Debug Bridge (ADB) — сервисом, предназначенным для отладки устройств на базе ОС Android.

ADB позволяет:

• просматривать отладочные сообщения ОС Android и приложений, запущенных на устройстве;
• копировать файлы с устройства и на него;
• устанавливать и удалять приложения;
• очищать и перезаписывать раздел data в памяти устройства;
• выполнять различные скрипты;
• управлять некоторыми параметрами сети.

Мы планировали воспользоваться ADB, чтобы модифицировать файловую систему робота и установить SSL-сертификаты, которые позволят нам прослушивать трафик. Чтобы выяснить, как можно включить ADB на роботе, мы решили считать содержимое микросхемы памяти устройства.

Получив и проанализировав образ файловой системы, мы выяснили следующее:

• При запуске системы в конфигурационном файле ОС Android прописан запуск adbd (демона ADB, отвечающего за выполнение команд на устройстве) с правами суперпользователя.
• На этапе загрузки робот на очень короткое время определяется как USB-устройство с доступом к ADB.
• После запуска ОС Android применяется конфигурация, в которой на USB активирован только сервис MTP. Служба ADB отключается.

Активация ADB

Мы проанализировали конфигурационные файлы, содержащиеся в считанной с микросхемы памяти прошивке, и в одном из них обнаружили настройку «ENABLE_ADB=N». После изменения указанной настройки на «ENABLE_ADB=Y» мы получили возможность активировать ADB и работать с ним до момента подключения робота к серверу, откуда он загружает новую конфигурацию и переписывает значение этой настройки на значение по умолчанию («ENABLE_ADB=N»).

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

Анализ API видеостриминга

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

Конфигурация облачного сервиса Agora

Значительная часть серверного API, с которым робот взаимодействует посредством выполнения HTTP-запросов, реализована на базе фреймворка Django REST Framework. Стоит отметить, что на момент исследования по недосмотру разработчиков на production-серверах вендора этот фреймворк был сконфигурирован на работу в режиме отладки, что позволило увидеть детальные описания всех конечных точек API и сообщения об ошибках с большим количеством отладочной информации. В качестве примера приводим страницу с описанием запроса на получение токена Agora, необходимого для установки соединения с роботом:

Ответ REST API на запрос токена Agora с описанием ошибки

Звонок на произвольного робота

Алгоритм установления соединения между родительским приложением и роботом выглядит следующим образом:

1. Родительское приложение делает POST-запрос по адресу /api/v3/agora/token:

   

   Запрос на получение токена для сессии Agora API

   В ответ сервер генерирует Agora Token, с помощью которого приложение может подключиться к звонку через сервис Agora. При этом параметр user_id может быть выбран случайным образом, а в параметре channel_name передается ID робота. Опытным путем мы установили, что при обработке запроса на генерацию токена Agora сервер производителя не проверяет, соответствует ли этот ID роботу, привязанному к текущему авторизованному пользователю. Более того, сервер в принципе не проверяет, является ли запрос авторизованным.

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

2. Для подключения к звонку в сервис Agora нужно передать следующие данные:
   • Токен, полученный с сервера производителя.
   • Название «комнаты» (channel_name), то есть идентификатор робота.
   • Agora APP ID — идентификатор приложения, использующего API Agora, одинаковый для всех роботов серии и приложения родителя.
3. Подключившись к Agora, неавторизованный пользователь может отправить на сервер производителя запрос, представленный на скриншоте:

   

   Запрос для отправки вызова по видеосвязи на робота

   Тогда робот с указанным в запросе ID (параметр username) отобразит входящий вызов:

   

   Входящий вызов на робота

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

Процесс обновления

В процессе обновления робот загружает из облака архив под названием APPS.z. В архив вложен сценарий командной строки, который отвечает за распаковку и установку обновления.

RCE в процессе обновления

Сценарий распаковки и установки обновления содержится в файле с расширением *.l и имеет следующий вид:

Сценарий распаковки файла обновлений

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

Parent hijacking

Злоумышленник может удаленно привязать произвольное устройство к своему аккаунту. Аккаунт родителя при этом потеряет доступ к роботу. Чтобы восстановить связь легитимным путем, придется обратиться в техподдержку производителя.

Атаки с перепривязкой робота происходят следующим образом:

1. При помощи вызова метода checkAuthentication злоумышленник узнает почту и номер телефона владельца по идентификатору устройства, который можно подобрать перебором.

   

   Запрос checkAuthentication для получения почты и номера телефона владельца

2. Злоумышленник пробует авторизоваться по полученной почте или номеру телефона. В процедуре авторизации используется слабый одноразовый пароль (one-time password, OTP), состоящий из 6 цифр, с неограниченным числом попыток ввода.

   

   Процесс авторизации с OTP на мобильном устройстве

3. После перебора OTP-кода и успешной авторизации злоумышленник может отвязать робота от родительского устройства, как показано на рисунке:

   

   Отвязка робота от родительского приложения

4. После этого злоумышленник может удаленно привязать робота к своему аккаунту. Для этого нужно указать OTP, сгенерированный игрушкой, как показано на рисунке:

   

   Пароль для синхронизации, сгенерированный роботом

   Злоумышленник может получить этот код при помощи вызова метода checkAuthentication, зная только идентификатор устройства: поле password в ответе сервера содержит OTP.

   

   Запрос checkAuthentication для получения OTP кода

Коммуникация с вендором

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

Timeline

• 27 марта 2023 г. — мы сообщили производителю о проблемах безопасности.
• 13 апреля 2023 г. — производитель принял отчет для проверки.
• 24 июля 2023 г. — производитель признал наличие проблем с безопасностью.
• 18 августа 2023 г. — производитель исправил проблемы с безопасностью.

Заключение

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

Производители таких игрушек, со своей стороны, должны тщательно тестировать защищенность своих продуктов и инфраструктуры и ответственно информировать покупателей о возможных угрозах.