Ivanti Connect Secure: как детектировать компрометацию устройства без вендорского патча

В середине января Ivanti подтвердила критические уязвимости в Connect Secure (бывший Pulse Secure): CVE-2024-21887 - инъекция команд через веб-компонент для аутентифицированных администраторов, и CVE-2024-21888 - повышение привилегий в самом SSL VPN. В реальных атаках эта пара использовалась в связке с CVE-2023-46805 (обход аутентификации) - вместе они дают удалённое выполнение кода без каких-либо учётных данных. По оценкам CISA и нескольких вендоров в области threat intelligence, цепочка эксплуатируется как минимум с декабря 2023 года.

Примерно в то же время к нам обратился клиент: на Ivanti Connect Secure зафиксирована аномальная активность. Устройство держит VPN-периметр для части пользователей, обновлений не было несколько месяцев - в общем, классический сценарий.

Рассказываем, как мы разбирались с этим вживую.

Что произошло

На устройстве сработал внешний мониторинг по исходящим соединениям - нетипичный трафик из VPN-апплайнса в сторону нескольких IP, которые не входят ни в один штатный список. Не массовый, не шумный - именно такие соединения, которые легко пропустить при беглом взгляде.

Клиент сам заметил это в логах SIEM и написал нам. Это хороший знак, но дальше нужно было понять: это реальная компрометация или ложная тревога.

Как детектировать факт взлома

Ivanti опубликовала Integrity Checker Tool (ICT) - утилиту, которая сравнивает файловую систему устройства с эталонным состоянием. Первое, что сделали - запустили её. Результат оказался неутешительным: расхождения в нескольких системных компонентах, в том числе в веб-слое.

Параллельно проверяли несколько индикаторов вручную.

Веб-шеллы и модифицированные компоненты. Атакующие в задокументированных случаях размещали веб-шеллы в каталогах, которые доступны через HTTPS и при этом не очищаются при обычной перезагрузке. Смотрели на временные метки файлов в /home/webserver/htdocs/ и смежных директориях, сравнивали с датами последних обновлений.

Процессы и cron. На устройстве Ivanti - это по факту Linux-апплайнс. Проверяли список запущенных процессов и crontab на предмет того, что не должно там быть. В одном из задокументированных публично разборов атак через эту же цепочку фигурировали задачи в cron, которые переустанавливали персистентность после ребута.

Исходящие соединения. Смотрели netstat и трафик за последние несколько суток. Устройство VPN по своей природе генерирует много соединений, но маршруты наружу с апплайнса напрямую (не от имени клиентов) - это повод остановиться.

Логи аутентификации. Проверяли обращения к административному интерфейсу за последние недели - нет ли входов с нетипичных адресов, нет ли попыток перебора. CVE-2024-21888 позволяет обойти аутентификацию, но след в логах всё равно остаётся - если только логи не были зачищены.

В нашем случае картина сложилась: веб-шелл нашёлся, исходящие соединения подтвердились, в логах - пробелы в нескольких временных интервалах. Компрометация была реальной.

Что делать без патча

Ivanti на момент публикации первых деталей об уязвимостях выпустила workaround - XML-файл, который ограничивает эксплуатацию CVE-2024-21887 через блокировку части точек вызова. Это не патч, это затычка, и она не закрывает CVE-2024-21888 полностью.

Что мы рекомендовали клиенту и что соответствует общим best practices для подобных ситуаций:

Первое - изоляция. До любых других действий устройство нужно изолировать от продуктивной сети. Не «ограничить доступ», а именно изолировать. Работающий скомпрометированный апплайнс продолжает быть точкой распространения атаки.

Второе - factory reset и переустановка. Ivanti прямо рекомендует это для скомпрометированных устройств. Обычный ребут или откат конфигурации не убирает персистентность - атакующие научились выживать через стандартные циклы перезагрузки.

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

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

Пятое - проверить всё окружение. VPN-апплайнс - это граница периметра. Если он был скомпрометирован, нужно проверить, что атакующие успели сделать внутри: какие хосты были доступны через VPN, нет ли следов горизонтального движения.

Что получилось в итоге

Клиент согласился на factory reset и временный перевод пользователей на резервный канал. Параллельно мы провели аудит сегментов сети, доступных через скомпрометированный апплайнс - на предмет следов продвижения атакующих внутрь. Чисто не было, но масштаб оказался ограниченным: либо атакующие не успели, либо не ставили задачей глубокое проникновение в этом конкретном случае.

История с Ivanti показательна не столько уязвимостями - критические дыры в VPN-апплайнсах случались и раньше. Показателен разрыв между обнаружением и доступностью патча: организации, которые зависят от этого устройства, несколько недель будут работать с mitigation вместо полноценного исправления. В этот период детектирование и мониторинг - единственное, на что можно опереться.

ICT от Ivanti стоит запустить прямо сейчас, если устройство в эксплуатации. Не ждать «тревожных сигналов» - их может не быть до того момента, когда они станут неудобно очевидными.