欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

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

預備知識

除非另有說明，否則數據包一律按 little-endian 字節順序排列

RDP協議的發展

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

發展至今，已經有 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 圖像。（摘自全球主流云桌面傳輸協議 - 知乎 ）

目前 RDP 協議標志位(對應了第一階段的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協議，最早出現在Windows NT 4.0上，這個協議本身本身就存在很大隱患，它使用明文傳輸。之后采取多種安全級別的加密算法，它支持四個加密級別：低、客戶端兼容、高、 并且符合 FIPS（無、40位RC4、56位RC4、128位RC4或3DES ），可以在服務器上配置所需的加密級別來傳輸數據。

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

[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 字段，后續設計為了保障安全微軟直接使用了 TLS 協議，同時為了兼容增加了requestedProtocols 字段作為可選字段。有些 rdp 協議的實現中并沒有注意這一點導致程序對此版本的 RDP 不兼容(默認配置的 windows 2000,windows 2003,xrdp)。

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

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

RDP在前兩個版本里不具備鑒權功能，只有數據傳輸的功能。鑒權只能使用 windows 自身身份認證的功能。

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

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

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

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

RDP協議的分層

RDP協議棧分為六個層次自上向下分別為

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

工具

nmap和wireshark

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

環境

準備工作

獲取rdp 私鑰

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

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

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

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

步驟2：把.pfx轉換成.pem

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

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

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

抓取rdp流

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

host 192.168.34.124 and port 3389

登錄后保存數據包

解密 RDP 數據流

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

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

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

此時數據包會顯示正常

開始分析

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

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

1. 初始化連接

X.224 Connection Request PDU

tpktHeader  數據格式如下

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

x224Crq 數據格式如下

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 協商請求 （RDP_NEG_REQ） |Microsoft 學習

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

像fofa一樣解析RDP信息，RDP提取操作系統，RDP登錄截屏 （Golang實現）

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

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

網絡空間測繪技術之：協議識別（RDP篇） - 知乎 (zhihu.com)

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

發現的問題

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

再看一下不正常的

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

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

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

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

經過 naabu 測試存活后測試。發現 FOFA 對于使用 TLS1.0 版本的 ntlmssp 的挑戰響應并沒有解析成功。

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

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

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

思考

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