幾年來，不斷有人利用NTLM中繼了大量內容，以提升Windows網絡中的特權。

[[327661]]

在本文中，我們建議從impacket到已經很好的ntlmrelayx中添加對RPC協議的支持，并探索它提供的新滲透測試方法。

CVE-2020-1113

由于沒有針對RPC協議的全局完整性驗證要求，中間人攻擊者可以將受害人的NTLM身份驗證中繼到通過RPC協議選擇的目標。如果受害者在目標上具有管理特權，則攻擊者可以在遠程目標上執行代碼，這個攻擊是在一個完全打了補丁的Windows Server 2016域控制器上測試的。

Compass Security在2020年1月發現了此漏洞，并向Microsoft安全響應中心披露了該漏洞，并將其標識為CVE-2020-1113。

Microsoft在2020年5月星期二的更新中發布了此修復程序，實施的解決方案增加了Task Scheduler Service的完整性要求。不過，該方案不能解決RPC缺少全局完整性要求的問題。

NTLM中繼101

下圖給出了NTLM中繼攻擊的簡化視圖：

 

攻擊者充當客戶端的服務器，并充當服務器的客戶端。他從客戶端消息中提取NTLM身份驗證塊，并將其放入服務器的修改后的消息中，反之亦然。最后，他可以根據需要使用經過身份驗證的會話。

為了使這種攻擊奏效，攻擊者就必須處于中間人的位置。這可以使用傳統的欺騙技術(ARP，DNS，LLMNR和Netbios等)，或者通過一個錯誤或誤用的特性(打印機錯誤、Juicy Potato等)觸發到攻擊者機器的連接來實現。

示例回顧

NTLM中繼已在多種攻擊中使用和重用：

1. 打印機錯誤：一種從Windows Server觸發SMB連接的好方法(與不受約束的委托結合使用特別方便);

2. PrivExchange：或如何從擁有Exchange郵箱的任何用戶升級為Domain Admins;

3. 斷開MIC ：或如何完全繞過繼電器保護。

這些攻擊中繼了以下協議：

SMB→SMB(打印機錯誤);

HTTP→LDAP(PrivExchange);

RPC的一些背景知識

定義

1. 遠程過程調用(RPC)是指程序在其他地址空間(例如在另一臺計算機上)中執行過程。

2. DCE / RPC是由Open Group設計的RPC協議標準;

3. MSRPC(aka MS-RPCE)是Microsoft的DCE / RPC的修改版本;

誰會使用RPC?

RPC用于遠程系統管理，WMI基于DCOM，該DCOM使用RPC作為傳輸方式(有時通過SMB)：

1. 監控和遠程管理工具支持WMI(快速搜索將提供例如Solarwinds，NetCrunch，PRTG，LanSweeper，Kaseya等)，并且必須配置特權服務帳戶。

 

注意：此監控解決方案需要具有管理權限的憑據，一旦獲取管理權限的憑據，此帳戶將嘗試連接到網絡中的所有主機。

2. 系統管理員還可以使用WMI手動執行遠程任務，可能使用特權帳戶。

 

默認情況下，RPC用于Windows防火墻，因為它用于遠程管理。

身份驗證和完整性

安全服務提供商，依賴RPC的工具使用標準Windows安全提供程序進行身份驗證，可能有以下值：

 

請注意，默認值為WINNT，這意味著NTLM身份驗證通過。

認證級別

身份驗證級別設置RPC交換中是否存在身份驗證和完整性檢查：

 

再次注意，默認值為CONNECT，這意味著沒有完整性檢查。

幸運的是，大多數基于RPC的協議都具有最低的安全要求(在Microsoft的每個協議文檔的第2.1節中都有詳細記錄)：

MS-SAMR：服務器SHOULD

MS-LSAD：請求者不得使用RPC提供的安全支持提供程序機制(用于身份驗證、授權、機密性或防篡改服務)。

不幸的是，其他一些具有較少的限制性要求：

MS-DCOM：服務器應注冊[MS-RPCE] 2.2.1.1.7節中指定的一個或多個安全提供程序，安全提供者的選擇取決于實現。

MS-TSCH：RPC服務器必須要求RPC_C_AUTHN_GSS_NEGOTIATE或RPC_C_AUTHN_WINNT授權。 RPC客戶端必須使用[MS-RPCE] 2.2.1.1.8節中指定的RPC_C_AUTHN_LEVEL_PKT_PRIVACY(值= 6)身份驗證級別。

