Исследователь под ником tokay0 в понедельник, 13 июля, выложил в открытый доступ подробности уязвимости, которая позволяет захватить управление роботами-пылесосами Shark и получить root-доступ практически без усилий. Компания SharkNinja, владеющая брендами Shark и Ninja, к моменту публикации так и не выпустила патч — хотя знала о проблеме с марта.
Началось всё с обычного скребка отвёрткой. tokay0 разобрал купленный им пылесос Shark RV2320EDUS, нашёл на плате UART-пины и подключился к консоли U-Boot — она, как выяснилось, вообще не требует пароля. Добавив к параметрам загрузки строку init=/bin/sh, он получил root-шелл прямо на старте системы. А дальше — простая находка: сертификаты и ключи для связи с облаком лежат открытым текстом в папке /mnt/res/vapp/certs/. Никакого шифрования, никакой защиты — бери и используй.
Проблема оказалась глубже, чем просто утечка ключа с одного устройства. Сертификат, извлечённый из RV2320EDUS, содержал политику доступа, которая никогда не была привязана именно к этому пылесосу. Когда такой сертификат предъявляется брокеру SharkNinja в облаке AWS IoT, брокер принимает команды, адресованные любому устройству в своей зоне ответственности — не только тому, чьим сертификатом воспользовались. Ни подбора пароля, ни эксплуатации переполнения буфера, ни повышения привилегий — просто дыра в архитектуре разрешений.
Механика атаки строится вокруг так называемой device shadow — документа состояния устройства, который AWS хранит для каждого подключённого гаджета. Демон appd, работающий на пылесосах SharkNinja, читает из этой тени поле Exec_Command. Функция execute_command берёт значение этого поля и запускает его через popen — можно исполнить что угодно объёмом до 1000 байт. Схема атаки получилась в три шага: подписаться на топик $aws/things/ и собирать серийные номера устройств, наблюдая за трафиком брокера; опубликовать в shadow целевого устройства обновление с полем Exec_Command; если на устройстве реализован соответствующий обработчик — команда выполнится с правами root.
Чтобы доказать, что это не теория, tokay0 купил ещё один пылесос — AV1102ARUS — специально как мишень для атаки. Используя сертификат, снятый с RV2320EDUS, он атаковал AV1102ARUS и получил обратный шелл, а заодно вытащил живую трансляцию с камеры устройства прямо во время его работы.
Интересно, что не любой украденный сертификат превращается в универсальную отмычку. Сертификат самого AV1102ARUS оказался правильно ограничен по области действия — с его помощью нельзя было подписаться на топики других устройств через wildcard. Прошивка на этом пылесосе была на несколько лет новее, чем на RV2320EDUS. Похоже, в какой-то момент SharkNinja исправила процесс выдачи сертификатов для новых моделей, но забыла применить исправление задним числом ко всем старым устройствам в парке.
Заголовки о «миллионах уязвимых пылесосов» звучат эффектно, но подтверждённая цифра скромнее и куда конкретнее. За 24 часа мониторинга трафика только в одном регионе AWS tokay0 насчитал 1 517 605 уникальных серийных номеров устройств Shark. Из них 673 816 — это 44% — прислали в ответ поле Exec_Response, что исследователь расценивает как подтверждение работы уязвимого обработчика команд. Важная оговорка: это устройства, которые были замечены отвечающими, а не те, что реально протестировали или взломали. Сам tokay0 считает, что реальное число потенциально уязвимых пылесосов выше.
Забавно, что у самой AWS уже есть встроенный инструмент, который должен был поймать эту проблему автоматически. Сервис Device Defender, предназначенный для аудита парка IoT-устройств, содержит проверку с говорящим названием IOT_POLICY_OVERLY_PERMISSIVE_CHECK, помеченную как критическая. Она как раз ищет политики, дающие доступ на публикацию и подписку по маске $aws/things/ вместо корректного ограничения через переменную ${iot:Connection.Thing.ThingName}. В документации AWS прямо написано: скомпрометированный сертификат с такой политикой позволяет злоумышленнику «читать или изменять тени устройств, задания и их выполнение для всех ваших устройств».
Хронология переписки с SharkNinja растянулась на месяцы. Первый контакт — 1 марта. 11 марта tokay0 отправил компании полное техническое описание уязвимости. 12 марта пришло подтверждение получения. Дальше — тишина до 27 апреля, когда SharkNinja сообщила, что отчёт «находится на рассмотрении». 11 июня, не получив внятного ответа, исследователь обратился в MITRE как CNA последней инстанции за присвоением идентификатора CVE — ответа не последовало вплоть до публикации. 3 июля SharkNinja пообещала назвать точную дату исправления к 10 июля. Дедлайн прошёл, письмо так и не пришло. 13 июля tokay0 опубликовал материалы в открытом доступе.
По словам исследователя, компания занижала серьёзность проблемы и даже сомневалась, «уместен ли вообще CVE» в этом случае. На момент публикации у уязвимости нет ни идентификатора CVE, ни оценки по шкале CVSS, ни официального advisory — то есть системам управления уязвимостями попросту не на что ссылаться. При этом опубликованная политика раскрытия уязвимостей SharkNinja обещает «регулярно информировать о ходе устранения уязвимости», одновременно требуя от исследователей молчать, пока компания сама не подтвердит исправление или не даст письменное разрешение на публикацию. По состоянию на четверг компания так ничего и не опубликовала. The Hacker News обратилось к SharkNinja за комментарием о статусе патча и сроках раскрытия — ответа пока нет.
Самое неожиданное в этой истории — то, что исправление вообще не требует обновления прошивки на пылесосах. Проблема живёт в облачном аккаунте SharkNinja в AWS, а не в коде на устройствах. Согласно рекомендациям самой AWS по устранению подобных ошибок, достаточно заменить некорректную политику через вызов CreatePolicyVersion с флагом setAsDefault — и исправленная версия автоматически применится ко всем сертификатам, использующим эту политику. Никакой массовой рассылки обновлений на устройства не нужно. Более капитальное решение — корректный перевыпуск всех сертификатов — tokay0 предлагал ещё в марте, но SharkNinja его не реализовала.
Пока патча нет, единственный доступный владельцам способ защититься — отключить пылесос от Wi-Fi. Это лишает устройство управления через приложение, расписаний уборки и построения карт помещения, превращая его обратно в обычный бытовой прибор без «умных» функций. Сам tokay0 не стал публиковать рабочие эксплойт-скрипты, пока уязвимость активна и не закрыта, хотя обнаружил и ряд других мелких проблем, которые счёл слишком незначительными для отдельного разбора. Остальную линейку подключённых устройств SharkNinja — умные грили и беспроводные термометры для мяса — он не тестировал, но полагает, что они «вероятно, тоже уязвимы», учитывая общую экосистему компании и её обещания по раскрытию информации, которые она так и не выполнила.
С момента первого обращения к SharkNinja прошло четыре месяца, а проблема остаётся нерешённой. Обещание «регулярно информировать» о ходе устранения уязвимости так и осталось на бумаге.
Началось всё с обычного скребка отвёрткой. tokay0 разобрал купленный им пылесос Shark RV2320EDUS, нашёл на плате UART-пины и подключился к консоли U-Boot — она, как выяснилось, вообще не требует пароля. Добавив к параметрам загрузки строку init=/bin/sh, он получил root-шелл прямо на старте системы. А дальше — простая находка: сертификаты и ключи для связи с облаком лежат открытым текстом в папке /mnt/res/vapp/certs/. Никакого шифрования, никакой защиты — бери и используй.
Проблема оказалась глубже, чем просто утечка ключа с одного устройства. Сертификат, извлечённый из RV2320EDUS, содержал политику доступа, которая никогда не была привязана именно к этому пылесосу. Когда такой сертификат предъявляется брокеру SharkNinja в облаке AWS IoT, брокер принимает команды, адресованные любому устройству в своей зоне ответственности — не только тому, чьим сертификатом воспользовались. Ни подбора пароля, ни эксплуатации переполнения буфера, ни повышения привилегий — просто дыра в архитектуре разрешений.
Механика атаки строится вокруг так называемой device shadow — документа состояния устройства, который AWS хранит для каждого подключённого гаджета. Демон appd, работающий на пылесосах SharkNinja, читает из этой тени поле Exec_Command. Функция execute_command берёт значение этого поля и запускает его через popen — можно исполнить что угодно объёмом до 1000 байт. Схема атаки получилась в три шага: подписаться на топик $aws/things/ и собирать серийные номера устройств, наблюдая за трафиком брокера; опубликовать в shadow целевого устройства обновление с полем Exec_Command; если на устройстве реализован соответствующий обработчик — команда выполнится с правами root.
Чтобы доказать, что это не теория, tokay0 купил ещё один пылесос — AV1102ARUS — специально как мишень для атаки. Используя сертификат, снятый с RV2320EDUS, он атаковал AV1102ARUS и получил обратный шелл, а заодно вытащил живую трансляцию с камеры устройства прямо во время его работы.
Интересно, что не любой украденный сертификат превращается в универсальную отмычку. Сертификат самого AV1102ARUS оказался правильно ограничен по области действия — с его помощью нельзя было подписаться на топики других устройств через wildcard. Прошивка на этом пылесосе была на несколько лет новее, чем на RV2320EDUS. Похоже, в какой-то момент SharkNinja исправила процесс выдачи сертификатов для новых моделей, но забыла применить исправление задним числом ко всем старым устройствам в парке.
Заголовки о «миллионах уязвимых пылесосов» звучат эффектно, но подтверждённая цифра скромнее и куда конкретнее. За 24 часа мониторинга трафика только в одном регионе AWS tokay0 насчитал 1 517 605 уникальных серийных номеров устройств Shark. Из них 673 816 — это 44% — прислали в ответ поле Exec_Response, что исследователь расценивает как подтверждение работы уязвимого обработчика команд. Важная оговорка: это устройства, которые были замечены отвечающими, а не те, что реально протестировали или взломали. Сам tokay0 считает, что реальное число потенциально уязвимых пылесосов выше.
Забавно, что у самой AWS уже есть встроенный инструмент, который должен был поймать эту проблему автоматически. Сервис Device Defender, предназначенный для аудита парка IoT-устройств, содержит проверку с говорящим названием IOT_POLICY_OVERLY_PERMISSIVE_CHECK, помеченную как критическая. Она как раз ищет политики, дающие доступ на публикацию и подписку по маске $aws/things/ вместо корректного ограничения через переменную ${iot:Connection.Thing.ThingName}. В документации AWS прямо написано: скомпрометированный сертификат с такой политикой позволяет злоумышленнику «читать или изменять тени устройств, задания и их выполнение для всех ваших устройств».
Хронология переписки с SharkNinja растянулась на месяцы. Первый контакт — 1 марта. 11 марта tokay0 отправил компании полное техническое описание уязвимости. 12 марта пришло подтверждение получения. Дальше — тишина до 27 апреля, когда SharkNinja сообщила, что отчёт «находится на рассмотрении». 11 июня, не получив внятного ответа, исследователь обратился в MITRE как CNA последней инстанции за присвоением идентификатора CVE — ответа не последовало вплоть до публикации. 3 июля SharkNinja пообещала назвать точную дату исправления к 10 июля. Дедлайн прошёл, письмо так и не пришло. 13 июля tokay0 опубликовал материалы в открытом доступе.
По словам исследователя, компания занижала серьёзность проблемы и даже сомневалась, «уместен ли вообще CVE» в этом случае. На момент публикации у уязвимости нет ни идентификатора CVE, ни оценки по шкале CVSS, ни официального advisory — то есть системам управления уязвимостями попросту не на что ссылаться. При этом опубликованная политика раскрытия уязвимостей SharkNinja обещает «регулярно информировать о ходе устранения уязвимости», одновременно требуя от исследователей молчать, пока компания сама не подтвердит исправление или не даст письменное разрешение на публикацию. По состоянию на четверг компания так ничего и не опубликовала. The Hacker News обратилось к SharkNinja за комментарием о статусе патча и сроках раскрытия — ответа пока нет.
Самое неожиданное в этой истории — то, что исправление вообще не требует обновления прошивки на пылесосах. Проблема живёт в облачном аккаунте SharkNinja в AWS, а не в коде на устройствах. Согласно рекомендациям самой AWS по устранению подобных ошибок, достаточно заменить некорректную политику через вызов CreatePolicyVersion с флагом setAsDefault — и исправленная версия автоматически применится ко всем сертификатам, использующим эту политику. Никакой массовой рассылки обновлений на устройства не нужно. Более капитальное решение — корректный перевыпуск всех сертификатов — tokay0 предлагал ещё в марте, но SharkNinja его не реализовала.
Пока патча нет, единственный доступный владельцам способ защититься — отключить пылесос от Wi-Fi. Это лишает устройство управления через приложение, расписаний уборки и построения карт помещения, превращая его обратно в обычный бытовой прибор без «умных» функций. Сам tokay0 не стал публиковать рабочие эксплойт-скрипты, пока уязвимость активна и не закрыта, хотя обнаружил и ряд других мелких проблем, которые счёл слишком незначительными для отдельного разбора. Остальную линейку подключённых устройств SharkNinja — умные грили и беспроводные термометры для мяса — он не тестировал, но полагает, что они «вероятно, тоже уязвимы», учитывая общую экосистему компании и её обещания по раскрытию информации, которые она так и не выполнила.
С момента первого обращения к SharkNinja прошло четыре месяца, а проблема остаётся нерешённой. Обещание «регулярно информировать» о ходе устранения уязвимости так и осталось на бумаге.