Windows. Часть 4. RDP.

Глава 1. RDP.

УЧЕБНЫЕ ВОПРОСЫ:

1. ОСНОВЫ RDP.

2. RDP-СОЕДИНЕНИЕ.

3. БАЗОВЫЙ ВВОД И ВЫВОД.

4. КАНАЛЫ В RDP.

5. СЖАТИЕ ДАННЫХ.

6. RDP-БЕЗОПАСНОСТЬ.

7. АУТЕНТИФИКАЦИЯ НА УРОВНЕ СЕТИ.

8. УЯЗВИМОСТИ RDP.

9. ЗАЩИТА УДАЛЕННОГО РАБОЧЕГО СТОЛА.

ИСТОЧНИКИ С МАТЕРИАЛАМИ ПО RDP

• Передача файлов. Часть 3. Дополнительные способы передачи файлов [§ 3.3].
• 
  

§ 1.1. Основы RDP

1.1.1) RDP (Remote Desktop Protocol) — протокол для удаленного доступа к компьютерам Windows. RDP позволяет пользователям управлять своей удаленной машиной Windows.

Существует более 4,5 миллионов RDP-серверов, подключенных только к Интернету, а многие другие RDP-сервера доступны из внутренних сетей.

RDP-протокол популярен, например его используют Microsoft Azure и Hyper-V в качестве протокола удаленного подключения по умолчанию.

Связь в RDP основана на нескольких каналах, протокол поддерживает до 64 000 уникальных каналов.

RDP передаёт монитор с удаленного сервера клиенту, а клавиатуру и мышь с клиента на удаленный сервер. Связь RDP зашифрована блочным шифрованием RSA RC4.

TPKT — транспортная служба ISO поверх TCP . TPKT позволяет одноранговым узлам обмениваться информационными блоками — блоки данных транспортного протокола ( TPDU или PDU ).

X.224 — транспортный протокол с установлением соединения, он обеспечивает транспортную услугу в режиме соединения. RDP использует его в начальном запросе и ответе на подключение.

T.125 MCS — служба многоточечной связи, позволяет RDP обмениваться данными и управлять несколькими каналами.

Отправка и получение данных через RDP похожа на модель OSI для связи. Передаваемые данные разделяются, направляются в канал, шифруются, упаковываются, обрамляются и заново упаковываются перед передачей по сети другой стороне. Затем они проходят тот же процесс в обратном порядке.

§ 1.2. RDP-соединение

1.2.1) Этапы RDP-соединения:

1. Инициация соединения
2. Обмен основными настройками
3. Подключение канала
4. Начало безопасности
5. Безопасный обмен настройками
6. Лицензирование
7. Обмен возможностями
8. Завершение подключения
9. Обмен данными

1.2.2) Инициация соединения — RDP-соединение инициируется клиентом с использованием PDU-запроса соединения X.224. Этот пакет содержит запрос на согласование RDP, который содержит несколько флагов подключения и протоколы безопасности, поддерживаемые клиентом. Эти протоколы безопасности могут относиться к одной из двух категорий:

• Стандартная безопасность RDP: шифрование RSA RC4 по умолчанию)
• Улучшенная безопасность RDP: TLS, CredSSP (TLS + NTLM/Kerberos), RDSTLS (RDP с поддержкой TLS).

Соединение подтверждается сервером с помощью X.224 Connection Confirm PDU. Этот пакет содержит ответ на согласование RDP, который используется для информирования клиента о выбранном протоколе безопасности, который будет использоваться на протяжении всего времени существования соединения.

С этого момента последующие данные будут упакованы в PDU данных X.224.

1.2.3) Обмен основными настройками — на этом этапе происходит обмен базовыми настройками между клиентом и сервером с использованием начального PDU MCS Connect и ответного PDU MCS Connect. 

Эти настройки, как со стороны клиента, так и со стороны сервера, включают в себя:

• Основные данные: версия RDP, разрешение рабочего стола, глубина цвета, информация о клавиатуре, имя хоста, информация о клиентском ПО (идентификатор продукта, номер сборки) и т. д.
• Данные безопасности: методы шифрования, размер сеансовых ключей, случайный выбор сервера (используется позже для создания сеансовых ключей) и сертификат сервера (некоторые из них актуальны только при использовании стандартной безопасности RDP).
• Сетевые данные: информация о запрошенных и выделенных виртуальных каналах. Он содержит количество каналов и массив конкретных виртуальных каналов. Клиент запрашивает точный тип каналов в запросе, а сервер предоставляет фактические идентификаторы каналов в ответе.

