ловим китайских шпионов 🕵

Posted: 2019-02-16 in IT, Security
Метки:,

Заметка будет про китайское железо с бэкдорами и сетевую магию для нейтрализации подобной муйни.

Ранее я уже писал про китайские камеры видеонаблюдения, и насколько охреневшими их разработчики бывают. Поскольку камеры и cctv-сервисы в последнее время стали вполне доступны, многие люди стали применять cctv для охраны квартир, дач и прочего имущества достаточно широко.
Камера при этом часто ставится во внутренней сети, возможно за роутером типа такого.

В случае, если решение использует коннект сервера к камере — то мы делаем просто проброс порта RTSP. Очень желательно прямо в правилах проброса ограничить диапазон Source-IP, поскольку в реализациях rtsp-сервера на камере тоже могут быть как уязвимости, так и откровенные бэкдоры.
В случае облачного решения, когда камера сама коннектиться к серверу, никакие внешние порты открывать не требуется.

Однако довольно многие китайские девайсы, а особенно камеры/DVR/прочий IoT, помимо сервера видеонаблюдения также могут отстукиваться своим разработчикам на левые сервера.

Так, изучаемая мной камера от BSP Security (переименованный хихиквижен) периодически пыталась зарезолвить адрес lbs1.goolink.org и достучаться до адресов 101.200.83.161 и 203.195.157.36, хотя всякие облачные сервисы в веб-морде камеры были выключены.

гугель находит буквально пару заметок, где эти адреса упомянуты в комментариях:

https://dshield.org/forums/diary/IoT+The+Rise+of+the+Machines+Guest+Diary/19173/
https://thecomputerperson.wordpress.com/2015/05/03/compromised-or-suspicious-swann-dvr-traffic/

Сами разработчики могут вам сколько угодно клясться и божиться, что это всё для «анализа удовлетворенности пользователей», «защиты от краж», «планирования разработки новых сервисов» — верить им не следует совершенно. Исходники они не выдают, и всячески препятствуют изучению своих прошивок, ссылаясь на интеллектуальную собственность копипаст говнокода друг у друга.

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

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

Конечно, лучше использовать железо, не замеченное в подобной хуйне, но это не всегда возможно — куча производителей часто просто перемаркировывают тот же хиквижен (иногда следы хика найти бывает непросто), могут быть ценовые вопросы или уже установленное ранее железо, менять которое несподручно. В любом случае, стоит предотвратить возможные хождения такого железа «на сторону».

Сперва заходим по SSH на наш роутер — для этого в настройках включаем протокол SSH. Втыкаем флешку в роутер, монтируем, и пробуем с помощью такого скрипта получить дамп траффика выбранного устройства (вместо /tmp для крупного дампа надо указать точку монтирования съёмного диска):

#!/bin/sh

iface='br0';
cdate=`date "+%Y-%m-%d_%T"`;
mac='00:11:22:33:44:55';

tcpdump -i $iface -s 65000 -tttt -w "/tmp/$iface-$cdate---$mac.pcap" ether host $mac

Пишем какое-то время, стопаем по Ctrl-C, выкачиваем дамп траффика и смотрим его на предмет скверны. Некоторые камеры могут отстукиваться каждую минуту на левый китайский сервер.

Теперь посмотрим правила файервола такими командами:

iptables-save
iptables --list -vn
iptables --list -vn -t nat

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

Так что будем добавлять свои правила сторонним скриптом, размещённым на флешке. Если что-то пойдёт не так и мы запорем доступы — просто ребутим роутер с вытащенной флешкой и получаем оригинальный конфиг файервола от производителя прошивки.

Сперва изучим цепочку FORWARD в таблице filter:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC {printer mac}
    0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            MAC {switch mac}
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            224.0.0.0/4         
 112K   45M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 other2wan  all  --  !br0   vlan2   0.0.0.0/0            0.0.0.0/0           
   38  1976 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
  325 16600 SECURITY   all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           
 6610  406K NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  325 16600 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
 4866  304K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
 4866  304K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
                 

Нам интересна строчка с направлением траффика в цепочку NSFW — к этому моменту уже дропнут возможный внешний траффик сетевых принтеров, разрешены ранее установленные сессии, разрешено прохождение траффика в LAN-сегменте через мост br0, применены правила фильтрации wan-траффика. Вероятность что-то действительно серьёзно сломать минимальна.

