Некоторое время назад получили IP-камеру от одного из наших партнеров с комментарием – “а можете посмотреть, что с камерой – что-то не то”. Уже с самого начала по настолько подробному описанию мы поняли, что будет непросто. Ну да ладно, посмотрим.

Запросили IP-адрес камеры, но получили в ответ – “я не знаю”. Да, часто бывает и так. К счастью, производитель разработал механизм поиска камеры в броадкаст-сегменте, такая функциональность встроена в их VMS (video management system). Построено на протоколе MDNS – при помощи отправки мультикаст запросов и ответов.

Запустили поиск, все сработало, камера нашлась в сети с айпи 10.22.107.41. Кстати, этот адрес был factory default, то есть, клиент не перенастраивал его вообще с момента получения камеры.

В общем, уже что-то. Пробуем зайти на веб-интерфейс. Открывается, но – “неправильные имя пользователя или пароль”. Значит, как минимум, хоть это поменяли. Ладно. Запрашиваем у клиента имя и пароль, получаем в ответ… догадались? Точно! “Я не знаю, кто-то другой её настраивал, я спрошу”. И через пару дней: “Нет, спросил, но никто не знает”.

На этом месте стоит отметить, что  камера немецая, не Китай. Политика по паролям очень строгая – можно сбросить камеру в завод, слетят все настройки, но пароль останется. Для сброса пароля её надо отправлять на завод-производитель, камеру проверят по базам – не украдена ли, кто импортер и т.д., потом, если всё хорошо, сбросят пароль, но за это также попросят 100 Евро. Если добавить отправку туда-назад, то становится понятно, почему желательно пароль всё-таки вспомнить.

Через пару дней от нашего клиента приходит ещё одно письмо: “Если вы нам на неё пробросите порт, мы попробуем зайти и перебрать наши обычные пароли, вдруг какой-то из них подойдет”.

Хорошо, наша задача – пробросить порт в NAT на роутере. Но есть один момент – мы без понятия, какой шлюз прописан на камере (зайти-то не можем) и прописан ли вообще. Если не прописан – ничего не выйдет, камера будет отвечать в локальном сегменте, а через роутер не проползет.  Можно, конечно, спросить у клиента шлюз. Думаю, ответ вы уже знаете.. Да, именно.

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

Лучше всего после того, как мы запускаем захват, перегрузить камеру. Лучше –  потому, что некоторые запросы в сеть могут быть однократными, ну или после долговременной работы таймауты могут достигнуть значительных величин, и, таким образом, мы может пропустить важный пакет (не дождаться, например).

Дамп получился следующий:

 

Цифрами я отметил стоящие внимания пакеты:

1.  MDNS-discovery выглядит именно так.

2. Интересно, камера делает то же самое, но на IPv6. Как минимум, это значит, что клиент не отключил IPv6 в настройках (а скорее, не догадывался, что этот IPv6 там вообще есть. А может, и не догадывался, что это такое вообще). IPv6 – это зацепка на будущее (вспомним SLAAC, мы могли бы навязать камере свой IPv6 шлюз). Но, конечно, связности с сетью клиента через IPv6 у нас нет.. Нашим провайдерам ещё до этого далеко.

3. Да, как раз об том я говорил в п.2. Камера спрашивает, есть ли IPv6 роутер в сегменте (router solicitation)? Ответа нет, т.к. IPv6-роутера в нашем сегменте нет. Но роутер под моим контролем, можно поднять. Как возможный, но трудоемкий вариант, оставим на потом.

4. Камера покидает какую-то мультикастовую группу (протокол IGMP). Понятия не имею, что это, но явно для нас не очень полезно.

5. Одинокий ARP-запрос. А вот это уже очень интересно. Камера пытается найти, у кого IP 10.255.255.254? За этим есть какой-то смысл. Ответа на ARP-запрос не видно, что естественно,ведь у нас в сети нет такого жителя. Но сам факт запроса говорит о том, что кто-то этот адрес в камеру вписал (или он был hard-coded, но адрес не из группы “well-known”). Это очень хорошая зацепка для нас. Может быть, это…  и есть прописанный шлюз? Кстати, обратите внимание, сам факт такого запроса говорит о том, что на камере установлена маска подсети /8 (оптимизация и грамотное построение сети зашкаливает).

6.  А это какой-то одинокий UDP броадкаст. Куда он и зачем – я не понял, видимо, какой-то проприетарный протокол. В нагрузке тоже ничего интересного не обнаружил.

Исходя из увиденного, пункт 5 – самая интересная находка. Стоит начать с него.

Что дальше? Я просто настроил второй айпи на внутреннем интерфейсе роутера. Присвоил ему 10.255.255.254, поднял NAT и пробросил внешний рандомный порт (пусть будет 48930) на входящий порт 80 камеры. Попробовал постучать в него – и камера увиделась! Значит, все сработало. Мы открыли внешний доступ к камере, вообще не имея доступа на веб-интерфейс, не имея возможности посмотреть настойки.

Затраченное на решение задачи время – плюс-минус 5 минут (я, естественно, не имею в виду всю предшествующую переписку, но она никак не относится к Wireshark).

..Если вам любопытно, чем же все-таки закончилась эта история – ответ прост. Клиент так и не смог вспомнить, какой пароль установил на камеру, ни одна из его попыток подбора не оказалась успешной. Но на этом этапе я с удовольствием передал все организационные вопросы коллегам.