BlueKeep в дикой природе: экстренный аудит периметра и закрытие RDP наружу

BlueKeep объявили в мае 2019-го, патчи вышли сразу - Microsoft даже поддержала Windows XP, что само по себе сигнал об уровне серьёзности. Осенью подоспели рабочие эксплойты, и с тех пор атаки на открытый порт 3389 идут фоновым шумом. Часть клиентов отреагировала сразу, часть - «поставили патч и успокоились». Несколько звонков за последние недели с похожей структурой: «у нас уведомления от провайдера / SIEM / службы безопасности - можете посмотреть периметр?» Посмотрели.

Что находим при сканировании

Первый шаг в таком аудите - посмотреть на периметр снаружи, как смотрит атакующий. Берём nmap, masscan, проверяем диапазон белых IP клиента. Картина стабильно повторяется:

• Открытый 3389 наружу у кого-то обязательно есть - иногда это «так и задумано», чаще это чьё-то временное решение, которое прижилось. У одного клиента нашли сервер с открытым RDP, про который в ИТ-отделе уже никто не помнил - судя по логам, доступ к нему не использовался несколько месяцев, но порт слушал исправно.
• Незащищённые RDP-сервисы на нестандартных портах - 3390, 33890 и прочая «безопасность через неизвестность». BlueKeep атакует по протоколу, а не по номеру порта; сканеры атакующих давно умеют баннер-грэббинг.
• Старые версии Windows без патчей - не потому что люди безответственные, а потому что «эта машина отдельная, мы про неё не думаем». Отдельных машин с открытым RDP оказывается больше, чем ожидается.

Патч от BlueKeep - это необходимое условие, но не достаточное. Даже пропатченный хост с открытым RDP наружу - отличная точка для атак методом перебора, фишинга учёток, эксплуатации других RDP-уязвимостей (а их за 2019 год вышло несколько, DejaBlue / CVE-2019-1181/1182 в том числе). Открытый порт 3389 на периметре - это приглашение, от которого лучше отказаться.

Что делаем

Схема, которую выстраиваем у клиентов, одна и та же в своей основе.

Первое - убираем прямой RDP с периметра. Порт 3389 закрывается на межсетевом экране или убирается за NAT. Исключений нет: ни для «технологических», ни для «временных» хостов. Если кто-то говорит «мне нужен прямой RDP», это разговор про архитектуру доступа, а не про исключение в правилах.

Второе - выставляем RD Gateway. Remote Desktop Gateway - это Microsoft-ный компонент, работающий поверх HTTPS (порт 443). Снаружи виден только HTTPS, внутрь пускает только аутентифицированных пользователей. Разворачивается на Windows Server, требует SSL-сертификат - в нашем случае обычно Let's Encrypt или корпоративный PKI, в зависимости от политики клиента. Все RDP-сессии идут через него, прямой доступ к 3389 внутри сети остаётся, но снаружи его нет.

Третье - MFA на шлюзе. RD Gateway поддерживает RADIUS, что открывает интеграцию с любым MFA-решением, умеющим говорить по RADIUS: Microsoft NPS Extension for Azure MFA, FreeRADIUS с Google Authenticator, аппаратные токены. У одного клиента уже стоял Azure AD с MFA - подключили NPS Extension за день. У другого - интегрировали с уже имеющимся FreeRADIUS. Итого: пароль плюс OTP, без этого на шлюз не попасть.

Четвёртое - патчи и инвентаризация. Параллельно проверяем, что KB4499175 (и последующие кумулятивные обновления) реально применены везде, где есть RDP. Везде - это не только серверы в основном домене, но и изолированные сегменты, ДМЗ, тестовые стенды. Несколько раз находили машины, которые формально числились в WSUS, но последний раз получали обновления в 2018-м.

Несколько пробелов, которые нашли

Каждый аудит немного свой, но пара наблюдений повторяется.

Первое - временный доступ для подрядчика, который стал постоянным. Классика: открыли RDP для внешней команды на время проекта, проект закончился, правило осталось. Учётка подрядчика иногда тоже остаётся активной.

Второе - сервисные учётки с RDP-доступом и простыми паролями. Это не про BlueKeep напрямую, но когда сканируешь периметр и видишь, что порт открыт - следующий вопрос про учётки. И там иногда обнаруживается, что у сервисной учётки пароль не менялся года три.

Третье - отсутствие логирования попыток входа где-либо, кроме самого сервера. Если сервер с RDP компрометирован, логи на нём первое, что исчезает. Централизованный сбор событий Windows Security Log - отдельный разговор, но хотя бы Event ID 4625 (неудачный вход) должны улетать во что-то внешнее.

Где сейчас

У одного из клиентов аудит ещё продолжается - инвентаризация оказалась объёмнее ожидаемого, в сети нашлось несколько хостов, про которые ИТ-отдел не имел актуальной информации. RD Gateway уже работает, прямой RDP с периметра снят, идём по списку внутренних хостов.

BlueKeep - не первая и не последняя RDP-уязвимость с предэксплуатируемым вектором через сеть. Протокол старый, реализации разные, атакующих поверхность огромная. Открытый 3389 на периметре в 2020 году - это не технический долг, это работающий вектор атаки прямо сейчас.