😱 Представьте: ваш NAC, сердце политик доступа, тихо отдаёт злоумышленнику пароли всех серверов. Не через сложный 0-day, а через банальный XML. Со мной такое чуть не случилось в 2025-м. Рассказываю, как сегодня горят сети из-за свежих дыр в Cisco ISE и AsyncOS, и что делать, чтобы не оказаться следующими. В конце — жёсткий чек-лист и подарок.
Знаете, что самое неприятное в работе SOC?
Когда угроза приходит не с тёмной стороны интернета, а изнутри, от устройства, которому ты безоговорочно доверяешь.
От того самого Cisco ISE, что контролирует, кто и с каким ноутбуком попал в сеть. Или от почтового шлюза AsyncOS, который годами верно фильтрует спам.
Честно говоря, в последние полтора года я вижу чёткий тренд: атаки сместились на инфраструктурное ПО. Не на конечные точки, а на те самые системы, которые призваны защищать. И Cisco оказалась в эпицентре. Почему? Да потому что эти решения стоят в самом сердце сетей тысяч российских компаний, включая банки и ОКИИ. Взломал ISE — получил ключи от всего королевства.
И знаете, что пугает больше всего? Многие CISO до сих пор считают эти системы «железками», которые «просто работают».
А тем временем, за последние 18 месяцев вышла целая серия критических уязвимостей, которые превращают ваш щит в удобную дверь для атакующего. Давайте разбираться без глянца, на пальцах и с примерами из нашей практики.
Часть 1: Тихий апокалипсис в ISE. CVE‑2026‑20029 — это не «средняя» уязвимость, а билет в админку
Начнём с той самой дыры, из-за которой у меня потели ладони в одном проекте для крупного финсектора. CVE‑2026‑20029. В бюллетенях её скромно классифицируют как XXE (XML External Entity) с требованием наличия прав администратора. Звучит не так страшно, да? На практике же это выглядит как полный провал.
Представьте: злоумышленник (уже имеющий учётку админа, пусть даже низкоуровневого) заходит в веб-морду ISE и загружает безобидный на вид XML-файл. А в этом файле — специальная строка, которая говорит системе: «Эй, вместо этого тега подставь содержимое вот того файла с диска». И система, верная, подставляет. А файл-то может быть каким угодно — /etc/shadow с хэшами паролей, конфигурацией с ключами доступа к другим системам, служебными логами.
Что на практике?
Мы на пентесте так вытаскивали конфиг RADIUS-сервера из памяти ISE, где в открытом виде лежали общие секреты для точек доступа. Получив их, атакующий может организовать MiTM-атаку или подделать легитимное устройство. И это лишь один файл.
Но главная фишка в другом. Все думают: «Ну и что, нужны права админа». А откуда они берутся? Правильно — фишинг, слабые пароли, неотозванные доступы уволившихся сотрудников, банальная небрежность. В реальных инцидентах, которые мы расследовали, компрометация начиналась именно с низкоуровневой учётки в ISE, которую забыли удалить. А дальше — цепная реакция.
Личный кейс: В одном госкомпании мы нашли учётку «service_admin» с паролем «Cisco123», которая висела на старом ISE 3.1. Её добавили для интеграции три года назад и благополучно забыли. Через неё и эту XXE вытащили сертификаты для подписи токенов доступа. Дальше — тишина. Атака стала практически невидимой.
🔐 Вывод первый:
Любая уязвимость, требующая аутентификации, — это угроза высочайшего уровня. Потому что учётные данные — самое слабое звено. Всегда.
Часть 2: Pre-Auth RCE — мечта хакера сбылась. CVE‑2025‑20337 и кошмар без пароля
А теперь забудьте про необходимость иметь логин и пароль. Следующая история — CVE‑2025‑20337. Уязвимость в десериализации на недокументированном эндпоинте. Переводя на человеческий: в ISE есть скрытая дверь для служебных нужд. Эту дверь нашли ребята из Amazon Threat Intelligence. И оказалось, что в неё можно постучаться без предъявления пропуска и попросить выполнить произвольный код.
Это уже уровень апокалипсиса.
Удалённое выполнение кода до аутентификации. Злоумышленнику даже не нужно знать пароль. Достаточно отправить хитромудрый запрос по сети на порт вашего ISE. И он получает оболочку с правами root. Всё. Игра окончена.
На что это похоже? Представьте, что у вас суперсовременный сейф с биометрией. Но кто-то обнаружил, что если постучать по боковой стенке три раза и дважды свистнуть, задняя стенка отвалится. Именно так это и работает.
Последствия?
Полный контроль. Установка веб-шеллов (мы видели кастомные варианты, маскирующиеся под легитимные компоненты ISE), перехват всех процессов аутентификации, изменение политик «на лету». Атакующий может, например, добавить в доверенную группу свой заражённый ноутбук и месяцами воровать данные, не вызывая подозрений.
Компании платят десятки миллионов за систему класса NAC, а её безопасность разбивается о банальную ошибку в коде обработки данных. И ведь исправление вышло давно, но сколько ISE до сих пор не обновлены? Сотни.
Часть 3: AsyncOS — забытый король уязвимостей. CVE‑2025‑20393 и китайская группировка у вас в почте
Давайте отойдём от ISE и посмотрим на другой краеугольный камень — почтовые и веб-шлюзы Cisco на AsyncOS. Казалось бы, железный работяга, фильтрует спам. Что может пойти не так?
Всё. CVE‑2025‑20393 — критическая дыра класса «Improper Input Validation». Снова pre-auth RCE, снова root. Но интереснее кто её эксплуатирует. Активно это делала китайская группировка, которую в индустрии называют UAT‑9686. Их почерк — чистота и скрытность.
Что они делают?
- Через уязвимость получают полный контроль над шлюзом.
- Устанавливают туннели (Reverse SSH, Chisel) для скрытого доступа извне.
- Разворачивают свой бэкдор под названием AquaShell.
- И… чистят логи своим скриптом AquaPurge.
Вы только вдумайтесь. Они не просто врываются, они убирают за собой. После их работы в логах AsyncOS — идеальная чистота. Ни намёка на вторжение. Обнаружить такое можно только по аномальной сетевой активности или с помощью EDR на самом аппаратном сервере, если он есть.
Метафора: Это как профессиональный вор, который не только обчищает сейф, но и пылесосит пол, стирая отпечатки. Вы приходите на работу, почта работает, всё тихо. А из вашего корпоративного шлюза уже месяц идёт утечка всех писем финансистов в неизвестном направлении.
Часть 4: Snort 3 в IOS XE — когда система защиты сама становится угрозой
И напоследок — изящная проблема, которая многих ставит в тупик. Речь о DoS-уязвимости в Snort 3, который работает на маршрутизаторах Cisco IOS XE. Казалось бы, отказ в обслуживании — не так страшно, перезагрузил и забыл.
Но давайте посмотрим глубже. Snort 3 — это движок системы предотвращения вторжений (IPS). Его задача — анализировать трафик и блокировать атаки. Что происходит, когда он «падает»? Правильно, ваш IPS перестаёт работать. На какое-то время сетевой трафик идёт «вслепую», без какой-либо инспекции.
В этом окне, которое может длиться от нескольких секунд до минут (пока система перезапустится), атакующий может протолкнуть тот самый вредоносный трафик, который в обычных условиях был бы заблокирован. Это как отвлечь охранника на кофе, пока его напарник проносит запрещённый груз.
Наблюдение из реального SOC: Мы часто видим сложные атаки, где DoS — не цель, а средство. Сначала «роняют» компонент защиты, чтобы обезопасить основной канал проникновения. И уязвимость в Snort 3 идеально ложится в эту тактику.
10 правил защиты Cisco-инфраструктуры в 2026 году (выпишите на стену)
По моему опыту, теория мертва без конкретики.
Вот список действий, который мы выдаём после каждого аудита. Не обещаю, что будет легко, но это спасёт.
- Апдейт ISE и AsyncOS — немедленно и тотально. Не выборочно, не «на тестовый». Если версия ниже 3.2 — миграция это ваш главный KPI на квартал. Для 3.2 — патч 8, для 3.3 — патч 8, для 3.4 — патч 4. Версия 3.5 не затронута CVE‑2026‑20029, но проверьте остальные.
- Выкиньте management-интерфейсы из интернета. Это даже не правило, это крик души. Никакого прямого доступа к вебу ISE, AsyncOS или IOS XE извне. Только через VPN, выделенный Jump-хост (желательно с PAM-решением), закрытый сегмент. Примените ACL на фаерволе.
- Жёсткий контроль учёток. Минимизируйте количество администраторов. Разделите роли: пусть один настраивает политики, другой — смотрит логи. Внедрите MFA для ВСЕХ админских аккаунтов. Ротация паролей — строго по регламенту.
- Бейте по уязвимостям регуляторными методами. CISA KEV (каталог эксплуатируемых уязвимостей) — ваша настольная книга. Если CVE там есть, её приоритет — «вчера». В российской практике ориентируйтесь на рекомендации ФСТЭК и ГосСОПКА.
- Детектируйте аномалии в поведении админов. Централизуйте логи с ISE, AsyncOS, IOS XE в вашу SIEM. Настройте правила: «Попытка доступа к ISE из необычной страны», «Загрузка файла в ISE в нерабочее время», «Массовое чтение конфигов».
- Примените технические контрмеры для XXE. На уровне WAF или самого приложения отключите обработку внешних XML-сущностей (CWE‑611). Настройте парсеры ISE на запрет внешних DTD. Это убивает целый класс атак.
- Пентестите свою инфраструктуру защиты. Не верьте, что NAC или почтовый шлюз неприкосновенны. Включайте их в регулярные тесты на проникновение. Особенно — недокументированные API и служебные порты.
- Готовьтесь к инцидентам заранее. Имейте на полке готовый план реагирования на компрометацию ISE или AsyncOS. Что делать? Отключать, изолировать, поднимать резервную копию (коричневую, проверенную), менять все связанные пароли и сертификаты.
- Следите не только за Cisco. Вокруг ISE и AsyncOS — целая экосистема: AD для аутентификации, серверы сертификатов, SIEM. Компрометация одного звена тянет за собой остальные. Ваша защита — настолько сильна, насколько сильно её самое слабое звено.
- Примите Zero Trust как философию. Не верьте внутренней сети по умолчанию. ISE — отличный инструмент для его реализации. Но и сам ISE должен быть верифицируемым устройством. Никакого слепого доверия, даже к системам безопасности.
══════
Нужна помощь, чтобы всё это внедрить?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист аудита Cisco-инфраструктуры + дорожную карту исправления косяков + коммерческое предложение.
Первые 5 заказов каждый месяц — расширенный аудит безопасности на 12 страниц в подарок!
══════
Часть 5: Фреймворки и реальная жизнь. Почему NIST и ФСТЭК правы, но этого мало
Все мы читали NIST SP 800-207 (Zero Trust) или привыкли к контрольным вопросам по 152-ФЗ. И там, и там правильно указано: системы контроля доступа (как ISE) — критичны, их надо усиленно защищать. Но на бумаге это выглядит как абстрактный контроль «П.4.12.б». А в жизни — это адская работа по исправлению конкретных конфигов, настройке правил корреляции и борьбе с техдолгом.
По моему опыту, главная ошибка — формальный подход. «У нас есть ISE? Есть. На нём стоит MFA для админов? Поставили галочку. Отчёт для ФСТЭК готов». А то, что MFA работает только для одного из пяти интерфейсов, а пароль от учётки «backup» написан на стикере под клавиатурой — об этом уже никто не думает.
Работа SOC — это искусство видеть суть за формальностью. Увидеть не «долю закрытых уязвимостей», а «какую конкретно дыру в ISE может использовать атакующий, который уже сидит в нашей сети». Это другое мышление.
Часть 6: Самые грубые ошибки, которые я видел (не повторяйте)
Давайте без прикрас. Вот топ-3 косяка, после которых хочется плакать:
- «У нас же есть фаервол, ISE внутри сети». И что? Внутренний злоумышленник или продвинутая угроза, прошедшая периметр (а такое бывает сплошь и рядом), увидит ISE как лакомую цель. Защита должна быть многослойной, даже внутри.
- Выборочное обновление. Обновили ядро ISE, но забыли про Passive Identity Connector (ISE‑PIC). А там та же дыра. Или обновили один кластер из трёх, а на остальных «потом». Атака идёт по самому слабому звену — по «потом».
- Логи — в никуда. Логи ISE, которые хранятся локально и перезаписываются раз в неделю — это не логи, это профанация. Их нужно слать в защищённую SIEM, желательно на выделенный лог-хост, к которому у администраторов ISE нет доступа. Чтобы при компрометации ISE атакующий не мог стереть следы.
Итоговые мысли (не банальные):
Безопасность Cisco ISE и AsyncOS — это не про галочки. Это про постоянную, кропотливую работу: анализ бюллетеней, тестирование патчей на стенде, жёсткий контроль доступа, тонкая настройка мониторинга. Это как обслуживание турбины самолёта: нельзя пропустить ни одной детали.
Ваша сеть 2026 года держится не на стенах периметра, а на прочности её ключевых узлов — систем контроля доступа и шлюзов. Если они дадут трещину, все остальные защиты могут стать бесполезны.
У вас ещё остались вопросы? Сомневаетесь, что ваш текущий подход выдержит атаку уровня CVE‑2025‑20337? Тогда давайте проверим.
FAQ: Ответы на главные 10 вопросов (как любит Дзен)
1. CVE‑2026‑20029 действительно опасна, если нужны права админа?
Да, чрезвычайно. Наличие учётки — частое явление. Атака через неё даёт доступ к самым чувствительным данным (пароли, ключи, конфиги), что ведёт к полной компрометации.
2. Наш ISE стоит во внутренней сети, доступа из интернета нет. Мы в безопасности?
Нет. Угроза может прийти изнутри (сетевой червь, недовольный сотрудник, уже проникшая APT). Pre-auth RCE (как CVE‑2025‑20337) не требует выхода в интернет для эксплуатации.
3. Обновили ISE до 3.5. Надо ли что-то делать ещё?
Обязательно. 3.5 не подвержена CVE‑2026‑20029, но проверьте другие CVE, закройте management-интерфейсы, настройте MFA, обеспечьте вынос логирования.
4. Какие признаки могут указывать на взлом ISE или AsyncOS?
Аномальная активность админ-учёток (входы ночью, с необычных IP), появление неизвестных файлов в системе, необъяснимые падения служб, подозрительные исходящие подключения с этих узлов.
5. Мы под 152-ФЗ. Эти уязвимости затрагивают выполнение требований?
Безусловно. Компрометация ISE или шлюза — это нарушение целостности и конфиденциальности КИ, что является прямым нарушением требований регулятора.
6. WAF защитит от этих атак?
Частично. От некоторых XXE и инъекций — да. Но от атак на недокументированные API или уязвимости в десериализации, которые идут по «легитимным» каналам, WAF часто бессилен.
7. Как часто нужно проверять такие системы?
Проверка конфигураций и установка патчей — непрерывный процесс. Полноценный аудит безопасности (не сканирование уязвимостей, а именно аукт) — минимум раз в год, а лучше раз в полгода.
8. Патч установить сложно? Боимся сломать работу.
Страх понятен. Поэтому патч сначала ставят на тестовый стенд, тщательно проверяют. В идеале — иметь кластерную конфигурацию, где можно последовательно обновлять узлы без остановки сервиса.
9. Какие аналоги Cisco ISE более безопасны?
У каждой платформы есть свои уязвимости. Вопрос не в бренде, а в качестве процессов эксплуатации: своевременное обновление, грамотная настройка, постоянный мониторинг.
10. С чего начать, если всё плохо?
С инвентаризации. Составьте полный список всех ваших Cisco-устройств (ISE, AsyncOS, IOS XE), их версий и точек подключения. Затем проверьте каждое по списку уязвимостей от Cisco PSIRT. Или доверьте это экспертам.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]