В заводских прошивках роутеров Zbtlink на базе OpenWrt обнаружили три встроенных механизма удалённого управления

Первый из них, получивший название ENDLESSDOORS, был раскрыт VulnCheck 5 августа. В списке процессов он маскировался под kworker — имя, обычно используемое рабочими потоками ядра Linux. Однако настоящие kernel worker отображаются в квадратных скобках, тогда как найденный kworker представлял собой обычный пользовательский процесс, занимал память и выполнялся с правами root.

В основе ENDLESSDOORS лежит модифицированная версия опубликованной в 2015 году программы rctl для удалённого управления Linux. Компонент запускается при загрузке сценарием /etc/init.d/skworker, соединяется с внешним управляющим сервером и сообщает ему MAC-адрес устройства. Как установили исследователи, аутентификация управляющего сервера и шифрование отсутствуют: полученные команды напрямую передаются в popen() и выполняются от имени root. Отдельная команда rctlbash позволяет открыть интерактивную командную оболочку маршрутизатора. Проблеме присвоен идентификатор CVE-2026-66747.

VulnCheck обнаружила ENDLESSDOORS во всех 21 образах прошивок, находившихся на странице загрузки Zbtlink. Наличие компонента было подтверждено, в частности, в моделях CPE2801, WE1026-5G-WD, WE1326, WE2007, WE2008-DSIM, WE2416, WE3326, WE5927, WE5931, WE5931AC, WE826-T3-DSIM, WG108, WG1602, WG1608-DSIM, WG209, WG2105, WG2107, WG259, WG3526 и Z8102AX-2DSIM.

Продолжая исследование цепочки поставок Zbtlink, специалисты приобрели в США маршрутизатор Deep Orange 3G/4G/LTE Router. Устройство оказалось перемаркированным ZBT-WE826-T2 с заводской прошивкой 2019 года. ENDLESSDOORS в ней ещё не присутствовал, однако вместо него исследователи обнаружили два других компонента, написанных на языке Nim и запускаемых процессом inetdetect.

• DARKLANTERN работает под именем infosrvd и принимает UDP-пакеты на порту 9992. Заводская конфигурация межсетевого экрана разрешает доступ к этому порту со стороны WAN. Специально сформированный запрос позволяет без нормальной аутентификации получить модель устройства, версию прошивки, MAC-адрес, SSID, время работы и другую информацию. Другой тип пакета передаёт строку в /etc/exec/cmd, позволяя выполнить произвольную команду с правами root. Используемая проверка основана на известном статическом значении, а проверку MAC-адреса можно обойти передачей нулевого значения. С 18 по 21 августа VulnCheck обнаружила 203 доступных из интернета устройства в 22 странах, представившихся 16 различными моделями.

• SPEAKINGSTONE запускается как yunmgrd и, в отличие от DARKLANTERN, самостоятельно устанавливает исходящее соединение с управляющей инфраструктурой по UDP-порту 10000. Благодаря этому механизм способен работать за NAT и межсетевыми экранами. Компонент отправляет серверу модель и версию прошивки, MAC-адрес, SSID, локальный IP-адрес, время работы и, при наличии, географические координаты устройства. По данным анализа VulnCheck, поддерживаемые команды позволяют выполнять произвольный код, получать логин и пароль PPPoE, изменять список подмены DNS, открывать обратный SSH-туннель и перенастраивать резервные управляющие серверы.

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

В прошивку SPEAKINGSTONE был встроен резервный домен findmyipaddr.com, который к моменту исследования оказался свободен. VulnCheck зарегистрировала его и направила соединения на контролируемый сервер-синкхол. К 21 августа с ним связались 392 уникальных устройства, из которых 390 находились в Китае. Около 83% подключений проходили через сеть China Mobile, а 363 устройства сообщали одну и ту же модель и версию прошивки.

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

Проблема осложняется тем, что Zbtlink работает преимущественно как OEM/ODM-производитель. Одни и те же аппаратные платформы могут продаваться под различными марками. Исследователи обнаружили связанные с ZBT устройства, распространявшиеся под брендами WiFlyer, Cioswi, CroSkylink, KuWFi, Deep Orange и другими названиями.

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

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

После публикации информации о DARKLANTERN и SPEAKINGSTONE Zbtlink вновь заявила, что функции удалённой поддержки и облачного доступа являются легитимными и не создают угроз безопасности. Однако исследователи указывают, что в изученных протоколах отсутствуют полноценные механизмы подтверждения доступа пользователем и проверки подлинности управляющего сервера. Возможность получать реквизиты PPPoE, управлять DNS-подменой, выполнять произвольные команды и открывать обратный SSH-туннель также заметно шире функций, обычно необходимых для диагностики маршрутизатора.

На момент первого раскрытия исправленные прошивки для всех затронутых устройств отсутствовали. VulnCheck рекомендует проверять маршрутизаторы на наличие пользовательских процессов kworker, файлов /usr/sbin/kworker, /usr/lib/librctl.so, /etc/kworker.cfg и /etc/init.d/skworker, а также контролировать исходящие соединения на порты 7000, 7001 и 10000 и входящий UDP-трафик на порт 9992.

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