1.2.4) Подключение канала — после определения списка виртуальных каналов, которые будут использоваться в сеансе RDP, на данном этапе выполняется подключение каждого отдельного канала. Он имеет несколько подэтапов:

1. Запрос MCS Erect Domain — высота в домене MCS. Поскольку RDP не использует расширенные топологии MCS, он будет равен 0.

2. MCS Attach User Request — запрос идентификатора пользовательского канала.

3. MCS Attach User Confirm — идентификатор пользовательского канала

4–5.  Запрос и подтверждение присоединения к каналу MCS — клиент начнет запрашивать присоединение к виртуальным каналам, используя их идентификаторы. Начиная с пользовательского канала, канала ввода-вывода и продолжая виртуальными каналами, согласованными при обмене базовыми настройками. Сервер, в свою очередь, подтвердит каждое успешное подключение к каналу.

С этого момента последующие данные, отправляемые клиентом, будут упакованы в PDU запроса отправки данных MCS, а данные, отправленные сервером, будут заключены в PDU индикации отправки данных MCS. Теперь данные можно перенаправлять в виртуальные каналы.

1.2.5) Обеспечение безопасности — клиент отправляет Security Exchange запрос, содержащий данные клиента, случайно зашифрованные с помощью открытого ключа сервера. Затем клиент и сервер используют случайные числа для создания ключей шифрования сеанса.

С этого момента последующий трафик RDP может быть зашифрован.

1.2.6) Безопасный обмен настройками — на данном этапе клиент отправляет зашифрованный Client Info запрос, содержащий информацию о поддерживаемых типах сжатия, пользовательском домене, имени пользователя, пароле, рабочем каталоге и т. д:

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

Во многих случаях сервер лицензирования не настроен для RDP-сервера, в этом случае RDP-сервер просто отправит ответ клиенту, который «одобрит» его лицензию (только до 2 сеансов).

1.2.8) Обмен возможностями — сервер отправляет свои поддерживаемые возможности в Demand Active запрос, которая содержит структуру, имеющая множество возможностей различных типов. 

Согласно Microsoft, есть 28 типов наборов возможностей. Основные типы: общие (версия ОС, общее сжатие), ввод (тип и функции клавиатуры, поддержка быстрого доступа), шрифты, виртуальные каналы, растровые кодеки и т.п.

Затем сервер может отправить или не отправить Monitor Layot запрос для описания мониторов дисплея на сервере.

И в конце, клиент пересылает Confirm Active ответ, в котором содержится клиентский набор возможностей.

1.2.9) Завершение подключения — Клиент и сервер обмениваются несколькими типами данных, чтобы завершить соединение. Все эти данные исходят от клиента (PDU можно отправлять один за другим, не дожидаясь ответа):

• Synchronize — используется для синхронизации идентификаторов пользователей между клиентом и сервером.
• Control-Cooperate — и клиент, и сервер отправляют этот ответ, чтобы указать на совместное управление сеансом.
• Control-Request Control — клиент отправляет запрос на управление удаленным компьютером, а сервер предоставляет это право.
• Persistent Key List (необязательно) — клиент отправляет серверу список ключей, каждый ключ идентифицирует кэшированное растровое изображение. Это позволяет кэшу растровых изображений быть постоянным. Кэширование растровых изображений — это механизм, используемый для уменьшения сетевого трафика, необходимого для передачи графического вывода с сервера клиенту.
• Font List — эти ответы предназначены для хранения информации о шрифтах для RDP-сеанса (имя шрифта, средняя ширина, подпись и т. д.), однако похоже, что Microsoft их не использует. Сказав это, эти PDU все еще обмениваются между клиентом и сервером в этот момент, но без фактических данных в нем (даже если какие-либо данные были, документация Microsoft указывает, что вы должны их игнорировать).

1.2.10) Обмен данными — после завершения соединения большая часть данных, передаваемых между клиентом и сервером, будет состоять из:

• входных данных (клиент-сервер).
• графических данных (сервер-клиент). 

Дополнительные данные, которые могут быть переданы, включают информацию об управлении соединением и сообщения виртуального канала.

§ 1.3. Базовый ввод и вывод

1.3.1) Во время существования соединения клиент и сервер обмениваются основными входными/выходными данными. Клиент отправляет ввод, а сервер отправляет вывод.

1.3.2) Входные данные — содержат информацию о мыши и клавиатуре, а также периодическую синхронизацию (например, состояние клавиш NAM_LOCK / CAPS_LOCK).

