It is currently 20-10-2017 01:06

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

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

by sigismund » 2016-07-26 00:37:16


В этой статье будет рассказано о том, как я анализировал трафик дешевой поворотной IP-камеры, а затем подключился к последовательной консоли на плате, получил пароль суперпользователя и залогинился при помощи telnet через беспроводной интерфейс


В этой статье будет рассказано о том, как я анализировал трафик дешевой поворотной IP-камеры, а затем подключился к последовательной консоли на плате, получил пароль суперпользователя и залогинился при помощи telnet через беспроводной интерфейс. Моей главной задачей было поиск уязвимостей и улучшение безопасности очень дешевых IoT-устройств (Internet of Things; Интернет вещей).

Подопытным устройством будет модель Logilink WC0030A в миру известная также как Apexis APM-JP8015-WS.


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


За последние пару лет IP-камеры сильно подешевели. Из-за массового производства цены на хорошие сенсоры изображений и функциональные платы упали значительно. Нашу подопытную IP-камеру, на момент написания статьи, можно было купить за 43 евро. Схожие модели/копии и клоны из Китая продаются еще дешевле.

С одной стороны, дешевое устройство – это просто здорово, если вы не хотите сильно раскошеливаться на систему оповещения или просто ради забавы хотите понаблюдать за соседями или животными. С другой стороны, дешевизна говорит о том, что вопросам безопасности разработчики не уделяли особого внимания (сколько заплатили, столько получили). Приложения/прошивки дырявые, функционал небогатый, а вопросы безопасности стоят на последнем месте.

Безопасность в дешевых IoT-устройствах становится одной из главных проблем. Производители не особо заботятся о персональных данных пользователей, использующих подобные продукты. А сами пользователи не имеют достаточных знаний, чтобы оценить безопасность или защитить свое устройство (в некоторых случаях главный совет – не использовать устройство вообще).

В качестве примера можно ввести следующий запрос в поисковик Shodan, который ищет IoT-устройства и вообще все, что не индексирует Google. Результаты запроса немного ошеломляют относительно того, какое количество небезопасных камер, к которым можно подключиться, находится в магазинах, гостиных, игровых площадках, парковках, кухнях, лестничных клетках, парках, фабриках, спальнях (o_O), аудиториях, отелях и даже погребальных конторах.

Прежде чем использовать вышеуказанную модель мне захотелось узнать объем «утекающей» информации и насколько сложно подключиться со стороны для наблюдения за моей собакой.

В составе камеры Logilink WC0030A идет сенсор на 0.3 МП, проводной Ethernet-интерфейс, WiFi радио (проводной интерфейс и WiFi нельзя использовать одновременно), несколько инфракрасных датчиков и 2-сторонее аудио. Камера может поворачиваться/наклоняться и имеет систему оповещения. Короче говоря, стандартный набор.

Внутри камеры установлен веб-сервер и доступ можно получить через веб-интерфейс. Кроме того, камера совместима с большим количеством мобильных приложений, многие из которых «немножко» дырявые. В мануале упоминается две учетные записи (admin:000000 и admin:1234). Метод проб и ошибок в различных местах, где требуется авторизация, помог получить наилучшие результаты.


Рисунок 2: Веб-интерфейс IP-камеры Logilink


В веб-интерфейсе есть стандартные кнопки и разделы, а также указана версия прошивки и самого интерфейса (этот интерфейс «неродной»; на момент написания статьи я установил версию от компании Apexis). Кроме того, я не являюсь владельцем фиолетового дивана (отсутствует баланс белого). В настройках можно сконфигурировать DNS, но даже в случае настройки или отключения DNS, по-видимому, камера всегда соединяется со встроенным dns-сервером (oipcam.com). Полностью отключить соединение нет никакой возможности. По-видимому, прямой MJPEG-видеопоток доступен по адресу

Код:__tp://[IP]/videostream.cgi?usr=[USERNAME]&pwd=[PASSWORD].

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

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

Код:$ nmap [IP]

Starting Nmap 6.40-2 ( __tp://nmap.org )
Nmap scan report for [IP]
Host is up (0.012s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http

Nmap done: 1 IP address (1 host up) scanned in 3.10 seconds


То, что открыт 80 порт было ожидаемо. Присутствие telnet уже вызывает смешанные чувства. Пробуем подключиться при помощи стандартных паролей:

Код:$ telnet [IP]
Trying [IP]...
Connected to [IP].
Escape character is \'^]\'.

(none) login: admin
Password: 1234
Login incorrect
(none) login: admin
Password: 000000
Login incorrect
(none) login: Connection closed by foreign host.


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

Если нужно проанализировать входящий/исходящий трафик, Wireshark, вероятно, является наилучшим выбором. Естественно, мы не можем запустить эту утилиту прямо на камере, поэтому будем перехватывать пакеты через роутер, к которому подключено устройство. Я использую дешевую и функциональную модель Nexx WT3020 с дистрибутивом OpenWRT. Идеальная система для перехвата трафика подсоединенных хостов.
Мы будем подключаться к роутеру через SSH, использовать tcpdump для перехвата всех пакетов, которые затем будут перенаправляться в Wireshark.

Установить tcpdump-mini можно либо через LuCI (веб-интерфейс в openWRT) или через SSH:

Код:[email protected]:~# opkg update
[email protected]:~# opkg install tcpdump-mini


Далее подсоединяемся к роутеру и запускаем перехват пакетов на интерфейсе br-lan (за исключением порта SSH) и полученную информацию перенаправляем в Wireshark:

Код:ssh -x [email protected] tcpdump \'not tcp port 22\' -i br-lan -s0 -U -w - | wireshark -k -i -

Можно пойти другим путем и выгрузить все пакеты в .pcap файл, а потом провести анализ.

Код:ssh -x [email protected] tcpdump \'not tcp port 22\' -i br-lan -s0 -U -w - > dump_$(date +\'%T_%m-%d-%y\').pcap

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

Код:eth.src == 54:cd:ee:[MAC] || eth.dst == 54:cd:ee:[MAC]

Этот фильтр выдает все пакеты, проходящие через камеру. В качестве фильтра используется MAC адрес устройства:


Рисунок 3: Фильтрация пакетов, проходящих через камеру


Из рисунка выше видно, что вначале камера формирует стандартный DHCP-запрос после получения IP‑адреса от рутера. Далее камера отсылает DNS-запрос для хостов time.nuri.net и checkip.dyndns.org. Первый адрес является NTP-сервером (где-то в Китае), который, возможно, использовался для установки времени. Второй URL используется для получения внешнего IP-адреса камеры через dyndns.org.

Затем устройство продолжает создавать DNS-запрос для адреса oipcam.com и отсылает следующий HTTP-запрос:

Код:__tp://www.oipcam.com/vipddns/upgengxin.asp?username=o9428&userpwd=958&userdomain=o9428.oipcam.com&userport=80&mac=00-00-00-00-00-00

(В запросе я изменил имя пользователя/пароль и обнулил MAC-адрес). Хост oipcam.com присылает HTTP-пакет «200 OK» с содержимым «UP».
Затем формируется DNS-запрос для адреса www.apexisalarm.com со следующим HTTP-запросом (uid изменен):

Код:__tp://www.apexisalarm.com/apns.php?cmd=reg_server&uid=53XHWU68T345HGf571N0

В ответ приходит следующее: reg_server !!!!
Server device 53XHWU68T345HGf571N0 login.
Затем камера пингует роутер. Возможно для того, чтобы проверить, работает ли сеть.

Далее еще один DNS-запрос для адреса checkip.dyndns.org и еще два пинга роутера. Потом DNS-запрос для адреса www.3322.org с HTTP-запросом __tp://www.3322.org/dyndns/getip. Последнее нужно для выявления IP-адреса камеры.

Затем несколько DNS-запросов для адреса www.ip138.com, которые завершаются неудачно. В конце концов, камера зацикливается на пинге роутера.
В итоге мы нашли 2 внешние службы, используемые камерой и расположенные по адресам oipcam.com и apexisalarm.com. Другие запросы предназначены для настройки времени и выявления внешнего IP-адреса (здесь, естественно, также может быть утечка IP).
Попытка использовать учетные записи, предназначенные для внешних служб, при подключении к telnet успехом не увенчалась.
Далее открываем корпус камеры для того, чтобы выяснить, откуда берется тиканье!


Рисунок 4: Задняя стенка камеры


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


Рисунок 5: Обратная сторона платы


На обратной стороне платы нет ничего интересного. Кнопка сброса справа, пустая площадка, предназначенная для микросхемы, вместе с обвязкой из выводов слева и микрофон наверху.


Рисунок 6: Управляющая плата


Управляющая плата идет с маркировкой Ralink RT5350F и, скорее всего, представляет собой OEM модуль, вставленный в главную плату. Маркировка JP8015 обозначает номер модели камеры. Кроме того, мы видим, что перемещение камерой управляется двумя шаговыми двигателями, запитываемыми от батарейки в 5В и работающими на постоянном токе.

Чип довольно функционален и используется в некоторых небольших дешевых WiFi роутерах, на большинстве из которых запущен дистрибутив OpenWRT. Работает на базе Линукса на частоте 360 МГц, имеет 24 GPIO-пина, хранилище на 8 МБ и оперативную память на 32 МБ. Вероятно, этот чип имеет сильное сходство с моделью NixCore X1, но не полностью. И все же будем надеяться, что выходные пины главной подложки совпадают.

Изучив эту таблицу и документацию для X1, приходим к выводу, что мы можем получить доступ к последовательному терминалу на микросхемах RX2/TX2 через 39 и 40 пины. Если взглянуть на камеру, те два пина находятся в нашем модуле, но ни к чему не подсоединены. Хороший знак.
После подсоединения последовательного USB-конвертора, работающего от напряжения 3.3В, к модулю на скорости 57600 бод попадаем в нужное место!

Протокол загрузки:
U-Boot 1.1.3 (Nov 18 2012 - 20:35:15)

В процессе загрузки обнаруживается множество интересных вещей, но давайте сфокусируем внимание на подключении к камере через telnet. Выполняем простую команду:

Код:$ cat /etc/passwd
root:1naesbIMqm.cY:0:0:root:/:/bin/sh


В итоге обнаруживаем только одного суперпользователя с паролем 1naesbIMqm.cY. Естественно пароль зашифрован при помощи необратимого алгоритма DES.
Попробуем сделать брутфорс при помощи John the ripper:

Код:$ john passwd --show
root:123456:0:0:root:/:/bin/sh

1 password hash cracked, 0 left


Задача оказалась простой.
Пробуем подключиться к telnet:

Код:$ telnet 192.168.1.242
Trying 192.168.1.242...
Connected to 192.168.1.242.
Escape character is \'^]\'.

(none) login: root
Password: 123456


BusyBox v1.12.1 (2012-11-19 22:34:42 PST) built-in shell (ash)
Enter \'help\' for a list of built-in commands.

#


И снова попадаем в нужное место (во второй раз).

Код:# cat /proc/version
Linux version 2.6.21 ([email protected]) (gcc version 3.4.2) #136 Mon May 20 11:39:34 CST 2013
# cat /proc/cpuinfo
system type : Ralink SoC
processor : 0
cpu model : MIPS 24K V4.12
BogoMIPS : 239.61
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16 dsp
VCED exceptions : not available
VCEI exceptions : not available


Теперь можно начать исследование файловой системы. Вероятно, скрипт test.sh выполняет большую часть работы и запускает два главных процесса:

Код:...
videocatch>/dev/null 2>&1 &
ipcamn>/dev/null 2>&1 &
...


Если остановить один из этих процессов, произойдет остановка контрольного таймера, и система перезапустится.
Смотрим загруженные модули ядра:

Код:# lsmod
Module Size Used by Tainted: P
usbvideo 56752 1 - Live 0xc0116000
watchdog 2064 1 - Live 0xc012d000
gpio 3968 3 - Live 0xc012b000
i2s 10688 3 - Live 0xc0140000
i2c 2816 0 - Live 0xc008a000
rt2860v2_sta 1319712 1 - Live 0xc0265000 (P)


Для звука используется интерфейс I2S, usbvideo или UVC – для дешевой камеры Alcor Micro Corp USB (058f:3861). Интерфейс I2C, вероятно, используется для шаговых контроллеров, а модуль gpio – для входных/выходных выводов системы оповещения и светодиодного дисплея.

Если выгрузить все строки исполняемого файла videocatch, получим следующий список:
__tps://gist.githubusercontent.com/JelmerT/699a6897741d47a4fdda/raw/a5599868aef1cf7afaf2b9d49e22ad0661b3ec84/strings_videocatch

Из списка выше видно, что процесс инициализирует USB камеру и каким-то образом работает с видео.
Выгружаем все строки процесса ipcamn:

__tps://gist.githubusercontent.com/JelmerT/da0b5e2c242ba38f7ee7/raw/0e251c5a3022bc9f28fd8e47b5750487e3626f72/strings_ipcamn

По-видимому, процесс Ipcamn отвечает за все остальные функции и взаимодействие с внешними службами.

На данный момент мы знаем, к каким службам подключается камера и какие порты открыты. Мы могли бы детально проанализировать файл ipcamn, но имея в наличие учетную запись суперпользователя, я не хочу сейчас этим заниматься.

Моя текущая задача – заблокировать весь трафик, проходящий через камеру (как входящий, так и выходящий), на уровне роутера. Кроме того, я бы хотел сделать видео сервер на базе системы motionEyeOS или ZoneMinder, который будет записывать, хранить и транслировать потоковое видео.

Идеальное решение проблемы – сделать отдельную сборку OpenWrt и загрузить ее в камеру. Естественно, необходимо добиться работоспособности вебкамеры на базе USB и других устройств ввода/вывода. В этом случае мы получим полный контроль над камерой и всеми данными. Поскольку прошивки OpenWRT и DD-WRT могут трансформировать дешевые WiFi роутеры в полноценное сетевое оборудование, те же дистрибутивы для IP-камер могли бы трансформировать эти устройства в дешевые стабильные системы видеонаблюдения. Дистрибутивы можно было бы назвать, например, так: CamWrt или OpenCamWrt или OpenCam. Пока не уверен. Эта тема для будущего поста.
sigismund
moderators
Сообщений: 788
Депозит: 0 BTC

Rating: 5