Аудит 47 IoT-устройств в офисе: реверс прошивки ESP8266-розеток и сегментация VLAN

Однажды к нам обратилась торговая компания на 32 РМ из ЮВАО, которая занимается оптовой поставкой инструмента. Их финдиректор наткнулся на статью на Хабре про реверс ESPшных устройств и попросил нас разобраться: «У нас в офисе 14 умных розеток от непонятного бренда, посмотрите, точно ли они не передают наружу что-то лишнее?». Мы, конечно, согласились, и заодно решили сделать полный аудит всех IoT-устройств в офисе — а их оказалось 47! В итоге мы нашли C2-адрес, ведущий в Гонконг. Хочу рассказать вам всю эту историю, включая то, какой инструментарий мы использовали.

День 1: инвентаризация — что вообще есть в сети

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

Админ мне озвучил вот что: 32 ПК, 12 камер Hikvision, два NAS Synology, 8 принтеров Kyocera, 7 SIP-телефонов Yealink, MikroTik роутер, NVR-сервер и два WiFi-AP. Всего 65 устройств. Но я же знаю, как это бывает в жизни: в реальной сети всегда найдётся больше — кто-то принесёт что-то из дома, кто-то купит на маркетплейсе и просто воткнёт в розетку.

Дальше я взялся за сетевое сканирование, используя masscan и nmap. Мой первый шаг — быстрый проход по всему диапазону IP-адресов:

# masscan быстро находит живые хосты
masscan 10.10.10.0/24 -p1-65535 --rate=10000 -oG /tmp/scan-fast.txt

# nmap детально по найденным IP
nmap -sV -O -A -p- -iL /tmp/scan-fast-hosts.txt -oA /tmp/nmap-full

# отдельно — Wi-Fi сегмент
iw dev wlan0 scan | grep -E "BSS|SSID|signal" > /tmp/wifi-survey.txt

Сканирование выявило 88 живых хостов в LAN. Минус 32 ПК, минус роутер и AP — остаётся 53 «не-ПК». Привычные принтеры, камеры, NAS — закрывают 26 хостов. Остаётся 27 непонятных устройств. Это всегда самое интересное.

Физический обход офиса

Сразу после того, как я закончил сетевое сканирование, я лично прошёл по офису и складу. Несмотря на то, что это, может, и старомодно, поверьте, такой обход даёт мне куда больше информации, чем любая, даже самая крутая, утилита. На складе я обнаружил 14 розеток с надписью «Smart Plug NoName Plus» — это китайские, с характерными розовыми светодиодами. В кабинетах руководителей нашёл 4 умных термостата Tuya BHT-002, а ещё две веб-камеры USB-Wi-Fi от Logitech. В серверной лежал один Raspberry Pi 4 — админ потом объяснил, что это для мониторинга температуры. И совсем уж странная находка: за окном висел один уличный погодный сенсор Aqara, я так и не понял, зачем он там.

Я выяснил, что из этих 22 «домашних» устройств 4 принадлежали руководителям — это те самые термостаты. 14 розеток были корпоративными; их поставил кто-то из админов год назад для удалённого управления оргтехникой. А вот оставшиеся 4 устройства оказались личными вещами сотрудников: Raspberry Pi админа, Aqara, которую кто-то просто воткнул и забыл, и две Logitech, лежащие на столе у одного из менеджеров.

И это было, пожалуй, одним из самых неприятных открытий: 4 устройства, о существовании которых админ компании даже не подозревал. Представьте, все они подключены к корпоративному Wi-Fi, используя пароль сотрудника, и у всех IP-адреса в той же сети, что и у бухгалтерских ПК. Это же прямо эталонная теневая IT!

День 2: проверка обновлений и базовых уязвимостей

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

А вот что мы обнаружили по камерам Hikvision DS-2CD2143: их было 12 штук, они стояли на складе и по периметру офиса. Прошивка V5.5.5_build_200120 — это, прямо скажем, совсем старая версия 2020 года. С тех пор для этой прошивки у Hikvision вышло аж 4 значимых CVE, включая CVE-2022-28171, позволяющую RCE через ONVIF. Вдобавок ко всему, telnet 23/TCP был открыт без пароля, а логин и пароль по умолчанию стояли admin/12345.

