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

Автор: Jelmer Tiete

В этой статье будет рассказано о том, как я анализировал трафик дешевой поворотной 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-видеопоток доступен по адресу

http://[IP]/videostream.cgi?usr=[USERNAME]&pwd=[PASSWORD].

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

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

$ nmap [IP]

Starting Nmap 6.40-2 ( http://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:      

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install tcpdump-mini

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

ssh -x root@192.168.1.1 tcpdump 'not tcp port 22' -i br-lan -s0 -U -w - | wireshark -k -i -

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

ssh -x root@192.168.1.1 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-запрос:

http://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 изменен):

http://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-запросом http://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 (root@test) (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, получим следующий список:

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

Выгружаем все строки процесса ipcamn:

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

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

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