Полгода назад на пентесте IoT-инфраструктуры промышленного заказчика я снял дамп SPI-флеш с роутера через CH341A - за первые двадцать минут binwalk нашёл в конфигах три пароля в plaintext. Два из них давали telnet root shell без какой-либо аутентификации. Устройство стояло на периметре, с белым IP, доступное из интернета. Это не аномалия: подобные артефакты регулярно встречаются в прошивках SOHO-роутеров и превращают устройство в готовый initial access без единого эксплойта. Запрет TP-Link в США только подсветил проблему, но не решил её - ниже разбираем, как проводить аудит прошивки роутера руками, от получения образа до готового чеклиста.
Запрет TP-Link в США и уязвимости роутеров: контекст для пентестера
В 2024–2025 годах вокруг TP-Link развернулось политическое расследование: CISA и ряд американских ведомств подняли вопрос о supply chain рисках. По MITRE ATT&CK это T1195.003 (Compromise Hardware Supply Chain, Initial Access) - сценарий, где скомпрометированное оборудование становится точкой входа ещё до подключения к сети. Суть претензий - не конкретный бэкдор в прошивке, а системная непрозрачность firmware-разработки, медленная реакция на CVE и факты использования скомпрометированных устройств TP-Link в ботнетах. Подробнее - в нашем статье о уязвимости iot устройств.Для пентестера эта история важна не политикой, а практикой: производители массового сетевого оборудования раз за разом наступают на одни и те же грабли. Hardcoded credentials, открытые debug-интерфейсы (telnet на нестандартном порту, UART shell без пароля), устаревшие компоненты - особенно Realtek SDK, на базе которого построены прошивки десятков OEM-производителей. Одна дыра в SDK транслируется в сотни моделей от разных брендов. По OWASP это A05:2021 (Security Misconfiguration) и A06:2021 (Vulnerable and Outdated Components) в чистом виде.
Вопрос не в том, можно ли доверять TP-Link. Те же проблемы встречаются у Netgear, D-Link, Tenda, в ряде случаев - у Asus. Аудит прошивки роутера - обязательный этап при пентесте любой сети с SOHO-оборудованием на периметре. Производитель вторичен.
Место firmware-аудита в цепочке атаки на сетевое оборудование
Роутер на периметре - не просто сетевое устройство. Это полноценный Linux-хост с root-доступом, через который проходит весь трафик сегмента. Бизнес-логика атаки: компрометация роутера даёт злоумышленнику pivot point для входа во внутреннюю сеть, перехват трафика (включая DNS hijacking для фишинга) и persistence, переживающий переустановку ОС на подключённых хостах.Вот как аудит прошивки встраивается в kill chain при пентесте сетевого оборудования:
- Recon / fingerprinting - определяем модель и версию firmware. Nmap с флагами
--script http-title,http-server-header, доступ к веб-интерфейсу, Shodan/Censys для внешнего скана. - Получение firmware - скачиваем с FTP/HTTP вендора, снимаем с устройства через UART/SPI или перехватываем при обновлении.
- Статический анализ - распаковка, поиск хардкод-кредлов, debug-эндпоинтов, reverse engineering бинарей в Ghidra.
- Эмуляция / динамический анализ - запуск firmware в QEMU, фаззинг веб-интерфейса, тестирование найденных эндпоинтов.
- Exploitation / initial access (T1190, Exploit Public-Facing Application) - эксплуатация найденных уязвимостей: command injection в веб-интерфейсе, аутентификация через хардкод-пароли, доступ через debug-порт.
- Persistence через firmware (T1542.001, System Firmware - Defense Evasion, Persistence) - проверяем возможность закрепления: модификация системного образа (T1601, Modify System Image), патч прошивки (T1601.001, Patch System Image), даунгрейд до уязвимой версии (T1601.002, Downgrade System Image).
- Lateral movement - скомпрометированный роутер используется для pivot'а: доступ к внутренним сегментам, ARP spoofing, DNS hijacking. Противник может также использовать его как часть внешней инфраструктуры для будущих операций - по MITRE ATT&CK это T1584.008 (Network Devices, тактика Resource Development).
Экстракция и распаковка firmware: пошаговый workflow
и выгрузка через TFTP или netcat.
Метод 4: SPI flash dump через CH341A. Последнее средство, когда нет ни обновлений на сайте, ни UART-доступа. Подключаем SOIC8-клипсу к чипу флеш-памяти (обычно Winbond 25Qxx или Macronix MX25L), читаем командой
flashrom -p ch341a_spi -r dump.bin. Надёжно, но требует вскрытия корпуса, а иногда и отпаивания чипа.Метод 5: из bootloader'а. При доступе к U-Boot через UART можно снять дамп через TFTP без возни с flash напрямую. Команды зависят от конкретной конфигурации U-Boot, но типичная последовательность:
md.b <addr> <len> для просмотра небольших участков памяти (проверить magic bytes), а для полноценной выгрузки - sf read / nand read для копирования flash в RAM с последующим tftp put на TFTP-сервер атакующего.Анализ энтропии: определение шифрования в firmware
Первый шаг после получения образа - проверка энтропии:binwalk -E firmware.bin. По данным Payatu (анализ D-Link DIR-822), если энтропия близка к 1.0 на всём протяжении файла - образ зашифрован или сжат целиком. Если значение скачет (низкая энтропия в начале, высокая в середине, снова падение) - нормальная структура: код загрузчика + сжатая файловая система (squashfs/cramfs). Именно этот паттерн характерен для большинства незашифрованных прошивок MIPS-роутеров.Binwalk v3 (полностью переписанный на Rust) заметно быстрее и точнее предыдущих Python-версий на больших образах. Unblob лучше справляется с нестандартными контейнерами, характерными для китайских чипсетов (HiSilicon, Realtek) - если binwalk буксует, пробуем его. Стандартная распаковка:
binwalk -e firmware.bin создаёт директорию с извлечённой файловой системой.Анализ прошивки: поиск уязвимостей роутеров
Статический анализ: бэкдоры и хардкод-пароли в firmware
После экстракции файловой системы (squashfs в 90% случаев для MIPS-роутеров) начинается охота за артефактами. Приоритет - от самого быстрого к самому трудоёмкому:1. Хардкод-пароли и ключи. Файлы
etc/shadow, etc/passwd, конфигурации в etc/config/ (для OpenWrt-based прошивок), скрипты в usr/sbin/. В прошивках на базе Realtek SDK хардкод-пароли нередко зашиты внутри ELF-бинарей - тут без strings с последующим анализом в Ghidra не обойтись.2. Debug-интерфейсы. Ищем telnetd, dropbear (SSH) с пустым паролем или запуск без аутентификации в init-скриптах (
etc/init.d/, etc/rc.d/). Типичный паттерн: telnetd запускается на нестандартном порту (23023, 26000) и не отображается в веб-интерфейсе. Классический A05:2021 (Security Misconfiguration).3. Устаревшие компоненты. Прогоняем
strings по основным бинарям - вылезут версии BusyBox, OpenSSL, libcurl, ядра Linux. Каждую версию сверяем по NVD (nvd.nist.gov). BusyBox до 1.36 и OpenSSL до 3.x нередко имеют известные CVE.4. Command injection в веб-интерфейсе. CGI-бинари в
usr/lib/cgi-bin/ или Lua-скрипты в usr/lib/lua/ - основная attack surface. Ищем вызовы system(), popen(), execve() с конкатенацией пользовательского ввода через Ghidra-декомпиляцию MIPS-бинарей httpd-демона. Это A03:2021 (Injection).
Bash:
# Базовый поиск хардкод-паролей в распакованной файловой системе
find ./squashfs-root -type f \( -name "*.conf" -o -name "*.sh" \) \
-exec grep -l -i "password\|secret\|key\|token" {} \;
# Поиск бинарей с вызовами system/popen (потенциал command injection)
grep -rl "system\|popen" ./squashfs-root/usr/sbin/ 2>/dev/null
# Проверка init-скриптов на запуск debug-сервисов
grep -rn "telnetd\|dropbear" ./squashfs-root/etc/init.d/Эмуляция и динамический анализ firmware
Статический анализ даёт артефакты, но для подтверждения эксплуатабельности нужна эмуляция. Firmadyne (и его форк FirmAE) автоматизирует запуск Linux-based firmware в QEMU: создаёт виртуальную сеть, эмулирует NVRAM, поднимает веб-интерфейс. Процесс через FAT (Firmware Analysis Toolkit):./fat.py firmware.bin - извлечение файловой системы, определение архитектуры (MIPS/ARM), настройка QEMU-образа, запуск эмуляции. После запуска роутер доступен по IP в виртуальной сети и тестируется стандартными инструментами: Burp Suite для веб-интерфейса, ручной fuzzing CGI-эндпоинтов.Оговорка: success rate у firmadyne - 40-60%, с ARM-прошивками дела обстоят хуже, чем с MIPS. Если полная эмуляция не взлетела - есть QEMU user-mode для отдельных бинарей:
qemu-mips -L ./squashfs-root ./squashfs-root/usr/sbin/httpd. Параметр -L указывает корневую файловую систему для загрузки зависимостей - аналог chroot, но для кросс-архитектуры.Расшифровка защищённых прошивок: firmware diffing
Ряд вендоров (D-Link, и постепенно TP-Link) перешёл на шифрование firmware-образов. По данным Payatu (анализ D-Link DIR-822 US variant), типичный подход: вендор выпускает «transition version» - промежуточную прошивку, ещё не зашифрованную, но уже содержащую утилиту дешифрования для последующих обновлений.Техника firmware diffing: берём две соседние версии (последнюю незашифрованную и первую зашифрованную), распаковываем обе файловые системы и сравниваем через
diff -rq или kdiff3. Ищем новые бинари с именами вроде encimg, fw_decrypt, imgdecrypt. В случае DIR-822 бинарь encimg принимал параметры -d -i <firmware_path> -s <image_sign>, где image_sign хранился в /etc/config/image_sign - по сути хардкод-ключ для AES. Шифрование есть, а ключ лежит рядом. Ну красота.Предусловия: работает если вендор использует симметричное шифрование с ключом в прошивке. Не работает если применяется PKI с аппаратной верификацией подписи (Secure Boot на базе eFuse) - это встречается в enterprise-оборудовании (Cisco, Juniper, Fortinet), но крайне редко в SOHO-сегменте.
Сравнение инструментов анализа прошивки
| Инструмент | Назначение | Преимущества | Ограничения | Когда использовать |
|---|---|---|---|---|
| binwalk v3 | Распаковка, энтропия | Быстрый (Rust), де-факто стандарт | False positives на нестандартных форматах | Первичный анализ любого firmware |
| unblob | Распаковка | Лучше с нестандартными контейнерами | Менее зрелый, документация скудная | Когда binwalk не справляется |
| Ghidra | Реверс бинарей | Бесплатный, MIPS/ARM декомпиляция | Медленнее IDA Pro на больших бинарях | Анализ httpd, CGI, crypto-бинарей |
| firmadyne/FirmAE | Эмуляция firmware | Автоматизация QEMU | Success rate 40-60%, ARM хуже MIPS | Динамический анализ веб-интерфейса |
| CH341A + flashrom | SPI flash dump | Надёжный дамп без софт-доступа | Требует вскрытия корпуса | Нет доступа к firmware иным способом |
| radare2/rizin | Реверс, скрипты | Скриптуемость, CLI-workflow | Высокий порог входа | Batch-анализ нескольких бинарей |
Ограничения firmware-аудита в современных средах
Secure Boot и signed firmware. Enterprise-роутеры (Cisco ISR, Juniper SRX, Fortinet FortiGate) используют аппаратную верификацию подписи. Модификация образа (T1601.001, Patch System Image) детектируется на уровне загрузчика. SOHO-устройства в подавляющем большинстве этой защиты не имеют - тут вольница.Cloud-managed firmware. Устройства с облачным управлением (Ubiquiti UniFi, TP-Link Omada) обновляются автоматически, прошивка верифицируется контроллером. Снижает window of exposure, но не исключает уязвимости в обновлённом образе - обновили, а дыру не закрыли, бывает.
RTOS и bare-metal. Часть IoT-устройств работает не на Linux, а на FreeRTOS, ThreadX, Zephyr. Binwalk и firmadyne к ним неприменимы - нужен анализ через Ghidra с ручной разметкой адресного пространства. Это другой класс задач, выходящий за рамки описанного workflow.
Отсутствие логирования. По OWASP A09:2021 (Security Logging and Monitoring Failures), подавляющее большинство SOHO-роутеров не логируют firmware-модификации. Даже если злоумышленник полностью заменит прошивку (T1495, Firmware Corruption), обнаружить это через штатные механизмы устройства почти невозможно. Единственный выход - внешний мониторинг: периодическое снятие хеша прошивки через JTAG/UART и сравнение с эталоном.
Чеклист аудита безопасности сетевого оборудования
Готовый чеклист для включения в отчёт по пентесту или передачи сетевым администраторам:- Идентификация устройства: модель, аппаратная ревизия, текущая версия firmware. Проверить на сайте вендора наличие обновлений.
- Проверка известных CVE: сверить версию firmware с базой NVD (nvd.nist.gov) и вендорскими advisory. Неустранённые CVE - critical finding.
- Экстракция firmware: получить образ одним из методов (FTP вендора, UART, SPI dump). Проверить энтропию через
binwalk -E. - Распаковка файловой системы:
binwalk -eилиunblob. Убедиться в наличии squashfs/cramfs/jffs2. - Поиск хардкод-паролей: проверить
etc/shadow,etc/passwd, конфигурационные файлы, строки в бинарях httpd/cgi. - Аудит debug-интерфейсов: проверить init-скрипты на запуск telnetd/dropbear без аутентификации, наличие UART shell и JTAG-пинов на плате.
- Проверка устаревших компонентов: извлечь версии BusyBox, OpenSSL, libcurl, ядра Linux; сверить с CVE-базами.
- Анализ веб-интерфейса: проверить CGI/Lua-обработчики на command injection, directory traversal, auth bypass. Приоритет - бинари httpd, goahead, lighttpd.
- Эмуляция (если применимо): запустить firmware через firmadyne/FAT, подтвердить найденные уязвимости в динамике.
- Проверка механизма обновления: HTTP или HTTPS? Есть ли проверка подписи firmware? Возможен ли даунгрейд до уязвимой версии (T1601.002)?
- Документирование: зафиксировать findings с указанием severity, шагов воспроизведения и рекомендаций. Привязать к MITRE ATT&CK ID и OWASP-категориям.
Отдельно про Realtek SDK, через который построены прошивки десятков OEM-брендов. Одна уязвимость в SDK множится на сотни моделей от разных вендоров - это supply chain в чистом виде (T1195.003), и политические решения её не закрывают. Закрывает только аудит конкретного железа, которое стоит в вашей сети. И ещё момент: формальный чеклист без реального reverse engineering - пустая трата времени. Пока не распаковал squashfs, не прогнал
strings по httpd, не проверил init-скрипты на скрытый telnetd - ты не провёл аудит, ты заполнил бумагу. Хочется руки в крови - задачи по reverse engineering ждут на HackerLab.
