На аудите домашней сети в 2024 году первый же
binwalk на прошивке роутера TP-Link вернул захардкоженный root:root в /etc/shadow - устройство 2021 года выпуска, актуальная прошивка с сайта вендора. Три минуты от скачивания firmware до полного доступа к файловой системе, ноль защитных механизмов. И это не уникальный случай - это типичный уровень IoT уязвимостей, с которым сталкиваешься на каждом втором устройстве «умного дома». Роутеры, колонки, смарт-ТВ - embedded-системы с Linux-ядром, открытыми портами и прошивками, которые обновляются раз в никогда. Ниже - практический разбор: как провести IoT пентест каждого из этих классов устройств, какие инструменты использовать и где конкретно искать дыры.Поверхность атаки IoT: почему умные устройства - лёгкая цель
Сервер или рабочая станция - это хотя бы минимальный набор защит: EDR-агент, хостовой firewall, регулярные патчи ОС. У IoT-устройств ничего из этого нет.Масштаб проблемы давно вышел за пределы отдельных домашних сетей. В 2016 году ботнет Mirai заразил сотни тысяч IoT-устройств - роутеры, веб-камеры, DVR - и генерировал рекордные DDoS-атаки: ~1 Тбит/с на хостинг OVH (сентябрь 2016, по данным CEO OVH Октава Клаба) и атаку на DNS-провайдера Dyn (октябрь 2016), которая положила Twitter, GitHub, Reddit и ещё десяток сервисов. С тех пор IoT-ботнеты только масштабируются.
Три фактора превращают IoT в лёгкую цель:
- Дефолтные учётные данные. Default Accounts (T1078.001, Initial Access) - вектор, который на IoT работает безотказно. MITRE ATT&CK описывает T1078.001 как платформонезависимую технику, хотя готовые тесты Atomic Red Team есть только для Windows и macOS. На embedded Linux дефолтные учётки эксплуатируются точно так же. Производители ставят
admin:admin, пользователи не меняют. - Устаревшие компоненты. Прошивки содержат библиотеки с известными уязвимостями (OWASP A06:2021 - Vulnerable and Outdated Components). Обновления выходят редко или не выходят вовсе.
- Открытые сервисы. SSH, Telnet, HTTP-панели, MQTT-брокеры без аутентификации - доступны из локальной сети, а иногда и из интернета (T1133, External Remote Services - техника в MITRE ATT&CK платформонезависимая, тесты Atomic Red Team - только для Windows).
IoT пентест роутера: от сканирования до firmware анализа
Разведка и сканирование сервисов безопасности роутера
Роутер - первый кандидат на проверку IoT устройств. Большинство домашних маршрутизаторов сидят на192.168.0.1 или 192.168.1.1, и первая задача - понять, что торчит наружу.Требования к окружению: Kali Linux (или дистрибутив с nmap и binwalk), минимум 4 ГБ RAM, подключение к целевой сети через Ethernet или Wi-Fi. Все действия выполняются на устройствах, к которым есть легальный доступ.
Запускаем
nmap -sV -sC -p- 192.168.1.1 - полное сканирование портов с определением версий и дефолтными NSE-скриптами. Типичная картина на домашнем роутере:- 80/443 - веб-панель администрирования (часто голый HTTP без TLS)
- 22 - SSH (нередко Dropbear - облегчённая реализация)
- 23 - Telnet (да, в 2025 году он открыт на десятках моделей)
- 53 - DNS-резолвер
- 5555 - UPnP или проприетарный сервис управления
admin:admin, root:root, admin:password, admin:1234. Классическая Security Misconfiguration (OWASP A05:2021) и Identification and Authentication Failures (A07:2021) в одном флаконе.Для разведки вширь полезен Shodan: запрос
"BusyBox" port:23 country:RU покажет маршрутизаторы с открытым Telnet и BusyBox-окружением (T1595.002).Ограничения: сканирование всех 65 535 портов на одном хосте занимает до 20 минут и оставляет заметный след в любой IDS. В корпоративной среде
nmap -sV -sC -p- вызовет алерт в SIEM в первую же минуту. Для тихой разведки - выборочное сканирование ключевых IoT-портов: nmap -sV -p 22,23,80,443,1883,5555,8080,8443.Анализ прошивки роутера через binwalk
Firmware анализ - следующий уровень после сетевого сканирования. Скачиваем прошивку с сайта производителя (у большинства вендоров она валяется в открытом доступе) и разбираем:
Bash:
binwalk -e firmware.bin # binwalk v2.x; для Kali 2024+/Ubuntu 24.04 может потребоваться установка из исходников или unblob как альтернатива
cd _firmware.bin.extracted/squashfs-root/
cat etc/shadow
grep -r "password" etc/
find . -name "*.conf" -exec grep -l "pass\|key\|secret" {} \;- /etc/shadow - захардкоженные учётные данные. Встречается куда чаще, чем хотелось бы.
- Конфигурационные файлы с паролями Wi-Fi, VPN-ключами, API-токенами.
- SSL-сертификаты и приватные ключи - если один ключ используется для всей линейки устройств, это критическая находка (OWASP A02:2021 - Cryptographic Failures).
- Скрипты инициализации в
/etc/init.d/- иногда содержат отладочные обработчики или бэкдоры.
Ограничения: статический анализ показывает только содержимое файловой системы. Конфигурация, которую устройство подтягивает с облака при первом включении, через binwalk не видна. Полноценный рантайм-анализ требует подключения через UART/JTAG к живому устройству - это аппаратный пентест, отдельная дисциплина.
Место в kill chain: найденные захардкоженные пароли дают Initial Access (T1078.001). Навык firmware анализа проверяется на сертификациях уровня eJPT и PNPT, и в CTF-задачах категории reversing - binary, который вам дадут на соревновании, принципиально не отличается от squashfs-образа из прошивки роутера.
Безопасность умной колонки: MQTT, mDNS и открытые протоколы
Умные колонки - по сути, Linux-компьютеры с микрофоном и постоянным подключением к облаку. Они вещают о себе через протоколы обнаружения, которые почти никогда не защищены.Начинаем с пассивного анализа. Запускаем Wireshark на интерфейсе в той же сети (через managed-свитч с port mirroring или через ARP-спуфинг) и смотрим:
- mDNS-анонсы (порт 5353) - колонка рассказывает всем в сети свою модель, имя, доступные сервисы. Без Wireshark ту же информацию даёт
avahi-browse -all -tв терминале. - MQTT-трафик (порт 1883 без TLS, 8883 с TLS) - протокол публикации/подписки для IoT-управления. Если брокер без аутентификации, подключаемся через
mosquitto_sub -h <ip> -t '#'и видим все сообщения: состояние устройств, команды, иногда данные датчиков. - HTTP/HTTPS-запросы к облаку - через Burp Suite с установленным CA-сертификатом на компаньон-приложение смартфона.
Ограничения: колонки крупных вендоров (Amazon Echo, Яндекс.Станция) шифруют каналы до облака - пассивный перехват покажет только DNS-запросы и TLS-хендшейки. Реальную attack surface здесь создают сторонние интеграции и мобильные приложения-компаньоны - именно они чаще содержат слабые места. Проверяйте API, которые вызывает мобильное приложение, через Burp - там находки встречаются регулярнее, чем в прямом анализе колонки.
Смарт-ТВ уязвимости и IoT hacking: ADB, DIAL и взлом умного дома
ADB как точка входа
Телевизоры на Android TV - отдельная категория с собственным набором IoT уязвимостей. Многие модели поставляются с включённым ADB (Android Debug Bridge) по сети без аутентификации. Проверяем:nmap -p 5555 192.168.1.0/24. Если порт открыт - подключаемся и получаем полноценный шелл:
Ограничения: на части моделей ADB отключён по умолчанию и требует явного включения в настройках разработчика. Но если пользователь активировал его для установки стороннего APK - порт так и остаётся открытым. Никто не помнит, что его нужно выключить обратно.
DIAL-протокол и его эксплуатация
DIAL (Discovery and Launch) - протокол от Netflix и YouTube для обнаружения и запуска приложений на смарт-ТВ. Работает поверх UPnP/SSDP: телевизор анонсирует себя, и любое устройство может отправить HTTP-запрос на запуск приложения - без аутентификации.Обнаружить DIAL-устройства можно через SSDP M-SEARCH (UDP 1900) с
ST: urn:dial-multiscreen-org:service:dial:1 или через nmap --script broadcast-upnp-info. В SSDP-ответе содержится LOCATION header, из device description извлекается Application-URL - порт зависит от вендора (например, 8008 на Chromecast, но может быть любым). Отправка POST /apps/YouTube на этот эндпоинт запускает приложение на ТВ - на ряде моделей без пароля и подтверждения, хотя DIAL 2.1 добавляет PIN-pairing.Это не RCE, но это контроль над пользовательским интерфейсом из любой точки локальной сети. В реальных сценариях DIAL используется для фишинга: атакующий запускает на ТВ жертвы браузер с поддельной страницей авторизации. При IoT security audit - валидная находка для отчёта.
Место в kill chain: ADB - Remote Services (T1021, Lateral Movement). DIAL - Exploitation of Remote Services (T1210, Lateral Movement). После закрепления на смарт-ТВ через ADB (T1021) атакующий может использовать устройство для ARP Cache Poisoning (T1557.002) и перехвата трафика других устройств в сети - роутера, ноутбука, камер.
Что засветится в сети при IoT security audit
При аудите IoT-устройств каждое действие оставляет следы. Таблица поможет спланировать, какие техники применять в зависимости от уровня мониторинга в целевой сети:| Действие | Протокол | MITRE ATT&CK | Что увидит IDS/SIEM |
|---|---|---|---|
| Сканирование портов nmap | TCP SYN | T1046, Network Service Discovery | Массовые SYN на диапазон портов |
| Брутфорс SSH/Telnet | TCP 22/23 | T1110.001, Password Guessing | Серия failed login events |
| Подключение к MQTT | TCP 1883 | T1078.001, Default Accounts | Новый клиент в логах брокера |
| ADB-подключение к ТВ | TCP 5555 | T1021, Remote Services | Соединение к нестандартному порту |
| Скачивание прошивки | HTTPS | T1593, Search Open Websites/Domains | Ничего - легитимный трафик |
| SSDP-сканирование | UDP 1900 | T1046, Network Service Discovery | UPnP discovery в логах |
| ARP-спуфинг | ARP | T1557.002, ARP Cache Poisoning | Duplicate IP / ARP anomaly |
В домашней сети большинство действий останутся незамеченными - у обычного роутера нет IDS. В корпоративной среде с SIEM сканирование и брутфорс детектируются быстро, а подключение к открытому MQTT или ADB-порту может не вызвать алерт без специализированных правил для IoT-трафика. Рекомендация для отчёта: внедрить мониторинг нестандартных портов и установить baseline сетевых операций (NIST CSF DE.AE-01).
Чеклист проверки IoT-устройств
Готовый список для включения в отчёт по аудиту:- Инвентаризация: составить реестр всех IoT-устройств в сети (NIST CSF ID.AM-01) -
nmap -snдля обнаружения хостов - Сканирование портов:
nmap -sV -sC -p-для каждого устройства - зафиксировать открытые порты и версии сервисов - Дефолтные креды: проверить Telnet, SSH, веб-панель на стандартные пары логин:пароль
- Firmware анализ: скачать прошивку,
binwalk -e, поиск захардкоженных секретов - Шифрование каналов: TLS на соединениях устройство-облако, версия не ниже 1.2
- Протоколы обнаружения: проверить mDNS, SSDP, UPnP - какую информацию устройство раскрывает в сети
- MQTT-аутентификация: попытка подключения без кредов через
mosquitto_sub - ADB-доступ: проверка порта 5555 на смарт-ТВ и Android-устройствах
- DIAL-эндпоинты: тест запуска приложений на ТВ без авторизации
- Версия прошивки: сравнить с актуальной на сайте вендора, проверить автообновление
- Сегментация: изолированы ли IoT-устройства от основной сети (VLAN, отдельная подсеть)
Работа с IoT-устройствами раз за разом подтверждает одно: вендоры embedded-систем живут в парадигме «выпустил - забыл». Прошивка, залитая на заводе, работает годами без единого патча. Пользователь не подозревает, что его роутер слушает Telnet на всех интерфейсах, а смарт-ТВ принимает ADB-подключения от любого устройства в сети. Скептики скажут - «бытовые устройства, зачем пентест?» Но именно через домашний роутер сотрудника атакующий попадает в VPN-туннель к корпоративной сети. IoT-пентест не про «взломать чайник ради лулзов» - это про attack surface, который большинство SOC-команд не мониторит и не инвентаризирует. Ни один стандарт и ни один Top-10 не исправит ситуацию, пока рынок не начнёт наказывать рублём за отсутствие обновлений - а этого пока не видно даже на горизонте. Единственный способ узнать, в каком состоянии безопасность конкретной сети - взять nmap, binwalk и проверить руками. Если идёшь к OSCP и хочешь подтянуть разведку сервисов и эксплуатацию сетевых протоколов - WAPT покрывает эту часть с лабами, где каждую технику отрабатываешь на стенде.
