BlueKeep ретроспектива: у 60% клиентов не было актуального реестра хостов с открытым RDP

Прошло несколько недель с patch-weekend по BlueKeep. Хосты обновлены - у большинства клиентов, с оговорками по отдельным случаям. Но Microsoft на прошлой неделе снова подняла тему: в официальном блоге MSRC они прямо написали, что считают эксплуатацию BlueKeep в виде червя реалистичным сценарием. Не гипотетическим, не теоретическим - реалистичным. CVSS 9.8 на фоне этого заявления перестаёт быть просто цифрой в бюллетене.

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

Что значит «реалистичный червь» на практике

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

Но Microsoft говорит именно о черве - самораспространяющемся коде без участия пользователя. EternalBlue в своё время дал WannaCry и NotPetya. BlueKeep живёт в той же зоне: RCE до аутентификации, широко распространённые ОС, открытый порт как единственное условие. Разница в том, что сейчас патч уже существует. Вопрос в том, установлен ли он везде, где нужно.

Ретроспектива: что мы увидели

По итогам работы с несколькими десятками клиентских инфраструктур картина сложилась неприятная - и примерно одинаковая у большинства.

Главный вывод: у примерно 60% клиентов не было актуального реестра хостов с открытым RDP. Не «неполного» и не «устаревшего» - а вообще никакого структурированного представления о том, какие машины принимают подключения на 3389. Когда начиналась митигация, первым шагом было сканирование периметра - потому что другого способа узнать, сколько хостов уязвимы, просто не было.

Это не проблема конкретного клиента. Это системный паттерн.

Как возникает эта ситуация. RDP на хосте, как правило, не включают намеренно как «публичный сервис». Его включают системные администраторы для своих нужд, разработчики для доступа к тестовым средам, иногда - внешние подрядчики, которым «надо подключиться разово». Порт остаётся открытым после того, как необходимость пропадает. Хост переезжает в другой сегмент, правило в firewall остаётся. Через год о нём никто не помнит - но он работает.

Когда таких хостов несколько десятков и нет единого реестра, инвентаризировать состояние «кто открыт» можно только сканированием. Что мы и делали.

Второй вывод: патчинг Windows-хостов во многих инфраструктурах - это ручная работа без централизованного контроля. WSUS есть у большинства, но покрытие WSUS и реальный парк Windows-машин совпадают редко. Один-два хоста вне домена, одна виртуалка, поднятая три года назад «под задачу» - они обновляются вручную, когда кто-то вспоминает. BlueKeep обнажил именно эти пятна: хосты с 3389, без NLA, с обновлениями трёхмесячной давности.

CMDB как инструмент безопасности, а не IT-бюрократия

Самый частый ответ на вопрос «почему нет реестра RDP-хостов» - «это же очевидно, все знают». Оказывается, не знают. Точнее, каждый знает про свой кусок инфраструктуры, но целостной картины нет ни у кого.

CMDB - база данных конфигурационных элементов - воспринимается многими как инструмент IT-менеджмента и документирования. На самом деле это инструмент безопасности с немедленным практическим применением: когда выходит критический CVE с CVSS 9.8, вопрос «сколько у нас хостов под угрозой» должен иметь ответ за минуты, а не за день сканирования.

Что минимально нужно фиксировать для таких случаев:

• Какие хосты принимают входящие соединения снаружи - и по каким портам и протоколам.
• Версия ОС и дата последнего обновления для каждого хоста.
• Кто владелец - не «отдел IT», а конкретный человек, который знает, для чего эта машина и можно ли её перезагрузить в выходные.
• Зависимости - что сломается, если хост уйдёт на перезагрузку.

Это не полная CMDB и не ITSM-процесс с тикетами. Это минимальный набор, без которого экстренная реакция на CVE превращается в детективное расследование.

Что делать с этим прямо сейчас

BlueKeep - хороший повод завести этот реестр, если его нет. Не потому что следующий критический CVE обязательно будет про RDP, но потому что следующий критический CVE будет. И вопрос «сколько у нас уязвимых хостов» снова окажется без быстрого ответа.

Конкретный шаг: после завершения BlueKeep-митигации зафиксировать в каком-либо виде список хостов с открытым RDP, версию ОС, дату патча, владельца. Сделать это прямо сейчас, пока инфраструктура только что прощупана сканером. Через три месяца это знание снова растворится.

Для клиентов, у которых аудит инфраструктуры не проводился давно, ситуация с реестром хостов - один из первых вопросов, который стоит включить в scope. Не потому что это красиво выглядит в отчёте, а потому что следующий экстренный патч-weekend будет проще, если знаешь, что именно патчить.

PoC для BlueKeep в публичном доступе по-прежнему отсутствует. Но Microsoft уже сказала своё слово - и оно звучит достаточно ясно.