攻擊過程

MS-WMI使用MS-DCOM，它是一個很好的攻擊載體。然而，由于典型的WMI代碼執行需要對多個RPC接口進行身份驗證，因此它不是NTLM中繼攻擊的最佳選擇(沒有重新身份驗證方法)。

MS-TSCH是管理計劃任務的協議，在atexec.py中使用，這是否意味著我們可以中繼NTLM身份驗證并使用預定的任務執行代碼?當然是的。

我們修改后的impacket包含以下三個新組件：

1. RPCRelayServer響應傳入RPC連接;

2. RPCRelayClient啟動到目標的RPC連接;

3. RPCAttack(基于ATExec)在目標上執行代碼;

PoC或GTFO

在我們的設置中，攻擊者計算機具有IP 172.16.100.21，目標計算機DC是具有最新補丁程序版本的Windows Server 2016，并且具有IP 172.16.100.1。受害用戶WINLAB \scooper-da在DC計算機的本地Administrators組中，并使用IP 172.16.100.14從該計算機打開一個SMB連接。

攻擊者啟動ntlmrelayx.py

攻擊者將安裝我們的自定義版本的impacket，并在其IP為172.16.100.21的主機上啟動該工具，他想在目標172.16.100.1上添加本地管理員(名為compass)：

 

通過受害者觸發連接

受害人從計算機172.16.100.14打開與攻擊者計算機的SMB連接，這模仿了管理員使用前面提到的工具訪問共享或執行管理任務：

# net view \\172.16.100.21\noshare\ 

該工具將啟動連接并進行中繼，由于中繼用戶是目標計算機上的本地管理員，因此他有權添加我們的新管理員：

 

結果，將創建一個新用戶并將其添加到本地Administrators組。

中繼攻擊的破壞力

測試了以下場景：

 

服務器端的SMB簽名(在我們的測試中設置為必需，如默認的DC安裝一樣)可防止從RPC中繼到SMB。在客戶端，默認情況下不需要SMB簽名，這可以成功中繼到RPC。

一些有趣的用例

在對iOS數字取證和事件響應(DFIR)進行例行調查之后，研究人員發現了一些可疑事件，這些事件早在2018年1月就影響了iOS上的默認郵件應用程序。研究人員分析了這些事件，發現了一個影響蘋果iphone和ipad的可利用漏洞。ZecOps在很長一段時間內，在企業用戶、vip和mssp上檢測到該漏洞的多個觸發器。

該漏洞的攻擊范圍包括向受害者的郵箱發送自定義電子郵件，使其能夠在iOS 12上的iOS MobileMail應用程序或在iOS 13上發送的郵件中觸發該漏洞。

幾乎沒有可疑事件包括黑客通常使用的字符串(例如414141…4141)，經過確認，我們驗證了這些字符串是由電子郵件發送者提供的。值得注意的是，盡管有證據顯示證實了受攻擊者的電子郵件是由受害者的iOS設備接收和處理的，但本應接收并存儲在郵件服務器上的相應電子郵件卻丟失了。因此，我們推斷這些電子郵件可能已被有意刪除。

我們知道從2018年1月開始在iOS 11.2.2上發生了多個觸發事件，當前，攻擊者可能正在濫用這些漏洞，詳情請點此。在研究觸發這些漏洞的過程中，我們已經看到一些可疑受害者之間的相似之處。

1.所有經過測試的iOS版本都容易受到攻擊，包括iOS 13.4.1;2.根據我們的發現，這些漏洞都是在iOS 11.2.2或更高版本上主動觸發的;3.iOS 6及更高版本容易受到攻擊，iOS 6于2012年發布，iOS6之前的版本可能也會受到攻擊，但我們尚未檢查較早的版本。因為在iOS 6發行時，iPhone 5已上市。

漏洞詳情

研究人員發現，MIME庫中MFMutableData的實現缺少對系統調用ftruncate()的漏洞檢查，該漏洞導致越界寫入。我們還找到了一種無需等待系統調用ftruncate失敗即可觸發OOB-Write的方法。此外，我們發現了可以遠程觸發的堆溢出。眾所周知，這兩種漏洞都是可以遠程觸發的。OOB寫入漏洞和堆溢出漏洞都是由于相同的漏洞而引發的，即未正確處理系統調用的返回值。遠程漏洞可以在處理下載的電子郵件時觸發，在這種情況下，電子郵件將無法完全下載到設備上。