1.3.3) Выходные данные — содержат растровые изображения сеанса пользователя на сервере. Кроме того, сервер может отправлять звуковую информацию (только в виде очень простого «гудка» — частота + продолжительность).

Эти базовые данные ввода/вывода могут передаваться одним из двух способов: медленным или быстрым путем .

Slow-Path — обычный PDU со всеми заголовками стека протоколов RDP.

Fast-Path — как следует из названия, он был создан для уменьшения как объема передаваемых данных, так и объема обработки, необходимой для их обработки. Это делается путем сокращения/удаления заголовков PDU из определенных типов PDU (например, ввод с клавиатуры/мыши).

§ 1.4. Каналы в RDP

1.4.1) В RDP большая часть данных передается по разным каналам (уровень MCS). Существует 2 основных типа каналов:

• статические виртуальные каналы.
• динамические виртуальные каналы.

1.4.2) Статические виртуальные каналы (SVC) — SVC обеспечивают связь между различными клиентскими и серверными компонентами через основное соединение данных RDP. 

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

Не все SVC созданы одинаковыми, некоторые открываются по умолчанию, а некоторые согласовываются на этапе обмена основными параметрами. SVC, которые создаются по умолчанию, имеют решающее значение для функциональности подключения RDP, в то время как другие позволяют использовать различные расширения для протокола.

Примеры SVC, созданных по умолчанию:

• Канал ввода/вывода
• Канал сообщений
• Пользовательский канал
• Канал сервера

SVC расширения идентифицируются по 8-байтовому имени, например:

• rdpdr — расширение файловой системы. Разрешает перенаправление доступа с сервера на файловую систему клиента.
• rdpsnd — расширение вывода звука.
• cliprdr — расширение буфера обмена. Позволяет совместно использовать буфер обмена между клиентом и сервером.
• drdynvc — расширение динамического виртуального канала (см. DVC ниже)

Все идентификаторы каналов SVC предоставляются на этапе обмена основными настройками, за исключением двух SVC: канала пользователя, который предоставляется на этапе подключения канала в PDU подтверждения подключения пользователя, и канала сервера, который имеет фиксированное значение 0x03EA (1002).

1.4.3) Динамические виртуальные каналы (DVC) — поскольку количество статических виртуальных каналов всего 31, RDP также поддерживает динамические виртуальные каналы. Динамические виртуальные каналы передаются по одному конкретному статическому виртуальному каналу — DRDYNVC. Эти каналы являются динамическими, поскольку вы можете создавать и уничтожать их на любом этапе жизни соединения (после инициализации). Разработчики могут создавать расширения, которые будут легко передавать данные по динамическому виртуальному каналу. Обычно DVC используются для ввода звука (клиент -> сервер), перенаправления PnP, рендеринга графики, эхо-канала, перенаправления видео и т. д.

1.4.4) Соотношение между различными типами каналов в RDP:

§ 1.5. Сжатие данных

1.5.1) RDP может использовать сжатие в выходных данных (как в быстром, так и в медленном пути) и в виртуальных каналах. И клиент, и сервер должны поддерживать сжатие в целом, а также определенный тип сжатия, согласованный для соединения. Клиент объявляет типы сжатия, которые он поддерживает, в PDU Client Info во время безопасного обмена параметрами.

Каждый PDU, который содержит сжатые данные, должен иметь некоторые флаги сжатия (содержащие тип сжатия и т. д.), установленные в заголовке этого конкретного PDU.

§ 1.6. RDP-безопасность

1.6.1) Безопасность протокола RDP может быть одного из двух типов:

• Стандартная безопасность
• Повышенная безопасность

1.6.2) Стандартная безопасность — трафик шифруется с использованием алгоритма шифрования RSA RC4 с использованием случайных значений клиента и сервера, которыми обмениваются на этапе обмена основными параметрами при инициализации соединения.

1.6.3) Повышенная безопасность — этот тип безопасности позволяет RDP передавать все операции безопасности (шифрование/дешифрование, проверки целостности и т. д.) внешнему протоколу безопасности. Это может быть одно из следующих:

• TLS 1.0/1.1/1.2
• CredSSP
• РДСТЛС

Решение о расширенном протоколе безопасности может приниматься либо на основе переговоров, либо напрямую. Основанный на согласовании означает, что инициализация соединения (запрос и ответ на соединение x.224) выходит за рамки протокола безопасности. После инициализации клиент и сервер выбирают протокол безопасности, выполняют рукопожатие по внешнему протоколу безопасности, и с этого момента все остальные этапы RDP-соединения будут инкапсулированы в этот внешний протокол безопасности.

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

