Это отчет по недавнему бэкдору, обнаруженому в устройствах DVR / NVR, построенных на основе HiSilicon SoC . Описанная уязвимость позволяет злоумышленнику получить root shell access и полный контроль над устройством. Формат полного разглашения информации для данного отчета был выбран из-за отсутствия доверия к поставщику. Доказательство концептуального кода представлено ниже.
Предыдущая работа и исторический контекст
HiSilicon имеет большой опыт реализации бэкдора на своих устройствах.
В самых ранних известных версиях это был доступ через telnet со статическим паролем root, который можно восстановить из образа прошивки с (относительно) небольшими вычислительными усилиями. Эта уязвимость была освещена в предыдущей авторской статье (на русском языке) в 2013 году. В 2017 году Istvan Toth провел всесторонний анализ прошивки HiSilicon. Он также обнаружил уязвимость удаленного выполнения кода во встроенном веб-сервере и многие другие уязвимости. Стоит отметить, что разглашение было проигнорировано продавцом.
В более поздних версиях встроенных программ по умолчанию отключен доступ через telnet и порт отладки (9527/tcp). Вместо этого у них был открытый порт 9530/tcp, который использовался для принятия специальной команды для запуска демона telnet и включения доступа к оболочке со статическим паролем, который одинаков для всех устройств. Такой случай охватывался этими статьями:
-
Ссылка скрыта от гостей, 2017 (на китайском языке)
- Ты и есть большой брат, или попробуй себя в роли всевидящего ока , 2017 (на русском, от пользователя Habr CentALT )
По-видимому, все эти годы HiSilicon не желал или был неспособен предоставить адекватные исправления безопасности для того же самого бэкдора, который, кстати, был реализован намеренно.
Технические детали
Обсуждаемые устройства с DVR/NVR/IP-камерами работают под управлением Linux с минимальным набором утилит, предоставляемых
Ссылка скрыта от гостей
, основным видеоприложением Sofia и небольшим набором пользовательских вспомогательных утилит, отвечающих за поддержку работы устройства. Аппаратное обеспечение имеет процессор ARM и от десятков до сотен мегабайт оперативной памяти.Устройство с уязвимой микропрограммой имеет macGuarder или dvrHelper, запускает процесс и принимает подключения через порт TCP 9530. Код и строки журнала предполагают, что macGuarder раньше это был отдельным процессом, но позже его функции были объединены в dvrHelper процесс как отдельный поток.
Стоит отметить, что в более ранних версиях прошивки процесс dvrHelper компилировался в busybox как дополнительный апплет. Принимая во внимание, что busybox имеет лицензию GNU GPL, возможно, что нарушение лицензии имеет место, потому что программное обеспечение dvrHelper распространялось без исходного кода.
Успешный процесс активации бэкдора следующий:
- Клиент открывает соединение с портом TCP-порта 9530 устройства и отправляет строку OpenTelnet:OpenOnce с байтом, указывающим общую длину сообщения. Этот шаг последний для предыдущих версий бэкдора. Вероятно, telnetd уже был запущен, если после этого шага нет ответа.
- Сервер (устройство) содержит строку, в randNum:XXXXXXXX гду XXXXXXXX это 8-значное случайное десятичное число.
- Клиент использует свой предварительный общий ключ и создает ключ шифрования для объединения полученных случайных чисел и PSK.
- Клиент шифрует случайное число ключом шифрования и отправляет его после строки randNum. Целому сообщению предшествует байт, указывающий общую длину сообщения.
- Сервер загружает тот же предварительный общий ключ из файла /mnt/custom/TelnetOEMPasswd или использует ключ по умолчанию,а именно 2wj9fsa2 если файл отсутствует.
- Сервер выполняет шифрование случайного числа и проверяет, совпадает ли результат со строкой от клиента. В случае успеха сервер отправляет строку verify:OK или verify:ERROR.
- Клиент зашифровывает строку Telnet:OpenOnce, дополняет ее байтом, длиной CMD: строки и отправляет на сервер.
- Сервер извлекает и расшифровывает полученную команду. Если результат дешифрования равен строке, на которую Telnet:OpenOnce он отвечает Open:OK, включаетса отладочный порт 9527 и запускаетса демон telnet.
Весь процесс аутентификации может напоминать своего рода аутентификацию запроса-ответа HMAC, за исключением того, что вместо хеш-кода используется симметричный шифр. Этот конкретный симметричный шифр напоминает некоторую вариацию 3DES-EDE2 для ключей длиной более 8 байт и аналогичен простому DES для более коротких ключей.
Легко видеть, что всё, необходимое для успешной аутентификации, это знание PSK (которое является распространенным и может быть получено из прошивки в виде открытого текста) и реализация этого симметричного блочного шифра. Восстановление реализации этого симметричного шифра является наиболее трудным, но оно было достигнуто в ходе этого исследования. Разведка и испытания проводились с использованием этого набора инструментов:
- Ghidra 9.1.1 от NSA (
Ссылка скрыта от гостей) - набор для проверки двоичного исполняемого кода.
- QEMU (точнее, qemu-user в Debian chroot -
Ссылка скрыта от гостей) - программное обеспечение, позволяющее прозрачно выполнять двоичные файлы внешней архитектуры (ARM) на хосте.
- Общие утилиты GNU и набор инструментов.
| Авторизоваться | пароль |
|---|---|
| root | xmhdipc |
| root | klv123 |
| root | xc3511 |
| root | 123456 |
| root | jvbzd |
| root | hi3518 |
Эти пароли также могут быть восстановлены из встроенного программного обеспечения с помощью брутфорса хэша в /etc/passwdфайле. Современный GPGPU потребительского уровня с
Ссылка скрыта от гостей
способен найти pre-image хэша за считанные часы.Отладочный порт 9527 принимает тот же логин/пароль, что и веб-интерфейс, а также обеспечивает доступ к оболочке и функции для управления устройством. Говоря об учетных записях веб-интерфейса, злоумышленник может сбросить пароль или получить хеши паролей из /mnt/mtd/Config/Account*файлов. Хеш-функция была описана в предыдущем исследовании Istvan Toth .
Затронутые устройства
Предыдущее исследование показало хорошую коллекцию брендов: tothi/pwn-hisilicon-dvr . Есть десятки брендов и сотни моделей.
Автор этого отчета, опираясь на отчет с множеством случайных IP-адресов, оценивает общее количество уязвимых устройств, открытых через Интернет, где-то между сотнями тысяч и миллионами.
Вероятно, самый простой способ проверить, является ли ваше устройство уязвимым, - это код PoC, представленный ниже.
Тестирование уязвимости
Код PoC: Snawoot/hisilicon-dvr-telnet .
Сборка PoC-программы из исходного кода: запустить make в исходном каталоге.
Использование: ./hs-dvr-telnet HOST PSK
Наиболее распространенные PSK по умолчанию один: 2wj9fsa2.
Пример сеанса:
Код:
$ telnet 198.51.100.23
Попытка 198.51.100.23 ...
telnet: невозможно подключиться к удаленному хосту: соединение отклонено
$ ./hs-dvr-telnet 198.51.100.23 2wj9fsa2
Отправлено OpenTelnet: команда OpenOnce.
randNum: 46930886
challenge = 469308862wj9fsa2
проверить: OK
Открыть: OK
$ telnet 198.51.100.23
Попытка 198.51.100.23 ...
Подключена к 198.51.100.23.
Escape-символ '^]'.
LocalHost логин: root
Пароль:Устройство следует считать уязвимым, если:
- Порт Telnet открывается после hs-dvr-telnetзапуска.
- Устройство отвечает на hs-dvr-telnetзапрос на запрос. Даже если проверка не удалась из-за неправильного PSK, существует правильный PSK, извлекаемый из прошивки.
- hs-dvr-telnet застревает в ожидании ответа, но порт telnet открывается (это произойдет с более старыми версиями прошивки, которые требуют только OpenTelnet:OpenOnce команды).
Однако, если замена невозможна, владельцы устройств должны полностью ограничить сетевой доступ к этим устройствам доверенным пользователям. Порты, участвующие в этой уязвимости: 23/tcp, 9530/tcp, 9527/tcp, но более ранние исследования показывают, что нет уверенности в том, что реализация других служб является надежной и не содержит уязвимостей RCE .
Не охваченное этим исследованием
Анализ кода показал, что процедура аутентификации на порте 9530 расшифровывает полезную нагрузку «CMD» произвольного размера (до размера буфера, считываемого из сокета за раз) в буфер на стеке с фиксированным размером 32 байта. Целевое использование этого переполнения требует знания PSK, поэтому более практичным является переход к обычному способу получения доступа. С другой стороны, мусор, отправленный с помощью команды CMD, может вызвать повреждение стека и сбой демона dvrHelper. Возможные последствия этого (потенциального) сбоя не были изучены, поскольку функциональность бэкдора macGuarder/dvrHelper выглядит строго превосходящей и простой.
Istvan Toth, автор предыдущего исследования по этому вопросу, представил свою собственную реализацию программы PoC:tothi/hs-dvr-telnet Данная реализация написана в чистом коде Python и реализует симметричный шифр более понятным способом. Также в нем описаны различия между вариантом шифра 3DES, используемым HiSilicon для аутентификации в бэкдоре, и оригинальным шифром 3DES. Эти различия могут быть выражены этим git commit: add support for slightly modified (big endian) HiSilicon Firmware 3DE… · tothi/pyDes@7a26fe0.
Другие исследователи и пользователи habr указали, что такая уязвимость ограничена устройствами на основе программного обеспечения Xiongmai (Hangzhou Xiongmai Technology Co, XMtech), включая продукты других поставщиков, которые поставляются продукты на основе такого программного обеспечения. На данный момент HiSilicon не может нести ответственность за бэкдор в двоичном файле dvrHelper/macGuarder.
Источник:Full disclosure: 0day vulnerability (backdoor) in firmware for HiSilicon-based DVRs, NVRs and IP cameras