Это критика. Если бы кто-то узнал внешний IP офиса и наличие этих камер, через час он бы получил полный контроль над NVR-сервером, а оттуда — почти прямой путь в локальную сеть. План — обновить прошивки до V5.7.8, сменить пароли, отключить telnet, поместить камеры в отдельный VLAN с deny на внешний интернет (только NVR может на них смотреть).

Наши NAS Synology DS220+ — их было 2 штуки, один для бухгалтерии, другой для общего хранилища. На них стояла DSM 7.0.1, а ведь актуальная версия уже DSM 7.2.2. Мы нашли несколько CVE — они не были критичными, но всё равно это устаревшие дыры. Хуже всего, что Web-интерфейс был открыт наружу через NAT! Это просто недопустимо. Наш план: обновить DSM, закрыть внешний доступ к интерфейсу и оставить возможность подключения только через VPN-доступ.

Что касается принтеров Kyocera M2540dn — их было 8 штук. Прошивка у них была свежая, обновлений мы не нашли. Однако на каждом принтере стоял дефолтный пароль admin — это, конечно, совсем не дело. И SNMP-community было стандартное, «public». Наш план такой: сменить пароли, изменить или вовсе отключить SNMP-community и ни в коем случае ничего не выставлять наружу.

А вот SIP-телефоны Yealink T31P — их было 7 штук. Прошивка 124.86.0.30 оказалась близка к актуальной. Telnet и SSH были закрыты, а веб-интерфейс защищён сменённым паролем. Тут админ прямо молодец, эти устройства настроены почти образцово! Единственный недочёт, который мы нашли, — это отсутствие VLAN-сегментации.

Что касается термостатов Tuya BHT-002 — их было 4 штуки. Прошивка на них стояла стандартная, Tuya WB3S. Через packet capture мы выяснили, что каждые 5 минут термостаты открывают соединение с tuya.ai-cloud.com — это нормально, это их управляющий сервер от Tuya. Но также, раз в час, они отправляли пакеты на какой-то адрес в Сингапуре, который мы так и не смогли идентифицировать. Я не могу с уверенностью сказать, что это утечка данных — возможно, это просто какая-то статистика для производителя, но сам факт настораживает.

День 3: реверс прошивки розеток ESP8266

Самое интересное в нашем аудите произошло на третий день. Розетки NoName Plus — их было 14 штук, китайские, купленные админом в 2024 году через Wildberries, по 380 ₽ за штуку. Раньше ими управляли через приложение «SmartLife» от Tuya, но где-то месяц назад они перестали реагировать на команды. Админ думал, что просто облако от Tuya обновилось, и старые розетки из-за этого «отвалились».

Когда мы просканировали розетки, стало ясно, что они очень активно общаются с интернетом. Мы обнаружили, что один из портов, 8443/TCP, был открыт, а прошивка работала на ESP8266 — это мы поняли по MAC-prefix Espressif. В общем, мы решили взять одну такую розетку, разобрать её и сделать дамп прошивки.

Дамп прошивки через esptool

Разобрали розетку — стандартная плата ESP8266 модуль ESP-12F + реле + ZMPT101B-измеритель тока. Запаял на ESP пин GPIO0 на землю (programming mode), подключил USB-UART CP2102 к GPIO1/3 (TX/RX) и питанию 3.3В. Команда дампа:

esptool.py --port /dev/ttyUSB0 --baud 115200 \
    read_flash 0x0 0x400000 dump-socket1.bin

# Connecting......
# Detected ESP8266
# Reading 4194304 bytes at 0x00000000 to dump-socket1.bin... 100%
# Saved dump-socket1.bin

# проверка структуры
file dump-socket1.bin
# dump-socket1.bin: data
binwalk dump-socket1.bin
# DECIMAL HEX        DESCRIPTION
# 0       0x0        ESP8266 bootloader
# 4096    0x1000     ESP8266 firmware partition 0
# 1048576 0x100000   ESP8266 firmware partition 1  (OTA)
# 2031616 0x1F0000   SDK config region
# 2097152 0x200000   SPIFFS filesystem
binwalk -e dump-socket1.bin
# Extracted firmware partitions to _dump-socket1.bin.extracted/

Извлёк SPIFFS-файловую систему через esptool spi_flash dump + mkspiffs. Внутри — три JSON-файла с настройками, скрипт автозапуска, прошитый Wi-Fi-пароль (наш офисный, в открытом виде! — это уже грабли), и main_app.bin как ESP8266 ELF.