Выбор усиленной безопасности означает, что этап начала безопасности не будет выполняться.

Ключевым преимуществом использования RDP Enhanced Security является то, что он включает аутентификацию на сетевом уровне (подробности доступны ниже).

§ 1.7. Аутентификация на уровне сети

Аутентификация на уровне сети (NLA) относится к использованию CredSSP для аутентификации пользователя перед инициацией подключения RDP. Это позволяет серверу выделять ресурсы только аутентифицированным пользователям.

В случае критической уязвимости в протоколе RDP NLA может ограничить использование этой уязвимости только аутентифицированными пользователями.

§ 1.8. Уязвимости RDP

1.8.1) Теперь, когда мы познакомились с основами протокола RDP, давайте рассмотрим некоторые из недавно обнаруженных критических уязвимостей и посмотрим, как они вписываются в общую картину протокола RDP.

1.8.2) BlueKeep (CVE-2019-0708) — это RCE-уязвимость в RDP-сервере Microsoft, затрагивающая компьютеры с Windows от Windows 2000 до Windows 7 и Windows Server 2008 R2. Она была обнаружена и исправлена ​​в мае 2019 года. Эта уязвимость представляет собой use-after-free , которая присутствовала в драйвере ядра Windows, обрабатывающем соединения RDP, — termdd.sys.

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

termdd.sys создает таблицу, содержащую указатель на структуру канала для каждого созданного канала. Эта таблица содержит до 32 (0x20) каналов. Статический виртуальный канал MS_T120 создается по умолчанию и всегда имеет индекс 0x1F. Это происходит еще до начала последовательности подключения.

Чтобы вызвать эту уязвимость, необходимо создать собственный RDP-клиент, который будет запрашивать статический виртуальный канал с именем MS_T120 в обмене основными настройками. Если такой канал запрашивается, RDP-сервер затем попытается выяснить, был ли этот канал уже создан для этого соединения. Если это так, он вернет указатель на существующую структуру управления каналом вместо создания новой. На данный момент у нас будет два указателя, указывающих на одну структуру данных, и массив каналов подключения будет выглядеть так:

Чтобы вызвать ошибку, клиент RDP должен отправить пакет, который заставит сервер закрыть канал MS_T120 (законное и задокументированное поведение). После закрытия канала сервер продолжит работу и освободит управляющую структуру канала MS_T120 и указатель на него в массиве каналов подключения, но только тот, который создан по запросу клиента (а не тот, который создан сервером автоматически) . Теперь у нас есть висячий указатель, и в следующий раз, когда сервер попытается получить доступ к каналу MS_T120 (что случается часто, так как это критический канал для работы RDP), система выполнит проверку на наличие ошибок.

1.8.3) DejaBlue (CVE-2019-1181 и CVE-2019-1182) — еще одна RCE-уязвимость в RDP-сервере Microsoft (отсюда и название), обнаруженная в 2019 году. На этот раз уязвимость затронула все версии Windows (7-10) до исправления. . DejaBlue — это целочисленная уязвимость переполнения, которая присутствовала в основной DLL RDP-сервера — RDPCoreTS.dll / RDPBase.dll (в зависимости от версии Windows).

Уязвимость заключается в функции, распаковывающей данные, отправленные по динамическому виртуальному каналу (DVC). Сжатые данные в DVC отправляются либо в PDU DYNVC_DATA_FIRST_COMPRESSED, либо в DYNVC_DATA_COMPRESSED. Фактические данные в любом из этих PDU представлены в форме RDP_SEGMENTED_DATA, которые могут содержать несколько сегментов. Сжатый RDP_SEGMENTED_DATA будет содержать несжатые данные.

Когда сервер RDP получает сжатый PDU DVC, он вызывает функцию, которая распаковывает его — DecompressUnchopper::Decompress(). Функция распаковки выделит память для распакованных данных размером uncompressedSize + 0x2000 без каких-либо проверок размера результата. Злоумышленник может сделать этот результат целочисленным для циклического переноса и привести к тому, что выделенная память станет меньше размера фактических распакованных данных. Это фактически приведет к переполнению кучи, которое можно использовать для выполнения кода.

Для более подробного изучения DejaBlue, вот несколько источников:

• https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html
• https://cyberx-labs.com/blog/analyzing-the-dejablue-heap-overflow-vulnerability/#_Toc28622447
• https://bbs.pediy.com/thread-256766.htm

§ 1.9. Защита удаленного рабочего стола

Есть 2 простых действия для защиты:

• Держать RDP-сервера под защитой брандмауэра.
• Включить NLA

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