微軟Exchange爆出0day漏洞，來看POC和技術細節
微軟 Exchange 似乎易受許可權提升攻擊影響，任何使用者，只要有郵箱，就能變身為 Domain Admin 。
荷蘭Fox-IT公司研究員Dirk-jan Mollema在部落格上釋出了PoC，並詳細解釋了攻擊細節。Mollema認為，主要的問題在於，Exchange預設在活動目錄域名具有高許可權。
他在部落格文章中指出，“ ExchangeWindowsPermissions 組在活動目錄的 Domain 物件上具有 WriteDacl 訪問許可權，使得該組成員均可修改域名許可權，其中的一個許可權是執行 DCSync 操作。”
這就導致攻擊者能夠通過Domain Controller操作同步活動目錄使用者的雜湊密碼。攻擊者可通過訪問這些雜湊密碼假冒使用者並在使用NTLM（微軟的認證協議）或該域名內的Kerberos認證的服務進行認證。
目前，Mollema尚未迴應相關問題。他釋出的部落格文章題目是《濫用Exchange：你距離成為Domain Admin僅差一個API呼叫》。全文如下：
在多數使用活動目錄和Exchange的組織機構中，Exchange伺服器都具有一種高許可權：成為Exchange伺服器上的Administer就足以提升至Domain Admin。最近我在ZDI上偶然發現了一篇部落格文章（見文末連結），他們詳細說明了如何使用NTLM經由HTTP讓Exchange進行認證。結合使用NTLM中繼攻擊，任何人只要擁有一個郵箱就能提升至Domain Admin許可權，在我所知道的大概90%的使用Exchange組織機構中都是可行的。這種攻擊可能是預設的，目前尚未有任何補丁，不過可以使用一些緩解措施來阻止此類許可權提升問題。本文詳細說明了這種攻擊，而且PoC已釋出，名為“PrivExchange”。
結合利用已知漏洞的新方法
這篇文章講的是如何結合利用一些新漏洞以及已知的協議弱點，發動新攻擊。結合使用3個元件，擁有郵箱的任何使用者就能提升至Domain Admin訪問許可權：
Exchange Servers預設的許可權太高 NTLM認證易受中繼攻擊 Exchange的某個功能使其能夠認證到具有Exchange伺服器計算機賬戶的攻擊者
Exchange和高許可權
這裡說的主要漏洞是，Exchange在活動目錄域名中具有高許可權。Exchange Windows Permissions組在活動目錄的Domain物件中具有WriteDacl訪問許可權，導致該組的任何成員都能修改域名許可權，其中一種許可權是執行DCSync操作。任何具有這種許可權的使用者或計算機都能執行同步操作，而這種操作正常情況下是供Domain Controllers進行復制，這就導致攻擊者能夠同步活動目錄中的所有使用者的雜湊密碼。多名研究人員曾對此進行過闡述（見文末參考部分），而且我和同事Rindert也在去年寫過。在那篇文章中我也釋出了ntlmrelayx的更新，增加了在NTLM中繼過程中執行這些訪問控制清單(ACL)攻擊的可能性。
NTLM 中繼機器賬戶
NTLM中繼已經存在有段時間了。之前，它的主要關注點是經由SMB中繼NTLM，以便在其它主機上執行程式碼。雖然到目前為止，仍然很可能在很多未啟用SMB簽名進行安全加固的公司中實施這種攻擊，但其它協議也易受中繼攻擊。我認為其中最有意思的協議就是LDAP，它可用於讀取並修改活動目錄中的物件。簡單說一下NTLM中繼，就是除非已經應用了緩解措施，否則在連線至攻擊者機器上之後和網路中的其它機器進行連線時，很可能會繞過Windows自動執行的認證，如下圖所示：
當認證被中繼到LDAP時，目錄中的物件可被修改，給予攻擊者許可權，包括DCSync操作所需要的許可權。因此，如果我們能夠使Exchange通過NTLM認證和我們進行認證，那麼我們就能執行ACL攻擊。值得注意的是，只有在受害者通過HTTP而非SMB和我們進行認證時，中繼到LDAP才奏效。
使 Exchange 進行認證
目前為止，唯一一個缺失的元件是使Exchange認證到我們的一種簡單方法。ZDI的一名未透露姓名的研究員發現，使 Exchange 經由 Exchange PushSubscription 功能通過 HTTP 向任意 URL 認證是很可能實現的。他們使用這個漏洞將NTLM認證中繼回Exchange（即反射型攻擊）並假冒其他使用者。如果我們再結合Exchange預設具有的高許可權並執行中繼攻擊而非反射型攻擊，那麼我們就能使用這些許可權獲得DCSync許可權。這個推送通知服務允許使用者在即使未發生任何事件的情況下每隔X分鐘（X值由攻擊者設定）傳送一次資訊。這就能確保Exchange即使在收件箱中沒有任何活動的情況下和我們連線。
執行許可權提升攻擊
實施攻擊，實現許可權提升的流程如下圖所示：
我們需要使用兩款工具執行該攻擊： privexchange.py 和 ntlmrelayx 。這兩款工具可從GitHub的PrivExchange和impacket庫中獲取。以中繼模式啟動ntlmrelayx，以Domain Controller上的LDAP作為目標，並通過如下程式碼使受攻擊者控制的使用者提升許可權（這個案例中是 ntu 使用者）：
我們開始執行 privexchange.py 指令碼：
如果是以沒有郵箱的使用者執行的話，就會得到如上出錯訊息。再嘗試一下通過具有關聯郵箱的使用者執行一下：
一分鐘之後（推送通知提供的值），我們可以看到連線進入ntlmrelayx，使用者獲得DCSync許可權：
我們確認DCSynx許可權位於secretsdump位置：
憑藉所有活動目錄使用者的雜湊密碼，攻擊者就相當於持有一張金卡，能夠假冒任何使用者或使用任何使用者密碼雜湊認證到任何接受NTLM或Kerberos域名認證的服務。
技術細節：中繼到 LDAP 並簽名
上文提到從SMB中繼到LDAP不起作用，這也是為何說這種攻擊無法通過使用最近釋出的SpoolService RPC濫用等實施（它通過SMB認證）的原因。由於關於這部分的問題很多，現在統一說一下。如果你不打算詳細瞭解NTLM認證部分，可以跳過這部分。
在SMB和HTTP中的NTLM認證的不同之處在於預設協商的標記(flag)。有問題的部分是 NTLMSSP_NEGOTIATE_SIGN 標記( 0x00000010 )，如MS-NLMP第2.2.2.5節所示。通過HTTP的NTLM認證並不會預設設定該標記，但如果是通過SMB認證，則會預設設定：
當我們將它中繼到LDAP時，認證成功，但LDAP的預期是所有通過衍生自密碼的會話金鑰簽名的資訊（中繼攻擊中不具備）。因此它會忽視任何不具備簽名的資訊，從而導致攻擊失敗。有人可能會想，是否可以在傳輸過程中修改這些標記，這樣就不用協商簽名了。由於Windows現代版本都預設包含一個MIC（資訊完整性程式碼）即基於所有3 NTLM資訊的簽名，因此對其中任何資訊的修改都會導致其不合法。
那我們能刪除MIC嗎？可以是可以，畢竟它並非受NTLM資訊保護的部分，但問題是NTLM認證(NTLMv2)中的最後一道防護措施阻止這樣做：在 NTLMv2 響應的底部（該響應本身以受害者密碼簽名）存在一個 AV_PAIR 結構 MsAvFlags 。當該欄位的值為 0x0002 時，表明客戶端傳送了一個具有type 3資訊的MIC。
修改NTLMv2響應將導致認證失效，因此我們不能刪除這個flags欄位。該欄位說明MIC被計算且包含，將使目標伺服器驗證MIC，從而驗證所有的3資訊都不會在傳輸過程中遭修改，因此我們無法刪除簽名標記。
我認為，這種情況僅對微軟對NTLM的實現有效。實現NTLM的自定義工具很可能並不受影響，只有新增MIC和AV_PAIR標記時，導致它們易受標記修改攻擊，從而導致SMB -> LDAP中繼成為可能。其中一個例子就是NTLM的Java實現，它可在傳輸過程中遭修改繞過安全措施。
攻擊無需任何憑證
上一節中，我們使用受攻陷憑證執行了攻擊的第一步。如果攻擊者只是位於執行網路攻擊的位置，但並不具備任何憑證，那麼仍然很可能觸發Exchange進行認證。如果我們執行SMB到HTTP（或HTTP到HTTP）中繼攻擊（使用LLMNR/NBNS/mitm6欺騙），那麼我們就能將位於同樣網路片段中的使用者認證中繼到Exchange EWS並使用他們的憑證觸發回撥。我給出了一小段修改後的httpattack.py，你可以結合ntlmrelayx從網路角度實施攻擊，而無需任何憑證（你只需要修改攻擊者主機即可，因為它在檔案中是硬編碼的）：
緩解措施
攻擊依靠多種元件才能實施。在此前的部落格文章中我已經強調過多種針對NTLM中繼攻擊和中繼到LDAP的防禦措施。
適用於該攻擊的最重要的緩解措施包括：
刪除Exchange在Domain物件上的不必要的高許可權。
啟用LDAP簽名以及LDAP通道繫結，分別阻止中繼到LDAP和LDAPS。
阻止Exchange伺服器和任意埠上的工作站進行連線。
啟用IIS中Exchange端點上（並非Exchange Back End，否則會導致Exchange崩潰）的Extended Protection for Authnticaiton。它將驗證NTLM認證中的通道繫結引數，它將NTLM認證關聯到TLS連線中並阻止向Exchange web服務進行中繼。
刪除登錄檔項(registry key)，從而能夠中繼回Exchange伺服器，如微軟對CVE-2018-8518緩解措施的討論。
在Exchange伺服器上執行SMB簽名（偏好域名中的所有其它伺服器和工作站）以阻止針對SMB的跨協議中繼攻擊。
如果不使用EWS的push/pull訂閱服務，則可以通過使用限制策略將EWSMaxSubscriptions設定為0的方式禁用。這是@gentikiwi提供的方法，我還沒有測試過合法應用程式使用它們的頻率，因此推薦在小範圍內進行測試。
工具以及受影響版本
PoC請參見 https://github.com/dirkjanm/PrivExchange ，且已在如下Exchange/Windows版本上進行了測試：
將Server2012R2 上的Exchange 2013 (CU21)中繼到Server 2016 DC（都是完全修復版本）
將Server 2016上的Exchange 2016 (CU11)中繼到Server 2019 DC（都是完全修復版本）
將Server 2019上的Exchange 2019中繼到Server 2019 DC（感謝@gentilkiwi進行測試）
如上的Exchange伺服器都是使用共享許可權模式安裝的（預設），但有writeup指出，RBAC拆分許可權部署也很容易受到攻擊（我並未親自測試過）。
Exchange 2010 SP3似乎並未受影響。在我的實驗室中，這個版本按類似於以上提及的SMB協商簽名，從而打破了這種中繼攻擊。版本14.3.435.0以及14.3.123.4均展現出這種行為。
資源/參考
可參見如下部落格文章、白皮書和研究論文了解關於此類攻擊的更多資訊：
1. 緩解資源
https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1
ACL許可權提升研究
2. NTLM中繼/簽名討論
NTLM反射型攻擊回顧 https://github.com/SecureAuthCorp/impacket/issues/451
NTLM SMB-> LDAP中繼 https://github.com/SecureAuthCorp/impacket/pull/500
中繼憑證林總
https://www.secureauth.com/blog/playing-relayed-credentials
3.其它參考
MS-NLMP
https://msdn.microsoft.com/en-us/library/cc236621.aspx
討論Exchange API的ZDI文章
通過meterpreter進行NTLM遠端中繼，討論如何遠端通過樞紐主機進行中繼
https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/