«Я хотел её только настроить…» Как я искал уязвимости в IP-камерах и нашел их

Содержание статьи

• Собираем информацию
• Исследуем строки
• Анализируем трафик
• Возможности удаленного доступа
• Баги в реализации FTP-сервера
• И что с этим делать?
• Минимизация рисков
• Outro

Новостями про уязвимости в тех или иных моделях IP-камер уже сложно кого-то удивить. Регулярно появляется информация о разнообразных багах и недокументированных учетных записях (бэкдорах). Несмотря на это, многие производители до сих пор относятся к безопасности своей продукции кое-как. Об одном из таких случаев и хочу рассказать.

WARNING

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

Начну с предыстории. Я и мой коллега внедряли распределенную систему видеонаблюдения на несколько сотен IP-каналов. Модель камер выбрали быстро — сыграла роль привлекательная цена и приличные ТТХ. Экземпляры, взятые на тестирование, показали себя нормально, работали стабильно, без нареканий.

Поскольку камер мы планировали покупать много, то потребовалось автоматизировать их настройку. Заставить нормально работать штатную утилиту (IPCManager) я так и не смог, поэтому пришлось изобретать свой велосипед.

По задумке управление камерой будет происходить через запросы по HTTP на 80-й порт скриптом на Python с использованием библиотеки requests.

Процесс должен сводиться к простому алгоритму:

1. Запустил скрипт.
2. Достал из коробки камеру.
3. Подключил.
4. Получил оповещение о завершении перенастройки.
5. Отключил.
6. Подключил следующую.
7. Далее по циклу.

В качестве оповещения об успешной перенастройке логично было бы использовать звуковой сигнал из динамика камеры. Однако заставить камеру пищать при помощи запроса по HTTP так и не получилось.

Собираем информацию

Я начал поиски альтернативного способа подчинить себе динамик камеры — просканировал камеры при помощи Nmap.

С портами 80 (HTTP) и 554 (RTSP) все понятно, 1935-й порт вроде как используется приложением Flash, через которое браузер показывает видео с камеры, а вот что висит на остальных портах — пока загадка.

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

Почти все манипуляции я проводил в Ubuntu desktop 16.04. Для начала я скачал прошивку камеры и начал ее изучать. Нужно заметить, что прошивки для исследуемой камеры в зависимости от версии могут иметь разное содержимое. Вот несколько примеров различий.

1. Файлы .rootfs и .fm. Первый содержит корневую файловую систему, включая искомый etcpasswd с паролем на Telnet, второй — включает «брендированный обвес» — веб-интерфейс с логотипом и другими индивидуальными особенностями конкретного продавца (об этом позже).
2. Файл .fm, который корневую ФС не включает.
3. Файл .fm, внутри которого сразу корневая ФС и «обвес».

Далее попробовал определить тип файла командой file.

$ file -b -i IPCAM_BV_EW_11_E_V2.37.170715_Airlink.fm application/octet-stream; charset=binary 

Для дальнейших манипуляций с файлами прошивки понадобится утилита binwalk. Забегая вперед, отмечу еще, что обязательно наличие модуля jefferson — для распаковки JFFS2.

WWW

На странице проекта в GitHub есть вся необходимая информация по установке.

Я заглянул внутрь бинарника при помощи binwalk.

JFFS2 — файловая система, которую часто используют на флеш-памяти.
Squashfs — специализированная сжатая файловая система, часто применяемая в роутерах, IP-камерах и прочих IoT-устройствах.

В интернете можно найти несколько способов монтирования JFFS2 и Squashfs, но проще всего распаковать их через тот же binwalk.

binwalk -Me  IPCAM_BV_EW_11_E_V2.37.170715_Airlink.fm binwalk -Me  IPCAM_BV_EW_11_V2.37.170715.rootfs  

где

• -e включает режим извлечения;
• -M пытается распаковывать вложенные элементы.

В итоге получилось два каталога с содержимым прошивки. В каталоге _IPCAM_BV_EW_11_V2.37.170715.rootfs.extracted можно найти файл etc/passwd, внутри которого находится хеш типа MD5 (Unix). Брутанув этот хеш с помощью John или hashcat, можно получить искомый пароль для подключения по Telnet.

Вот пример запуска брута через hashcat:

hashcat64 -m 500 -a 0 --force usrhashes.txt dictworst_passwds.dict -o usrrecovered.txt 

Здесь

• -m 500 — тип хеша, который будем брутить, 500 — md5crypt / MD5(unix);
• -a 0 — режим работы, 0 — атака по словарю;
• --force — игнорировать предупреждения;
• usrhashes.txt — файл, в который я положил взламываемый хеш;
• dictworst_passwds.dict — словарь;
• -o usrrecovered.txt — файл, в который будет записан восстановленный пароль.

Hashcat отработал очень быстро, так как пароль тривиален и есть в популярных словарях. Учетки на Telnet получены, но моя история только начинается…

Продолжение статьи доступно только подписчикам

Cтатьи из последних выпусков журнала можно покупать отдельно только через два месяца после публикации. Чтобы читать эту статью, необходимо купить подписку.

Подпишись на журнал «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?

Источник