追溯解密基於 SSL 加密的 RDP 會話

網路竊聽者可以記錄加密後的RDP（Remote Data Protocol）會話，並且之後可以解密。這種方式可能洩露通過RDP連線傳送的所有資料，包括按鍵動作、使用者名稱及密碼。本文主要說一下幕後過程。

更加專業的說法是：這篇文章關於  完全正向保密（Perfect Forward Secrecy – PFS），為何SSL連線往往不是想象中的那樣安全。因為RDP使用SSL，所以容易遭遇追溯解密。

使用Wireshark記錄加密的RDP連線

我會記錄我的乙太網介面的所有流量，然後使用mstsc(Microsoft terminal services client)連線到一個RDP伺服器，並輸入一個密碼。輸入密碼之後我直接停止了資料抓取。

怎樣判別RDP會話脆弱可攻擊

如果你首先對 TCP 3389 埠流量進行“Analyze | Follow TCP Stream” ，然後“Analyze | Decode As… | SSL”，Wireshark會顯示SSL伺服器Hello資訊。檢查是否在用基於 RSA 演算法的密碼套件。如果是，那這篇文章適用於RDP會話，並會告訴你如何破解它。

Wireshark跟蹤展示SSL伺服器Hello訊息

請注意，相對基於 CredSSP（SSL+NLA）的連線，我只是嘗試了以SSL為基礎的RDP連線，所以情況因人而異。

開始解密…

提取服務證書的SSL私鑰

隨著伺服器被滲透，擁有管理員許可權的攻擊者可以輕易地從證書儲存區提取用於服務驗證的私鑰。

geocerts站點提供如何這樣做的逐步解說，它與其它解說一樣好。被終端伺服器使用的證書位於為“Computer Account”建立的“Personal”或者“Remote Desktop”證書儲存區。僅僅使用MMC的“Certificates”外掛為SSL證書匯出私鑰。我匯出的檔案使用.pfx格式，它需要你設定一個密碼。

做這個示例時我使用Windows 2003伺服器。我覺得從更新版本的Windows中提取所需證書更加困難。這就把它當作練習留給讀者了。

將.pfc格式檔案轉化為.pem格式

為了解密SSL流量，我們會用到Wireshak，它處理PEM格式檔案（這裡是.cer格式）時需要使用金鑰。而格式的轉化僅需要使用以下OpenSSL單行小命令：

使用Wireshark解密流量

使用Wireshare 解密SSL流量時有一點棘手，是因為對我來說，學習使用這個教程時Wireshark首次為我所用。

我指定RSA金鑰列表如下：

接下來在Wireshark中有可能看到所有清晰的文字流量。在“Follow TCP Stream”對話方塊中，我選擇了十六進位制儲存方式並向下翻動對話方塊。我正在尋找符合我輸入密碼的按鍵的一些簡簡訊息。

Wireshare顯示符合按鍵流量的十六進位制轉儲檢視

紅色字型顯示的資訊來自於RDP客戶端。我們會檢查以44 04 00開頭的每四個位元組一組的資訊。這些以44 04 00的資訊與金鑰按鍵被按下的動作相符合，而以44 04 01開頭的四個位元組資訊則是與金鑰按鍵被釋放動作相符合。

首個感興趣的資訊是：

然後是每種情況中的鍵掃描碼最後四個位元組。（漏掉一些不感興趣的內容）：

如果我們依次查詢每一項可以得到到：

當我們考慮到SHIFT鍵的作用，可以將password變化為Password1。

結論

攻擊者追溯解密SSL流量的能力在某些情況下是不可取的。這不是某個不尋常或者孤立的例子。因為很大部分HTTPS網站很容易出現同樣的問題。

從傳統意義上來說，這不是一個漏洞。它引發的這些弱點允許攻擊者盜取SSL私鑰，從這一點來說，所有的安全宣告都形同虛設。

實際上，回顧完全正向保密的缺失非常有趣，完全正向保密與微軟的安全漏洞定義相對立。它看上去與微軟的定義並不適應。如果正向保密的缺失真的呈現出了問題，那麼這問題將會導致“某些標準不完美卻被廣泛接受”。

當RSA作為金鑰交換演算法時，禁用對RSA的支援是SSL問題通常的補救方法。然而，我還沒有找到Windows 2003上的有效解決方案。閱讀補丁KB245030之後，我做了以下設定登錄檔項的實驗：

然而，我只是成功地完全阻止了RDP連線。