На последних трёх проектах по тестированию безопасности IoT я вскрывал корпуса устройств, подключался к UART - и в двух случаях из трёх получал root-шелл без единого запроса пароля. Третье устройство хотя бы запросило логин, но пара
admin:admin прошла сразу. По опыту индустрии, в подавляющем большинстве IoT-ассессментов хотя бы один отладочный интерфейс (UART или JTAG) остаётся полностью открыт в продакшн-версии устройства. Это не баг - это состояние индустрии.Пентест IoT-устройств отличается от тестирования веб-приложений тем, что атакующая поверхность одновременно охватывает железо, прошивку, радиоканалы, облачные API и мобильные приложения. Стандартные методологии сетевого пентеста покрывают от силы треть этого пространства. Ниже - воспроизводимый процесс, который я использую на реальных проектах, с привязкой к OWASP IoT Security Testing Guide (ISTG) и MITRE ATT&CK.
Модель IoT-устройства и скоупинг по OWASP ISTG
Русскоязычные материалы по аудиту безопасности IoT обычно перечисляют шаги вроде «просканируйте сеть, найдите уязвимости, эксплуатируйте». Это описание пентеста веб-приложения, а не IoT-устройства. OWASP IoT Security Testing Guide (ISTG) предлагает другой подход - компонентную модель, где каждый элемент устройства тестируется отдельно.По ISTG любое IoT-устройство раскладывается на две категории элементов:
Внутренние элементы: процессор (ARM, AVR, x86), память (EEPROM, флеш-чипы), прошивка (установленная + механизм обновления) и сервисы обмена данными (сетевые демоны, отладочные сервисы).
Интерфейсы: внутренние (UART, JTAG, SPI, I2C - доступны после вскрытия корпуса), физические (USB, Ethernet - доступны снаружи), беспроводные (Wi-Fi, BLE, Zigbee, Z-Wave) и пользовательские (веб-панель, дисплей, камера).
Для скоупинга пентеста ISTG использует модель атакующего с двумя осями:
| Уровень физического доступа | Описание | Пример |
|---|---|---|
| Уровень 1 (удалённый) | Нет физического доступа, атака через интернет | Shodan, облачный API |
| Уровень 2 (близость) | Находится вблизи устройства, атака из LAN/WLAN | Wi-Fi, Bluetooth |
| Уровень 3 (физический, неинвазивный) | Устройство в руках, корпус закрыт | USB, кнопки, внешние порты |
| Уровень 4 (физический, инвазивный) | Корпус вскрыт, доступ к PCB | UART, JTAG, дамп флеш-памяти |
Примечание: приведена упрощённая авторская адаптация модели OWASP ISTG.
| Уровень авторизации | Описание |
|---|---|
| AA-1 | Анонимный доступ (без учётных данных) |
| AA-2 | Обычный пользователь |
| AA-3 | Привилегированный пользователь / администратор |
| AA-4 | Производитель / root-доступ (максимальные привилегии) |
На пересечении этих осей определяется, какие компоненты попадают в скоуп. IP-камера на стене здания - Уровень 2/AA-1: тестируем беспроводные интерфейсы, сетевые сервисы, веб-панель. Умное устройство, которое атакующий может купить и разобрать дома, - Уровень 4/AA-3: тестируем всё, включая чипы памяти и отладочные интерфейсы на плате.
Этот этап - не формальность. Без чёткого скоупинга пентест IoT превращается в хаотичное тыканье
nmap-ом в устройство с последующим «уязвимостей не обнаружено» в отчёте. Видел такие отчёты - на устройстве потом находили открытый UART с рутом.Разведка и fingerprinting IoT-инфраструктуры
Разведка IoT-устройств начинается задолго до физического контакта. Первый шаг - определить, что именно перед нами.
Внешняя разведка (PA-1). Для устройств, торчащих в интернет, Shodan и Censys - стандартные точки входа. Запрос
http.title:"Camera" country:"RU" в Shodan выдаёт тысячи результатов с открытыми веб-интерфейсами. По MITRE ATT&CK это Search Open Technical Databases (T1596, Reconnaissance; также релевантна T1595.002 - Vulnerability Scanning). Но Shodan - только начало. Полезнее смотреть FCC ID устройства: каждое радиоизлучающее устройство, продаваемое в США, проходит сертификацию FCC, и в открытом доступе лежат фотографии внутренностей - PCB, чипы, антенны. Это Gather Victim Host Information: Hardware (T1592.001) / Firmware (T1592.003) - ещё не вскрыв корпус, вы знаете, какой процессор стоит внутри и где на плате искать UART.Локальная разведка (PA-2). В сегменте локальной сети сканирование
nmap -sV -O --script=banner <target> выявляет открытые порты и баннеры сервисов. IoT-устройства часто выдают себя характерными fingerprint-ами: lighttpd, uhttpd, GoAhead-Webs, Boa HTTPd в качестве веб-сервера. Открытые порты 1883 (MQTT без TLS), 5683 (CoAP) или нестандартные порты в диапазоне 8000-9000 - типичные маркеры.Для Zigbee и Z-Wave устройств нужен SDR-приёмник или специализированный адаптер (CC2531 для Zigbee, RTL-SDR для разведки частотного диапазона). Wireshark имеет встроенный диссектор Zigbee. Для захвата трафика - KillerBee (
zbdump) с адаптером CC2531. Well-known Trust Center Link Key ZigBeeAlliance09 позволяет расшифровать join-процедуру и вытянуть network key для последующей расшифровки трафика. Да, ключ лежит прямо в спецификации - и да, это работает.Что собирать. На этом этапе фиксируется: модель устройства, версия прошивки (часто видна в веб-интерфейсе или баннере), открытые порты и сервисы, используемые протоколы, наличие стандартных учётных данных. Всё это определяет дальнейший вектор.
Аппаратный пентест: UART, JTAG и дампы памяти
Здесь начинается территория, которую русскоязычные материалы почти не покрывают. Аппаратный пентест - это PA-4 по модели ISTG и прямой путь к OWASP IoT Top 10 2018 I10 (Lack of Physical Hardening) и I1 (Weak, Guessable, or Hardcoded Passwords).
Требования к окружению
JTAG и дамп флеш-памяти
JTAG даёт более глубокий доступ - вплоть до пошаговой отладки процессора. JTAGulator подключается ко всем подозрительным контактным площадкам и через BYPASS/IDCODE-сканирование определяет распиновку TDI/TDO/TCK/TMS. OpenOCD подключается к найденному интерфейсу и позволяет читать/записывать память, останавливать процессор и копаться в регистрах.Для устройств, где UART заблокирован, а JTAG отключён через fuse bits, остаётся прямой дамп флеш-чипа. Программатором CH341A или Dediprog снимается полное содержимое SPI/NOR-флеш. Команда
flashrom -p ch341a_spi -r dump.bin создаёт побайтовую копию. Дальше - анализ прошивки.Анализ прошивки IoT-устройства
Прошивка - центральный элемент тестирования безопасности IoT. По классификации ISTG это компонент ISTG-FW, и он делится на две части: установленная прошивка (ISTG-FW[INST]) и механизм обновления (ISTG-FW[UPDT]).Первый шаг - извлечение файловой системы. Если у вас уже есть дамп (с UART, через веб-интерфейс обновления или через CH341A),
binwalk находит и распаковывает всё автоматически:
Bash:
binwalk -e firmware.bin
# Результат: _firmware.bin.extracted/ с файловой системой SquashFS/JFFS2- Захардкоженные учётные данные (T1552.001, Credential Access):
strings firmware.bin | grep -i -E 'pass|pwd|key|secret|token'- первая команда, не последняя. Firmwalker автоматизирует этот процесс, проверяяshadow,passwd, конфигурационные файлы, SSL-сертификаты и приватные ключи. - Устаревшие компоненты (OWASP IoT I5): проверка версий BusyBox, OpenSSL, ядра Linux через
stringsиgrep. Устройства с BusyBox 1.19 и OpenSSL 1.0.1 - регулярная находка в 2025 году. Не исключение, а норма. - Отладочные функции в бинарниках: Ghidra помогает найти скрытые backdoor-аккаунты и отладочные эндпоинты, которые не видны через веб-интерфейс. На одном проекте так нашли скрытый CGI-эндпоинт с command injection - его не было ни в документации, ни в веб-интерфейсе.
- Механизм обновления (OWASP IoT I4): скачивается ли прошивка по HTTP или HTTPS? Проверяется ли цифровая подпись перед установкой? Возможен ли downgrade до уязвимой версии?
Сетевой уровень: перехват и атаки на IoT-протоколы
Сетевой анализ - OWASP IoT I7 (Insecure Data Transfer and Storage) и I2 (Insecure Network Services). По MITRE ATT&CK - Network Sniffing (T1040, Discovery/Credential Access).MQTT без аутентификации
MQTT - де-факто стандарт обмена сообщениями между IoT-устройствами. Проблема: в тестируемых IoT-инсталляциях брокеры нередко работают без аутентификации и без TLS. Подключение к такому брокеру тривиально:
Bash:
mosquitto_sub -h <broker_ip> -t '#' -v
# Подписка на все топики - видим все сообщения от всех устройствCoAP и проприетарные протоколы
CoAP (порт 5683/UDP) - легковесная альтернатива HTTP для constrained devices. Wireshark декодирует CoAP нативно. Zeek с плагинами позволяет писать правила для обнаружения аномалий в IoT-трафике. Проприетарные бинарные протоколы на нестандартных портах требуют реверса: запись трафика в pcap, анализ структуры пакетов, идентификация паттернов. Тут терпение важнее инструментов.На что обращать внимание
| Протокол | Порт | Типичная уязвимость | OWASP IoT |
|---|---|---|---|
| MQTT | 1883 | Нет аутентификации, plaintext | I2, I7 |
| MQTT/TLS | 8883 | Самоподписанные сертификаты | I7 |
| CoAP | 5683 | Отсутствие DTLS | I7 |
| HTTP (веб-панель) | 80/8080 | Command injection, default creds | I1, I3 |
| Telnet | 23 | Default credentials, plaintext | I1, I9 |
| UPnP/SSDP | 1900 | Раскрытие информации, RCE | I2 |
Эксплуатация веб-интерфейсов и API
Большинство IoT-устройств предоставляют веб-интерфейс для управления - и это один из самых дырявых компонентов. По MITRE ATT&CK - Exploit Public-Facing Application (T1190, Initial Access) и Password Guessing (T1110.001, Credential Access).Встроенные веб-серверы (GoAhead, uhttpd, lighttpd, Boa) часто содержат уязвимости, которые давно закрыты в «большом» вебе, но живут десятилетиями в прошивках: command injection через параметры диагностических утилит (
ping, traceroute), directory traversal, SSRF через функции обновления.Конкретная цепочка, которую я воспроизводил неоднократно:
- Подбор стандартных учётных данных (OWASP IoT I9 - Insecure Default Settings). Списки дефолтных паролей для IoT-устройств собраны в
SecLists/Passwords/Default-Credentials. - Если веб-интерфейс содержит форму диагностики (ping, DNS lookup) - проверка command injection:
; id,| cat /etc/shadow,[ICODE],whoami. - Анализ API-запросов через Burp Suite: часто встречается отсутствие авторизации на API-эндпоинтах - IDOR, mass assignment, доступ к чужим устройствам через перебор серийных номеров.
- Проверка механизма обновления прошивки: если устройство скачивает обновление по HTTP без верификации подписи (OWASP IoT I4) - возможна подмена прошивки через MITM.
- Для устройств, чьи веб-интерфейсы доступны из интернета, Metasploit содержит модули для ряда популярных IoT-платформ. В msfconsole команда
search type:exploit iotпокажет доступные эксплойты;search type:exploit routerиsearch type:exploit camera- дополнительные модули для конкретных классов устройств. Контекст применения: decision tree выбора вектора
| Условие | Вектор | Инструменты | OWASP IoT |
|---|---|---|---|
| Устройство в руках, корпус можно вскрыть | UART → root-шелл → дамп прошивки | Bus Pirate, minicom, binwalk | I10, I1 |
| Устройство в руках, корпус sealed/tamper-proof | Дамп прошивки через OTA-обновление + сетевой анализ | binwalk, Wireshark, Burp Suite | I4, I7 |
| Устройство в LAN, физического доступа нет | Сканирование портов → веб-интерфейс → MQTT/CoAP | nmap, Burp Suite, mosquitto_sub | I2, I3, I9 |
| Устройство доступно из интернета | Shodan recon → веб-эксплуатация → облачный API | Shodan, Burp Suite, Metasploit | I3, I9 |
| Есть образ прошивки (с сайта производителя) | Статический анализ → эмуляция → поиск 0day | binwalk, Ghidra, FirmAE | I5, I1 |
Принцип простой: если есть физический доступ - начинайте с железа. UART-шелл за 15 минут даёт больше информации, чем три дня фаззинга веб-интерфейса. Если физического доступа нет - прошивка с сайта производителя + сетевой анализ закрывают большую часть скоупа.
Ограничения и где методология ломается
Не каждое IoT-устройство поддаётся описанному процессу. Ограничения, с которыми я сталкиваюсь регулярно:
- Проприетарные RTOS. Устройства на FreeRTOS, Zephyr или полностью кастомных прошивках без Linux-ядра не распаковываются binwalk-ом. Нужен полный реверс в Ghidra с нуля - это дни работы, не часы. На одном проекте мы потратили четыре дня только на то, чтобы разобраться в формате файловой системы.
- Защищённые чипы. Процессоры с Secure Boot, TrustZone и прожжёнными fuse bits блокируют чтение прошивки и отключают JTAG. Обход требует glitching-атак (voltage fault injection) - специализированное оборудование (ChipWhisperer, ~$250-350) и экспертиза. Это уже не «подключился и снял дамп», а исследовательская работа.
- Encrypted firmware. Если прошивка зашифрована и ключ не извлекается из bootloader-а - статический анализ невозможен без аппаратных атак на криптографию.
- Эмуляция. FirmAE и Firmadyne работают с ~70% прошивок на базе GNU/Linux. Остальные 30% требуют ручной настройки QEMU или не эмулируются вовсе из-за завязки на проприетарные аппаратные модули.
Заключение
За семь лет работы с embedded-системами я пришёл к выводу, что главная проблема безопасности IoT - не сложность атак, а элементарность большинства находок. Захардкоженные пароли, открытый UART с root-шеллом, MQTT без аутентификации, обновления по HTTP - всё это OWASP IoT Top 10 2018 категории I1 и I9, и они покрывают подавляющее большинство реальных уязвимостей. Производители embedded-устройств в массе своей до сих пор не прошли тот путь, который веб-разработка прошла десять лет назад.Фреймворк работает только если им пользуются. Пока я вижу, что даже в отчётах крупных ИБ-компаний IoT-пентест сводится к «просканировали Nmap-ом, нашли дефолтный пароль» - без аппаратного уровня, без анализа прошивки, без тестирования радиопротоколов. Это не пентест IoT - это пентест сетевого стека устройства, который совпадает с IoT только по названию. Если хочется разобраться, как полная цепочка от UART до root-шелла собирается на практике - задачи в категориях hardware и IoT на HackerLab.pro построены на похожих сценариях с реальным оборудованием.
Последнее редактирование модератором:
