幾年來，不斷有人利用NTLM中繼了大量內(nèi)容，以提升Windows網(wǎng)絡(luò)中的特權(quán)。

[[327661]]

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

CVE-2020-1113

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

Compass Security在2020年1月發(fā)現(xiàn)了此漏洞，并向Microsoft安全響應(yīng)中心披露了該漏洞，并將其標(biāo)識為CVE-2020-1113。

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

NTLM中繼101

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

 

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

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

示例回顧

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

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

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

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

這些攻擊中繼了以下協(xié)議：

SMB→SMB(打印機(jī)錯誤);

HTTP→LDAP(PrivExchange);

RPC的一些背景知識

定義

1. 遠(yuǎn)程過程調(diào)用(RPC)是指程序在其他地址空間(例如在另一臺計算機(jī)上)中執(zhí)行過程。

2. DCE / RPC是由Open Group設(shè)計的RPC協(xié)議標(biāo)準(zhǔn);

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

誰會使用RPC?

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

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

 

注意：此監(jiān)控解決方案需要具有管理權(quán)限的憑據(jù)，一旦獲取管理權(quán)限的憑據(jù)，此帳戶將嘗試連接到網(wǎng)絡(luò)中的所有主機(jī)。

2. 系統(tǒng)管理員還可以使用WMI手動執(zhí)行遠(yuǎn)程任務(wù)，可能使用特權(quán)帳戶。

 

默認(rèn)情況下，RPC用于Windows防火墻，因為它用于遠(yuǎn)程管理。

身份驗證和完整性

安全服務(wù)提供商，依賴RPC的工具使用標(biāo)準(zhǔn)Windows安全提供程序進(jìn)行身份驗證，可能有以下值：

 

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

認(rèn)證級別

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

 

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

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

MS-SAMR：服務(wù)器SHOULD

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

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

MS-DCOM：服務(wù)器應(yīng)注冊[MS-RPCE] 2.2.1.1.7節(jié)中指定的一個或多個安全提供程序，安全提供者的選擇取決于實現(xiàn)。

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

攻擊過程

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

MS-TSCH是管理計劃任務(wù)的協(xié)議，在atexec.py中使用，這是否意味著我們可以中繼NTLM身份驗證并使用預(yù)定的任務(wù)執(zhí)行代碼?當(dāng)然是的。

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

1. RPCRelayServer響應(yīng)傳入RPC連接;

2. RPCRelayClient啟動到目標(biāo)的RPC連接;

3. RPCAttack(基于ATExec)在目標(biāo)上執(zhí)行代碼;

PoC或GTFO

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

攻擊者啟動ntlmrelayx.py

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

 

通過受害者觸發(fā)連接

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

# net view \\172.16.100.21\noshare\ 

該工具將啟動連接并進(jìn)行中繼，由于中繼用戶是目標(biāo)計算機(jī)上的本地管理員，因此他有權(quán)添加我們的新管理員：

 

結(jié)果，將創(chuàng)建一個新用戶并將其添加到本地Administrators組。

中繼攻擊的破壞力

測試了以下場景：

 

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

一些有趣的用例

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

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

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

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

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

漏洞詳情

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

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

利用漏洞后的異常行為

除了手機(jī)郵件應(yīng)用暫時放緩?fù)猓脩粲^察不到任何其他異常行為。在iOS 12上嘗試?yán)寐┒?成功/失敗)之后，用戶只會注意到郵件應(yīng)用程序突然崩潰。在iOS13上，除了暫時的速度下降之外，這不會引起注意。如果隨后進(jìn)行另一次攻擊并刪除電子郵件，則失敗的攻擊在iOS 13上不會明顯。

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

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

為了找出導(dǎo)致進(jìn)程崩潰的原因，我們需要看一下MFMutableData的實現(xiàn)。

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

濫用用戶帳戶

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

RPC→RPC：你從監(jiān)控工具獲得連接，并在其他主機(jī)上獲得管理員訪問權(quán)限。

 

濫用計算機(jī)帳戶

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

 

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

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

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

編碼

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

https://github.com/CompassSecurity/impacket

緩解措施

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

1. 及時修補(bǔ)你的Windows!

2. 通過GPO對整個網(wǎng)絡(luò)中的客戶端和服務(wù)器強(qiáng)制執(zhí)行數(shù)據(jù)包簽名;

3. 檢查你的Active Directory ACL：應(yīng)該使用最小特權(quán)原則;

4. 網(wǎng)絡(luò)分段可以幫助防止中繼攻擊。

5. 立即停止使用NTLM。

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

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

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

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

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

Remote Juicy Potato：在“打印機(jī)錯誤”的線索中發(fā)現(xiàn)一個錯誤會很有趣，該錯誤會觸發(fā)通過RPC遠(yuǎn)程驗證到給定主機(jī)的調(diào)用。