Я загрузил main_app.bin в Ghidra, используя плагин ghidra-xtensa. После этого я занялся статическим анализом. Моей целью было найти такие строки, как tuya, http, mqtt, hongkong, telnet, password, post. И что вы думаете? Среди прочего, я нашёл две очень любопытные строки:

// фрагменты из main_app.bin через Ghidra
// строки в .rodata
0x40246218: "https://%s/api/v1/heartbeat"
0x4024623c: "43.128.X.X"     <-- IP в Гонконге
0x40246250: "POST"
0x40246264: "{\"uuid\":\"%s\",\"ver\":\"1.2.7\",\"act\":\"%s\"}"

// функция, обращающаяся к этой строке
void FUN_4020a3c8(void) {
    snprintf(buf, 256, "https://%s/api/v1/heartbeat", "43.128.X.X");
    http_post(buf, json_body);
    parse_response(resp);   // вызывает eval_command
}

То есть прошивка раз в 4 часа отправляет HTTPS-запрос на IP в Гонконге (43.128.X.X, AS Tencent), передаёт UUID устройства и текущую активность. В ответ парсит JSON с «командами» (act-поле). Какие именно команды поддерживаются — мы не успели до конца разобрать, но кода функции eval_command хватало на 200+ строк ассемблера. Подозреваю, что розетка может выполнять команду «передать настройки Wi-Fi» или «передать список устройств в сети».

Что мы решили делать с этой находкой

Наш первый шаг был очевиден: мы физически выключили все 14 розеток из сети. К счастью, бухгалтерия от этого не пострадала, потому что розетки управляли некритичными вещами — вентиляторами, лампами в коридоре, чайником. К концу дня все эти розетки были убраны, мы выкупили их за 5 600 ₽ через Wildberries и заменили на новые от российского бренда Rubetek.

Потом мы провели детальный анализ, чтобы понять, что вообще могло утечь. Розетки, как мы выяснили, видели MAC-адреса других устройств в сети через ARP, видели DNS-запросы и теоретически могли бы провести ARP-poisoning. Однако доказательств активной атаки мы не нашли — судя по логам MikroTik за прошлый год, никаких подозрительных исходящих соединений из сети не было. Но сам факт, что устройства имеют C2, уже очень плох.

Мы тут же сообщили в админскую базу, написали в чат с финдиректором, и там мы приняли твёрдое решение: с этого момента никаких безымянных IoT-устройств в офисе быть не должно! Только проверенные бренды, и всё строго в отдельной VLAN.

День 4: проектирование VLAN и фильтрация

На четвёртый день мы уже вовсю занимались проектированием и внедрением VLAN-сегментации. У клиента стоит серьёзное оборудование: MikroTik CCR2004-16G-2S+ и два управляемых коммутатора Mikrotik CRS328-24P-4S+RM. Это даёт нам нативную поддержку 802.1Q VLAN, что очень удобно.

Мы разбили сеть на 4 VLAN-а. VLAN 10 — это наша офисная сеть (10.10.10.0/24): здесь будут все ПК, принтеры и рабочие WiFi-устройства. Это такая «доверенная зона». VLAN 20 — для CCTV+NVR (10.10.20.0/24): сюда мы отправили 12 камер Hikvision и NVR-сервер. Для этой VLAN мы запретили весь исходящий трафик в интернет, оставив только внутренний обмен между камерами и NVR. VLAN 30 — это NAS+VoIP (10.10.30.0/24): здесь у нас два NAS Synology и 7 SIP-телефонов Yealink, а также SBC, если бы он был. Доступ в интернет здесь тоже ограничен: NAS могут выходить только для бэкап-сервисов, а телефоны — только до SIP-провайдера. И наконец, VLAN 40 — это IoT-untrust (10.10.40.0/24): сюда попали термостаты, любые «умные» устройства и гостевой Wi-Fi. Эта зона полностью изолирована от всех остальных VLAN, а доступ в интернет разрешён, но только на те домены, которые мы прописали в MikroTik DNS-фильтре.

/interface/vlan
add disabled=no interface=ether1 name=vlan10-office vlan-id=10
add disabled=no interface=ether1 name=vlan20-cctv vlan-id=20
add disabled=no interface=ether1 name=vlan30-nas vlan-id=30
add disabled=no interface=ether1 name=vlan40-iot vlan-id=40

/ip/address
add address=10.10.10.1/24 interface=vlan10-office
add address=10.10.20.1/24 interface=vlan20-cctv
add address=10.10.30.1/24 interface=vlan30-nas
add address=10.10.40.1/24 interface=vlan40-iot

