RDP 遠程桌面連接協(xié)議，作為相對比較廣泛的協(xié)議。對于協(xié)議識別來說很值得學習。首先 RDP 資料豐富，開源的程序也特別多。另一方面作為一個比較老的協(xié)議，版本豐富，兼容性強，小問題也多。從安全的角度更能看出協(xié)議的演變和發(fā)展。本文會從環(huán)境搭建、簡要分析和思考這幾方面來講解。

預備知識

除非另有說明，否則數(shù)據(jù)包一律按 little-endian 字節(jié)順序排列

RDP協(xié)議的發(fā)展

RDP（Remote Desktop Protocol，遠程桌面協(xié)議）是基于 ITU-T（國際電信聯(lián)盟）的T.120協(xié)議中的T.128應用程序共享協(xié)議（又稱為 T.share），隨后由英國軟件公司 DataConnection Limited 優(yōu)化成 RDP 的雛形。此時，微軟看到 RDP 是塊肥肉，果斷收購了DataConnection Limited，進而把 RDP 變成自己的囊中物（知識產(chǎn)權(quán)）。

發(fā)展至今，已經(jīng)有 10 個版本了。當前主要使用的版本有 6.1（Windows Server 2008/Windows Vista SP1/Windows XP SP3），7.0（Windows Server 2008 R2/Windows 7），其中 7.0 版本增加了 Remote FX 功能，用于提升高清圖像的渲染效果，如 2D、3D 圖像。（摘自全球主流云桌面?zhèn)鬏攨f(xié)議 - 知乎 ）

目前 RDP 協(xié)議標志位(對應了第一階段的RDP Negotiation Request,requestedProtocols 字段)一共有[六個版本]([MS-RDPBCGR]: RDP Negotiation Request (RDP_NEG_REQ) | Microsoft Learn)分別是 PROTOCOL_RDP、 PROTOCOL_SSL、 PROTOCOL_HYBRID、  PROTOCOL_RDSTLS、  PROTOCOL_HYBRID_EX 、PROTOCOL_RDSAAD。

PROTOCOL_RDP 又稱為標準型RDP協(xié)議，最早出現(xiàn)在Windows NT 4.0上，這個協(xié)議本身本身就存在很大隱患，它使用明文傳輸。之后采取多種安全級別的加密算法，它支持四個加密級別：低、客戶端兼容、高、 并且符合 FIPS（無、40位RC4、56位RC4、128位RC4或3DES ），可以在服務器上配置所需的加密級別來傳輸數(shù)據(jù)。

對于標準的RDP協(xié)議微軟犯了一個錯誤，加密的算法使用 RSA, 但是公鑰是內(nèi)置在客戶端中。也就是說所有服務器的私鑰其實都是一樣的。微軟現(xiàn)在已經(jīng)公開了此私鑰：

[MS-RDPBCGR]: Terminal Services Signing Key | Microsoft Learn

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/c2389e29-5706-4ac4-b555-e26f93144db7

這個版本中RDP Negotiation Request 并沒有 requestedProtocols 字段，后續(xù)設計為了保障安全微軟直接使用了 TLS 協(xié)議，同時為了兼容增加了requestedProtocols 字段作為可選字段。有些 rdp 協(xié)議的實現(xiàn)中并沒有注意這一點導致程序?qū)Υ税姹镜?RDP 不兼容(默認配置的 windows 2000,windows 2003,xrdp)。

PROTOCOL_SSL 使用標準的加密層,類似于 http 和 https 的關(guān)系。數(shù)據(jù)默認是安全的，所以在傳輸過程中內(nèi)部的數(shù)據(jù)是明文的，但是也有問題一旦知道私鑰就很容解出來例如在 clientInfo 中會直接傳遞明文包含賬戶密碼

在rdp協(xié)議鏈接階段也會把一些本地主機的信息發(fā)送給客戶端

RDP在前兩個版本里不具備鑒權(quán)功能，只有數(shù)據(jù)傳輸?shù)墓δ堋ｈb權(quán)只能使用 windows 自身身份認證的功能。

PROTOCL_HYBRID、PROTOCOL_HYBRID_EX就是為了解決這個問題，從 PROTOCL_HYBRID協(xié)議起，操作系統(tǒng)身份鑒別功能由憑證安全支持提供商（CredSSP）協(xié)議來提供，簡單的來說，就是在進入遠程桌面的界面之前，需要實現(xiàn)輸入正確的用戶名和密碼，也就是我們常說的 NLA。

