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

[[327661]]

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

CVE-2020-1113

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

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

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

NTLM中繼101

下圖給出了NTLM中繼攻擊的簡(jiǎn)化視圖：

 

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

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

示例回顧

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

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

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

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

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

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

HTTP→LDAP(PrivExchange);

RPC的一些背景知識(shí)

定義

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

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

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

誰會(huì)使用RPC?

RPC用于遠(yuǎn)程系統(tǒng)管理，WMI基于DCOM，該DCOM使用RPC作為傳輸方式(有時(shí)通過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手動(dòng)執(zhí)行遠(yuǎn)程任務(wù)，可能使用特權(quán)帳戶。

 

默認(rèn)情況下，RPC用于Windows防火墻，因?yàn)樗糜谶h(yuǎn)程管理。

身份驗(yàn)證和完整性

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

 

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

認(rèn)證級(jí)別

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

 

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

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

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

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

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

MS-DCOM：服務(wù)器應(yīng)注冊(cè)[MS-RPCE] 2.2.1.1.7節(jié)中指定的一個(gè)或多個(gè)安全提供程序，安全提供者的選擇取決于實(shí)現(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)身份驗(yàn)證級(jí)別。

攻擊過程

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

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

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

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

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

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

PoC或GTFO

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

攻擊者啟動(dòng)ntlmrelayx.py

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

 

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

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

# net view \\172.16.100.21\noshare\ 

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

 

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

中繼攻擊的破壞力

測(cè)試了以下場(chǎng)景：

 

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

一些有趣的用例

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

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

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

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

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

漏洞詳情

研究人員發(fā)現(xiàn)，MIME庫中MFMutableData的實(shí)現(xiàn)缺少對(duì)系統(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)程漏洞可以在處理下載的電子郵件時(shí)觸發(fā)，在這種情況下，電子郵件將無法完全下載到設(shè)備上。

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

利用漏洞后的異常行為

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

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

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

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

下面的調(diào)用樹是從崩潰日志中提取的，只有選定的一些設(shè)備才會(huì)發(fā)生崩潰。通過分析MIME庫，-[MFMutableData appendBytes:length:]的偽代碼如下：在崩潰發(fā)生之前執(zhí)行以下調(diào)用堆棧：如果數(shù)據(jù)大小達(dá)到閾值，則使用文件存儲(chǔ)實(shí)際數(shù)據(jù)，當(dāng)數(shù)據(jù)更改時(shí)，應(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)用將無法截?cái)辔募⒎祷芈┒创a。但是，在ftruncate系統(tǒng)調(diào)用失敗時(shí)，_flushToDisk無論如何都會(huì)繼續(xù)，這意味著映射的文件大小不會(huì)擴(kuò)展，執(zhí)行最終會(huì)到達(dá)appendBytes()函數(shù)中的memmove()，從而導(dǎo)致mmap文件出現(xiàn)超出邊界(OOB)的寫入。

濫用用戶帳戶

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

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

 

濫用計(jì)算機(jī)帳戶

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

 

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

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

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

編碼

我們將于6月中旬將對(duì)impacket的修改推送到以下GitHub存儲(chǔ)庫，請(qǐng)你注意查看：

https://github.com/CompassSecurity/impacket

緩解措施

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

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

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

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

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

5. 立即停止使用NTLM。

以下想法可以改善ntlmrelayx中對(duì)RPC的支持：

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

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

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

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

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