/ip/firewall/filter
# офисный VLAN — полный доступ
add chain=forward in-interface=vlan10-office action=accept

# CCTV — только до NVR в своём VLAN
add chain=forward in-interface=vlan20-cctv \
    src-address=10.10.20.0/24 dst-address=10.10.20.10 action=accept
add chain=forward in-interface=vlan20-cctv action=drop comment="cctv-isolate"

# NAS+VoIP — только бэкап-сервисы и SIP-провайдер
add chain=forward in-interface=vlan30-nas \
    dst-address-list=approved-backup-targets action=accept
add chain=forward in-interface=vlan30-nas \
    dst-address-list=sip-provider action=accept
add chain=forward in-interface=vlan30-nas action=drop comment="nas-voip-isolate"

# IoT — полный deny между VLAN
add chain=forward in-interface=vlan40-iot \
    out-interface=!ether-wan action=drop comment="iot-no-lateral"
add chain=forward in-interface=vlan40-iot \
    dst-address-list=approved-iot-clouds action=accept
add chain=forward in-interface=vlan40-iot action=drop comment="iot-default-drop"

Лист «approved-iot-clouds» содержит только разрешённые адреса Tuya (для термостатов) и Rubetek (для новых розеток). Всё остальное дропается. Если бы зомби-розетки оставались, их трафик до Гонконга был бы заблокирован на уровне фаервола.

Перенос устройств в VLAN

Чтобы физически перенести все устройства в нужные VLAN-ы, нам понадобилось два рабочих вечера — мы делали это после окончания рабочего дня, чтобы не мешать сотрудникам. Камеры и NVR мы переключили, настроив порты на коммутаторе в access-mode в VLAN 20. NAS отправили в VLAN 30. А вот принтеры мы оставили в VLAN 10, так как ими пользуются все, и они не несут особых рисков.

С SIP-телефонами Yealink в VLAN 30 была одна небольшая хитрость: их нужно было перенастроить через TFTP-конфиг. Дело в том, что они сами тегируют свой трафик 802.1Q VLAN-ID, и теперь он должен был быть 30. Но через провижионинг-сервер Yealink AutoP мы справились очень быстро — за 20 минут все 7 телефонов переадресовались куда надо.

День 5: документация и обучение клиента

Последний день аудита — оформление документации. Мы сдали клиенту три документа: реестр устройств с MAC, IP, версией прошивки, ответственным сотрудником (47 строк); диаграмму сети с VLAN-разбиением; регламент «как добавить новое IoT-устройство в офис» — 7 шагов, каждый с расшифровкой.

Регламент здесь просто необходим — иначе через полгода админ снова купит какую-нибудь «умную лампочку» и просто воткнёт её в общую сеть. Мы договорились с финдиректором, что теперь любая закупка IoT-устройств проходит через ITfresh: мы обязательно проверяем каждое устройство ещё до подключения. Стоимость такой проверки — 1 200 ₽ за устройство, и занимает она всего 30 минут. Финдиректор сразу согласился, ведь это гораздо дешевле, чем проводить повторный аудит.

Также провели часовой инструктаж с админом клиента: как самому пользоваться masscan, как смотреть в logs MikroTik исходящие соединения, как реагировать на алерты. У клиента теперь работает простой Telegram-бот, который раз в час забирает из MikroTik топ-10 исходящих хостов и шлёт алерт, если появляется что-то новое.

Цифры и личные впечатления

Наш полный IoT-аудит занял у инженера 5 рабочих дней, а его стоимость составила 180 000 ₽ — это 110 тысяч за базовый аудит и ещё 70 тысяч за реверс розеток и проектирование VLAN. И вот что мы нашли: 14 розеток с C2, ведущим в Гонконг; 12 камер Hikvision с открытым telnet; 2 NAS с устаревшим DSM; 4 теневых устройства, среди которых Raspberry Pi, две Logitech и Aqara; а ещё кучу дефолтных паролей. Замена розеток обошлась в 5 600 ₽, и теперь новые от Rubetek работают через WiFi VLAN 40.

Больше всего меня удивило в этом проекте, как обычная торговая компания смогла за 4 года эксплуатации собрать целый «зоопарк» IoT-устройств, причём абсолютно без всякой системы! Это, конечно, не злой умысел — это просто естественное накопление, когда у бизнеса нет чёткого регламента. Теперь, с новым регламентом, такая история точно не повторится: все новые устройства будут проходить проверку через нас, а теневые устройства будут видны благодаря скрипту мониторинга.

