Защита RDP-подключения к VDS/VPS в эпоху «заслуженного» киберпанка

Пандемия вируса COVID-19 радикально изменила модель работы персонала множества организаций в добровольно-принудительном порядке, «наградив» большую его часть статусом «дистанционный», а кое-кого, даже «удалённый работник».

Если до «мега-эпидемии» сотрудники выполняли свои трудовые обязанности из офиса, используя подконтрольную IT-отделу компании корпоративную инфраструктуру, то во время самоизоляции, «львиная» доля офисной работы стала выполняться с домашних устройств с использованием протокола удалённого рабочего стола (RDP). Популярного, как сама ОС от MS, но, как свидетельствует список уязвимостей, не самого безопасного протокола. Как защитить свой RDP от посягательств извне, мы далее и поговорим.

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

RDP наоборот

В 2018 году, в процессе исследований безопасности протокола удалённого  рабочего стола, специалисты Check Point Research  обнаружили множественные уязвимости в трёх популярных клиентах, предназначенных для работы с ним:

• RDP-клиент от Microsoft / Mstsc.exe
• rdesktop 
• FreeRDP

Всего было обнаружено 25 уязвимостей, среди  которых были и критические, в том числе и те, что позволяют злоумышленнику изменить обычное направление связи и атаковать клиентский компьютер, то есть осуществить атаку с помощью обратного RDP-соединения (reverse RDP-attack).

В RDP-клиенте от Microsoft эта уязвимость «таилась» в общем буфере обмена между клиентом и сервером. Которая, при использовании буфера в процессе соединения, позволяла серверу с эксплойтом «включать» собственные файлы в инициированный пользователем процесс обмена.  А функционалу атаки обхода пути (path traversal attack) — определять «конечным пунктом назначения» для файла любое место в клиентском компьютере. Например, без лишних уведомлений отправить исполняемый файл (программу-майнер, шифровальщик) в папку автозагрузки компьютера пользователя, для его запуска при следующей перезагрузке системы. 

Демонстрация уязвимости от Check Point Research

О факте чего и было сообщено компании Microsoft (MSRC) 16 октября 2018 года. В ответ на что,17 декабря 2018 года адресат ответил:

“Thank you for your submission. We determined your finding is valid but does not meet our bar for servicing. For more information, please see the Microsoft Security Servicing Criteria for Windows (https://aka.ms/windowscriteria).”

«Спасибо за подачу заявки. Мы определили, что ваша находка действительна, но не соответствует нашему уровню обслуживания. Дополнительные сведения см. в разделе Критерии обслуживания Microsoft для Windows (https://aka.ms/windowscriteria)».

В результате чего данная уязвимость не получила своего ID и патча для её исправления. источник

ГипеРДП

После публикации информации об этой уязвимости, сотрудники Check Point Research стали получать множество комментариев и вопросов, один из которых вызвал неподдельный интерес и побудил вернуться к дальнейшему исследованию и посмотреть на уязвимость под «другим углом», а именно: может ли уязвимость RDP-клиента Microsoft быть использована в Microsoft Hyper-V?

В результате дальнейшего изучения выяснилось, что в основе GUI для управления ВМ — Hyper-V manager, негласно используется технологии RDP, в расширенных сеансах которого, так же как и в свойствах удалённого рабочего стола есть возможность включения общего буфера обмена. И как следствие — присутствует та же самая уязвимость!

Демонстрация уязвимости в Hyper-V от Check Point Research

Об этом сотрудники Check Point Research рассказали в своем блоге, а также на конференции Black Hat USA 2019.

Презентация уязвимости на Black Hat USA 2019

Ну и, конечно же, сообщили в MSRC. На этот раз Microsoft завела тикет и в октябре 2019 года выпустила патч для исправления этой уязвимости, получившей  ID: CVE-2019-0887. источник

Неисповедимы пути

После анализа эффективности патча, когда эксперты Check Point Research собрались уже было присвоить уязвимости статус «закрыта», к ним обратился пользователь Mac OS RDP Client, с информацией об особенностях поведения клиента после установки исправления от MS.

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

В феврале 2020 года Microsoft собралась с силами и выпустила патч для исправления и этой уязвимости CVE-2020-0655, который, по словам экспертов Check Point Research, в полной мере так не решил проблему атаки обхода пути (path traversal attack), в частности, для Windows API. Оповещённая об этом «косячке» компания Microsoft пока эту ситуацию никак не прокомментировала. источник

И, что…

Как может заметить проницательный читатель, для удачного проведения атаки такого типа необходим скомпрометированный RDP-сервер. А «достать» его можно тремя путями:

• Создать свой и выдать его за легитимный
• Получить доступ к существующему и скомпрометировать его
• Гибридный

Относительно безопасным, оптимальным по затратам и скорости провижининга вариантом в сегодняшних реалиях будет — «завладеть» арендуемым у сервис-провайдера облачным или VPS/VDS — сервером. И тому есть три основные причины:

• Каждый арендуемый виртуальный сервер под управлением Windows — это уже RDP-сервер по-умолчанию
• Каждый арендуемый виртуальный сервер под управлением Windows, как правило, уже имеет RDP-аккаунт с админскими правами и единым логином для всех пользователей. 
• Как правило, RDP-доступ к виртуальному серверу осуществляется через доступный на публичном IP-адресе TCP-порт: 3389.

Собственно этот — «торчащий наружу» порт, наверно, та, самая «красная тряпка» для кибер-злоумышленника, желающего завладеть каким-нибудь виртуальным сервером, подобрав пароль к нему методом простого автоматизированного перебора. Или как его ещё называют брутфорс-атакой.

Для справки: Пример роста количества атак семейства Bruteforce.Generic.RDP, февраль — апрель 2020 г. от Лаборатории Касперского.

источник

… дальше

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

В RUVDS для этого требуется три простых шага:

• Объединить виртуальный сервер с компьютерами, которым необходим доступ к нему по RDP, виртуальной частной сетью. Я использую — ZeroTier 
• Настроить нативный файрвол виртуального сервера:
  В настройках сервера во вкладке Сети кликаем настроить файрвол для публичных адресов.

  

  И начинаем создавать правила:
  Первое — запрещаем все внешние соединения
  Второе — разрешаем соединения виртуальной сети. В данном случае — ZeroTier.
  Третье — разрешаем RDP-соединение только по адресу виртуального сервера в виртуальной сети. Принимаем изменения.

• Установить успешное RDP-соединение по IP-адресу сервера внутри виртуальной сети согласно этой инструкции.

На этом хочу откланяться и советую следить за «здоровьем» RDP-подключения вашего виртуального сервера. Ибо, с момента CVE-2020-0655, появилось ещё три уязвимости с функционалом reverse RDP-attack.