您好,登錄后才能下訂單哦!
怎么進行Microsoft Exchange任意用戶偽造漏洞的分析,相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
近日,Microsoft 公告中披露了一則關于 Exchange Server 的任意用戶偽造漏洞,天融信阿爾法實驗室對此漏洞進行了復現及分析。漏洞復現是在 exchange server 2010 SP2 中進行的,復現過程中,發現原作者給出獲取用戶 SID 的方法,在 2010 版本中并沒有相關操作選項,所以作者給出的 POC 也就無法使用。不過后來在Github中找到一個 POC。在該 POC 中,使用了一種反向委托的方法來獲取用戶 SID,并利用這個 POC 成功復現了漏洞。
Microsoft ExchangeServer 是個消息與協作系統。Exchange Server 可以被用來構架應用于企業、學校的郵件系統或免費郵件系統。它還是一個協作平臺。你可以在此基礎上開發工作流,知識管理系統,Web 系統或者是其他消息系統,是一個全面的 Internet 協作應用服務器,適合有各種協作需求的用戶使用。
在 MicrosoftExchange Server 中存在一個特權提升漏洞,該漏洞允許任何經過身份驗證的用戶冒充 ExchangeServer 上的其他任意用戶。漏洞產生的原因是由于在 Exchange Server 中使用 NTLM 身份驗證時存在特定缺陷,服務器產生的 NTLM 響應可以反射回攻擊者服務器,導致攻擊者可以驗證任意的 EWS(Exchange Web 服務)請求。
Exchange Server 2010
Exchange Server 2013
Exchange Server 2016
CVE-2018-8581
Windows 2008 R2
Exchange Server 2010 SP2
首先進行腳本參數配置。
在填好相關參數時,運行腳本。
然后再打開 web 界面執行相關操作。
輸入目標(Administrator)郵箱后確定。
最終就成功代理了目標(Administrator)郵箱。
在代理成功后,可以接收目標郵箱的郵件收取,也可以對其郵件進行查看、刪除等操作。
現在用 mailtest2 用戶向目標(Administrator)郵箱發送一封郵件。
可以看到,代理用戶成功接收到了由 mailtest2 用戶向目標(Administrator)郵箱新發來的郵件。
如果想移除委托關系,可以將腳本中的 FLAG 改為 0 后運行。
Remove 后再查看委托用戶的郵箱。
為了能夠讓大家在分析漏洞時能夠更加流暢,這里先介紹幾個概念。
SID 全稱為:Security Identifiers,是微軟從 Server2000 時代引入的一個概念:安全標識符。在 MicrosoftOS 系統中(Server2000 以上級別)工作組環境下:計算機、組、用戶都會有自己的 SID 號,這些信息是存儲在用戶計算機本地注冊表中的。這些 SID 號是根據其對象類型的不同隨機生成的,具有一定的命名規則。簡單來說,SID 其實就是對象身份的象征。
EWS 是微軟實現的一種客戶端和服務器之間的交換信息的協議。Exchange Server 提供了包括從電子郵件、會議安排、團體日程管理、任務管理、文檔管理、實時會議和工作流等豐富的協作應用。
3.1 什么是 NTLM 認證?
NTLM 認證簡單來說就是一種在不直接提供密碼的情況下,客戶端間接向服務器證明知道用戶的密碼,從而達到認證目的的一種方法。
3.2 NTLM 認證流程
3.2.1 客戶端如果試圖訪問服務器資源,首先會向服務器發送協商消息。在發送的請求中會包含一個以明文表示的用戶名。
3.2.2 服務器接收到請求后會生成一個 16byte 的隨機數,并返回給客戶端。這個隨機數被稱為 Challenge 或者 Nonce。
3.2.3 客戶端在接收到服務器返回的 Challenge 后,會使用當前登錄用戶的密碼哈希值對其加密,生成 Authenticate 認證消息,然后將 Authenticate 發送給服務器。
3.2.4 服務器接收到客戶端發送回來的 Authenticate 后,會向 DC(Domain)發送針對客戶端的驗證請求。該請求主要包含以下三方面的內容:客戶端用戶名,客戶端 Authenticate 和原始的 Challenge。
3.2.5 DC 根據用戶名獲取該帳號的密碼哈希值,對原始的 Challenge 進行加密。如果加密后的 Challenge 和服務器發送的一致,則意味著用戶擁有正確的密碼,驗證通過,否則驗證失敗。DC 將驗證結果發給服務器,并最終反饋給客戶端。
3.3 NTLM 認證消息的結構
Negotiate 協商消息、Challenge 挑戰消息和 Authenticate 認證消息, 他們的結構很相似:NTLMSSPXXXXXXXXXX。其中 NTLMSSP 表示是 NTLM 驗證的請求。但是在實際中,NTLMSSPXXXXXXXXXX 是經過 base64 編碼的。
舉個例子:
概念介紹完,接下來開始分析漏洞利用流程及原理,通過 POC 來看,漏洞利用執行過程可分為四大步驟。
圖一:總流程圖
獲取用戶 SID 的目的是為了后續構造 SOAP 頭來冒充用戶。
<t:EmailAddress>是攻擊者郵箱地址,這里可以理解成委托方。
<t:PrimarySmtpAddress>是受害者郵箱地址,可以理解成被委托方。
該腳本是通過反向委托的方式來獲取目標郵箱用戶 SID。通過向服務器發送一個將 CONTROLLED_EMAIL 委托給 TARGET_MAIL 的請求包,服務器就會返回 TARGET_MAIL 用戶 SID。
上圖是代碼執行流程,看代碼可以發現,這部分有多次 add 和 remove 委托的行為。之所以這樣重復請求,是為了防止發生意外錯誤。
上面說到 Exchange Server 添加委托操作的時候,服務器會返回被委托方(Target)的 SID,但是當添加委托時,返回的數據包中如果包含 ErrorDelegateAlreadyExists 字符時,說明已經存在委托行為。
這時就需要先remove掉委托關系,然后再add,這樣才能獲取到用戶SID。
第二步:請求推送訂閱
推送訂閱目的是將 NTLM 響應返回給攻擊者服務器。
這部分是漏洞點所在,包括兩個漏洞--SSRF 和 NTLM 身份驗證缺陷。
SSRF 漏洞:攻擊者可以使用一個已認證的郵箱賬號發 EWS 發送推送訂閱請求。(圖中/EWS/Exchange.asmx 是 EWS 請求的地址)。推送訂閱時,Exchange 允許用戶自己指定 URL,所以攻擊者可以將這一 URL 改為自己的服務器地址。上圖的 EVIL_HTTPSERVER_URL 就是攻擊者自己的服務器。當這個推送訂閱請求包發送到服務器時,服務器就會向攻擊者指定的 URL 發送請求。
其中<t:URL>是 SSRF 的核心,跟蹤一下服務器處理流程。
根據請求的 Exchange.asmx 文件以及請求內容,找一下 Exchange Server 的處理函數。
可以看到該類其中有一個關鍵的數據成員 Url, 下面跟蹤一下該成員函數,看看哪里使用了該成員函數。
可以看到該 Url 被保存到 PushSubScription 的 clientUrl 中了。
跟蹤發現該變量僅有三處使用。
主要的一處便是通過 Http 協議進行 Notification 消息發送的過程。
在這里準備好各種參數之后,通過http協議和指定的URL進行通信。
NTLM 身份驗證缺陷:在發送請求時,Exchange Server 使用的是 CredentialCache.DefaultCredentials 進行連接:
并且 CredentialCache.DefaultCredentials 是以 NT AUTHORITY\SYSTEM 權限運行,這就會導致 Exchange Server 將服務器生成的 NTLM 響應發送到攻擊者的服務器。Exchange Server 默認情況下還設置了以下注冊表項:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck= 1
這就導致攻擊者可以使用返回 NTLM 響應進行 HTTP 身份驗證,從而可以驗證任意 EWS 請求。
第三步:構造攻擊數據包
由于 CredentialCache.DefaultCredentials 是以 NT AUTHORITY\SYSTEM 權限運行,所以攻擊者可以與 TokenSerializationRight 進行「特權」會話,然后利用 SOAP 頭部模擬任何想要偽裝的用戶。
使用一開始獲取到的用戶 SID 來構造 SOAP 頭冒充受害者用戶。
SOAP Body 處構造的是委托請求的包,作用是目標郵箱的 inbox 收件箱將會委托于攻擊者,這樣就可以查看并修改目標郵箱的郵件。
第四步:NTLM 認證及攻擊
這里攻擊者利用 Python HTTPServer 搭建一個簡單的 web 服務器來作為自己的服務器,這個服務器其實是起到一個代理(中轉)的作用。因為在 NTLM 認證證程中,它監聽并響應著 Exchange Server 訂閱功能發來的請求(請求中包含 NTLM 值),同時利用得到的 NTLM 響應值請求 EWS,在這個過程中,它其實充當著就是一種像中間代理人一樣的身份。我們可以把這個攻擊者服務器稱作代理服務器。
下面以 Wireshark 通信流量包來詳細分析下 NTLM 的整個認證及攻擊流程,大家可對照總流程(圖一)的第四步驟來分析。
首先,攻擊者在推送訂閱后,Exchange Server 的訂閱功能會向代理服務器發送 POST 請求。
然后代理服務器會返回一個包含 WWW-Authenticate:NTLM 的 header 頭并返回 401 狀態(未認證)。
Exchange Server 收到后,就會發送一個 Negotiate 協商消息開始 NTLM 驗證。
然后代理服務器會用這個 Negotiate 協商消息并帶上 relay_body(攻擊包)去請求 EWS。
接著,EWS 就會返回 Challenge 挑戰消息,然后代理服務器會將這個 Challenge 挑戰消息響應回 Exchange Server 的訂閱功能。
Exchange Server 的訂閱功能接收到后,就會對其加密,返回 Authenticate 認證消息給代理服務器。
然后,代理服務器返回了 401 狀態。其實這個返回什么并不重要,因為我們目的是獲取 Authenticate 認證消息。
最后代理服務器就會用這個獲取到的 Authenticate 認證消息并帶上 relay_body(攻擊包)去請求 EWS,從而成功驗證并完成攻擊。
手工修復:
刪除 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck 鍵值
在管理員權限的命令行窗口中,輸入如下命令:
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa/v DisableLoopbackCHECK /f
在刪除鍵值后,無需重新啟動操作系統,也無需重新啟動 Exchange Server。
官方補丁:
Microsoft 在 2018 年 11 月發布了補丁,但該補丁僅對該漏洞進行了緩解,并沒有進行嚴格意義上的修復。不過 Microsoft 發布的公告指出,在此后 Exchange 累計更新中,將不會再默認啟動這一注冊表項。
看完上述內容,你們掌握怎么進行Microsoft Exchange任意用戶偽造漏洞的分析的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。