Манипуляции напрямую цепочкой FORWARD тоже могут быть более сложны и опасны — логика правил может поменяться в новых версиях прошивки, да и потребуется при вставке своих правил «прицеливаться», вставляя свои команды точно в нужных позициях, а удаление своих правил из FORWARD также потребует лишнего скриптинга.

Цепочка же NSFW нам подходит идеально — там по умолчанию вообще нет никаких правил, и через неё проходят именно новые исходящие транзитные соединения. Её можно просто очистить, да и правила можно писать в неё прямо подряд.

Напишем такой скрипт, и сохраним его на флешке (не в /jffs !!), не забываем поставить ему chmod +x :

# cat /mnt/usbflash/ban_some_network.sh
#!/bin/sh

ipt=/usr/sbin/iptables

# Camera-1 to 43.21.10.10 cctv-server;
$ipt -A NSFW -s 192.168.0.11 -d 43.21.10.10 -j ACCEPT
$ipt -A NSFW -s 192.168.0.11 -j DROP

# Cisco Voip to sip-servers area 12.34.56.0..127 subnet
$ipt -A NSFW -s 192.168.0.16 -d 12.34.56.0/25 -j ACCEPT
$ipt -A NSFW -s 192.168.0.16 -j DROP

Теперь пропишем его старт в конец скрипта /jffs/scripts/post-mount — это позволит применять наши правила файервола сразу после монтирования флешки и легко их отменить, если мы что-то накосячим. Делаем контрольный ребут, и видим наши правила:

Chain NSFW (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    2   152 ACCEPT     all  --  *      *       192.168.0.11         43.21.10.10       
 1415 84900 DROP       all  --  *      *       192.168.0.11         0.0.0.0/0           
    2   152 ACCEPT     all  --  *      *       192.168.0.16         12.34.56.0/25       
    0     0 DROP       all  --  *      *       192.168.0.16         0.0.0.0/0   

Видим, как файервол дропает левый траффик китайской камеры во второй строчке (1415 пакетов, 84900 байт), для сравнения — цисковский телефон при этом не шалит, в четвертой строчке нули в счётчиках. Проверяем, что камера при этом успешно шлёт поток на видеосервер.

Если всё хорошо — надо добавить/перенести запуск нашего скрипта в файл /jffs/scripts/firewall-start — это позволит восстанавливать наши правила не только при первой загрузке, но и при манипуляциях в веб-интерфейсе с тем же порт-форвардом или любыми настройками, затграгивающими файервол.

Можно добавить аналогичные правила для IP-адреса какой-нибудь виртуальной машины и проверить, что это действительно хорошо работает.

Если же вы опасаетесь, что китайские камеры начнут менять IP и MAC-адреса — то на текущий момент за ними такого не замечено (это легко палится прямо в веб-морду роутера), да и на этот случай у нас заготовлен ip dhcp / arp inspection, IP-MAC-Port-Binding и прочие хорошие вещи.

В итоге мы для двух устройств — камеры видеонаблюдения и сип-телефона разрешили доступ по белому списку только к тем серверам, которые им реально нужны, прикрыв многие возможности организации бэк-коннектов и утечек данных. Конечно, такая изоляция не идеальна — есть ещё всякое DNS-/ICMP-туннелирование и прочие извраты, но это уже более сложные атаки, да и против них можно найти меры противодействия.

Важное дополнение: роутер с включенным CTF+FA (Cut Throw Forwarding + Flow Acceleration) обрабатывает уже одобренный траффик аппаратно — из-за этого уже пропущенный траффик может не попадать в tcpdump. При анализе траффика помимо tcpdump-а на роутере и таблицы текущих соединений (Системный журнал — подключения) имеет смысл посмотреть сырой траффик от устройства как он есть — для этого используем тестовый ноутбук и подключение камеры через управляемый свитч, умеющий Port Mirroring.

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

Держите свой файервол наготове.

Враг не пройдёт. :]

- комментарии
  1. […] через ловим китайских шпионов — Amin ‘s Blog […]

  2. добрый день при переходе на на любую страницу на вашем сайте из браузера хром у меня появляется ошибка, а если зайти с макстона то работает, из-за так происходит?

  3. Amin:

    Я бы проверил вашу ОС и браузерные плагины на предмет отсутствия скверны.
    У меня сайт работает в консольном Links без JS, чистый WP обычно не создает проблем..