Исследование безопасности IP-камеры Grandstream GXV3611_HD

Автор: boredhackerblog

Введение

Около года назад в моем распоряжении оказалась IP-камера Grandstream GXV3611_HD, у которой были проблемы с Power over Ethernet (PoE), технологией, позволяющей передавать удаленному устройству, наряду с данными, электрическую энергию. Я решил попробовать устранить этот недочет. Поскольку я не настолько хорошо разбираюсь в электронных схемах, мне пришлось посмотреть в блоге EEVblog множество видео по теме ремонта и устранения проблем у IP-камер. В конечно итоге, проблему решить не удалось, но зато получилось найти уязвимость, связанную с sql-инъекцией, и недокументированную команду, позволяющую запустить службу telnet и удаленно залогиниться с правами суперпользователя.

Аппаратная часть

Камера разобрана, а на рисунке ниже показано 10x2 пинов. Я предполагал, что эти контакты предназначались для отладки и были последовательными.

Рисунок 1: Внутреннее устройство IP-камеры

Я подключил свой мультиметр ко всем пинам, что выяснить, присутствует ли где-то напряжение более 5 вольт, поскольку мой логический анализатор Saleae может оперировать с напряжениями не выше этого значения. На контактах не было напряжения более 5 вольт, и я решил подключить логический анализатор к случайным пинам.

Рисунок 2: Подключение логического анализатора

После включения камеры я заметил появление данных на одном из каналов и предположил, что этот разъем – последовательный.

Рисунок 3: Информация на одном из каналов, отображаемая на экране логического анализатора

Коммуникация с камерой и получение шелла

Я подсоединил последовательный адаптер (FTDI) и подключился к камере при помощи терминала Putty. Скорость в бодах определялась на основе выходного сигнала на логическом анализаторе и была примерно 115200 бод, что является одним из стандартных значений.

Рисунок 4: Предварительная настройка терминала Putty

Я подключился к пину TX и смог получить данные с камеры в терминале.

Рисунок 5: Процесс загрузки IP-камеры

Я выбрал пин, находящийся над TX, чтобы убедиться, сможет ли этот контакт принимать информацию. Так и оказалось. Единственный пригодный способ для нахождения пина RX, который я знаю, - отслеживание дорожек на плате.

Рисунок 6: Подключение к пину RX

Я перезагрузил камеру и остановил автозагрузку.

Рисунок 7: Остановленный процесс автозагрузки

В камере был загрузчик U-Boot, используемый во многих подобных устройствах.

Я посмотрел видео под названием «Hacking 20 devices in 45 minutes» с конференции Defcon, где рассказывалось о получения шелла при помощи изменения опции init в U-Boot, и поступил схожим образом.

Команда printenv выводит все текущие настройки загрузки.

Рисунок 8: Текущие настройки загрузки

Команда setenv позволяет изменять значение опций загрузки. Я установил init=/bin/sh, чтобы получить доступ к шеллу.

Рисунок 9: Изменение настроек загрузки

Команда bootm используется для загрузки из памяти. Адрес берется из выходных данных команды printenv.

Рисунок 10: Возобновление загрузки после изменения настроек

Камера загрузилась, и я получил доступ к шеллу busybox:

Повторное получение шелла

Я начал просматривать файловую систему и заметил пустые папки. Подобное случилось потому, что я модифицировать процесс загрузки.

Рисунок 11: Просмотр содержимого некоторых папок

Я снова перезагрузил камеру и позволил устройству загрузиться в обычном режиме. После загрузки мне было предложено ввести логин и пароль.

Рисунок 12: Перезагрузка камеры в обычном режиме

Поскольку логина я не знал, то перезагрузил камеру и снова изменил init на /bin/sh, а затем выгрузил хеши.

Рисунок 13: Содержимое файла passwd

Пароль оказался пустым.

Рисунок 14: Поиск паролей к найденным хешам

Я загрузил камеру в обычном режиме и залогинился. Теперь я мог просматривать содержимое папок, которые ранее были пустыми.

Рисунок 15: Содержимое некоторых папок после ввода корректного логина/пароля

Поиск уязвимостей

