Как превратить умную колонку Google в «жучок» и получить за это $100 тысяч |
||
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
2023-06-07 18:00 Недавно компания Google выплатила мне награду в $107500 за ответственное раскрытие проблем безопасности в умной колонке Google Home. Эти уязвимости позволяли нападающему, находящемуся в пределах беспроводного доступа, создать на устройстве бэкдор-аккаунт и удалённо отправлять команды через Интернет, получать доступ к микрофону и выполнять произвольные HTTP-запросы в локальной сети жертвы (что потенциально позволит нападающему узнать пароль Wi-Fi или получить прямой доступ к другим устройствам жертвы). Все эти проблемы были устранены. Расследование Я экспериментировал с Google Home и обратил внимание, насколько просто добавлять новых пользователей через приложение Google Home. Также я заметил, что привязка аккаунта к устройству даёт удивительно высокую степень контроля над ним.
В случае Google Home получить прошивку очень сложно, потому что на печатной плате устройства нет контактов для отладки, и единственный способ считывания флэш-памяти заключается во выпаивании чипа NAND. Кроме того, Google не публикует образы прошивок для скачивания. Впрочем, на DEFCON продемонстрировали, что это возможно (см. ниже). При реверс-инжиниринге мне нравится по возможности начинать с атаки MITM, потому что обычно это самый простой способ разобраться, как работает устройство. Типичные IoT-устройства для общения со своими приложениями используют протоколы наподобие HTTP или Bluetooth. HTTP легко прослушать при помощи инструментов вроде mitmproxy. Я люблю mitmproxy, потому что это свободное ПО, оно имеет UI на основе терминала и предоставляет удобный Python API. Так как у Google Home нет собственного дисплея или UI, большинство параметров контролируется через приложение Google Home. Немного погуглив, я выяснил, что люди уже начали документировать локальный HTTP API для взаимодействия с Google Home. Устройства Google Cast (в том числе Google Home и Chromecast) объявляют о себе в локальной сети при помощи mDNS, поэтому для их обнаружения можно использовать dns-sd :
Можно использовать nmap , чтобы найти порт, на котором работает локальный HTTP API:
Мы видим HTTP-серверы на портах 8008 и 8443. Согласно неофициальной документации, ссылку на которую я привёл выше, от поддержки 8008 отказались и теперь работает только 8443. Другие порты используются для различных функций Chromecast, а неофициальная документация частично доступна в Интернете. Давайте попробуем отправить запрос:
(Мы используем --insecure , потому что устройство отправляет самостоятельно подписанный сертификат, которому доверяет приложение Google Home, но мой компьютер не доверяет)Отлично, мы получили параметры устройства. Однако в документации говорится, что большинству конечных точек API требуется cast-local-authorization-token . Давайте попробуем что-то более интересное, например, перезагрузить устройство:
Оно отклоняет запрос, потому что мы не авторизованы. Как же получить токен? В документации написано, что можно или извлечь его из папки приватных данных приложения Google Home (если на телефоне есть root), или использовать скрипт, который получает на входе имя пользователя и пароль Google, вызывает API, после чего приложение Google Home использует его для получения токена, а затем возвращает токен. Однако для обоих этих способов нужно, чтобы у нас имелся уже связанный с устройством аккаунт, поэтому я решил разобраться, как вообще выполняется привязка. Предположительно, этот токен используется, чтобы нападающий (или зловредное приложение) в локальной сети не получил доступа к устройству. То есть, для привязки аккаунта и получения токена нужно что-то большее, чем простой доступ к локальной сети? Я поискал в документации, но не нашёл упоминаний привязки аккаунтов, поэтому продолжил свое исследование. Подготавливаем прокси Для перехвата незашифрованного HTTP-трафика при помощи mitmproxy в Android достаточно запустить прокси-сервер, а затем сконфигурировать телефон (или только нужное приложение) так, чтобы весь трафик перенаправлялся на прокси. Однако в неофициальной документации по локальному API говорится, что Google недавно начала использовать HTTPS. Кроме того, я хотел перехватывать трафик не только между приложением и устройством Google Home, но и между приложением и серверами Google (который точно передавался по HTTPS). Я подумал, что поскольку при процессе привязки задействовались аккаунты Google, часть процесса может происходит на сервере Google, а не в устройстве. Следим за процессом привязки Итак, давайте понаблюдаем, что происходит, когда новый пользователь привязывает свой аккаунт к устройству. Мой аккаунт Google уже был привязан, поэтому я создал новый аккаунт для «нападающего». Когда я открыл приложение Google Home и вошёл под новым аккаунтом (убедившись, что я подключён к той же сети Wi-Fi, что и устройство), устройство появилось в разделе «Other devices». Когда я коснулся его, то увидел такой экран: Я нажал кнопку, и устройство предложило для продолжения установить приложение Google Search. Предполагаю, что через это приложение выполняется настройка сопоставления голоса (Voice Match), но если я нападающий, то мне не нужно добавлять свой голос в устройство — я хочу только привязать свой аккаунт. Так можно ли привязать аккаунт без Voice Match? Я подумал, что это возможно, ведь первоначальная настройка устройства целиком выполнялась в приложении Home, и от меня не требовали включить Voice Match на основном аккаунте. Я уже был готов выполнить сброс к заводским настройкам и понаблюдать за первоначальной привязкой аккаунта, но потом кое-что понял.Большая часть внутренней архитектуры Google Home схожа с устройствами Chromecast. Согласно докладу с DEFCON, в устройствах Google Home используется та же операционная система, что и в Chromecast (разновидность Linux). Локальный API тоже выглядит знакомым. На самом деле, имя пакета приложения Home заканчивается на chromecast.app , и раньше оно просто называлось Chromecast. В то время его единственная задача заключалась в настройке устройств Chromecast. Теперь оно отвечает за настройку и управление не только Chromecast, а всеми умными домашними устройствами Google.Поэтому почему бы нам не понаблюдать, как работает процесс привязки Chromecast, а затем не воспроизвести его с Google Home? Это будет проще, потому что Chromecast не поддерживают Voice Match (как и Google Assistant). К счастью, у меня под рукой было несколько Chromecast. Я подключил один из них и нашёл его в приложении Home: Теперь мне оставалось только коснуться баннера «Enable voice control and more» и подтвердить, после чего мой аккаунт был привязан! Отлично, теперь посмотрим, что произошло на стороне сети: Мы видим POST-запрос к конечной точке /deviceuserlinksbatch в clients3.google.com :Это двоичная полезная нагрузка, но мы сразу же можем увидеть, что она содержит информацию об устройстве (например, имя устройства «Office TV»). Мы видим, что content-type является application/protobuf . Protocol Buffers — это формат сериализации двоичных данных Google. Как и в JSON, данные хранятся в парах «ключ-значение». Клиент и сервер, обменивающиеся данными protobuf, имеют копию файла .proto , определяющего имена полей и типы данных (например, uint32 , bool , string , etc). В процессе кодирования данные обрезаются и остаются лишь номера полей и wire type. К счастью, wire type практически напрямую транслируются обратно в исходные типы данных (обычно есть только незначительное количество вариантов того, какой исходный тип данных может основываться на wire type). Google предоставляет инструмент командной строки protoc , позволяющий кодировать и декодировать данные protobuf. Опция --decode_raw приказывает protoc выполнять декодирование без файла .proto , угадывая типы данных. Такого сырого декодирования обычно достаточно для того, чтобы понять структуру данных. Но если она кажется неправильной, то можно создать собственный файл .proto со своими догадками о типах данных, попытаться декодировать их, и, если результат будет нелогичным, продолжать изменять файл .proto до получения нужного результата.В нашем случае применение --decode_raw приводит к созданию идеально читаемого результата:
Похоже, что полезная нагрузка запроса привязки состоит из трёх элементов: имени устройства, сертификата и «Cloud ID». Я сразу же узнал эти значения из предыдущих запросов локального API /setup/eureka_info . То есть, похоже, что процесс привязки заключается в следующем:
Я хотел использовать mitmproxy для повторной отправки модифицированной версии запроса, заменив информацию Chromecast на информацию Google Home. Потом мне захотелось создать файл .proto , чтобы можно было использовать protoc --encode для создания запросов привязок с нуля, но на этом этапе я просто хотел быстро протестировать, сработает ли это. Выяснилось, что можно заменять любые строки в двоичной полезной нагрузке, не вызывая никаких проблем, при условии, что они имеют одинаковую длину. cloud ID и cert имели одинаковую длину, однако длина имени («Office speaker») отличалась, поэтому я переименовал устройство в приложении Home, чтобы длина совпадала. Затем я отправил модифицированный запрос, и всё сработало. Параметры Google Home были разблокированы в приложении Home. В mitmproxy я видел, что вместе с запросами локального API передавался локальный токен аутентификации устройства.Воссоздаём реализацию на Python Далее я решил воссоздать реализацию процесса привязки в скрипте на Python, чтобы мне больше не приходилось возиться с приложением Home.
Воссоздать сам запрос привязки было немного сложнее. Сначала я изучил упомянутый в неофициальной документации API скрипт, вызывающий cloud API Google. В нём используется библиотека gpsoauth, которая реализует на Python поток логина Google в Android. По сути, она превращает имя пользователя и пароль Google в токены OAuth, которые можно использовать для вызова незадокументированных Google API. Она используется некоторыми неофициальными Python-клиентами сервисов Google, например, gkeepapi для Google Keep. Я воспользовался mitmproxy и gpsoauth, чтобы разобраться в запросе привязки и его воссоздании. Он выглядит так:
Для создания полезной нагрузки protobuf я написал простой файл .proto для запроса привязки, чтобы можно было использовать protoc --encode . Я дал известным мне полям понятные имена (например, device_name ), а неизвестным полям назначил обобщённые имена:
В качестве первого теста я использовал этот .proto для кодирования сообщения с теми же значениями, которые я перехватил из приложения Home, и убедился, что двоичный результат получился таким же.В итоге у меня получился скрипт на Python, получающий на входе учётные данные Google и IP-адрес, и использующий их для привязки аккаунта к устройству Google Home по указанному IP-адресу. Дальнейшее исследование Написав скрипт на Python, я должен был начать думать с точки зрения нападающего. Какой уровень контроля над устройством даёт нам привязанный аккаунт и каковы потенциальные сценарии атак? Сначала я нацелился на функцию routines, позволяющую удалённо выполнять в устройстве голосовые команды. Проведя изучение предыдущих атак на устройства Google Home, я нашёл атаку «Light Commands», которая дала мне понимание того, какие команды может использовать нападающий:
Я хотел пойти глубже и придумать атаку, которая бы работала на всех устройствах Google Home, вне зависимости от наличия у пользователя других умных устройств. Я попытался придумать способ применения голосовой команды для активации микрофона и слива данных. Возможно, мне удастся использовать голосовые команды для загрузки в устройство приложения, включающего микрофон? После изучения документации «conversational actions» стало понятно, что можно создать приложение для Google Home, а затем вызывать его на привязанном устройстве при помощи команды «talk to my test app». Однако возможности таких «приложений» довольно ограничены. Они не имеют доступа к сырому звуку с микрофона, а получают только транскрипцию сказанного пользователем. Они даже не выполняются на самом устройстве: серверы Google общаются с приложением через веб-хуки от лица устройства. Более любопытными показались мне «действия умного дома», но их я исследовал уже позже. Внезапно меня озарило: эти устройства поддерживают команду "call [номер телефона]". По сути, можно использовать эту команду, чтобы приказать устройству отправлять данные со своего микрофона на какой-нибудь произвольный телефонный номер. Создаём зловредные routine Интерфейс для создания routine в приложении Google Home выглядит так: При помощи mitmproxy я узнал, что на самом деле это просто WebView, встраивающий веб-сайтhttps://assistant.google.com/settings/routines , который загружает обычный веб-браузер (если вы залогинены в аккаунт Google). Это немного упростило реверс-инжиниринг.Я создал routine для выполнения команды «call [мой номер телефона]» по средам в 20:26 (тогда была среда, 20:25). Для routine, выполняемых автоматически в определённое время, необходимо указать «устройство для звука» (устройство, в котором будет выполняться routine). Его можно выбрать из списка устройств, привязанных к вашему аккаунту: Минутой позже routine выполнилась в Google Home и позвонила на мой телефон. Я принял вызов и прослушал, как говорю в микрофон Google Home. Отлично! (Позже, изучая сетевые запросы, я обнаружил, что можно указать не только час и минуту активации routine, но и точную секунду, поэтому мне достаточно было подождать до активации routine не примерно минуту, а всего несколько секунд.) Сценарий атаки У меня было ощущение, что Google не намеревалась так легко предоставлять удалённый доступ к сигналу микрофона в Google Home. Я быстренько придумал сценарий атаки: Нападающий хочет пошпионить за жертвой. Но для этого всё равно требуется социальный инжиниринг и взаимодействие с пользователем, что неидеально с точки зрения нападающего. Можно ли сделать атаку более удобной? С более абстрактной точки зрения суммарная информация об устройстве (name, cert и cloud ID) используется как «пароль», дающий удалённый контроль над устройством. Устройство раскрывает этот пароль через локальную сеть при помощи локального API. Есть ли у нападающего другие способы доступа к локальному API? В 2019 году известность получил CastHack: обнаружилось, что тысячи устройств Google Cast (в том числе Google Home) были видны из публичного Интернета. Поначалу считалось, что проблема вызвана тем, что устройства использовали UPnP для автоматического открытия портов маршрутизатора, связанных с воспроизведением (8008, 8009 и 8443). Однако оказалось, что устройства Cast используют UPnP только для локального обнаружения, а не для перенаправления портов. Поэтому причиной, вероятно, была широко распространённая ошибочная сетевая конфигурация (возможно, как-то связанная с UPnP). Обнаружившие CastHack люди не осознавали истинного уровня доступа, предоставляемого локальным API (в сочетании с cloud API): Что с помощью этого могут сделать хакеры? (Всё это конечные точки локального API, уже задокументированные сообществом. Это было ещё до того, как локальный API начал требовать токена аутентификации) Чего хакеры НЕ могут сделать с этим? Существуют сервисы наподобие Shodan, позволяющие сканировать Интернет в поисках открытых портов и уязвимых устройств. При помощи простых поисковых запросов мне удалось найти сотни устройств Cast с открытым портом 8443 (локальный API). Я не исследовал этот вопрос долго, потому что в конечном итоге плохую конфигурацию маршрутизатора Google исправить не в состоянии. Однако когда я читал про CastHack, то обнаружил датированные ещё 2014 годом (!) статьи о RickMote — разработанном исследователем безопасности Bishop Fox Дэном Петро proof of concept, захватывающем ближайшие Chromecast и воспроизводящем «Never Gonna Give You Up» с YouTube. Петро обнаружил, что когда Chromecast теряет соединение с Интернетом, то переходит в «режим настройки» и создаёт собственную открытую сеть Wi-Fi. Изначально она предназначается для того, чтобы позволить владельцу устройства подключиться к этой сети из приложения Google Home и сбросить параметры Wi-Fi (например, в случае смены пароля). RickMote пользуется этим поведением. Оказалось, что обычно очень просто заставить близкие устройства отключиться от их сети Wi-Fi: достаточно отправить на целевое устройство набор пакетов «deauth». WPA2 обеспечивает сильное шифрование фреймов данных (если выбран хороший пароль). Однако «управляющие» фреймы, например, фреймы деаутентификации (приказывающие клиентам отсоединиться) не зашифрованы. 802.11w и WPA3 поддерживают зашифрованные управляющие фреймы, однако в Google Home Mini поддержки ни того, ни другого нет (см. примечание в конце статьи). (Но даже если бы она была, для их работы их должен был бы поддерживать и маршрутизатор, а из-за потенциальных проблем с совместимостью в домашних маршрутизаторах потребительского уровня это сейчас редкость. Кроме того, даже если бы их поддерживали и устройство, и маршрутизатор, у нападающего всё равно есть другие способы нарушить работу вашего Wi-Fi. Всегда доступен вариант простого глушения канала, хотя для этого и требуется специализированное нелегальное оборудование. В конечном итоге, Wi-Fi — это плохой выбор для устройств, которые постоянно должны быть подключены к Интернету.) Я захотел проверить, по-прежнему ли используется это поведение «режима настройки» в Google Home. Установив aircrack-ng , я применил следующую команду для атаки deauth:
Устройство Google Home мгновенно отключилось от сети и создало собственную: Я подключился к сети и использовал netstat , чтобы получить IP маршрутизатора (маршрутизатором был Google Home), и увидел, что он назначил себе адрес 192.168.255.249 . Я отправил запрос к локальному API, чтобы проверить, работает ли он:
Потрясающе! Он работал! Благодаря этой информации можно было привязать аккаунт к устройству и удалённо контролировать его. Ещё более классный сценарий атаки Нападающий хочет пошпионить за жертвой. Нападающий может подобраться к области беспроводного действия Google Home (но у него НЕТ пароля от Wi-Fi жертвы). Что ещё мы можем сделать? Очевидно, что привязанный аккаунт даёт огромную степень контроля над устройством. Мне захотелось узнать, может ли нападающий сделать что-нибудь ещё. Мы будем учитывать нападающих, ещё не находящихся в сети жертвы. Возможно ли взаимодействовать с другими устройствами жертвы (а, может быть, и атаковать их) через скомпрометированный Google Home? Мы уже знаем, что при помощи привязанного аккаунта можно:
Выше мы изучали "Conversational Actions" и выяснили, что они слишком ограничены песочницей, чтобы быть полезными для нападающего. Но есть и другой тип действия: "Smart Home Actions". Производители устройств (например, Philips) могут использовать их для добавления поддержки своих устройств на платформе Google Home (например, когда пользователь говорит «включи свет», лампочки Philips Hue получат команду «включиться»). Особенно интересным при чтении документации мне показался Local Home SDK. Smart Home Actions используются только для запуска через Интернет (как и Conversational Actions), но недавно (в апреле 2020 года) Google добавила поддержку их локального выполнения для снижения задержек. SDK позволяет написать на TypeScript или JavaScript локальное приложение, содержащее бизнес-логику умного дома. Устройства Google Home или Google Nest могут загружать и исполнять приложение внутри устройства. Приложение напрямую общается с умными устройствами по Wi-Fi в локальной сети, выполняя команды пользователя по имеющимся протоколам. Звучит многообещающе. Я изучил, как это работает, и выяснил, что эти локальные домашние приложения не имеют прямого доступа к локальной сети. Невозможно просто подключиться к любому IP-адресу; вместо этого нужно задать «конфигурацию сканирования» при помощи вещания по mDNS, UPnP или UDP. Google Home сканирует сеть от лица пользователя и при нахождении любого подходящего устройства возвращает объект JavaScript, позволяющий приложению взаимодействовать с устройством по TCP/UDP/HTTP. Можно ли это обойти? Я заметил, что в документации что-то говорится об отладке при помощи Chrome DevTools. Оказалось, что когда локальное домашнее приложение запущено в тестовом режиме (развёрнуто в собственном аккаунте разработчика), Google Home открывает порт 9222 для Chrome DevTools Protocol (CDP). Доступ по CDP обеспечивает полный контроль над экземпляром Chrome. Например, можно открывать или закрывать вкладки и перехватывать сетевые запросы. Это заставило меня задуматься: возможно, я смогу создать такую конфигурацию сканирования, которая приказывает Google Home сканировать в поисках себя, чтобы можно было подключиться к CDP, получить контроль над запущенным в устройстве экземпляром Chrome и использовать его для создания произвольных запросов в локальной сети. При помощи привязанного аккаунта я создал локальное домашнее приложение и настроил конфигурацию сканирования на поиск mDNS-сервиса _googlecast._tcp.local . Перезагрузил устройство, после чего приложение загрузилось автоматически. Оно быстро обнаружило себя и я мог отправлять HTTP-запросы к localhost !CDP использует WebSockets, доступные через стандартный JS API. Правило ограничения домена не применяется к WebSockets, поэтому мы можем запросто инициировать WebSocket как localhost из локального домашнего приложения (хостящегося на каком-нибудь публичном веб-сайте), если у нас будет нужный URL. Так как доступ по CDP может привести к тривиальному RCE в десктопной версии Chrome, адрес WebSocket при включенной отладке каждый раз генерируется случайным образом, чтобы предотвратить подключение случайных веб-сайтов. Адрес можно получить запросом GET к http://[CDP host]:9222/json . Обычно он защищён правилом ограничения домена, поэтому мы не можем просто применить XHR-запрос, но поскольку у нас есть полный доступ к localhost через Local Home SDK, можно использовать его для создания запроса. Получив адрес, мы можем использовать JS-конструктор WebSocket() для подключения.Через CDP мы можем отправлять произвольные HTTP-запросы через локальную сеть жертвы, что позволяет атаковать другие устройства жертвы. Как говорится ниже, я также нашёл способ считывать и записывать произвольные файлы в устройстве при помощи CDP. Proof of Concept Описанные ниже PoC опубликованы здесь: https://github.com/DownrightNifty/gh_hack_PoC. Так как проблемы с безопасностью были устранены, вероятно, всё это больше не работает, но я решил, что это стоит задокументировать и сохранить. PoC 1: шпионим за жертвой Я создал PoC, работающее в моём Android-телефоне (через Python в Termux), чтобы продемонстрировать, насколько быстрым и простым может быть процесс привязки аккаунта. Описанная ниже атака может быть выполнена в течение всего нескольких минут. Для PoC я заново реализовал привязку к устройству и routines API на Python, а также создал следующие утилиты:
Вот видео того, как выглядит удалённое инициирование звонка:
Как видите, нет никакого звукового уведомления о том, что выполняются команды, поэтому жертве сложно это заметить. По большей части жертва может продолжать обычным образом пользоваться устройством (однако некоторые команды, например, воспроизведение музыки, во время вызова работать не будут). Proof of concept 2: делаем произвольные HTTP-запросы в сети жертвы Как говорилось выше, нападающий может удалённо установить в привязанное устройство smart home action и использовать Local Home SDK для выполнения произвольных HTTP-запросов в локальной сети жертвы.
Теперь мы можем отправлять HTTP(S)-запросы к приватной локальной сети жертвы, как будто у нас есть пароль от WiFi, (хотя его пока нет), сконфигурировав программу на своём компьютере так, чтобы она перенаправляла трафик через локальный прокси-сервер, который, в свою очередь, перенаправляет его в Google Home. Например, curl --proxy 'localhost:8000' --insecure -v https://localhost:8443/setup/eureka_info возвращает информацию Google Home, потому что через прокси localhost резолвится в IP-адрес Google Home. JSON-ответ на /setup/eureka_info содержит IP-адрес, что полезно для определения структуры локальной сети.Мне даже удалось при помощи chrome --proxy-server='localhost:8000' --ignore-certificate-errors --user-data-dir='SOME_DIR' перенаправить Chrome через прокси, и всё работало на удивление хорошо.Очевидно, что возможность отправки запросов в приватной локальной сети открывает большую поверхность атак. При помощи IP-адреса Google Home можно определить подсеть, в которой находятся другие устройства жертвы. Например, моё устройство Google Home имеет IP-адрес 192.168.86.132 , поэтому я могу предположить, что другие устройства находятся в диапазоне от 192.168.86.0 до 192.168.86.255 . Можно написать простой скрипт для проверки при помощи cURL всех возможных адресов в поисках устройства в локальной сети, которое можно атаковать или с которого можно украсть данные. Так как на проверку каждого IP-адреса тратится всего несколько секунд, проверить все можно примерно за десять минут. В своей локальной сети я нашёл веб-интерфейс принтера по адресу http://192.168.86.33 . На его странице сетевых настроек есть <input type="password"> , в котором обычным текстом указан пароль к моему WiFi. Также интерфейс предоставляет механизм обновления прошивки, который, как мне кажется, может быть уязвим для атаки.Также можно поискать маршрутизатор жертвы и попробовать атаковать его. IP-адрес моего роутера 192.168.1.254 находится в первых результатах поиска в Google «default router IPs». Можно написать скрипт, чтобы проверить их. Интерфейс конфигурации маршрутизатора тоже мгновенно возвращает пароль к моему Wi-Fi обычным текстом. К счастью, я поменял стандартный пароль администратора, поэтому нападающий с доступом хотя бы не сможет поменять настройки, однако большинство людей не меняет пароль и его можно найти по запросу "[название бренда] router password", а затем поменять DNS-сервер на собственный, устанавливать зловредные обновления прошивки и так далее. Даже если жертва поменяет пароль маршрутизатора, он всё равно может остаться уязвимым. Например, в июне 2020 года исследователь обнаружил в 79 моделях маршрутизаторов Netgear уязвимость переполнения буфера, которая привела к root shell; процесс он описал как «простой». Proof of concept 3: считывание/запись произвольных файлов в устройстве Также я обнаружил способ считывания/записи произвольных записей в привязанном устройстве при помощи методов
Так как мы не можем исследовать файловую систему Google Home (и в <input type="file" webkitdirectory> нельзя загружать папки вместо файлов), то не совсем понятно, какое влияние это окажет. Мне удалось найти какую-то информацию о структуре файловой системы из информации «open source licenses» и из доклада на DEFCON по Google Home. Я сдампил несколько двоичных файлов, например, /system/chrome/cast_shell и /system/chrome/lib/libassistant.so , а затем пропустил их через strings в поисках интересных файлов, которые можно украсть или повредить. Возможно, в /data/chrome/chirp/assistant/cookie , возможно, содержится информация о пользователе? /data/chrome/chirp/assistant/settings и /data/chrome/chirp/assistant/phenotype_package_store содержат GAIA ID аккаунтов, привязанных к моему Google Home. Мне удалось сдампить /data/chrome/chirp/assistant/nightmode/nightmode_params , отредактировать его в шестнадцатеричном редакторе и перезаписать оригинал моей модифицированной версией. После перезапуска изменения применились. Получается, если в парсере файла конфигурации обнаружится баг, то, вероятно, потенциально это может привести к RCE?Исправления Мне известно, что Google реализовала следующие исправления:
Всё равно можно деаутентифицировать Google Home и получить доступ к информации об устройстве через конечную точку /setup/eureka_info , но вы больше не сможете использовать её для привязки аккаунта и получить доступ к остальному локальному API, потому что нельзя получить локальный токен аутентификации.В устройствах с дисплеем (например, Google Nest Hub) сеть настройки защищена паролем WPA2, отображаемым в виде QR-кода на дисплее (который нужно сканировать приложением Google Home), что добавляет ещё один уровень защиты. Кроме того, на этих устройствах можно сказать «add my voice», чтобы открылся экран с кодом привязки, предлагающий посетить https://g.co/nest/voice. Через этот веб-сайт можно привязать аккаунт к устройству, даже если он не добавлен к его Home (и это нормально, потому что для этого всё равно требуется физический доступ к устройству). Похоже, команда «add my voice» не работает в Google Home Mini. Вероятно, потому что у него нет дисплея, позволяющего предоставить код привязки. Думаю, если бы Google хотела реализовать это, то можно было бы произносить код привязки вслух или передавать его текстом на указанный номер телефона. Размышления и выводы Архитектура Google Home основана на Chromecast. Chromecast не делает такого упора на защиту от атак по принципу близости к устройству, потому что в нём они по большей мере не нужны. Что плохого может случиться, если кто-то взломает Chromecast? Запустит воспроизведение порно? Однако Google Home гораздо более критичное для безопасности устройство, ведь оно может управлять другими устройствами умного дома и микрофоном. Если бы архитектура Google Home создавалась с нуля, то, наверное, таких проблем бы вообще не возникло. Хронология раскрытия
Предыдущие исследования Вот несколько заинтересовавших меня статей, которые я нашёл во время своего исследования устройств Google Home:
Дополнение: статический анализ приложения Google Home Во время своих исследований я глубже покопался в приложении Google Home. В нём я не нашёл никаких проблем безопасности, однако узнал кое-что о локальном API, чего пока нет в неофициальной документации. Конечная точка show_led Чтобы найти список конечных точек локального API (а потенциально и незадокументированные точки), я поискал в декомпилированном исходном коде известную конечную точку ( defpackage/ufo.java :SHOW_LED показалась мне интересной, и её не было в официальной документации. Поиск места, где используется эта константа, привёл меня к StereoPairCreationActivity :При помощи потрясающей функции JADX «rename symbol», переименовав несколько методов, я смог найти класс, отвечающий за создание полезной JSON-нагрузки для этой конечной точки: Похоже, что полезная нагрузка состоит из целочисленного animation_id . Мы можем отправить его конечной точке так:
Это заставит светодиоды воспроизводить анимацию медленной пульсации. К сожалению, похоже, есть только две анимации: 1 (сброс светодиодов в обычное состояние) и 2 (непрерывная пульсация). Что ж, ладно.Шифрование пароля от Wi-Fi Также мне удалось найти алгоритм, используемый для шифрования пользовательского пароля от Wi-Fi перед его отправкой через конечную точку Дополнение: атаки деаутентификации на Google Home Mini Выше я говорил, что Google Home Mini не поддерживает ни WPA3, ни 802.11w. Мне хотелось бы пояснить, как я это обнаружил. Источник: habr.com Комментарии: |
|