Хочу дать совет всем владельцам бизнеса с 25-50 РМ: если у вас в офисе больше 20 IoT-устройств, и вы уже не помните, откуда они все взялись — тогда обязательно закажите аудит. Это всего 5 дней работы, но зато вы будете спокойны на долгие годы.

FAQ: что чаще всего спрашивают клиенты

Зачем торговой компании аудит IoT-устройств?

Представьте, торговая компания на 32 РМ держит склад и офис, где активно используются CCTV-камеры, NAS-хранилища, сетевые принтеры, умные термостаты, IP-телефония. Каждое из таких устройств — это потенциальная лазейка для атакующего: на нём может быть бэкдор от производителя, устаревшая прошивка с CVE, или даже открытый telnet с дефолтными паролями. Один скомпрометированный CCTV в той же сети, что и компьютер бухгалтера, — это прямая угроза утечки 1С-базы! Аудит как раз и нужен, чтобы найти и устранить эти риски ещё до того, как они превратятся в настоящую проблему.

Что вы нашли в прошивке китайских розеток?

Мы обнаружили, что в двух розетках китайского бренда NoName Plus, купленных через маркетплейс за 380 ₽/шт, была установлена кастомная прошивка на ESP8266. Эта прошивка каждые 4 часа отправляла HTTPS-запросы на IP-адрес в Гонконге (43.128.X.X, AS Tencent). Цель этого C2 осталась неясной, но совершенно точно производитель такого не планировал! Запросы шли с уникальным UUID устройства, а в ответ приходил JSON с командами. Мы тут же отключили эти розетки из офисной сети, а остальные устройства того же бренда выявили и заменили.

Какой инструментарий вы используете для IoT-аудита?

Для сетевой части мы использовали nmap для сканирования портов, masscan для быстрого обнаружения новых устройств, Wireshark для перехвата трафика и MikroTik flow для длительного наблюдения. А для работы с прошивками у нас был esptool для снятия дампов с ESP8266/ESP32, binwalk для извлечения файловых систем из бинарей и Ghidra для статического анализа кода. Если нужно, для аудита Wi-Fi-сегмента мы используем hcxtools. Всё это опенсорсное и отлично работает на Linux. У нас на каждом инженере — это стандартный набор инструментов.

Что делать с CCTV Hikvision с открытым telnet?

Это типичная проблема Hikvision и Dahua старых прошивок: дефолтные пароли, открытый telnet, ONVIF без авторизации. План действий: 1) обновить прошивку до актуальной версии (если поддерживается); 2) сменить дефолтные пароли админ-учётки; 3) отключить telnet через веб-интерфейс; 4) поместить камеры в отдельный VLAN с deny-all на выход в интернет (только NVR-сервер видит камеры); 5) на NVR настроить outgoing только на доверенные адреса. Без VLAN-изоляции остальные пункты — половина решения.

Сколько стоит IoT-аудит для офиса 30-50 РМ?

Базовый IoT-аудит для офиса с 30-50 РМ обычно занимает 4-5 рабочих дней инженера и стоит от 110 000 до 140 000 ₽. В эту стоимость входит: полная инвентаризация всех IoT-устройств, сканирование на уязвимости, проверка актуальности прошивок, базовая VLAN-сегментация и подробный отчёт с нашими рекомендациями. Реверс прошивки подозрительных устройств — это отдельная история, и стоит такая услуга от 12 до 25 тысяч за устройство, цена зависит от его сложности. В случае с торговой компанией на 32 РМ, полный пакет, включая реверс 2 розеток, обошёлся им в 180 000 ₽.

Итог

Я считаю, что IoT-аудит — это не просто разовая прихоть, а настоящая гигиена для любого бизнеса, где в офисе есть много разных устройств. Вот у той торговой компании на 32 РМ мы за 5 дней нашли 14 розеток с C2 в Гонконге, 12 камер с открытым telnet и четыре теневых устройства. Мы всё это устранили, развернули VLAN-сегментацию, и даже написали регламент по закупке IoT-оборудования. Стоимость нашей работы составила 180 тысяч, но выявленных рисков было на порядок больше. Я уверен, что через полгода эта работа полностью себя окупит, предотвратив потенциальную утечку данных.