tothi/pwn-hisilicon-dvrЭксплойт уровня proof-of-concept и раскрытие уязвимостей для DVR/NVR-устройств HiSilicon hi3520d. Демонстрирует RCE через веб-интерфейс, учётные данные бэкдора и анализ переполнения буфера.
= Взлом DVR HiSilicon Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] В этом отчёте раскрываются серьёзные уязвимости (с кодом доказательства концепции (PoC)) устройств DVR/NVR, построенных на HiSilicon hi3520d и аналогичных системах на кристалле (SoC). Эксплуатация уязвимостей приводит к несанкционированному удалённому выполнению кода (RCE) только через веб-интерфейс, что приводит к полному захвату взломанного устройства. Из-за отсутствия обновлённых прошивок использование этих устройств не рекомендуется. Связались с производителем до декабря 2016 г., но ответа до сих пор нет. Дата публикации раскрытия — февраль 2017 г.
== предисловие
Пару лет назад я купил дешёвое китайское устройство DVR на eBay. Загрузочный логотип устройства гласит: «SECULINK - Security Monitoring». Будучи энтузиастом ИТ-безопасности, я решил внимательнее изучить устройство, чтобы увидеть, насколько «безопасен» этот сервис видеонаблюдения. Гугля по этой теме, я нашёл некоторые интересные материалы, но копнул глубже и обнаружил гораздо более интересные и серьёзные проблемы (0-day) об этом устройстве.
Давайте рассмотрим весь процесс взлома с самого начала. (Новые собственные достижения будут отмечены наряду со старыми, известными.)
== изучаем DVR
Сначала нам следует изучить официальный пользовательский интерфейс, затем копнуть глубже, возможно, попытаться получить прошивку. Шансы найти уязвимости возрастают вместе с прошивкой.
=== DVR с первого взгляда
Устройство DVR, предназначенное для тестирования, имеет бренд «Seculink».
image::./seculink_device.png[Устройство DVR Seculink]
Доступные физические интерфейсы:
Официальные пользовательские интерфейсы:
Непосредственно доступный интерфейс настройки ограничен аутентификацией пользователя (имя пользователя, пароль). Суперпользователь по умолчанию — 'admin', пароль по умолчанию пустой.
После установки надёжного пароля пользователь может чувствовать себя в безопасности, что его/её видео с камер не доступно другим. Люди часто пробрасывают веб-порт (tcp/80) устройства DVR из своей защищённой локальной сети в WAN, чтобы получить доступ к потокам DVR извне (это можно проверить, например, подходящим поиском в Shodan ;) ).
=== получение прошивки
Существует много способов получить прошивку:
Хотя последний (загрузка) метод здесь работает и является самым простым, давайте попробуем первый, потому что он также даёт другую информацию об устройстве.
=== сканирование служб
Давайте выполним полное сканирование портов на DVR. Обратите внимание, что SYN-сканирование (по умолчанию, если запущено от root) очень медленное из-за отбрасываемых пакетов, но полное TCP-сканирование с установкой соединения завершается за пару минут.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Обобщая и проводя ручное тестирование:
Обратите внимание, что для открытия rtsp-потока также требуются учётные данные.
Здесь следует отметить, что устройство, вероятно, является некоторой Linux-подобной системой.
Подключение к 9527/tcp (с помощью чистого netcat) показывает консоль приложения
с журналируемыми сообщениями и приглашением входа. Вход с любыми
определёнными учётными данными приложения работает. Команда help после
приглашения даёт краткое описание команд консоли. Команда
shell кажется наиболее интересной. Да, она даёт root-шелл на
устройстве. ;)
Обратите внимание, что это, очевидно, серьёзная проблема безопасности, потому что любой (низкопривилегированный) пользователь приложения не должен автоматически получать root-шелл на устройстве.
=== root-шелл
Исследование устройства в root-шелле (например, с помощью dmesg) делает
очевидным, что DVR работает под управлением ядра Linux (версии 3.0.8), у него
процессор ARMv7, модель SoC — hi3520d.
Из списка запущенных процессов (ps) ясно, что приложением DVR
является /var/Sofia, который, помимо указанных выше TCP-портов, обнаруженных
nmap, также прослушивает 34568/udp и 34569/udp
(netstat -nlup).
Из списка смонтированных дисков (команда mount) ясно, что
образ прошивки находится в устройствах /dev/mtdblockX (где X=0,1,2,3,4,5).
Прошивка небольшая и, следовательно, ограниченная, поэтому нам придётся проявить изобретательность, если мы хотим копировать файлы на устройство или с него. К счастью, NFS поддерживается, поэтому настройка NFS-сервера на нашем рабочем компьютере и монтирование его с DVR решает проблему:
Теперь получить прошивку несложно:
Мы можем получить и файлы (не только сырые образы):
=== telnet-интерфейс
Для доступа к устройству через telnet-интерфейс (порт 23/tcp) нам
могут понадобиться учётные данные ОС. Заглянув в /etc/passwd, мы видим
хэш пароля для пользователя root:
Обратите внимание, что кроме root других пользователей нет, всё работает с полными привилегиями. (Поэтому если кто-то каким-либо образом проникнет на устройство, препятствий нет — атакующий немедленно получает полную власть.)
Предполагая шестисимвольный буквенно-цифровой пароль (в нижнем регистре), hashcat быстро взламывает указанный выше слабый DES-хэш:
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
