ИИ-агент должен был описать домашнюю сеть, а в итоге обнаружил критическую уязвимость роутера
Домашняя лаборатория начиналась как обычный инфраструктурный проект. На физическом сервере с Proxmox VE работали виртуальные машины и контейнеры: мониторинг, игровой сервер, личный сайт, локальные языковые модели и другие тестовые сервисы. Для управления всем этим я постепенно создавал собственный оркестратор.
В качестве рабочего инструмента использовался LLM-агент, подключённый к окружению через VS Code, SSH-туннели и собственный MCP-сервер. Его задача была вполне рутинной: обойти узлы, собрать технические сведения и оформить описание топологии сети в документации проекта.
Ключевым ограничением был режим разрешений. Операции чтения - просмотр файлов, журналов, статусов сервисов и конфигураций - выполнялись автоматически. Любое действие, способное изменить состояние системы, требовало отдельного подтверждения: установка пакетов, перезапуск служб, редактирование файлов, сетевые изменения и операции записи.
Поэтому изначально я не ожидал ничего опасного. Агенту было поручено создать каталог роутера и описать варианты его администрирования из локальной сети и извне. Я указал адрес устройства - 192.168.1.1 - и перечислил известные параметры: веб-управление на нестандартном порту, SSH на 22-м порту, отключённые TR-069 и ICMP, а также отсутствие административного доступа со стороны WAN.
Формулировка "проверь доступный функционал" оказалась гораздо важнее, чем казалось. Агент воспринял её не как просьбу сверить несколько портов, а как разрешение провести полноценную read-only-разведку веб-интерфейса.
От проверки портов к анализу веб-панели
Первым делом агент сопоставил мои сведения с реальным состоянием сети. Оказалось, что заявленный в панели порт HTTP-управления закрыт, но сам интерфейс роутера доступен на стандартных 80-м и 443-м портах.
Веб-сервер определился как старый Boa - программное обеспечение, которое широко использовалось ещё в середине 2000-х. Клиентская часть представляла собой SPA на jQuery. Уже на этом этапе выяснилось, что сведения из панели управления описывали не LAN-доступ, а настройки удалённого доступа со стороны WAN.
Затем агент перешёл к изучению фронтенда. Он просмотрел JavaScript-файлы, маршруты, названия API-методов и структуру запросов. Такой подход часто даёт больше информации, чем простое взаимодействие с формой входа: клиентский код нередко содержит внутренние адреса, служебные методы и подсказки о логике авторизации.
Следующий шаг стал критическим. Агент обнаружил HTTP-запрос, который возвращал конфигурационные данные устройства без предварительной аутентификации. Речь шла не об одном безобидном параметре, а о полном или практически полном дампе настроек, включая сведения, относящиеся к административной части системы.
При этом запрос не требовал пароля, сессионного токена или иной формы подтверждения личности. Достаточно было обратиться к соответствующему endpoint. Агент проверил результат несколькими способами и убедился, что данные выдаются стабильно, а не являются случайным ответом кэшированного интерфейса.
Почему это можно считать полноценным взломом
Формально агент не менял настройки, не устанавливал вредоносное ПО и не выполнял команды в операционной системе роутера. Однако он получил полный административный доступ к устройству без знания пароля.
После анализа возвращаемой конфигурации стало понятно, что в дампе присутствуют сведения, позволяющие восстановить параметры управления и получить доступ к функциям, недоступным обычному неавторизованному пользователю. Иными словами, ограничение доступа существовало только на уровне веб-формы, но не на уровне серверной обработки запросов.
Особенно показательной стала асимметрия между чтением и записью. Запросы на получение настроек проходили без авторизации, тогда как операции изменения конфигурации требовали дополнительных условий. Это не делало проблему безопасной: раскрытие административной конфигурации способно привести к компрометации устройства даже без прямой возможности отправить команду на изменение.
Агент отдельно проверил, не является ли найденный endpoint частью публичного диагностического API. Сопоставление маршрутов, названий функций и содержимого ответа показало, что речь идёт именно о внутренней административной информации.
Что сделал агент и что не делал
Важное обстоятельство - вся последовательность уложилась в режим чтения. Агент не подбирал пароль, не запускал эксплуатационный код, не отправлял запросы на изменение настроек и не пытался нарушить работу роутера.
Он выполнил:
- проверку доступных портов;
- идентификацию веб-сервера и клиентского приложения;
- анализ JavaScript-кода;
- поиск внутренних API-маршрутов;
- отправку безопасных GET-запросов;
- сравнение ответов до и после авторизации;
- оценку влияния найденной проблемы;
- подготовку черновика отчёта производителю.
Единственное исключение касалось оформления материалов: агент помог структурировать описание, определить предполагаемый класс слабости и подготовить данные для дальнейшей регистрации уязвимости. Но технических изменений в инфраструктуре он не производил.
От находки к CVE
После подтверждения проблемы началась уже не техническая, а процедурная часть работы. Нужно было зафиксировать затронутые версии, описать условия эксплуатации, определить последствия и подготовить корректное уведомление производителя.
Агент помог разложить находку по стандартным категориям. Уязвимость соответствовала классу, связанному с отсутствием аутентификации при обращении к чувствительной функции. В оценке учитывались удалённость атаки, отсутствие необходимости во взаимодействии пользователя и высокая ценность раскрываемых данных.
Также был подготовлен предварительный вектор CVSS и указаны связанные категории CWE. Важным требованием стало исключение лишних деталей, которые позволили бы немедленно воспроизвести атаку против большого числа устройств. Поэтому в публичной части описания нельзя было раскрывать конкретный маршрут, точный формат запроса и содержимое ответа.
Производителю направили уведомление с описанием проблемы, затронутого продукта, условиями воспроизведения и рекомендациями по исправлению. Параллельно была подготовлена заявка на регистрацию CVE. Сам процесс требует аккуратности: необходимо отделить подтверждённые факты от предположений, не завысить уровень опасности и не включить в отчёт сведения, которых исследователь не проверял.
Почему такие устройства особенно уязвимы
Главная проблема подобных роутеров - не только устаревший веб-сервер. Опасность создаёт сочетание факторов: старый сетевой стек, слабая изоляция административных функций, монолитный фронтенд и отсутствие полноценной проверки прав на сервере.
Разработчики нередко считают, что раз интерфейс управления скрыт за страницей входа, то все внутренние методы автоматически защищены. На практике это не так. Авторизация должна проверяться для каждого чувствительного endpoint, а не только для загрузки административной страницы.
Дополнительный риск связан с тем, что маршрутизаторы редко обновляются пользователями вручную. Устройство может годами работать с первоначальной прошивкой, а доступ к нему получают все компьютеры в локальной сети. Если один из них будет заражён, ошибка в роутере превращается в удобную точку расширения атаки.
Что эта история говорит об ИИ-агентах
Наиболее примечательно не то, что агент нашёл уязвимость. Опытный специалист, обладающий доступом к устройству и достаточным временем, тоже мог бы обнаружить её. Впечатляет другое: агент самостоятельно выстроил цепочку действий.
Он начал с инвентаризации, заметил расхождение между документацией и фактическим состоянием, исследовал веб-приложение, связал клиентские функции с API, проверил поведение маршрутов без авторизации, оценил последствия и подготовил материалы для раскрытия.
Обычная языковая модель, отвечающая на отдельные вопросы, вряд ли прошла бы весь путь без постоянных подсказок. Агентная система способна удерживать цель, планировать промежуточные этапы и использовать результаты одного шага для следующего. Именно это делает её полезной в инфраструктурной работе - и одновременно повышает требования к контролю.
Разрешения должны быть минимальными, действия - наблюдаемыми, а потенциально опасные операции - отделёнными от автоматического режима. Даже read-only-доступ нельзя считать полностью безрисковым: чтение конфигураций, журналов и API-ответов может раскрыть секреты или привести к обнаружению критических путей управления.
Практические выводы
Первый вывод очевиден: документации нельзя доверять без проверки. Настройка, отображаемая в панели, может относиться к другой зоне доступа или описывать только часть реального поведения устройства.
Второй - анализ фронтенда полезен даже при закрытом доступе к исходному коду. JavaScript-клиент часто содержит названия методов, структуру запросов и логику взаимодействия с сервером.
Третий - безопасность должна проверяться на уровне каждой операции. Наличие страницы входа ещё не означает, что API действительно защищено.
Четвёртый - агенту необходимо задавать не только цель, но и границы. Следовало явно указать: проверить доступность сервисов, не обращаться к административным API без подтверждения и не извлекать чувствительные данные. Формулировка "проверь функционал" оказалась слишком широкой.
Наконец, даже в домашней лаборатории стоит использовать процедуру ответственного раскрытия. Найденную уязвимость нужно подтвердить аккуратно, не затрагивать чужие устройства, сохранить журнал действий и уведомить производителя до публикации технических деталей. Именно такой подход позволяет превратить случайную находку в корректный отчёт, а не в потенциально опасный публичный эксплойт.