摘自死磕RDP協(xié)議，從截圖和爆破說起

https://www.freebuf.com/articles/network/365312.html

CredSSP 協(xié)議雖然也使用 TLS 隧道，但它不是在受保護的隧道中傳輸密碼，而是使用 NTLM 或 Kerberos 進行身份驗證。該協(xié)議也稱為網(wǎng)絡級認證（NLA）。使用外部安全協(xié)議的好處是 RDP 開發(fā)人員不再需要手動實現(xiàn)協(xié)議安全機制，而是可以依賴眾所周知且經(jīng)過驗證的安全協(xié)議包（例如實現(xiàn) SSL 的 Schannel 安全包，請參閱 [MSDN- SCHANNEL]）提供端到端安全性。

RDP協(xié)議的分層

RDP協(xié)議棧分為六個層次自上向下分別為

1. 應用層（也可以稱為RDP層，因為應用就是RDP，主要是基于T.128協(xié)議）
   在這一層，RDP 作為應用程序運行，處理遠程桌面會話中的具體應用邏輯，例如圖形界面的渲染、輸入設備的信號處理等。
2. 安全層（用于加密）
   這一層負責加密 RDP 會話，以保護數(shù)據(jù)傳輸?shù)陌踩浴Ｋ鼈兩婕皵?shù)據(jù)加密、身份驗證和完整性檢查。
3. MCS (Multipoint communication service) 、GCC(Generic Conference Control)層[ T.124 ]（MCS和GCC都是國際電信聯(lián)盟 (ITU) T.120 系列的一部分）
   這一層處理會話的建立、管理和結(jié)束等多點通信服務。(負責維持連接)。區(qū)別: GCC 主要用于 RDP 會話的會議控制和管理提供了會議的創(chuàng)建和維護機制 ,MCS側(cè)重于數(shù)據(jù)傳輸和通信管理處理實際的數(shù)據(jù)交換和消息流。MCS負責數(shù)據(jù)傳輸和交換，GCC負責會話的創(chuàng)建和維護
4. ISO 層(TPKT)（包含國際電信聯(lián)盟 (ITU) X224協(xié)議）和TCP/IP層
   它是一種連接層協(xié)議，用于在 RDP 會話中建立、管理和斷開連接。(為了防止TCP粘包)
5. TCP/IP層
   最底層是網(wǎng)絡協(xié)議層，主要使用 TCP/IP 協(xié)議棧來傳輸 RDP 會話數(shù)據(jù)。這一層處理所有與網(wǎng)絡相關(guān)的通信，如 IP 地址管理和數(shù)據(jù)包傳輸。

工具

nmap和wireshark

實際上nmap和wireshark 可以解決大部分協(xié)議分析和學習問題。

環(huán)境

準備工作

獲取rdp 私鑰

Wireshark for Pentester: Decrypting RDP Traffic（https://www.hackingarticles.in/wireshark-for-pentester-decrypting-rdp-traffic/）

