Часто возникает вопрос – насколько безопасно подключаться через удаленный рабочий стол Windows?
Сеансы удаленного рабочего стола работаю по зашифрованному каналу, не позволяя никому просматривать сеанс путем прослушивания в сети. Однако, есть уязвимость в методе, используемом для шифрования сеансов в более ранних версиях RDP. Эта уязвимость может позволить неавторизованный доступ к вашему сеансу с помощью “Man-in-the-middle attack”.
Удаленный рабочий стол можно защитить с помощью SSL/TLS в Windows Vista, Windows 7, Windows 8, Windows 10 и Windows Server 2003/2008/2012/2016.
Хотя, удаленный рабочий стол более безопасен, чем инструменты удаленного администрирования, такие как VNC, которые не шифруют весь сеанс, каждый раз, когда доступ администратора к системе предоставляется удаленно, возникает риск. Следующие советы помогут защитить удаленный доступ к рабочим столам и серверам, которые вы поддерживаете.
Основные советы по безопасности для удаленного рабочего стола
Используйте надежные пароли
Надежные пароли для любых учетных записей с доступом к удаленному рабочему столу следует рассматривать как обязательный шаг перед включением удаленного рабочего стола.
Парольные фразы должны:
- Содержать восемь символов или более
- Содержать символы из двух из следующих трех классов символов
- По алфавиту (пример: az, AZ)
- Числовой (пример: 0-9)
- Пунктуация и другие символы (пример: ,! @ # $% ^ & * () _ + | ~ – = `{} []:”; ‘<>?,. /)
Парольные фразу не должны:
- Производное от имени пользователя
- Слово, найденное в словаре (русском или иностранном)
- Слово из словаря, написанное задом наперед
- Словарное слово, перед котором или за которым следует любой другой одиночный символ (пример: password1, 1password)
Не используйте легко угадываемые пароли. Некоторые примеры паролей, которые легко угадать:
- Имена членов семьи, домашних животных, друзей и т.д.
- Компьютерные термины и названия, команды, сайты, компании, оборудование, программное обеспечение.
- Дни рождения и другая личная информация, такая как адреса и номера телефонов.
- Шаблоны слов и чисел, такие как aaabbb, qwerty, 123321 и т.д.
- Пароли никогда не следует записывать или хранить в сети.
- Следует регулярно менять пароли, не реже одного раза в шесть месяцев. Также следует менять свой пароль каждый раз, когда вы подозреваете, что учетная запись была взломана.
- Попробуйте использовать разные пароли для каждой системы, как минимум, не используйте тот же пароль для любой из ваших учетных записей.
Обновите программное обеспечение
Одним из преимуществ использования удаленного рабочего стола по сравнению с сторонними инструментами удаленного администрирования является то, что компоненты автоматически обновляются с использованием последних исправлений безопасности в стандартном цикле исправлений Microsoft.
- Убедитесь, что используете последние версии клиентского и серверного программного обеспечения, включив и проверив автоматические обновления Microsoft.
- Если используете клиенты удаленного рабочего стола на других платформах, убедитесь, что они все еще поддерживаются и установлены последние версии.
- Более старые версии могут не поддерживать высокий уровень шифрования и могут иметь другие недостатки безопасности.
Ограничьте доступ с помощью брандмауэров
- Используйте брандмауэры, чтобы ограничить доступ к портам удаленного рабочего стола (по умолчанию TCP 3389). Использование шлюза RDP настоятельно рекомендуется для ограничения доступа RDP к рабочим столам и серверам.
- В качестве альтернативы для поддержки подключения за пределами локальный сети можно использовать VPN подключение, чтобы получить IP-адрес виртуальной сети и добавить пул сетевого адреса в правило исключения брандмауэра RDP.
Включите аутентификацию на сетевом уровне
Windows 10, Windows Server 2012 R2/2016/2019 также по умолчанию предоставляют проверку подлинности на уровне сети (NLA). Лучше оставить это на месте, так как NLA обеспечивает дополнительный уровень аутентификации перед установкой соединения. Вы должны настраивать серверы удаленного рабочего стола только для разрешения подключений без NLA, если вы используете клиенты удаленного рабочего стола на других платформах, которые его не поддерживают.
- NLA должен быть включен по умолчанию в Windows 10, Windows Server 2012 R2 / 2016/2019.
- Чтобы проверить это, вы можете посмотреть параметр групповой политики Требовать проверку подлинности пользователя для удаленных подключений с помощью проверки подлинности на уровне сети, находящейся в папке Компьютер Политики Компоненты Windows Службы удаленного рабочего стола Узел сеанса удаленного рабочего стола Безопасность. Этот параметр групповой политики должен быть включен на сервере с ролью узла сеансов удаленного рабочего стола.
Ограничьте количество пользователей, которые могут войти в систему с помощью удаленного рабочего стола
По умолчанию все администраторы могут войти в удаленный рабочий стол.
Если есть несколько учетных записей администратора на компьютере, следует ограничить удаленный доступ только для тех учетных записей, которые в нем нуждаются.
Если удаленный рабочий стол не используется для системного администрирования, удалите весь административный доступ через RDP и разрешите только учетные записи пользователей, требующие службы RDP. Для отделов, которые управляют множеством машин удаленно, удалите локальную учетную запись администратора из доступа RDP по адресу и вместо этого добавьте техническую группу.
- Нажмите Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
- В разделе «Локальные политики» -> «Назначение прав пользователя» перейдите к «Разрешить вход через службы терминалов». Или «Разрешить вход через службы удаленных рабочих столов»
- Удалите группу администраторов и выйдите из группы пользователей удаленного рабочего стола.
- Используйте панель управления системой, чтобы добавить пользователей в группу «Пользователи удаленного рабочего стола».
Типичная операционная система MS будет иметь следующие настройки по умолчанию, как показано в локальной политике безопасности:
Рисунок 1 – Настройка локальной политике безопасности
Проблема в том, что «Администраторы» здесь по умолчанию, а учетная запись «Локальный администратор» находится у администраторов.
Несмотря на то, что рекомендуется использовать соглашение о паролях, чтобы избежать идентичных паролей локального администратора на локальном компьютере и строго контролировать доступ к этим паролям или соглашениям, использование учетной записи локального администратора для удаленной работы на компьютере не позволяет должным образом регистрировать и идентифицировать пользователя, использующего систему. Лучше всего переопределить локальную политику безопасности с помощью параметра групповой политики.
Рисунок 2 – Настройка групповой политики безопасности
Установите политику блокировки учетной записи
Установив на своем компьютере блокировку учетной записи на определенное количество ошибочных попыток, вы предотвратите получение доступа к вашей системе с помощью средств автоматического подбора пароля. Чтобы установить политику блокировки учетной записи:
- Зайдите в Пуск -> Программы -> Администрирование -> Локальная политика безопасности.
- В разделе «Политики учетных записей» -> «Политики блокировки учетных записей» установите значения для всех трех параметров. Разумным выбором являются три недопустимые попытки с длительностью блокировки 3 минуты.
Лучшие методы для дополнительной безопасности RDP
Не разрешайте прямой доступ RDP клиентам серверам за пределами своей сетии
Открытие RDP (порт 3389) для сетей за пределами частной сети крайне не рекомендуется и является известным вектором для многих атак. Варианты ниже перечислены способы повышения безопасности, сохраняя при этом доступ к системе по протоколу RDP.
После настройки шлюза RDP узлы должны быть настроены так, чтобы разрешать RDP-соединения только от узла шлюза или подсетей компании там, где это необходимо.
Используйте шлюзы RDP
Настоятельно рекомендуется использовать шлюз RDP. Он позволяет жестко ограничить доступ к портам удаленного рабочего стола, одновременно поддерживая удаленные подключения через один сервер-шлюз.
При использовании сервера шлюза удаленных рабочих столов все службы удаленных рабочих столов на вашем рабочем столе и рабочих станциях должны быть ограничены, чтобы разрешить доступ только из шлюза удаленных рабочих столов. Сервер шлюза удаленных рабочих столов прослушивает запросы удаленного рабочего стола через HTTPS (порт 443) и подключает клиента к службе удаленного рабочего стола на целевой машине.
- Используйте службу шлюза RDP в компании. Это лучший вариант для разрешения доступа RDP к системе, относящейся к категории UC P2 и ниже. Включает интеграцию DUO. Служба шлюза RDP предоставляется командой Windows.
- Служба выделенного шлюза. Требуется для RDP-доступа к системам UC P4 или выше. Также должен быть настроен для DUO.
Некоторые компании используют VPS, управляемый IST, в качестве шлюза удаленных рабочих столов. По приблизительной оценке, 30–100 одновременно работающих пользователей могут использовать один шлюз удаленных рабочих столов. Hа на виртуальном уровне обеспечивает достаточно отказоустойчивый и надежный доступ; однако можно реализовать чуть более сложную реализацию шлюза удаленных рабочих столов с балансировкой сетевой нагрузки.
По сути, все, что необходимо – это простое изменение на расширенной вкладке RDP-клиента:
Рисунок 3 – Подключение через шлюз удаленных рабочих столов
Измените порт для удаленного рабочего стола
Изменение порта прослушивания поможет «спрятать» удаленный рабочий стол от злоумышленников, которые сканируют сеть в поисках компьютеров, прослушивающих порт удаленного рабочего стола по умолчанию (TCP 3389). Это обеспечивает эффективную защиту от новейших червей RDP, таких как Morto.
Для этого отредактируйте следующий раздел реестра (ВНИМАНИЕ: не пытайтесь это сделать, если вы не знакомы с реестром Windows и TCP / IP): HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp.
Измените порт прослушивания с 3389 на другой и не забудьте обновить все правила брандмауэра с новым портом. Хотя этот подход полезен, это безопасность посредством неизвестности, что не является самым надежным подходом к обеспечению безопасности.
Убедитесь, что вы также используете другие методы для ограничения доступа, как описано в этой статье.
Туннелируйте подключение к удаленному рабочему столу через IPSec или SSH
Если использование шлюза удаленных рабочих столов невозможно, вы можете добавить дополнительный уровень проверки подлинности и шифрования, туннелируя сеансы удаленного рабочего стола через IPSec или SSH. IPSec встроен во все операционные системы Windows, начиная с Windows 2000, но использование и управление в Windows 10 значительно улучшены . Если доступен SSH-сервер, вы можете использовать SSH-туннелирование для подключений к удаленному рабочему столу.
С распространением COVID-19 организации перевели сотрудников на удаленный режим работы, что напрямую повлияло на кибербезопасность организаций и привело к изменению вектора угроз.
В 2020 году увеличилось использование сторонних сервисов для обмена данными, работа сотрудников на домашних компьютерах в потенциально незащищенных сетях Wi-Fi. Увеличилось количество людей, использующих инструменты удаленного доступа. Это стало одной из главных проблем для сотрудников ИБ.
Одним из наиболее популярных протоколов прикладного уровня, позволяющим получать удаленный доступ к рабочей станции или серверу под управлением ОС Windows, является проприетарный протокол Microsoft — RDP (англ. Remote Desktop Protocol — Протокол удаленного рабочего стола). Во время карантина в сети Интернет появилось большое количество компьютеров и серверов, к которым можно подключиться удаленно. Наблюдался рост активности злоумышленников, которые хотели воспользоваться текущим положением вещей и атаковать корпоративные ресурсы, доступные для сотрудников, отправленных на удаленную работу. На рисунке 1 представлена статистика атак на RDP. По графику видно, что количество атак на RDP значительно увеличилось с начала пандемии.
Таким образом, протокол RDP становится всё более востребованным в том числе и для злоумышленников. В данной статье описаны основные виды атак на RDP, уязвимости и способы их эксплуатации, а также предложены некоторые рекомендации по повышению уровня защищенности RDP.
1. Предварительный сбор информации о RDP
В этом разделе рассмотрены инструменты и методы, которые связаны с поиском и проверкой защищённости удаленных рабочих столов, работу которых обеспечивает служба RDP.
По умолчанию RDP сервер прослушивает TCP-порт 3389 и UDP-порт 3389, поэтому компьютеры с включённым удалённым рабочим столом можно искать с помощью утилиты Nmap командой вида:
sudo nmap – p 3398 -sU -sS СЕТЬ
Например, на рисунке 2 продемонстрирован результат работы команды nmap:
sudo nmap –p 3389 -sU -sS –open 192.168.0.0/24
Для сбора баннеров достаточно добавить опции -sV --script=banner
sudo nmap -p 3389 -sU -sS -sV --script=banner 192.168.0.0/24
1.1 Сбор дополнительной информации о RDP
У Nmap также имеется перечень скриптов для сбора дополнительной информации о RDP:
sudo nmap -p 3389 -sU -sS --script rdp-enum-encryption, rdp-ntlm-info, rdp-vuln-ms12-020 192.168.0.1
Ниже описан каждый из них отдельно:
1.1.1 rdp-enum-encryption
Определяет, какой уровень безопасности и уровень шифрования поддерживаются службой RDP. Это происходит путём циклического перебора существующих протоколов и шифров. При запуске в режиме отладки сценарий также возвращает отказавшие протоколы и шифры, а также обнаруженные ошибки.
Этот скрипт перечисляет информацию от удалённых служб RDP с включённой аутентификацией CredSSP (NLA).
1.1.3 rdp-vuln-ms12-020
Проверяет, является ли машина уязвимой для уязвимости MS12-020 RDP.
Также доступность RDP проверяется модулем Metasploitauxiliary(scanner/rdp/rdp_scanner), пример использования Metasploit для проверки доступности RDP приведен на рисунке 4
1.1.4 rdp-sec-check
Утилита rdp-sec-check используется для получения характеристик настроек безопасности службы RDP
Пример запуска: rdp-sec-check
Вывод команды продемонстрирован на рисунке 5
Результат после строки [+] Summary of security issues (перечень проблем безопасности) говорит о том, что не используется NLA (англ. Network Level Authentication — Аутентификация на уровне сети), следовательно, возможна атака DoS (англ. Denial [ЗДС1] [ЛОВ2] of Service – отказ в обслуживании). Далее сказано, что SSL поддерживается, но не является обязательным, потенциально это может привести к атаке MiTM (англ. Man in the Middle – атака «человек по середине»).
Помимо приведенных выше способов доступность службы RDP проверяется обычными утилитами:
в Windows: mstsc
в Linux: freerdp:
xfreerdp /f /u:ИМЯ-ПОЛЬЗОВАТЕЛЯ /p:ПАРОЛЬ /v:ХОСТ[:ПОРТ]
Далее перейдем с основным видам атак на RDP и уязвимостям.
2 Виды атак на RDP
2.1 BruteForce RDP
По статистике основным способом получения доступа по RDP является слабая парольная политика, поэтому, давайте рассмотрим основные способы перебора данных учетных записей RDP. Удобными являются утилиты ncrack, hydra, patator:
пример использования утилиты hydra:
ncrack -vv --user -P pwds.txt rdp://
пример использования hydra:
hydra -V -f -L -P rdp://
пример использования patator :
patator rdp_login host=192.168.0.101 user=FILE0 password=FILE1 0=user.txt 1=passwords.txt -x ignore:fgrep='ERRCONNECT_LOGON_FAILURE'
Также утилита crowbar может использоваться для осуществления перебора данных учетных записей RDP. Пример использования данной утилиты продемонстрирован на рисунке 6.
./crowbar.py –server -b rdp -u -C
Ниже показан пример перебора учетных записей к RDP с помощью данной утилиты.
Перед проверкой нужно удостовериться, что разрешено удаленное подключение к данному компьютеру. Как показано на рисунке 7 необходимо установить пункт «разрешить удаленные подключения к этому компьютеру» в свойствах системы.
Чтобы снизить возможность перебора данных учетных записей рекомендуется в настройках локальной политики безопасности выставить количество неудачных подключений, после которых будет происходить блокировка учетной записи. Для начала, как показано на рисунке 8, установили пороговое значение равное 3.
В результате, при попытке перебора данных учетных записей доступа к RDP, утилита не показывает каких-либо результатов.
В случае, если же выставлено значение «0», как показано на рисунке 10, то злоумышленник может неограниченно пытаться получать доступ к RDP.
На рисунке 11 продемонстрировано получение данных учетных записей RDP.
Зная данные учетных записей можно осуществить подключение через утилиту xfreerdp, доступную в Kali Linux. Пример на рисунке 12.
После чего получил доступ к удаленной машине.
2.2 MitM атака на RDP с помощью утилиты Seth
С помощью seth выполняется атака MitM, в результате которой извлекаются учётные данные из RDP подключений.
При организации атаки «человек посередине» злоумышленник выдавал себя за правильный режим аутентификации, а пользователь, который не знал о переключении, по незнанию предоставлял правильные учетные данные. Далее рассмотрен пример использования этой утилиты.
Установка зависимостей:
git clone https://github.com/SySS-Research/Seth.git
cd Seth
pip install -r requirements.txt
apt install dsniff
Для проведения атаки злоумышленнику требуется локальный IP-адрес, целевой IP-адрес и сетевой интерфейс, который будет использоваться. В данном случае это eth0. На рисунке 14 продемонстрирован пример запуска утилиты с необходимыми параметрами.
Использование:
/usr/share/seth/seth.sh
Далее после запуска утилиты злоумышленником цель открыла диалоговое окно «Подключение к удаленному рабочему столу» и пыталась подключиться к машине и пользователю по своему выбору. Пользователь запрашивает учетные данные для подключения в качестве исходного запроса проверки подлинности безопасности.
Далее всплывает окно диспетчера сертификатов. На рисунке 16 видно, что существует конфликт между именем сервера и доверенным центром сертификации. Это похоже на окно с запросом на сохранение сертификата. Допускаем, что наша цель нажала «Да» в окне, представленном на рисунке 16.
Как только соединение было установлено, злоумышленник в окне терминала увидел перехваченные данные. На рисунке 17 продемонстрирован захват хэша NTLM, а также пароль, введенный пользователем.
2.3 BlueKeep (CVE-2019-0708)
С 2019 года было обнаружено несколько серьезных RCE (англ. Remote Code Execution – Удаленное Выполнение Кода), связанных с RDP. Их эксплуатация приводит к отказу в обслуживании, а также к удаленному исполнению кода на целевой системе. Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов. В результате эксплуатации уязвимости неаутентифицированный пользователь может удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP для удаленного выполнения произвольного кода на целевой системе. Информация о BlueKeep опубликована в мае 2019 года, но уязвимыми до сих пор остаются достаточное количество RDP-серверов. Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости опубликованы в августе 2019 года.
Пример эксплуатации и проверки с помощью модуля metasploit:
auxiliary(scanner/rdp/cve_2019_0708_bluekeep)
CVE-2019-0708 — это уязвимость типа use-after-free драйвера termdd.sys, который используется в Microsoft RDP. Для лучшего понимания, рассмотрим схему образования связи RDP:
Протокол удаленного рабочего стола (RDP) обеспечивает соединение между клиентом и конечной точкой (endpoint прим.), определяя данные, передаваемые между ними в виртуальных каналах. Виртуальные каналы — это двунаправленные каналы данных, расширяющие RDP. Windows Server 2000 определил 32 статических виртуальных канала (SVCs) с RDP 5.1, но из-за ограничений на количество каналов дополнительно определил динамические виртуальные каналы (DVCs), которые содержатся в рамках выделенного SVC. SVC создаются в начале сеанса и остаются до завершения сеанса, в отличие от DVC, которые создаются и удаляются по запросу.
Эту привязку 32 SVC исправляет патч CVE-2019-0708 в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в драйвере RDP termdd.sys. Как видно на рисунке 19, соединения RDP Connection Sequence инициируются, а каналы настраиваются до начала действия безопасности. Блок «RDP security commencement», как видно на схеме, выполняется после инициализации и базовых настройки канала, что позволяет CVE-2019-0708 выполнять функцию червей, поскольку данная уязвимость может самостоятельно распространяться по сети после обнаружения открытого порта 3389.
Уязвимость связана с тем, что имя SVC «MS_T120» привязывается в качестве канала по умолчанию к номеру 31 во время последовательности инициализации конференции GCC протокола RDP. Это имя канала используется корпорацией Microsoft для внутренних целей, и нет очевидных законных вариантов использования клиентом запроса на подключение через SVC с именем «MS_T120».
На рисунке 20 показаны легитимные запросы канала во время последовательности инициализации конференции GCC без канала MS_T120.
Пока конференция GCC инициализируется клиент предоставляет имя канала, которое не занесено сервером в белый список, что означает, что злоумышленник может настроить другой SVC с именем «MS_T120» на канале, отличном от 31. Использование MS_T120 на другом канале приводит к повреждению памяти кучи (англ. Heap Memory Corruption) и RCE.
На рисунке 21 показан аномальный запрос канала во время последовательности инициализации конференции GCC с каналом «MS_T120» на канале номер 4.
Компоненты, участвующие в управлении каналом MS_T120, выделены на рисунке 22. Эталонный канал MS_T120 создается в rdpwsx.dll, а пул кучи выделяется в rdpwp.sys. Повреждение кучи происходит в termdd.sys, когда эталонный канал MS_T120 обрабатывается в контексте индекса канала, отличного от 31.
Исправление Microsoft, показанное на рисунке 23, теперь добавляет проверку запроса на подключение клиента с использованием имени канала «MS_T120» и обеспечивает его привязку только к каналу 31 (1Fh) в функциях _IcaBindVirtualChannels и _IcaRebindVirtualChannels в termdd.sys.
Данная часть материала взята с сайта https://cve-2019-0708.info/understanding-the-wormable-rdp-vulnerability-cve-2019-0708.php
2.3.1 BlueGate
Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate опубликована в начале 2020 года.
Шлюз удаленных рабочих столов (RDG), ранее известный как шлюз служб терминалов, — это компонент Windows Server, обеспечивающий маршрутизацию для удаленного рабочего стола (RDP). Вместо того, чтобы пользователи подключались напрямую к серверу RDP, пользователи подключаются и аутентифицируются на шлюзе. После успешной аутентификации шлюз будет перенаправлять RDP-трафик на адрес, указанный пользователем, фактически выступая в роли прокси. Идея состоит в том, что только шлюз должен быть открыт для сети Интернет, оставляя RDP-серверы в безопасности за брандмауэром. В связи с тем, что RDP представляет собой гораздо большую поверхность атаки, правильная настройка с использованием RDG может уменьшить поверхность атаки организации.
В обновлении безопасности от января 2020 года Microsoft устранила две уязвимости в RDG. Обе ошибки, CVE-2020-0609 и CVE-2020-0610, позволяют выполнять удаленное выполнение кода до аутентификации.
Для того, чтобы разобраться в технических аспектах уязвимостей начнем с просмотра различий между пропатченой и исходной версиями уязвимой библиотеки DLL.
Была изменена только одна функция. RDG поддерживает три различных протокола: HTTP, HTTPS и UDP. Обновленная функция отвечает за обработку последнего. Для удобства на рисунке 24 рассмотрена функция в виде псевдокода, в котором ненужный код был удален.
Протокол RDG UDP позволяет разбивать большие сообщения на несколько отдельных пакетов UDP. Из-за того, что UDP не требует установления соединения, пакеты могут приходить не по порядку. Работа этой функции заключается в повторной сборке сообщений, гарантируя, что каждая часть находится в правильном месте. Каждый пакет содержит заголовок, содержащий следующие поля:
fragment_id: позиция пакета в последовательности
num_fragments: общее количество пакетов в последовательности
fragment_length: длина данных пакета
Обработчик сообщений использует заголовки пакетов, чтобы гарантировать повторную сборку сообщения в правильном порядке и отсутствие утерянных частей. Однако реализация этой функции содержит некоторые ошибки, которые можно использовать.
CVE-2020-0609
memcpy_s копирует каждый фрагмент по смещению в пределах буфера повторной сборки, который выделяется в куче. Смещение для каждого фрагмента вычисляется путем умножения идентификатора фрагмента на 1000. Однако проверка границ не учитывает смещение. Предположим, что размер буфера равен 1000, и мы отправляем сообщение с двумя фрагментами.
1-й фрагмент (fragment_id=0) имеет длину 1. this->bytes_written равен 0, поэтому проверка границ проходит.
1 байт записывается в буфер по смещению 0, а bytes_written увеличивается на 1. Второй фрагмент (fragment_id=1) имеет длину 998. проверка границ проходит.
998 байт записываются в буфер по смещению 1000 (fragment_id*1000), что приводит к записи 998 байт после конца буфера.
Следует отметить, что пакеты не обязательно отправлять по порядку (помните, это UDP). Таким образом, если первый пакет, который мы отправляем, имеет fragment_id=65535 (максимум), он будет записан со смещением 65535*1000, т.е. полные 65534000 байт после конца буфера. Управляя fragment_id, можно записать до 999 байт в диапазоне от 1 до 65534000 после окончания буфера. Эта уязвимость гораздо более гибкая, чем типичное линейное переполнение кучи. Это позволяет нам контролировать не только размер записываемых данных, но и смещение до места их записи. Благодаря дополнительному контролю легче выполнять более точную запись, избегая ненужного повреждения данных.
CVE-2020-0610
Объект класса поддерживает массив 32-битных целых чисел без знака (по одному для каждого фрагмента). Как только фрагмент получен, соответствующий элемент массива устанавливается с 0 на 1. Как только каждый элемент устанавливается на 1, повторная сборка сообщения завершена, и сообщение может быть обработано. В массиве есть место только для 64 записей, но идентификатор фрагмента может находиться в диапазоне от 0 до 65535. Единственная проверка заключается в том, что fragment_id меньше, чем num_fragments (которое также можно установить равным 65535). Следовательно, установка для fragment_id любого значения от 65 до 65535 позволит нам записать 1 (TRUE) за пределами массива. Хотя возможность установить единственное значение в 1 может показаться неправдоподобным для превращения в RCE, даже самые незначительные изменения могут оказать огромное влияние на поведение программы.
Если по какой-либо причине вы не можете установить патч, все же можно предотвратить использование этих уязвимостей. RDG поддерживает протоколы HTTP, HTTPS и UDP, но уязвимости существуют только в коде, отвечающем за обработку UDP. Простого отключения использования UDP или брандмауэра порта UDP (обычно порта 3391) достаточно для предотвращения эксплуатации. Отключение протокола UDP продемонстрировано на рисунке 27.
2.4 Session Hijacking
Перехват сеанса — это тип атаки, при котором злоумышленник может получить доступ к активному сеансу, который не доступен злоумышленнику напрямую. Чтобы продемонстрировать атаку такого типа, нужно создать сценарий. На рисунке 28 представлен демонстрационный стенд на Windows с включенной службой удаленного рабочего стола и работающей с двумя активными пользователями: raj и aarti. Одним из наиболее важных факторов для выполнения атаки перехвата сеанса является то, что другой сеанс, который мы пытаемся перехватить, должен быть активным.
Пусть мы вошли под пользователем raj, используя учетные данные, которые удалось извлечь на предыдущих этапах проникновения, описанных в разделе 3.2.
Теперь нам нужно снова запустить Mimikatz после входа в систему как пользователь raj. Необходимо перечислить все активные сеансы. Мы используем команду сеансов из модуля ts. На рисунке 30 видим, что существует сеанс 3 для пользователя aarti, который активен.
Использовали команду elevate для повышения уровня из модуля токена, чтобы выдавать текущий токен за NT AuthoritySYSTEM и предоставить возможность подключения к другим сеансам. Вернувшись к выходным данным сеанса, мы увидели, что у пользователя aarti есть сеанс 3. Нам нужно подключиться к этому конкретному сеансу с помощью удаленной команды модуля ts. Пример подключения продемонстрирован на рисунке 31.
Как видно на рисунке 32, удалось получить сеанс удаленного рабочего стола для пользователя aarti, имея изначально доступ к пользователю raj. Таким образом session hijacking успешно реализована в службе удаленного доступа RDP.
3 Рекомендации по повышению уровня защищенности RDP
Около 80% взломов связано не с уязвимостями протокола RDP, а с ненадежными паролями. Поэтому в компаниях должна быть принята и закреплена в инфраструктуре политика использования сложных для подбора паролей и обязательной двухфакторной аутентификацией. Пароли пользователям желательно хранить в специальных защищенных менеджерах паролей. Решения по безопасности также должны быть дополнительно защищены паролем, чтобы нельзя было их отключить изнутри при атаке.
3.1 Журналы событий в Windows
Прежде чем переходить к смягчению последствий атак на RDP, нам сначала нужно уметь обнаружить следы атаки. Как и все службы в Windows, удаленный рабочий стол также создает различные журналы, содержащие информацию о пользователях, которые вошли в систему, или время, когда они вошли в систему и вышли из нее, с указанием имени устройства и, в некоторых случаях, IP-адреса подключающегося пользователя.
Существуют различные типы журналов, касающихся службы удаленного рабочего стола. Например: журналы аутентификации, входа в систему, выхода из системы, подключения сеансов. При подключении к клиенту аутентификация может быть успешной или неудачной. Для этих случаев есть различные EventID для распознавания. Журналы аутентификации находятся внутри раздела безопасности. Рассмотрим некоторые из них:
EventID 4624: процесс аутентификации прошел успешно
EventID 4625: процесс аутентификации завершился сбоем
Есть события Logon и Logoff. Вход в систему произойдет после успешной аутентификации. Logoff будет отслеживать, когда пользователь был отключен от системы. Эти конкретные журналы будут расположены по следующему адресу:
Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.
Event ID 21: Remote Desktop Logon
Event ID 23: Remote Desktop Logoff
Наконец, есть журналы подключения к сеансу. В этой категории больше всего событий, потому что существуют разные причины отключения, и пользователю должно быть понятно на основе конкретного идентификатора события. Эти журналы расположены по следующему адресу:
Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational.
EventID 24: сеанс удаленного рабочего стола отключен
EventID 25: сеанс удаленного рабочего стола переподключен
3.2 Установка ограничения времени активного сеанса
Для смягчения последствий мы также можем установить определенное ограничение по времени для отключенных сеансов, бездействующих служб удаленного рабочего стола, которые могут забивать использование памяти, и других. Эти политики можно найти по адресу:
Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.
3.3 Network Level Authentication
NLA обеспечивает более надежную защиту от подмены ключей, требуя аутентификацию до установления сессии и во время сессии. В последние годы именно NLA затрудняла эксплуатацию серьезных уязвимостей в протоколе.
3.4 Ряд других полезных практик:
-
Если RDP не используется, то выключите его и отключите на брандмауэре сети внешние соединения с локальными машинами на порту 3389 (TCP/UDP) или любом другом порту RDP.
-
Использовать VPN (англ. Virtual Private Network – виртуальная частная сеть).
-
Используйте нестандартные ключи, например, PKI (Public Key Infrastructure), а соединения RDP стройте с помощью TLS (Transport Layer Security).
-
Постоянно обновляйте все ПО на устройствах сотрудников до актуальных версий. Помните, что 80-90% эксплойтов создано после выхода патча на уязвимость. Узнав, что была уязвимость, атакующие ищут ее именно в старых версиях софта. Это является хорошей практикой корпоративной ИТ-политики. Кроме того, любые незащищенные или устаревшие компьютеры нужно изолировать.
-
По возможности используйте шифрование на устройствах, которые используются для решения рабочих задач (например, шифрование диска).
-
Сделайте резервные копии ключевых данных. Резервные копии должны быть доступны только администратору или пользователю резервного копирования. Права на папки к файлам резервного копирования также должны быть максимально ограничены.
-
Блокировать учетные записи с пустым паролем.
-
Использовать двухфакторную аутентификацию.
-
Настроить политику блокировки при неудачных попытках ввода пароля. Рекомендуется установить значение блокировки равное 3.
-
Ограничить кол-во пользователей, которые могут войти в систему с помощью RDP.
Спасибо за прочтение и уделенное время!
Надеюсь, данный материал был полезен. Будьте бдительны и следите за актуальными уязвимостями, чтобы снизить риски атак на вашу корпоративную инфраструктуру. Благодарю за прочтение!
В этой инструкции описаны рекомендуемые действия по защите Вашего сервера.
Переименуйте стандартную учетную запись администратора
Нажмите Win + X и выберите «Управление компьютером»:
Затем выберите «Локальные пользователи» —→ «Пользователи» —→ кликните правой кнопкой мыши по имени пользователя «Администратор» и выберите «Переименовать»:
Переименуйте пользователя и используйте это имя для последующих подключений к удаленному рабочему столу.
Блокировка RDP-подключений для учетных записей с пустым паролем
Усилить безопасность можно запретив подключаться к учетным записям с пустым паролем. Для этого нужно включить политику безопасности «Учетные записи»: разрешить использование пустых паролей только при консольном входе»:
-
Откройте локальную политику безопасности (нажмите Win + R и введите команду secpol.msc)
-
Перейдите в раздел «Локальные политики» –-> «Параметры безопасности».
3. Дважды щелкните на политике «Учетные записи: разрешить использование пустых паролей…» и убедитесь, что она включена:
Вещь полезная, поэтому не оставляйте этот параметр без внимания.
Смена стандартного порта Remote Desktop Protocol
Не лишним будет сменить стандартный порт на котором работает протокол RDP. Как это сделать уже описано в наших инструкциях: Windows Server 2012 и Windows Server 2016.
Защита от буртфорса
Чтобы блокировать множественные попытки подключения с неверными данными, можно отслеживать журнал событий и вручную блокировать атакующие IP адреса посредством брандмауэра Windows или воспользоваться готовым приложением. Последний случай мы рассмотрим подробнее.
Для блокировки атакующих IP адресов будем использовать свободно распратраняющееся ПО — IPBan. Это приложение проверено и работает в Windows Server 2008 и всех последующие версях. Windows XP и Server 2003 — не роддерживаются. Алгоритм его работы простой: программа мониторит журнал событий Windows, фиксирует неудачные попытки входа в систему и, после 5-ти попыток злоумышленника подобрать пароль, блокирует IP адрес на 24 часа.
Итак:
- Cкачайте архив с программой здесь;
- В нем находятся два архива IPBan-Linux-x64.zip и IPBan-Windows-x86.zip, нам нужен последний. Распакуйте архив IPBan-Windows-x86.zip в любое удобное место (в примере это корень диска C:);
- Так как файлы скачанные с интернета система автоматически блокирует в целях безопасности, для работы приложения необходимо разблокировать все файлы. Щелкните правой кнопкой мыши на все извлеченные файлы и выберите свойства. Обязательно выберите «разблокировать», если этот параметр доступен. Либо, откройте окно PowerShell (Win + R, введите powershell и «ОК») и воспользуйтесь командой следующего вида:
get-childitem “местоположение папки” | unblock-file -confirmНапример:
4. Вам нужно внести следующие изменения в локальную политику безопасности, чтобы убедиться, что в логах системы отображаются IP-адреса. Октройте «Локальную политику безопасности» (Win + R, введите secpol.msc и «OK«). Перейдите в «Локальные политики» —> «Политика аудита» и включить регистрацию сбоев для «Аудита входа в систему» и «Аудита событий входа в систему»:
5. Для Windows Server 2008 или эквивалентного вам следует отключить логины NTLM и разрешить только NTLM2-вход в систему. В Windows Server 2008 нет другого способа получить IP-адрес для входа в систему NTLM. Октройте «Локальную политику безопасности» (Win + R, введите secpol.msc и «OK«). Перейдите в «Локальные политики» —> «Параметры безопасности» —> «Сетевая безопасность: Ограничения NTLM: входящий трафик NTLM» и установите значение «Запретить все учетные записи»:
6. Теперь необходимо создать службу IPBan, чтобы приложение запускалось при старте системы и работало в фоновом режиме. Запустите оснастку PowerShell (Win + R, введите powershell и «ОК») и выпоните команду типа:
sc.exe create IPBAN type= own start= auto binPath= c:\"Каталог с программой"\IPBan.exe DisplayName= IPBANНапример:
Перейдите в службы (Win + R, введите services.msc и «OK«) и запустите службу IPBAN, в дальнейшем она будет запускаться автоматически:
В «Диспетчере задач» можно убедиться, что служба запущена и работает:
Таким образом, программа следит за неудачными попытками авторизации и добавляет неугодные IP адреса в созданное правило для входящих подключений брандмауэра Windows:
Заблокированные IP адреса можно разблокировать вручную. Перейдите на вкладку «Область» в свойствах правила «IPBan_0» и удалите из списка нужный Вам IP адрес:
Защита RDP-подключения: как обеспечить безопасный удаленный доступ к компьютеру
Основные угрозы при использовании RDP
Несмотря на удобство удаленного рабочего стола, он несет в себе множество рисков:
- Атаки методом перебора паролей (Brute Force) – злоумышленники автоматически подбирают пароли, используя специальные программы.
- Эксплуатация уязвимостей в протоколе RDP – устаревшие версии могут содержать бреши в безопасности.
- Фишинговые атаки – хакеры могут получить учетные данные через поддельные сайты или электронные письма.
- DDoS-атаки – перегрузка сервера может привести к отказу в обслуживании.
Чтобы минимизировать риски, необходимо грамотно подойти к настройке RDP-сервера и использовать специализированные решения для защиты.
Как настроить RDP-подключение для безопасного удаленного доступа
1. Включение двухфакторной аутентификации
Одним из самых надежных методов защиты RDP является двухфакторная защита. Это дополнительный уровень безопасности, который требует ввода кода подтверждения из приложения или SMS.
2. Изменение стандартного порта RDP
По умолчанию RDP использует порт 3389, который легко находят злоумышленники. Изменение порта снижает вероятность атак методом подбора пароля.
3. Ограничение доступа по IP-адресу
Можно настроить RDP так, чтобы доступ к серверу был возможен только с определенных IP-адресов.
4. Использование VPN
Настройка RDP через VPN позволит скрыть сервер от посторонних глаз, обеспечивая дополнительную защиту данных.
5. Отключение учетных записей по умолчанию
Учетная запись Administrator – одна из первых целей злоумышленников. Лучше создать новую учетную запись с уникальным именем.
6. Ограничение количества попыток входа
Настройка удаленного доступа RDP должна включать ограничение попыток входа, что поможет защитить систему от атак методом перебора.
7. Обновление системы и использование антивирусного ПО
Обновление ОС Windows 10 и Windows Server помогает закрыть уязвимости, а антивирусные программы блокируют вредоносное ПО.
Как работает защита RDP с 2GC
Компания 2GC предлагает эффективное решение для защиты RDP-подключения. Продукт основан на технологии Argo Tunnel от Cloudflare, которая обеспечивает защищенное соединение без прямого открытия портов.
Преимущества 2GC:
- Защита RDP-сервера без сложных настроек.
- Автоматическое шифрование трафика для защиты данных.
- Обход DDoS-атак благодаря серверам Cloudflare.
- Удобный интерфейс – подключение осуществляется без командной строки.
- Поддержка SSH, RDP и других протоколов.
Как настроить RDP в Windows 10 через 2GC
Процесс подключения через 2GC упрощен до минимума:
- Установите утилиты Cloudflare на сервер.
- Настройте удаленный рабочий стол RDP в Windows.
- Подключитесь через клиент 2GC.
Итог
Настройка RDP в Windows 10 требует тщательного подхода к безопасности. Использование двухфакторной аутентификации, изменение стандартного порта, настройка доступа по IP и VPN значительно снижают риски.
Однако, если вам нужен простой и надежный инструмент для защиты удаленного подключения, обратите внимание на 2GC – решение, разработанное для малого и среднего бизнеса, обеспечивающее надежную защиту RDP без сложных настроек.
📌 Инвестируйте в надежные технологии и защитите свой бизнес с 2GC!
Ранее мы рассказывали, как настроить сервер терминалов, а сегодня поговорим о его защите. Далее будут рассмотрены пять мер, позволяющих существенно повысить безопасность RDP в Windows 2016. В статье предполагается, что сервер терминалов уже прошел предварительную настройку и работает. Все скриншоты соответствуют Windows Server 2016.
Смена стандартного порта Remote Desktop Protocol
Начнем со стандартной меры — смены стандартного порта Windows 2016 RDP, что позволит предотвратить атаку всем известных портов (well-known ports).
Настройку порта можно осуществить с помощью реестра —
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber.
Рис. 1. Смена порта RDP в Windows Server 2016 с помощью редактора реестра
После этого запустите Брандмауэр Windows и на боковой панели слева выберите Дополнительные параметры. Далее — Правила для входящих соединений и нажмите кнопку Создать правило (на панели справа)
Рис. 2. Правила для входящих подключений
В появившемся окне выберите Для порта и нажмите кнопку Далее. Затем выберите Определенные локальные порты и введите порт, указанный при редактировании реестра (рис. 3). В следующем окне мастера нужно выбрать Разрешить подключение (рис. 4).
Рис. 3. Задаем новый порт
Рис. 4. Разрешаем подключение
Собственно, на этом настройка безопасности RDP завершена. Отключитесь от сервера и установите новое соединение. Не забудьте в настройках RDP-клиента Windows Server 2016 указать новый порт: IP-адрес_сервера: порт.
Блокируем учетные записи с пустым паролем
Усилить RDP безопасность можно, запретив windows server подключаться учетным записям с пустым паролем. Для этого нужно включить политику безопасности «Учетные записи: разрешить использование пустых паролей только при консольном входе»:
- Откройте локальную политику безопасности (нажмите Win + R и введите команду secpol.msc)
- Перейдите в раздел Локальные политики, Параметры безопасности
- Дважды щелкните на нужной нам политике и убедитесь, что для нее задано значение Включен (рис. 5).
Рис. 5. Включение политики безопасности в Windows 2016 RDP «Учетные записи: разрешить использование пустых паролей только при консольном входе»
Настраиваем политику блокировки
Основная проблема в том, что по умолчанию Windows-server (даже 2016!) не защищен от брутфорса, поэтому безопасность RDP в Windows 2016 пребывает не на очень высоком уровне. При наличии какого-либо сервиса, в частности, FTP, вас могут брутфорсить, пока не получат доступ к системе, перебирая огромное множество логинов и паролей. Именно поэтому необходима настройка временной блокировки пользователя после нескольких неудачных попыток.
Необходимый набор правил и настроек называется Политика блокировки учетной записи (Account Lockout Policy). Пока вы еще не закрыли окно Локальная политика безопасности, перейдите в раздел Политики учетных записей, Политика блокировки учетной записи. Установите Пороговое значение блокировки — 5 (максимум 5 неудачных попыток входа), Продолжительность блокировки учетной записи — 30 (на 30 минут учетная запись будет заблокирована после 5 неудачных попыток входа).
Рис. 6. Настройка политики блокировки учетной записи
Настройка службы шлюза служб терминалов
Служба «Шлюз TS (служб удаленных рабочих столов)» Windows Server 2016 разрешает сторонним пользователям реализовывать удаленное подключение к терминальным серверам и другим машинам частной сети с активированным протоколом удаленного рабочего стола. Служба обеспечивает RDP безопасность подключений за счет использования протокола HTTPS/SSL, что позволяет не заниматься настройкой VPN для шифрования трафика.
Служба позволяет контролировать доступ к машинам, устанавливая правила авторизации и требования к удаленным пользователям. Администратор сможет контролировать пользователей, которые могут подключаться к внутренним сетевым ресурсам, сетевые ресурсы, к которым могут подключаться пользователи, определять, должны ли клиентские компьютеры быть членами групп Active Directory и др.
Порядок действий для установки службы «Шлюз ТS»:
- Откройте Диспетчер серверов и на главной его странице нажмите ссылку Добавить роли и компоненты
- Нажмите Далее, а затем выберите Установка ролей или компонентов.
- Выберите ваш сервер из пула серверов
- Выберите Службы удаленных рабочих столов и нажмите Далее несколько раз, пока не достигнете страницы Выбор служб ролей
- Выберите службы ролей Шлюз удаленных рабочих столов (рис. 7)
- Нажмите кнопку Добавить компоненты
- Нажимайте Далее для завершения процедуры установки. Когда все будет готово для установки выбранных компонентов, нажмите кнопку Установить (рис. 8).
Рис. 7. Установка службы ролей
Рис. 8. Все готово для установки
Далее нужно создать сертификат для шлюза служб удаленных рабочих столов. Запустите Диспетчер служб IIS, выберите пункт Сертификаты сервера. На панели справа выберите Создать сертификат домена. Введите необходимые сведения (рис. 11).
Рис. 9. Диспетчер служб IIS
Рис. 10. Выберите Создать сертификат домена
Рис. 11. Информация о сертификате
Далее нужно выбрать центр сертификации, который подпишет сертификат, и нажать кнопку Готово. Сертификат появится в списке сертификатов.
Следующий шаг — настройка шлюза TS на использование сертификата. Вернитесь к Диспетчеру серверов и, используя меню Средства, запустите Диспетчер шлюза удаленных рабочих столов. Обратите внимание, что есть одна ошибка — Сертификат сервера еще не установлен или не выбран. Собственно, все, что остается сделать — нажать ссылку рядом Просмотр и изменение свойств сертификата и выбрать ранее созданный сертификат, нажав кнопку Импорт сертификата (рис. 13). В этом окне также можно создать самозаверяющийся сертификат.
Рис. 12. Диспетчер шлюза удаленных рабочих столов
Рис. 13. Выбор сертификата SSL
Используем протокол SSL/TLS для защиты RDP
Если соединение с RDP-сервером реализовывается не через VPN, для обеспечения защиты подключений рекомендуется активировать SSL/TLS-туннелирование соединения.
Опцию RDP через TLS можно активировать через набор правил и настроек защиты сервера удаленных рабочих столов. Введите команду gpedit.msc и перейдите в раздел Конфигурация компьютера, Административные шаблоны, Компоненты Windows, Службы удаленных рабочих столов, Узел сеансов удаленных рабочих столов, Безопасность. Откройте политику Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP. Выберите значение Включено и выберите уровень безопасности SSL (рис. 14).
Рис. 14. Включение RDP через TLS
На этом настройка безопасности RDP Windows server 2016 закончена. Рекомендуем также прочитать статью «Обеспечение безопасности виртуального Windows-сервера». Если у вас что-то не получается, специалисты службы поддержки xelent.ru помогут вам с настройкой.