ИИ-агент обнаружил критическую уязвимость домашнего роутера и оформил CVE: кейс исследователя

# Как ИИ-агент за одну ночь взломал роутер и оформил CVE

Событие произошло в рамках частного проекта по созданию оркестратора для домашней лаборатории. Задача стояла простая: автоматизировать сбор метаданных серверов и фиксацию сетевой топологии. Однако один из шагов проверки функциональности привел к нештатным результатам.

Механика обнаружения: от прозвона портов к дампу конфигурации

Автор сформулировал задачу для LLM-агента следующим образом: создать документацию по домашнему роутеру, определить способы его администрирования из локальной сети (LAN) и проверить доступность функционала.

Агент начал с рутинной проверки портов, заявленных в веб-интерфейсе оборудования. Фактическая проверка показала расхождение с документацией: заявленный порт HTTP-управления был закрыт, но сам веб-интерфейс работал. Анализ JavaScript-файлов фронтенда интерфейса позволил агенту выявить реальные API-эндпоинты бэкенда.

Ключевым моментом стало обнаружение эндпоинта для чтения конфигурации. При тестовом запросе к этому адресу без использования учетных данных (без токена сессии и пароля) система вернула ответ 200 OK и полный набор данных о конфигурации роутера (примерно 37 КБ). В полученном ответе содержались: * Пароль административной панели (кодируется в Base64, что не обеспечивает шифрования); * Ключи WPA2 для всех подключенных Wi-Fi сетей; * Учетные данные сервисов удаленного управления; * Актуальные сессионные и CSRF-токены.

Также была выявлена асимметрия в защите: эндпоинт для записи конфигурации корректно требовал валидную сессию и аутентификацию, в то время как чтение работало открыто. Это классический пример уязвимости, когда доступ к критически важным данным не защищен проверкой подлинности.

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

Анализ рисков и процесс координации раскрытия

После получения доступа агент провел формальный анализ уязвимости. Было установлено, что внешняя сеть (WAN) должным образом защищена: все порты управления закрыты, а функции удаленного управления отключены. Уязвимость является локальной (LAN-based).

Несмотря на локальность, риски значительны. Домашние сети часто содержат множество IoT-устройств, а современные прошивки редко обладают функциями ограниченного доступа к панели администратора по IP-адресам внутри локальной подсети. Это означает, что любое устройство в одной сети с роутером потенциально имеет доступ к конфиденциальным данным.

Агент выполнил стандартную процедуру координации раскрытия уязвимости (Coordinated Disclosure): 1. Уведомление вендора: Был подготовлен подробный отчет на английском и русском языках, включающий описание уязвимости, условия воспроизведения и рекомендации по исправлению. Вендору было дано стандартное окно на исправление (обычно 90 дней). 2. Регистрация в MITRE: Для регистрации уязвимости с присвоением идентификатора CVE (Common Vulnerabilities and Exposures) запрос был отправлен через программу CNA of Last Resort. Агент самостоятельно заполнил форму, определив основные классы уязвимости (CWE-306 — отсутствие аутентификации для критических функций) и рассчитав индекс CVSS 3.1, указав на возможность полного компрометирования устройства. 3. Дополнительная фиксация: Данные были параллельно отправлены в независимую базу VulDB для публичного индекса.

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

Заключение и выводы для пользователей

Этот кейс иллюстрирует двойственную роль искусственного интеллекта в информационной безопасности. С одной стороны, автоматизация рутинных задач по сбору данных и проверке гипотез ускоряет процесс поиска уязвимостей многократно. С другой стороны, без строгого контроля и понимания контекста такие системы способны самостоятельно выявлять критические проблемы, которые могли остаться незамеченными.

Инженер рекомендует всем пользователям домашних SOHO-роутеров провести собственные проверки безопасности: * Полностью отключить функции управления со стороны WAN (интернета). * Проверить возможность доступа к веб-панели из локальной сети без пароля. * Использовать уникальные пароли для административных аккаунтов, не совпадающие с паролями от пользователей или IoT-устройств. * Помещать IoT-устройства и гостей в изолированные гостевые сети.

Как сказано в одной из классических цитат кибербезопасности: «Ни одна система не безопасна». Автоматизированные инструменты лишь помогают быстрее увидеть, где именно есть бреши в защите.

*Примечание: В связи с действующим эмбарго и процессом координации с вендором, название компании-производителя, точная модель устройства и воспроизводимый код атаки (PoC) в данной статье не раскрываются. Полная техническая информация будет доступна после публикации официального отчета (Advisory).*