如何使用Wireshark解密Windows遠程桌面（RDP）協(xié)議-二進制漏洞-看雪-安全社區(qū)(https://bbs.kanxue.com/thread-255173.htm)

下載好最新版本的Mimikatz（https://github.com/gentilkiwi/mimikatz/releases）把Mimikatz放到RDP服務器里，命令行執(zhí)行Mimikatz.exe 運行下面3條命令

privilege::debug
crypto::capi
crypto::certificates -systemstore:CERT_SYSTEM_STORE_LOCAL_MACHINE -store:"Remote Desktop" /export

步驟2：把.pfx轉(zhuǎn)換成.pem

openssl pkcs12 -in win.pfx -out mykey.pem 

運行上面的命令以后，會提示需要密碼( password )，輸入 mimikatz 即可

注意 測試的最新版本的 windows10 導出不了私鑰

抓取rdp流

為了抓取干凈的數(shù)據(jù)包需要進行一些設置 首先捕獲過濾器設置

host 192.168.34.124 and port 3389

登錄后保存數(shù)據(jù)包

解密 RDP 數(shù)據(jù)流

wireshark 設置 菜單欄 Wireshark -> preference -> protocols ->TLS

設置完解密后rdp 連接初始化(Connect Request PDU)并沒有使用TLS加密。會顯示Ignored Unknown Record

這個是數(shù)據(jù)包解析錯誤導致的，為了便于分析請設置請選中此數(shù)據(jù)包

此時數(shù)據(jù)包會顯示正常

開始分析

微軟將rdp初始化連接分成10部分

連接順序可以分為十個不同的階段但是并不是所有的階段都會出現(xiàn)如 Security Exchange 在標準RDP中會出現(xiàn)。但是增強型RDP中沒有出現(xiàn)。我們這里只關(guān)注必要的階段

1. 初始化連接

X.224 Connection Request PDU

tpktHeader  數(shù)據(jù)格式如下

tpktHeader (4 bytes): A TPKT Header, as specified in [T123] section 8.

x224Crq 數(shù)據(jù)格式如下

x224Crq (7 bytes): An X.224 Class 0 Connection Request transport protocol data unit (TPDU), as specified in [X224] section 13.3.

X.224 Connection Response PDU

圖片來源： RDP Negotiation Request (RDP_NEG_REQ) | Microsoft Learn --- [MS-RDPBCGR]：RDP 協(xié)商請求 （RDP_NEG_REQ） |Microsoft 學習

作為協(xié)議識別只需要知道第一個階段已經(jīng)可以粗略識別了。在這里參考bodyhack的代碼。

像fofa一樣解析RDP信息，RDP提取操作系統(tǒng)，RDP登錄截屏 （Golang實現(xiàn)）

https://xz.aliyun.com/t/11978

另外想要精確識別就是在進行 tls連接后會進行ntlmssp的挑戰(zhàn)響應，能夠非常準確的提取出來主機名和操作系統(tǒng)的版本。

網(wǎng)絡空間測繪技術(shù)之：協(xié)議識別（RDP篇） - 知乎 (zhihu.com)

https://zhuanlan.zhihu.com/p/336936793

發(fā)現(xiàn)的問題

在實現(xiàn)的時候為了準確和方便需要判斷如果flag支持 CredSSP。實現(xiàn)過程中發(fā)現(xiàn)我測試的 windows7 版本在發(fā)送 ntlm 協(xié)議的時候并沒有正確的返回數(shù)據(jù)。抓包后發(fā)現(xiàn)NTLMSSP_NEGOTIATE消息被分開兩部分發(fā)送了。我們先看看正常的數(shù)據(jù)包

再看一下不正常的

先發(fā)送 30 再發(fā)送其他數(shù)據(jù)。經(jīng)過調(diào)試和分析發(fā)現(xiàn)是 Golang 標準庫在實現(xiàn)的時候為了解決 TLS1.0 的安全問題而引入的https://github.com/golang/go/blob/2184a394777ccc9ce9625932b2ad773e6e626be0/src/crypto/tls/conn.go#L1216

大概意思是 TLS 1.0 在使用塊模式密碼時容易受到選擇明文攻擊，因為它們的初始化向量是可預測的。通過將每個應用數(shù)據(jù)記錄分成兩條記錄，可以有效地隨機化初始化向量，從而防止這種攻擊。解決此類問題有兩種方法:

使用 FOFA (無腦吹確實好用)隨機選擇10000條測試一下效果

fofax -q 'protocol="rdp"' -ec -fs 10000 >rdp.txt

經(jīng)過 naabu 測試存活后測試。發(fā)現(xiàn) FOFA 對于使用 TLS1.0 版本的 ntlmssp 的挑戰(zhàn)響應并沒有解析成功。

再次挑選測試發(fā)現(xiàn)有些版本的 windows 客戶端可以正確連接，但是使用 Golang 在進行 TLS 握手的時候直接退出，看環(huán)境推測是 windows server 2016。搭建以后抓包

經(jīng)過分析，發(fā)現(xiàn) Server Hello 要求的 Cipher Suite 為TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)。Client Hello 中并沒有支持。(go 默認支持的很少)好吧統(tǒng)統(tǒng)加上去，可以正常識別了。

本文發(fā)布時，此類問題 FOFA 已經(jīng)修復，其他空間搜索引擎可以自測。

思考

在協(xié)議識別過程中，各家系統(tǒng)對協(xié)議支持都相對比較完善了。但是基礎庫應該已經(jīng)是協(xié)議識別準確率的短板。很多廠商很有可能并沒有關(guān)注這一塊。只是依賴編程語言的標準庫或者第三方庫。而對于不同的協(xié)議尤其是老舊協(xié)議的支持，還有加密算法的支持，可能隨著編程語言和安全的發(fā)展往往無法會廢棄掉，而這種基礎庫往往很見細節(jié)，可能少實現(xiàn)一個都會漏掉很多。