D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Путь к облаку полон дыр: эксплуатация пограничных маршрутизаторов 4G
Ноам Моше/3 октября 2023 г.
- Team82 обнаружила и раскрыла критические уязвимости в пограничных маршрутизаторах ER2000 компании ConnectedIO.
- Эти маршрутизаторы 3G/4G действуют как шлюзы, подключая устройства IoT к Интернету.
- Обнаруженные нами уязвимости затронули не только пограничные маршрутизаторы, но также облачную платформу управления устройствами и протокол связи, используемый между устройствами и облаком.
- Злоумышленник мог использовать эти недостатки для полной компрометации облачной инфраструктуры, удаленного выполнения кода.
- ConnectedIO предоставил обновления прошивки, устраняющие все уязвимости, обнаруженные Team82. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
- Team82 представила это исследование на S4x23 в начале этого года, см. видео ниже.
Введение
Резкий рост количества устройств Интернета вещей создал проблемы управления для компаний, которым необходимо обеспечить безопасность сотен или тысяч подключенных устройств. Например, во многих промышленных условиях невозможно посетить каждое устройство индивидуально, когда необходимо применить обновления безопасности или функций или когда устройство не работает и требует внимания.
В результате все большее количество устройств получает удаленный доступ и управление ими через облачные приложения из централизованной точки, обеспечивая единое представление о состоянии и конфигурациях устройств.
В сфере ИТ, где практически любое устройство подключено к внутренней сети организации, убедиться, что каждое устройство подключено к Интернету и имеет доступ к платформе управления облаком, очень просто. Однако в других средах подключение не так просто.
В реальных приложениях компании могут иметь сотни удаленных объектов, каждый из которых содержит десятки устройств, совместно работающих для обеспечения производственной деятельности компании. Во многих случаях подключение каждого объекта к кабельному Интернет-соединению невозможно либо из-за высоких затрат, либо из-за физических ограничений.
Чтобы обеспечить доступ к Интернету на этих сайтах, используется маршрутизатор 3G/4G, действующий как шлюз между удаленным сайтом и Интернетом и позволяющий устройствам XIoT на этом сайте подключаться к сети. Благодаря этому соединению организации также могут удаленно управлять своими устройствами.
Этот вариант использования маршрутизаторов 3G/4G в качестве шлюзов заинтриговал нас и поднял исследовательские вопросы: могут ли злоумышленники злоупотреблять одной и той же архитектурой? Могут ли злоумышленники использовать их для доступа и контроля над миллионами удаленных сайтов по всему миру, одновременно нарушая тысячи процессов?
Это поверхность атаки, которую мы хотели изучить, выявляя уязвимости в маршрутизаторах 3G/4G, которые могут открыть доступ злоумышленникам к тысячам внутренних сетей. Используя уязвимости в маршрутизаторах, злоумышленники могут скомпрометировать их и получить полный контроль над сетями. Это может открыть множество сценариев атак, позволяя злоумышленникам вывести из эксплуатации удаленный сайт, трафик «человек посередине» или атаковать внутренние устройства XIoT.
В этой статье мы сосредоточимся на наших исследованиях и обнаружении критических уязвимостей в платформе ConnectedIO, в основном в пограничном маршрутизаторе 4G ER2000 и облачных сервисах. Обнаруженные нами уязвимости затрагивают все неисправленные устройства, позволяя злоумышленникам выполнять произвольный код на этих устройствах, не требуя прямого доступа к ним или не подвергая их воздействию Интернета. Кроме того, мы также обнаружили уязвимости, которые подвергают риску облачную платформу ConnectedIO. Все эти уязвимости были раскрыты компании ConnectedIO, которая предоставила обновления прошивки, устраняющие все уязвимости. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
Технические детали
ConnectedIO предлагает широкий спектр решений для подключения, в основном ориентированных на маршрутизаторы с поддержкой 4G, которые позволяют устройствам IoT/IIoT оставаться подключенными к Интернету. В своем портфолио ConnectedIO предлагает широкий спектр маршрутизаторов и модемов 4G, каждый из которых имеет разные коммуникационные возможности и характеристики.
Помимо оборудования, ConnectedIO предлагает облачную SaaS-платформу для управления своими устройствами. Эта облачная платформа позволяет владельцам активов контролировать свои устройства, а пользователям просматривать данные о своих устройствах, изменять конфигурации, выполнять операции по техническому обслуживанию и автоматически обновлять прошивку устройства.
В начале нашего исследования нам нужно было понять, как пользователи заявляют о своих устройствах и как устройства регистрируются и идентифицируются в облаке.
Несмотря на то, что существует множество методов, с помощью которых устройства могут идентифицировать себя в облаке, ConnectedIO решила полагаться на аппаратные идентификаторы, записанные в устройство во время его производства: MAC-адрес устройства и номер IMEI.
Используя эти два идентификатора, устройство подключается к облаку и сообщает, что хочет подключиться. Затем облако ConnectedIO проверяет параметры, убеждаясь, что они соответствуют реальному устройству, произведенному ConnectedIO, и только если эти два идентификатора верны, облако примет соединение.
После понимания того, как устройства идентифицируют себя в облаке, нашим следующим шагом было понять, как пользователи могут заявить права на свои устройства, взять на себя ответственность и получить полный контроль над своими устройствами.
Чтобы заявить права на устройства, пользователь должен доказать облаку, что он действительно является законным владельцем устройства. Для этого облако ConnectedIO требует от пользователя предоставить «секреты», известные только владельцу устройства: серийный номер и IMEI устройства. Поскольку эта информация напечатана на этикетке устройства, расположенной на задней стороне устройства, она должна быть известна только людям, имеющим физический доступ к самому устройству.
После того как пользователь успешно заберет свое устройство, он сможет полностью контролировать его с помощью облака ConnectedIO. Тогда они смогут использовать всю функциональность, предлагаемую облаком, для управления своим устройством.
Хотя важно аутентифицировать и проверить устройство, требуя от него предоставления «секретов», известных только ему, прежде чем принять его в облако, мы заметили, что производители и поставщики полагаются на использование аппаратных идентификаторов MAC-адреса и IMEI/серийного номера. Эти идентификаторы не следует использовать для аутентификации/заявления на устройства, поскольку они не являются криптографически безопасными и злоумышленники могут легко их угадать.
Например, на MAC-адрес не следует полагаться как на идентификатор, поскольку он состоит из трех случайных байтов, а это означает, что энтропия секрета очень низка. Что касается IMEI/серийного номера, то обычно эти идентификаторы являются последовательными, а это означает, что, зная идентификатор одного устройства, довольно легко угадать идентификаторы других устройств.
Понимание связи между облаком и устройством
После понимания процесса заявки на устройство нашей следующей целью было понять, как устройство на самом деле подключается к облаку и устанавливает безопасный канал связи между собой и облаком.
Мы начали с извлечения прошивки устройства, которую нам удалось найти внутри облачной платформы ConnectedIO. Извлечение прошивки было простым, поскольку ConnectedIO не реализовывал механизм упаковки/шифрования прошивки. Вместо этого мы просто использовали binwalk для извлечения содержимого прошивки, что дало нам доступ к файловой системе устройства.
Затем мы искали URL-адреса и IP-адреса, которые можно было бы связать с облаком ConnectedIO. Нашей целью было понять, какой именно протокол связи ConnectedIO выбрал для реализации своей связи между устройством и облаком. Мы обнаружили URL-адрес, указывающий на облако ConnectedIO, внутри файла конфигурации и исполняемого файла. Внутри файла конфигурации под названием redirectTo.sh, мы обнаружили маршрутизатор, настраивающийся следующей конфигурацией, как показано на изображении ниже:
Внутри этого сценария маршрутизатор настраивает конфигурацию MQTT для устройства, включая URL-адрес, имя пользователя и пароль. Затем он запускает двоичный файл cioClient, который управляет фактической связью с облаком. Однако еще до исследования двоичного файла мы уже можем сделать вывод, что устройство взаимодействует с облаком с помощью MQTT.
MQTT — это протокол издатель-подписчик (pub-sub), предназначенный для обеспечения распределенной удаленной связи. В протоколе MQTT находятся два объекта: клиент, который отправляет и получает сообщения, и брокер, который распределяет полученные сообщения и маршрутизирует их соответствующим клиентам.
Чтобы рассылать сообщения нужным клиентам, брокер хранит список топиков, которые представляют собой каналы связи с разными названиями, которые клиенты могут использовать для общения. Клиенты могут публиковать сообщения в этих топиках или подписываться и получать сообщения, отправленные в топики, на которые они подписаны. Всякий раз, когда сообщение отправляется в определенный топик, брокер рассылает его всем пользователям, подписавшимся на этот топик.
Эта связь варьируется от простых обновлений статуса, которые устройство периодически отправляет, до команд, которые облако отправляет устройству, и ответов на эти команды.
Поняв, что устройство общается с облаком с помощью MQTT, нашей следующей целью было понять, на какие топики устройства подписываются и публикуют сообщения. Для этого мы исследовали двоичный файл и обнаружили следующую схему:
cio/device/status: это используется устройствами для отправки периодических обновлений статуса в облако. Эти обновления включают текущее состояние устройства, а также сообщение об обнаружении его соседей.
cio/device/DR{DEVICE_IMEI} (Device Receive): группа топиков, используемая облаком для выдачи команд устройствам. У каждого устройства есть своя уникальный топик, определяемая номером IMEI устройства.
cio/device/DS/{DEVICE_IMEI} (Device Send): группа топиков, используемая устройствами для отправки ответов в облако после выдачи команд устройства. У каждого устройства есть свой уникальный топик, определяемая номером IMEI устройства.
Поскольку устройства разбросаны по всему миру, брокер MQTT должен быть подключен к Интернету и доступен всем. Это сделало его интересной целью для нашего исследования.
Pwning Cloud Communication
Поняв эту схему, используемую ConnectedIO, мы хотели посмотреть, будут ли на самом деле работать жестко запрограммированные учетные данные для брокера MQTT. После дальнейшего исследования двоичного файла мы узнали, что он использует эти учетные данные для аутентификации у брокера, что дало нам дополнительную надежду, что мы сможем подключиться к нему.
Затем мы написали простой скрипт Python, который пытается аутентифицироваться у MQTT-брокера ConnectedIO, используя найденные нами жестко закодированные учетные данные, и, к нашему удивлению, брокер принял наше соединение, давая нам возможность подключаться и общаться с MQTT-брокером, как с действительным устройством. Однако мы хотели полностью понять наши разрешения; на какие топики мы могли бы подписаться.
Из-за своей бизнес-логики устройствам необходимы публикации в status топике для отправки периодических status сообщений. Помимо топика состояния, устройства также должны иметь возможность подписываться на свою собственную DR топик (device receive), а также отправлять сообщения в свою DS топик (device send).
Однако, поскольку все устройства использовали одни и те же жестко закодированные учетные данные, брокер не мог различать устройства, а это означало, что ему пришлось разрешить всем устройствам подписываться на все топики DR, а также публиковать сообщения во всех топики DR. Это означало, что если бы мы знали IMEI устройства (который необходим для знания полного названия топика устройства), мы могли бы выдавать себя за каждое устройство и получать/отправлять сообщения от его имени.
Нашей следующей целью было подписаться на статус topic (на который устройства не должны подписываться, а только публиковать), и когда мы попытались это сделать, нам удалось получить сообщения о состоянии, отправленные другими устройствами. Это означало, что брокер MQTT был неправильно настроен, чтобы позволить устройствам подписываться на status топик, а не только отправлять ему сообщения.
Подписавшись на этот топик, мы увидели десятки тысяч сообщений с устройств со всего мира. Эти сообщения содержали простые отчеты о пульсе устройств, а также более сложную конфигурацию и конфиденциальную информацию, такую как MAC-адрес устройства, настройки Wi-Fi, SSID и пароли.
Хотя информация, отправленная в status сообщениях, сама по себе была конфиденциальной, одно поле в сообщении оказалось более важным; устройство отправило свой IMEI, чтобы облако знало, какое устройство отправило status отчет. Это означало, что, пассивно прослушивая топик статуса, мы могли раскрыть весь IMEI устройства, который является «секретным» компонентом топиков DS/DR, а это означает, что теперь у нас была возможность выдавать себя за любое устройство по нашему выбору.
Теперь у нас был полный список идентификаторов IMEI всех устройств, а это значит, что мы могли выдавать себя за все устройства. Однако, хотя олицетворение устройств может оказаться критически важным для платформы, нашей реальной целью было самостоятельное взаимодействие с устройствами, то есть мы хотели напрямую подавать команды устройствам.
Для этого нам пришлось публиковать сообщения в топике DR (прием устройства) других устройств, выдавать себя за облако и выдавать команды для выполнения устройствами. Логично, что топик аварийного восстановления не должна быть доступна для публикации устройствами, поскольку она используется исключительно облаком для выдачи команд устройствам. Однако мы хотели посмотреть, существует ли в топике уязвимость, аналогичная той, которую мы нашли в DR топике, позволяющая устройствам публиковать сообщения в DR топике, а не просто подписываться на нее. Как оказалось, эта уязвимость затронула и DR топик, дав нам возможность выдавать себя за облако и подавать команды устройствам.
Используя возможность публиковать команды для выполнения на устройстве, мы могли заставить устройства выполнять наши команды, изменять их конфигурации и многое другое. Это открыло перед нами широкий спектр возможностей по эксплуатации устройств.
Pwning Devices
После получения возможности подавать команды устройствам через DR топик и утечки IMEI, мы захотели изучить, какие команды облако может выдавать устройствам. Для этого мы исследовали двоичный файл, который управляет всей облачной связью.
При исследовании двоичного файла на устройстве мы определили функцию, которая анализирует полученную полезную нагрузку MQTT и выполняет полученные ею команды.
Фактическая полезная нагрузка, передаваемая через MQTT, основана на ascii, с параметрами, разделенными знаком «,». Когда программа получает сообщение, она разделяет его на «» и помещает каждый раздел в соответствующий параметр. Затем каждый параметр имеет различное назначение, например, второй параметр в полезных данных представляет собой целочисленный код операции, определяющий, какой тип команды должно выполнить устройство.
Особенно наше внимание привлекла одна конкретная команда: команда bash с кодом операции «1116», которая выполняет удаленную команду «как есть».
Эта команда, которая не требует какой-либо другой формы аутентификации, кроме возможности записать ее в правильный топик, позволяет нам выполнять произвольные команды на всех устройствах.
Используя этот код операции команды, мы смогли сгенерировать полезную нагрузку, которая приведет к выполнению кода всякий раз, когда он будет отправлен на устройство.
Затем, отправив эту полезную нагрузку на наше собственное устройство, предоставив код операции 1116 (команда bash), нам удалось добиться выполнения произвольного кода на нашем устройстве.
Это означало, что у нас была возможность удаленно выполнять код на любых облачных устройствах ConnectedIO.
Помимо этих уязвимостей, нам удалось выявить еще четыре уязвимости, позволяющие злоумышленникам удаленно выполнять код на всех устройствах ConnectedIO. Эти уязвимости отслеживаются под следующими CVE: CVE-2023-33375 , CVE-2023-33376 , CVE-2023-33377 и CVE-2023-33378 .
Ключевые моменты
Мы видим, что все больше маршрутизаторов 3G и 4G действуют как шлюзы в Интернет, когда устройства не могут напрямую подключиться к Интернету. Блокировка этих маршрутизаторов и шлюзов имеет решающее значение для целостности и доступности устройств Интернета вещей и стоящих за ними серверных служб.
В этом отчете мы исследовали прошивку семейства пограничных маршрутизаторов ConnectedIO ER2000 и обнаружили ряд критических уязвимостей не только в облачной платформе управления поставщика и самих устройствах, но также в реализации протокола связи, который поддерживает передачу данных между устройством и облаком и связь между облаком и устройством.
Чтобы эксплуатировать устройства ConnectedIO, нам пришлось объединить несколько уязвимостей как в устройствах, так и в брокере MQTT, что дало нам возможность выполнять произвольный код на всех устройствах, подключенных к Интернету.
Во-первых, исследуя прошивку маршрутизатора, мы обнаружили жестко запрограммированные учетные данные аутентификации, используемые всеми маршрутизаторами для связи с облаком ConnectedIO. Затем мы использовали эти учетные данные вместе с неправильной настройкой в брокере MQTT, чтобы подписаться на топик статуса и прослушивать сообщения, что дало нам знания об идентификаторе IMEI всех подключенных устройств.
Затем мы использовали список, который мы составили из IMEI всех устройств, чтобы сгенерировать имена тем DR (прием устройств) для всех маршрутизаторов, что позволило нам выдавать команды этим устройствам, выдавая себя за облако ConnectedIO.
Наконец, воспользовавшись одной из многочисленных уязвимостей, которые мы обнаружили в самих маршрутизаторах, начиная от простого API-интерфейса «команда как услуга ОС» и заканчивая уязвимостью переполнения буфера, мы получили возможность выполнять код на любом устройстве, подключенном к Интернету.
Вкратце, вот цепочка эксплуатации:
- Используйте жестко запрограммированные учетные данные для подключения к брокеру MQTT, выдавая себя за устройство.
- Слейте все IMEI устройств через status топик.
- Сгенерируйте имя топика DR для всех устройств (используя утекший IMEI).
- Отправьте на устройства вредоносную полезную нагрузку, вызывающую одну из нескольких уязвимостей RCE, и получите полный контроль над этими устройствами.
Эти уязвимости, если они будут использованы, могут представлять серьезную угрозу для тысяч компаний по всему миру, позволяя злоумышленникам нарушить работу и производство компаний, а также предоставляя им доступ к внутренним сетям компаний.
Чтобы устранить эти уязвимости, ConnectedIO предоставила обновления прошивки, устраняющие все уязвимости, обнаруженные Team82. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
Переведено специально для XSS.IS
Автор перевода: yashechka
Источник: https://claroty.com/team82/research...-filled-with-holes-exploiting-4g-edge-routers
Ноам Моше/3 октября 2023 г.
- Team82 обнаружила и раскрыла критические уязвимости в пограничных маршрутизаторах ER2000 компании ConnectedIO.
- Эти маршрутизаторы 3G/4G действуют как шлюзы, подключая устройства IoT к Интернету.
- Обнаруженные нами уязвимости затронули не только пограничные маршрутизаторы, но также облачную платформу управления устройствами и протокол связи, используемый между устройствами и облаком.
- Злоумышленник мог использовать эти недостатки для полной компрометации облачной инфраструктуры, удаленного выполнения кода.
- ConnectedIO предоставил обновления прошивки, устраняющие все уязвимости, обнаруженные Team82. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
- Team82 представила это исследование на S4x23 в начале этого года, см. видео ниже.
Введение
Резкий рост количества устройств Интернета вещей создал проблемы управления для компаний, которым необходимо обеспечить безопасность сотен или тысяч подключенных устройств. Например, во многих промышленных условиях невозможно посетить каждое устройство индивидуально, когда необходимо применить обновления безопасности или функций или когда устройство не работает и требует внимания.
В результате все большее количество устройств получает удаленный доступ и управление ими через облачные приложения из централизованной точки, обеспечивая единое представление о состоянии и конфигурациях устройств.
В сфере ИТ, где практически любое устройство подключено к внутренней сети организации, убедиться, что каждое устройство подключено к Интернету и имеет доступ к платформе управления облаком, очень просто. Однако в других средах подключение не так просто.
В реальных приложениях компании могут иметь сотни удаленных объектов, каждый из которых содержит десятки устройств, совместно работающих для обеспечения производственной деятельности компании. Во многих случаях подключение каждого объекта к кабельному Интернет-соединению невозможно либо из-за высоких затрат, либо из-за физических ограничений.
Чтобы обеспечить доступ к Интернету на этих сайтах, используется маршрутизатор 3G/4G, действующий как шлюз между удаленным сайтом и Интернетом и позволяющий устройствам XIoT на этом сайте подключаться к сети. Благодаря этому соединению организации также могут удаленно управлять своими устройствами.
Этот вариант использования маршрутизаторов 3G/4G в качестве шлюзов заинтриговал нас и поднял исследовательские вопросы: могут ли злоумышленники злоупотреблять одной и той же архитектурой? Могут ли злоумышленники использовать их для доступа и контроля над миллионами удаленных сайтов по всему миру, одновременно нарушая тысячи процессов?
Это поверхность атаки, которую мы хотели изучить, выявляя уязвимости в маршрутизаторах 3G/4G, которые могут открыть доступ злоумышленникам к тысячам внутренних сетей. Используя уязвимости в маршрутизаторах, злоумышленники могут скомпрометировать их и получить полный контроль над сетями. Это может открыть множество сценариев атак, позволяя злоумышленникам вывести из эксплуатации удаленный сайт, трафик «человек посередине» или атаковать внутренние устройства XIoT.
В этой статье мы сосредоточимся на наших исследованиях и обнаружении критических уязвимостей в платформе ConnectedIO, в основном в пограничном маршрутизаторе 4G ER2000 и облачных сервисах. Обнаруженные нами уязвимости затрагивают все неисправленные устройства, позволяя злоумышленникам выполнять произвольный код на этих устройствах, не требуя прямого доступа к ним или не подвергая их воздействию Интернета. Кроме того, мы также обнаружили уязвимости, которые подвергают риску облачную платформу ConnectedIO. Все эти уязвимости были раскрыты компании ConnectedIO, которая предоставила обновления прошивки, устраняющие все уязвимости. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
Технические детали
ConnectedIO предлагает широкий спектр решений для подключения, в основном ориентированных на маршрутизаторы с поддержкой 4G, которые позволяют устройствам IoT/IIoT оставаться подключенными к Интернету. В своем портфолио ConnectedIO предлагает широкий спектр маршрутизаторов и модемов 4G, каждый из которых имеет разные коммуникационные возможности и характеристики.
Помимо оборудования, ConnectedIO предлагает облачную SaaS-платформу для управления своими устройствами. Эта облачная платформа позволяет владельцам активов контролировать свои устройства, а пользователям просматривать данные о своих устройствах, изменять конфигурации, выполнять операции по техническому обслуживанию и автоматически обновлять прошивку устройства.
В начале нашего исследования нам нужно было понять, как пользователи заявляют о своих устройствах и как устройства регистрируются и идентифицируются в облаке.
Несмотря на то, что существует множество методов, с помощью которых устройства могут идентифицировать себя в облаке, ConnectedIO решила полагаться на аппаратные идентификаторы, записанные в устройство во время его производства: MAC-адрес устройства и номер IMEI.
Используя эти два идентификатора, устройство подключается к облаку и сообщает, что хочет подключиться. Затем облако ConnectedIO проверяет параметры, убеждаясь, что они соответствуют реальному устройству, произведенному ConnectedIO, и только если эти два идентификатора верны, облако примет соединение.
После понимания того, как устройства идентифицируют себя в облаке, нашим следующим шагом было понять, как пользователи могут заявить права на свои устройства, взять на себя ответственность и получить полный контроль над своими устройствами.
Чтобы заявить права на устройства, пользователь должен доказать облаку, что он действительно является законным владельцем устройства. Для этого облако ConnectedIO требует от пользователя предоставить «секреты», известные только владельцу устройства: серийный номер и IMEI устройства. Поскольку эта информация напечатана на этикетке устройства, расположенной на задней стороне устройства, она должна быть известна только людям, имеющим физический доступ к самому устройству.
После того как пользователь успешно заберет свое устройство, он сможет полностью контролировать его с помощью облака ConnectedIO. Тогда они смогут использовать всю функциональность, предлагаемую облаком, для управления своим устройством.
Хотя важно аутентифицировать и проверить устройство, требуя от него предоставления «секретов», известных только ему, прежде чем принять его в облако, мы заметили, что производители и поставщики полагаются на использование аппаратных идентификаторов MAC-адреса и IMEI/серийного номера. Эти идентификаторы не следует использовать для аутентификации/заявления на устройства, поскольку они не являются криптографически безопасными и злоумышленники могут легко их угадать.
Например, на MAC-адрес не следует полагаться как на идентификатор, поскольку он состоит из трех случайных байтов, а это означает, что энтропия секрета очень низка. Что касается IMEI/серийного номера, то обычно эти идентификаторы являются последовательными, а это означает, что, зная идентификатор одного устройства, довольно легко угадать идентификаторы других устройств.
Понимание связи между облаком и устройством
После понимания процесса заявки на устройство нашей следующей целью было понять, как устройство на самом деле подключается к облаку и устанавливает безопасный канал связи между собой и облаком.
Мы начали с извлечения прошивки устройства, которую нам удалось найти внутри облачной платформы ConnectedIO. Извлечение прошивки было простым, поскольку ConnectedIO не реализовывал механизм упаковки/шифрования прошивки. Вместо этого мы просто использовали binwalk для извлечения содержимого прошивки, что дало нам доступ к файловой системе устройства.
Затем мы искали URL-адреса и IP-адреса, которые можно было бы связать с облаком ConnectedIO. Нашей целью было понять, какой именно протокол связи ConnectedIO выбрал для реализации своей связи между устройством и облаком. Мы обнаружили URL-адрес, указывающий на облако ConnectedIO, внутри файла конфигурации и исполняемого файла. Внутри файла конфигурации под названием redirectTo.sh, мы обнаружили маршрутизатор, настраивающийся следующей конфигурацией, как показано на изображении ниже:
Внутри этого сценария маршрутизатор настраивает конфигурацию MQTT для устройства, включая URL-адрес, имя пользователя и пароль. Затем он запускает двоичный файл cioClient, который управляет фактической связью с облаком. Однако еще до исследования двоичного файла мы уже можем сделать вывод, что устройство взаимодействует с облаком с помощью MQTT.
MQTT — это протокол издатель-подписчик (pub-sub), предназначенный для обеспечения распределенной удаленной связи. В протоколе MQTT находятся два объекта: клиент, который отправляет и получает сообщения, и брокер, который распределяет полученные сообщения и маршрутизирует их соответствующим клиентам.
Чтобы рассылать сообщения нужным клиентам, брокер хранит список топиков, которые представляют собой каналы связи с разными названиями, которые клиенты могут использовать для общения. Клиенты могут публиковать сообщения в этих топиках или подписываться и получать сообщения, отправленные в топики, на которые они подписаны. Всякий раз, когда сообщение отправляется в определенный топик, брокер рассылает его всем пользователям, подписавшимся на этот топик.
Эта связь варьируется от простых обновлений статуса, которые устройство периодически отправляет, до команд, которые облако отправляет устройству, и ответов на эти команды.
Поняв, что устройство общается с облаком с помощью MQTT, нашей следующей целью было понять, на какие топики устройства подписываются и публикуют сообщения. Для этого мы исследовали двоичный файл и обнаружили следующую схему:
cio/device/status: это используется устройствами для отправки периодических обновлений статуса в облако. Эти обновления включают текущее состояние устройства, а также сообщение об обнаружении его соседей.
cio/device/DR{DEVICE_IMEI} (Device Receive): группа топиков, используемая облаком для выдачи команд устройствам. У каждого устройства есть своя уникальный топик, определяемая номером IMEI устройства.
cio/device/DS/{DEVICE_IMEI} (Device Send): группа топиков, используемая устройствами для отправки ответов в облако после выдачи команд устройства. У каждого устройства есть свой уникальный топик, определяемая номером IMEI устройства.
Поскольку устройства разбросаны по всему миру, брокер MQTT должен быть подключен к Интернету и доступен всем. Это сделало его интересной целью для нашего исследования.
Pwning Cloud Communication
Поняв эту схему, используемую ConnectedIO, мы хотели посмотреть, будут ли на самом деле работать жестко запрограммированные учетные данные для брокера MQTT. После дальнейшего исследования двоичного файла мы узнали, что он использует эти учетные данные для аутентификации у брокера, что дало нам дополнительную надежду, что мы сможем подключиться к нему.
Затем мы написали простой скрипт Python, который пытается аутентифицироваться у MQTT-брокера ConnectedIO, используя найденные нами жестко закодированные учетные данные, и, к нашему удивлению, брокер принял наше соединение, давая нам возможность подключаться и общаться с MQTT-брокером, как с действительным устройством. Однако мы хотели полностью понять наши разрешения; на какие топики мы могли бы подписаться.
Из-за своей бизнес-логики устройствам необходимы публикации в status топике для отправки периодических status сообщений. Помимо топика состояния, устройства также должны иметь возможность подписываться на свою собственную DR топик (device receive), а также отправлять сообщения в свою DS топик (device send).
Однако, поскольку все устройства использовали одни и те же жестко закодированные учетные данные, брокер не мог различать устройства, а это означало, что ему пришлось разрешить всем устройствам подписываться на все топики DR, а также публиковать сообщения во всех топики DR. Это означало, что если бы мы знали IMEI устройства (который необходим для знания полного названия топика устройства), мы могли бы выдавать себя за каждое устройство и получать/отправлять сообщения от его имени.
Нашей следующей целью было подписаться на статус topic (на который устройства не должны подписываться, а только публиковать), и когда мы попытались это сделать, нам удалось получить сообщения о состоянии, отправленные другими устройствами. Это означало, что брокер MQTT был неправильно настроен, чтобы позволить устройствам подписываться на status топик, а не только отправлять ему сообщения.
Подписавшись на этот топик, мы увидели десятки тысяч сообщений с устройств со всего мира. Эти сообщения содержали простые отчеты о пульсе устройств, а также более сложную конфигурацию и конфиденциальную информацию, такую как MAC-адрес устройства, настройки Wi-Fi, SSID и пароли.
Хотя информация, отправленная в status сообщениях, сама по себе была конфиденциальной, одно поле в сообщении оказалось более важным; устройство отправило свой IMEI, чтобы облако знало, какое устройство отправило status отчет. Это означало, что, пассивно прослушивая топик статуса, мы могли раскрыть весь IMEI устройства, который является «секретным» компонентом топиков DS/DR, а это означает, что теперь у нас была возможность выдавать себя за любое устройство по нашему выбору.
Теперь у нас был полный список идентификаторов IMEI всех устройств, а это значит, что мы могли выдавать себя за все устройства. Однако, хотя олицетворение устройств может оказаться критически важным для платформы, нашей реальной целью было самостоятельное взаимодействие с устройствами, то есть мы хотели напрямую подавать команды устройствам.
Для этого нам пришлось публиковать сообщения в топике DR (прием устройства) других устройств, выдавать себя за облако и выдавать команды для выполнения устройствами. Логично, что топик аварийного восстановления не должна быть доступна для публикации устройствами, поскольку она используется исключительно облаком для выдачи команд устройствам. Однако мы хотели посмотреть, существует ли в топике уязвимость, аналогичная той, которую мы нашли в DR топике, позволяющая устройствам публиковать сообщения в DR топике, а не просто подписываться на нее. Как оказалось, эта уязвимость затронула и DR топик, дав нам возможность выдавать себя за облако и подавать команды устройствам.
Используя возможность публиковать команды для выполнения на устройстве, мы могли заставить устройства выполнять наши команды, изменять их конфигурации и многое другое. Это открыло перед нами широкий спектр возможностей по эксплуатации устройств.
Pwning Devices
После получения возможности подавать команды устройствам через DR топик и утечки IMEI, мы захотели изучить, какие команды облако может выдавать устройствам. Для этого мы исследовали двоичный файл, который управляет всей облачной связью.
При исследовании двоичного файла на устройстве мы определили функцию, которая анализирует полученную полезную нагрузку MQTT и выполняет полученные ею команды.
Фактическая полезная нагрузка, передаваемая через MQTT, основана на ascii, с параметрами, разделенными знаком «,». Когда программа получает сообщение, она разделяет его на «» и помещает каждый раздел в соответствующий параметр. Затем каждый параметр имеет различное назначение, например, второй параметр в полезных данных представляет собой целочисленный код операции, определяющий, какой тип команды должно выполнить устройство.
Особенно наше внимание привлекла одна конкретная команда: команда bash с кодом операции «1116», которая выполняет удаленную команду «как есть».
Эта команда, которая не требует какой-либо другой формы аутентификации, кроме возможности записать ее в правильный топик, позволяет нам выполнять произвольные команды на всех устройствах.
Используя этот код операции команды, мы смогли сгенерировать полезную нагрузку, которая приведет к выполнению кода всякий раз, когда он будет отправлен на устройство.
Затем, отправив эту полезную нагрузку на наше собственное устройство, предоставив код операции 1116 (команда bash), нам удалось добиться выполнения произвольного кода на нашем устройстве.
Это означало, что у нас была возможность удаленно выполнять код на любых облачных устройствах ConnectedIO.
Помимо этих уязвимостей, нам удалось выявить еще четыре уязвимости, позволяющие злоумышленникам удаленно выполнять код на всех устройствах ConnectedIO. Эти уязвимости отслеживаются под следующими CVE: CVE-2023-33375 , CVE-2023-33376 , CVE-2023-33377 и CVE-2023-33378 .
Ключевые моменты
Мы видим, что все больше маршрутизаторов 3G и 4G действуют как шлюзы в Интернет, когда устройства не могут напрямую подключиться к Интернету. Блокировка этих маршрутизаторов и шлюзов имеет решающее значение для целостности и доступности устройств Интернета вещей и стоящих за ними серверных служб.
В этом отчете мы исследовали прошивку семейства пограничных маршрутизаторов ConnectedIO ER2000 и обнаружили ряд критических уязвимостей не только в облачной платформе управления поставщика и самих устройствах, но также в реализации протокола связи, который поддерживает передачу данных между устройством и облаком и связь между облаком и устройством.
Чтобы эксплуатировать устройства ConnectedIO, нам пришлось объединить несколько уязвимостей как в устройствах, так и в брокере MQTT, что дало нам возможность выполнять произвольный код на всех устройствах, подключенных к Интернету.
Во-первых, исследуя прошивку маршрутизатора, мы обнаружили жестко запрограммированные учетные данные аутентификации, используемые всеми маршрутизаторами для связи с облаком ConnectedIO. Затем мы использовали эти учетные данные вместе с неправильной настройкой в брокере MQTT, чтобы подписаться на топик статуса и прослушивать сообщения, что дало нам знания об идентификаторе IMEI всех подключенных устройств.
Затем мы использовали список, который мы составили из IMEI всех устройств, чтобы сгенерировать имена тем DR (прием устройств) для всех маршрутизаторов, что позволило нам выдавать команды этим устройствам, выдавая себя за облако ConnectedIO.
Наконец, воспользовавшись одной из многочисленных уязвимостей, которые мы обнаружили в самих маршрутизаторах, начиная от простого API-интерфейса «команда как услуга ОС» и заканчивая уязвимостью переполнения буфера, мы получили возможность выполнять код на любом устройстве, подключенном к Интернету.
Вкратце, вот цепочка эксплуатации:
- Используйте жестко запрограммированные учетные данные для подключения к брокеру MQTT, выдавая себя за устройство.
- Слейте все IMEI устройств через status топик.
- Сгенерируйте имя топика DR для всех устройств (используя утекший IMEI).
- Отправьте на устройства вредоносную полезную нагрузку, вызывающую одну из нескольких уязвимостей RCE, и получите полный контроль над этими устройствами.
Эти уязвимости, если они будут использованы, могут представлять серьезную угрозу для тысяч компаний по всему миру, позволяя злоумышленникам нарушить работу и производство компаний, а также предоставляя им доступ к внутренним сетям компаний.
Чтобы устранить эти уязвимости, ConnectedIO предоставила обновления прошивки, устраняющие все уязвимости, обнаруженные Team82. Пользователи защищены автоматически, поскольку эти обновления были внесены в облачную инфраструктуру и периферийные устройства.
Переведено специально для XSS.IS
Автор перевода: yashechka
Источник: https://claroty.com/team82/research...-filled-with-holes-exploiting-4g-edge-routers