受影響的庫：/System/Library/PrivateFrameworks/MIME.framework/MIME;易受攻擊的函數：-[MFMutableData appendBytes:length:]。

利用漏洞后的異常行為

除了手機郵件應用暫時放緩外，用戶觀察不到任何其他異常行為。在iOS 12上嘗試利用漏洞(成功/失敗)之后，用戶只會注意到郵件應用程序突然崩潰。在iOS13上，除了暫時的速度下降之外，這不會引起注意。如果隨后進行另一次攻擊并刪除電子郵件，則失敗的攻擊在iOS 13上不會明顯。

在失敗的攻擊中，攻擊者發送的電子郵件將顯示消息：“此消息無內容。”

崩潰取證分析，用戶經歷的部分崩潰(多次崩潰中的一部分)如下;崩潰的指令是stnp x8，x9，[x3]，這意味著x8和x9的值已被寫入x3并由于訪問存儲在x3中的無效地址0x000000013aa1c000而崩潰。

為了找出導致進程崩潰的原因，我們需要看一下MFMutableData的實現。

下面的調用樹是從崩潰日志中提取的，只有選定的一些設備才會發生崩潰。通過分析MIME庫，-[MFMutableData appendBytes:length:]的偽代碼如下：在崩潰發生之前執行以下調用堆棧：如果數據大小達到閾值，則使用文件存儲實際數據，當數據更改時，應相應更改映射文件的內容和大小，系統調用ftruncate()被inside -[MFMutableData _flushToDisk:capacity:]調用以調整映射文件的大小。ftruncate的幫助文檔是這樣說明的：如上所示，如果調用失敗，則返回-1，并且全局變量errno指定漏洞。這意味著在某些情況下，此系統調用將無法截斷文件并返回漏洞代碼。但是，在ftruncate系統調用失敗時，_flushToDisk無論如何都會繼續，這意味著映射的文件大小不會擴展，執行最終會到達appendBytes()函數中的memmove()，從而導致mmap文件出現超出邊界(OOB)的寫入。

濫用用戶帳戶

使用最少的特權來進行滲透測試，對于安全專業人員來說是一個極大的挑戰，所以管理員必須使用高權限帳戶處理所有事情。

RPC→RPC：你從監控工具獲得連接，并在其他主機上獲得管理員訪問權限。

 

濫用計算機帳戶

有時(通常是在舊的Exchange服務器上)，一個計算機帳戶是另一臺計算機的管理員。

 

此BloodHound捕獲顯示了一個常見的情況，即用一個計算機賬戶管理給其他計算機。

RPC→RPC：如果你在受害計算機上具有低特權會話，則可以使用RottenPotato觸發與攻擊者計算機的RPC連接并將其中繼到目標。

SMB→RPC：受害者計算機如果激活后臺處理程序服務，你可以使用打印機錯誤觸發與攻擊者計算機的SMB連接，并將其中繼到目標。

編碼

我們將于6月中旬將對impacket的修改推送到以下GitHub存儲庫，請你注意查看：

https://github.com/CompassSecurity/impacket

緩解措施

此攻擊依賴于幾個漏洞，CVE-2020-1113只是其中之一。以下是一些解決潛在漏洞的緩解措施：

1. 及時修補你的Windows!

2. 通過GPO對整個網絡中的客戶端和服務器強制執行數據包簽名;

3. 檢查你的Active Directory ACL：應該使用最小特權原則;

4. 網絡分段可以幫助防止中繼攻擊。

5. 立即停止使用NTLM。

以下想法可以改善ntlmrelayx中對RPC的支持：

1. 支持會話重用：RPC攻擊目前只有一次機會，不能像SMB那樣通過socks代理保存和重用會話。

2. 開發更多的RPC攻擊：使用未經分析的MS-DCOM，MS-WMI或其他協議，有可能使攻擊的工作范圍超出CVE-2020-1113。

3. 支持更多的RPC接口：某些客戶端將在身份驗證之前執行未經身份驗證的RPC調用。 PoC目前僅支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。

可以找到其他向量來獲得傳入的RPC連接：

Remote Juicy Potato：在“打印機錯誤”的線索中發現一個錯誤會很有趣，該錯誤會觸發通過RPC遠程驗證到給定主機的調用。