Cisco IOS XE CVE-2023-20198: incident response у двух клиентов

Прошло несколько дней с того момента, как мы закрывали Web UI на устройствах IOS XE, и ситуация стала заметно хуже. Threat intelligence сообщает о тысячах скомпрометированных устройств по всему миру - атакующие не просто создавали учётки, они ставили импланты. У двух наших клиентов появились основания думать, что Web UI был доступен до того, как мы успели его закрыть. Пришлось делать полноценный incident response.

Что изменилось за несколько дней

Когда мы писали про CVE-2023-20198 в конце сентября, картина была такая: уязвимость активно эксплуатируется, атакующие создают учётки с привилегиями уровня 15, рекомендация - отключить Web UI. За неделю выяснилось, что это не полная картина.

Исследователи из нескольких компаний зафиксировали вторую уязвимость в цепочке, которая используется вместе с первой. Схема: через CVE-2023-20198 получают учётку уровня 15, затем эскалируют до root-уровня и устанавливают имплант - Lua-скрипт в файловую систему IOS XE, который открывает backdoor и слушает входящие запросы. Количество видимых заражённых хостов по данным Censys и аналогичных платформ - в районе десяти тысяч устройств.

Оба клиента, которые к нам обратились, - у них Web UI был доступен извне по историческим причинам. Один пообещал закрыть «завтра», второй - вообще не знал, что он торчит. До нашего внепланового прохода мы до них не добрались.

Как выглядел IR на практике

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

Проверка IOC шла по нескольким направлениям:

• Проверка учётных записей. show running-config | include username - ищем незнакомые имена. У обоих клиентов нашлись посторонние учётки: у одного одна, у второго две. Имена ни на что не похожи - случайные строки, не «admin2» или «backup», а что-то вроде хэш-фрагментов. Это уже нехороший знак.
• Проверка импланта. Cisco в своих обновлённых рекомендациях дала конкретный curl-запрос для детектирования Lua-бэкдора: HTTP-запрос к специфическому пути на устройстве. Ответ с непустым телом означает активный имплант. На одном из двух устройств имплант ответил.
• Проверка файловой системы. dir flash: и dir bootflash: на предмет незнакомых файлов с расширениями .lua или вообще без расширений в нестандартных местах. На заражённом устройстве нашёлся файл с именем, не совпадающим ни с одним штатным компонентом IOS XE.

На втором устройстве посторонние учётки были, но имплант не отвечал - либо не был установлен, либо уже убран. Это неприятная неопределённость: нет ответа - не значит чисто.

Восстановление из резервных копий

Для заражённого устройства решение однозначное - восстановление из заведомо чистого бэкапа. Попытки вычистить имплант вручную при живой IOS XE - это лотерея: Cisco прямо говорит, что гарантии чистоты без переустановки образа нет.

У клиента бэкапы конфигураций велись через RANCID - последний снапшот перед датой начала активной эксплуатации (примерно 18 сентября, по данным threat intel) у нас был. Образ IOS XE скачали с Cisco CCO, проверили хэш, залили через TFTP на устройство, восстановили конфиг из бэкапа.

Несколько моментов, которые добавили работы:

• Посторонние учётки в бэкапе не было - значит, они появились после последней резервной копии. Конфиг восстановили без них, что и хотели.
• Сертификат для HTTPS Web UI был самоподписанным и сгенерирован на устройстве - после переустановки пришлось перегенерировать. Мелочь, но требует времени.
• Часть ACL была изменена злоумышленником - это выяснилось при сравнении восстановленного конфига с тем, что было на устройстве до очистки. Конкретно: убраны несколько запрещающих правил для входящего трафика на management-интерфейс. Классика - расширяешь себе доступ.

Для второго устройства, где имплант не подтверждён, приняли решение тоже восстановить из бэкапа - лучше лишняя работа, чем сомнения.

Что видно по итогу

Несколько наблюдений, которые стоит зафиксировать.

Посторонние учётки - это ещё не конец. Удалить учётку через no username <имя> и сохранить конфиг - это не IR. Если учётка появилась через CVE-2023-20198, значит, был доступ к Web UI, а значит, возможно, был и имплант. Нельзя останавливаться на удалении учётки.

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

Сравнение конфигов даёт информацию об атаке. Когда смотришь diff между чистым бэкапом и скомпрометированным конфигом, видно, что именно менял атакующий. В нашем случае это помогло понять масштаб вмешательства и убедиться, что кроме учётки и ACL ничего больше не изменилось.

Общая ситуация с CVE-2023-20198 остаётся открытой - Cisco только начала выкатывать патчи для части версий IOS XE, покрытие неполное. Аудит сетевого оборудования в ближайшие недели будет у нас в приоритете у всех клиентов с Cisco в парке.