После получения последовательного шелла и доступа к файловой системе я начал поиск уязвимостей, связанных с удаленным доступом, посредством исследования процессов, запущенных на устройстве.

Рисунок 16: Перечень процессов, запущенных на устройстве

В перечне на рисунке выше отмечены запущенные процессы webs и cli. Webs – веб-сервер, cli – сервер, связанный с настройкой telnet (telnet configuration server).

Было решено проанализировать оба этих процесса в IDA.

Я начал с cli поскольку этот процесс по объему оказался сильно меньше, чем webs. После подключения к серверу telnet и авторизации, нам становится доступен перечень команд.

Рисунок 17: Перечень команд, доступных в telnet

Я загрузил бинарник в IDA и стал искать строку «Username:»

Рисунок 18: Результаты поиска по строке «Username:»

Во время просмотра дизассемблированной версии я нашел sql-выражения. Я посмотрел в окно со строками и функциями и обнаружил, что программа использует sqlite.

Рисунок 19: Окна со строками и функциями

Я скопировал файлы cli, webs и system.db на свой компьютер. System.db представляет собой базу данных в sqlite, в которой есть таблица user с именами пользователей, паролей, привилегий и статусами учетных записей.

Рисунок 20: Содержимое таблицы user

На рисунке ниже показана часть дизассемблированного кода, имеющая отношения к SQL-запросу для взаимодействия с таблицей user.

Рисунок 21: Часть кода, взаимодействующего с таблицей user

Часть кода, связанная с аутентификацией и подверженная sql-инъекции.

Рисунок 22: Уязвимость, связанная с sql-инъекцией

В обычном режиме запрос выполняется так:

На входе = Имя пользователя

Итоговый запрос = select * from users where name = ' Имя пользователя ';

Мы можем сделать так:

На входе = ';на собственный sql запрос;--

Итоговый запрос = select * from users where name = ''; на собственный sql запрос;--';

Я открыл базу данных system.db в SQLite Database Browser и опробовал некоторые выражения перед выполнением запросов непосредственно внутри камеры.

Первой моей мыслью было изменить пароль административного аккаунта.

Рисунок 23: Выполнение запроса на изменение пароля у пользователя admin

Трюк сработал.

Однако внутри камеры при выполнении запроса возникла ошибка.

Рисунок 24: Обрыв соединения после выполнение запроса

Соединение обрывалось, если в поле Username передавалось слишком много данных.

Я вернулся в SQLite Database Browser, и после некоторых экспериментов появился следующий запрос: '; update user set password='a';--

Рисунок 25: Результат выполнения обновленного запроса

Запрос, показанный выше, позволяет выставить пароль «a» всем пользователям таблицы user.

Сейчас я понимаю, что мог бы изменять поля privilege и disable, чтобы лучше замаскироваться. В таком случае я мог бы залогиниться при помощи анонимной учетной записи.

Получение удаленного шелла

Я продолжил исследование файла cli и заметил команду !#/, которая не присутствовала в справке, когда я вводил команду 'help'.

Рисунок 26: Недокументированная команда !#/

На рисунке ниже показано место, куда происходит переход:

Рисунок 27: Участок кода, выполняемый после команды !#/

Попросту говоря, происходит выполнение telnetd на порту 20000. После sql-инъекции и получения доступа к конфигурационному меню командной строки я могу выполнить команду !#/ и запустить telnetd. Далее я могу авторизироваться удаленно при помощи логина root и пустого пароля.

Рисунок 28: Удаленное подключение к камере

Ссылки

http://www.grandstream.com/products/ip-video-surveillance/hd-ip-cameras/product/gxv3611hd

https://www.youtube.com/user/EEVblog

Vulnerability Note: https://www.kb.cert.org/vuls/id/253708

CVE: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2866

https://www.saleae.com/

https://www.adafruit.com/products/284

https://www.youtube.com/watch?v=h5PRvBpLuJs

https://en.wikipedia.org/wiki/Das_U-Boot

http://www.denx.de/wiki/U-Boot/WebHome

http://www.denx.de/wiki/view/DULG/UBootCmdGroupEnvironment

http://sqlitebrowser.org/