通過 HTTP 請求走私竊取活動目錄憑據
利用面向公眾的服務是在網絡中獲得初步立足點的方法之一，這種情況在野外會經常看到。眾所周知，各種攻擊者都會濫用諸如緩沖區溢出(G0098)、SQL注入(G0087)或其他已知帶有功能利用代碼(G0016)的漏洞。
本文描述了一個HTTP請求走私(HRS)漏洞，這是我們在一次滲透測試中發現的。它可以用來模擬利用面向公眾的服務，同時在客戶的網絡中獲得初步立足點。在這個示例中，它允許我們獲取Active Directory憑據，從而用該憑據登錄到Outlook Web Access (OWA)查看敏感數據。
本文還會介紹如何通過將客戶端遷移到一個中間人Exchange服務器來獲得對OWA的持久訪問權。
HTTP請求走私
HTTP請求走私(HRS)漏洞現在非常普遍。早在2005年，CGISecurity就發布了一份白皮書，詳細描述了漏洞是如何產生的，它會造成什么后果，以及如何緩解它。如果你不確定HRS是如何工作的，我強烈建議你閱讀這篇白皮書或PortSwigger關于HRS的文章來熟悉一下。當網絡服務器和代理可以不同步時，就會出現 HRS。攻擊者發送的請求在前端服務器和后端服務器上的解釋不同。例如，攻擊者發送一個特殊的請求，前端服務器將其解釋為1個請求，但后端服務器將其解釋為2個請求。第二個請求因此被“走私”通過前端服務器并最終到達后端服務器。正如 PortSwigger 的 James Kettle 所描述的，該請求的響應將被提供給下一位訪問者。
濫用HRS會極大地影響系統的保密性、完整性和可用性。正如一份負責任的披露中所公布的，Evan Custodio 能夠通過濫用 HRS 竊取 cookie 來接管 Slack 帳戶。其他示例包括 New Relic上的憑據盜竊和美國國防部基礎設施上的用戶重定向。
在我們的例子中，HRS允許我們獲取Active Directory憑據，這將在下面的攻擊敘述中描述。這種攻擊敘述包含了從起初到最后的整個路徑。
識別代理基礎設施
在一次滲透測試中，我們的目標是通過滲透客戶的數字基礎設施獲得初步立足點。由于自動掃描無法產生結果，我們很快進行了手動測試。包括 Outlook Web Access (OWA) 在內的各種服務在使用 GoBuster 工具對子域進行暴力破解時被識別。使用中的詞表由@bitquark 生成，包含 100000 個最常用的子域。
在檢查這些服務時，我們發現我們正在與代理進行通信。有幾種方法可以檢測服務是否在代理之后運行。Web 應用程序的一種常用技術是向應用程序發送以下請求，該請求的第一行包含另一個URI。
要求：
一般的web服務器會生成一個“421 Misdirected Request”響應。下面包括一個示例。
響應：
然而，當我們在owa.customer.com上運行此操作時，服務器返回了以下響應，即 302 Moved Temporarily。那時，我個人認為這種重定向是HTTP代理的典型行為。但是，后來我意識到它應該是帶有實際響應正文的 200 OK 或 203 Non-Authoritative Information，如 RFC7230中所述。
響應：
但是，確實表明正在使用代理的是 Server 標頭，其中 server1 作為值。這是 Microsoft IIS 服務器的非默認值。默認情況下，該值為 Microsoft-IIS/8.5（或其他版本）。這表明，最有可能的是，代理更改了響應。
現在我們有了owa.customer.com被代理的跡象，我們可以繼續檢查它是否容易受到HRS的攻擊。
識別易受攻擊的代理設置
考慮到 James Kettle 的研究，我們著手調查這種設置是否可能容易受到 HRS 的影響。為了確定 owa.customer.com 是否容易受到 HRS 的攻擊，我們發送了以下請求。
此請求的 Content-Length 為 124，即整個正文。它將被發布到代理，代理將使用它來確定正文的長度為 124 字節。然后將該請求轉發到實際的 OWA 服務。
如果此設置易受 HRS 攻擊，OWA 會以不同方式處理請求（使用分塊編碼而不是使用內容長度）。分塊編碼允許客戶端在正文中發送數據塊。在這種情況下，有一大塊數據。這是從十六進制數44開始的，如果轉換成十進制，就是68。這是塊的長度，可以在下一行中看到。在這68個字符之后，請求以一個大小為0的塊終止。這是 OWA 接受的正常請求。
但是，終止后的部分未處理。OWA 服務會將其視為代理（可能來自另一個用戶）發送的下一個請求的一部分。
這也適用于其他方式（如果代理使用分塊編碼而 OWA 使用內容長度）。基礎設施易受 HRS 攻擊的方式有多種。所有這些方式都在 PortSwigger 的博客中進行了描述。實際上，我們使用的真正技巧是在傳輸編碼標頭之前插入了一個空格，Transfer-Encoding: chunked。雖然代理無法解析它并使用 Content-Length 來確定正文長度。但是，OWA 能夠解析它并使用 Transfer-Encoding 標頭來確定正文長度。
當我們執行上面的請求時，我們得到了來自服務器的以下響應。
可以看出，響應狀態為 200 OK，表示我們的請求有效，服務器返回了有效響應。起初，我認為這意味著它沒有解釋我們正文的第二部分，因為它會產生一個400 Bad Request 響應狀態。我認為代理/OWA 設置很可能很容易受到攻擊。然而，經過進一步的研究，事實證明 OWA 接受任何任意 POST 數據。
更確定的驗證方法是在請求正文的第二部分檢查其他用戶是否收到了對我們請求的響應。由于我們正文第二部分中的請求通常返回 301 Moved Permanently，因此現在應該將另一個用戶重定向到 hacker.com 域，因為該用戶將重定向作為對他們請求的響應。為了驗證這一點，我們檢查了hacker.com的訪問日志。它的重要部分已包含在下面。
事實上，事實證明它很脆弱！其中一位用戶被重定向到我們的 hacker.com 域，這表明 HRS 請求已成功執行。
查看訪問日志，我認為發生了一些有趣的事情。在我看來，受害者實際上應該向hacker.com 的根或/owa 端點發出GET 請求，而不是向Microsoft-Server-ActiveSync 端點發出OPTIONS 請求，因為它被重定向了。但是，在查看 RFC7231之后，很明顯接收到 301 Moved Permanently 的客戶端可以為后續請求維護其請求方法和正文，就像 308 Permanent Redirect 一樣，其中客戶端需要維護請求方法和主體。
總而言之，這意味著有可能從用戶那里獲取更多信息，我們將在接下來的章節中介紹這些信息。
從hacker.com 的訪問日志中可以看出，受害者試圖使用Microsoft-Server-ActiveSync 執行同步操作。ActiveSync是一種 HTTP 協議，它使用戶能夠從 Exchange 服務器下載郵件，而不是使用僅使用戶能夠在 Web 客戶端中查看郵件的 OWA。
可以在各種郵件客戶端中配置 ActiveSync，例如 Apple Mail。正如 Apple 連接到 ActiveSync 端點的手冊中所見，用戶必須提供服務器、域、用戶名和密碼。這些詳細信息很可能會通過 HTTP 請求發送到服務器。在配置期間或在每個請求中。
將憑據發送到服務器的時間實際上取決于在Exchange中配置的身份驗證類型。常見的身份驗證類型是“現代身份驗證”，它使用SAML協議，因此在使用用戶名和密碼進行初始身份驗證之后生成身份驗證令牌。身份驗證類型“基本身份驗證”是通過在每個HTTP請求中發送用戶名和密碼(base64編碼)進行身份驗證的一種方法。
如果 Exchange 服務器配置為使用帶有基本身份驗證的 ActiveSync，則用戶將在每個 HTTP 請求中發送用戶名和密碼。由于我們能夠執行 HRS，也許能夠截獲這些憑據！
盜取并使用憑據
目前我們知道，一個成功的HRS攻擊可以將受害者重定向到一個惡意服務器，郵件客戶端維護請求方法，并且很可能還維護標頭和正文，并且我們還知道受害者在每個ActiveSync請求中發送base64編碼的憑據。這意味著我們馬上就要獲得這些證書了。
可以通過多種方式捕獲非法服務器上的請求標頭。為了進行概念驗證，我選擇使用Burp Collaborator，它充當HTTP和各種其他協議的所有捕獲服務器。
我更改了最初的 HRS 請求，將受害者重定向到我的 Burp Collaborator URI 而不是hacker.com。最后的請求包括在下面。
幾分鐘后，正如預期的那樣，Burp Collaborator捕獲了來自受害者的ActiveSync請求。
我們已經成功捕獲了包含受害者編碼憑據的授權標頭。
HRS攻擊如下圖所示。
將受害者的郵箱永久遷移到我們的非法交易服務器上。
未記錄的功能
作為滲透測試人員，我們想更深入地研究這一發現可能產生的影響。出于這個原因，我們從攻擊者的角度尋找進一步的選擇，其中最值得注意的是獲得對受害者憑據的永久訪問權限。事實證明，ActiveSync有一個功能，可以在用戶的郵箱從辦公場所遷移到Office365時自動更新郵件客戶端的配置。此功能的工作原理如下：
· 客戶端嘗試通過 HTTP ActiveSync 協議檢索郵件；
· Exchange 會檢查用戶的郵箱是否存在或者是否遷移到 Office365；
· DC 返回未找到郵箱（這意味著已遷移）；
· Exchange 嘗試獲取域的 TargetOWAURL（郵箱所在的位置）；
· DC 返回 TargetOWAURL（在本例中為outlook.office365.com）；
· Exchange 使用一個HTTP 451重定向到TargetOWAURL來響應客戶端；
· 客戶端將 TargetOWAURL 用于所有未來的請求；
· 對 TargetOWAURL 的 HTTP ActiveSync 請求成功。
總而言之，如果Exchange服務器以451 Unavailable For Legal Reasons 和 X-MS-Location 標頭相結合的方式響應，則受害者Exchange服務器配置會相應更新。下文包括此類響應的示例。
但是，使用我們的 HRS 攻擊無法為受害者生成 451 Unavailable For Legal Causes。只能生成 301 Moved Permanently，因為這是將 URI 添加到 GET 請求的第一行時的響應。但是，我們可以使用 301 Moved Permanently 將受害者重定向到非法服務器，該服務器隨后以 451 Unavailable For Legal Reasons 響應非法交換服務器。如果我們確保非法交換服務器只是合法環境的代理，我們可以永久地在所有受害者的 ActiveSync 請求中間人，而受害者不會注意到任何事情。攻擊過程如下。
將受害者的郵箱遷移到我們的非法交易所
為了證明上述理論有效，我們將“受害者”（tgad.local\bob）連接到我們的演示環境；代理 tgvmex01.proxy 后面的 Exchange 服務器。Bob 使用 ActiveSync 連接。他的 iOS Exchange 配置如下所示。
想要將Bob的郵箱遷移到非法交換服務器的攻擊者需要首先執行HRS攻擊，將Bob的ActiveSync請求重定向到非法服務器。下面提供了一個示例。
無論請求是什么，服務器 rogue-server.com 始終提供相同的響應。此響應包含在下面，并且響應標頭中的非法交換服務器具有 451 Unavailable For Legal Reasons 狀態。
當 Bob 成為 HRS 攻擊的受害者時，他將收到非法服務器的 451 Unavailable For Legal Reasons 響應。Bob 的電子郵件客戶端會將服務器地址更改為 rogue-exchange.remote，因為響應表明郵箱遷移到了這個Exchange 服務器。
最初的幾次嘗試都沒有成功。但是在連續嘗試了幾次之后，HRS攻擊最終觸發了Bob的同步請求，導致Bob的郵件客戶端將配置更改為非法交換。這可以在下面的Bob的Exchange設置中看到。
由于惡意交換器將所有請求代理給合法交換器，Bob不會注意到惡意配置更改(除非他查看自己的exchange設置)。作為一個攻擊者，我們現在能夠攔截他的所有ActiveSync請求，即使在Bob更改了他的憑據之后。
緩解措施
存在多種針對 HRS 漏洞的緩解措施。在理想情況下，代理服務器和后端服務器（在本例中為 Exchange）都完全按照 RFC7231中的說明解釋 HTTP 請求。這將防止 HRS 漏洞，因為兩個服務器都以相同的方式解釋 HTTP 請求的邊界。
然而，我們并不是生活在一個理想的世界里。更好的緩解措施是禁用代理和后端之間的 http-reuse（一種性能優化），以便每個請求都通過單獨的網絡連接發送。此外，可以通過強制從代理到后端的 HTTP/2 連接來緩解 HRS，因為此版本的 HTTP 協議中不會出現 HRS 漏洞。
最后，我們強烈建議不要將基本身份驗證用作 Exchange 的身份驗證方法。請改用現代身份驗證。使用現代身份驗證，攻擊者只能攔截oAuth令牌。
如果你認為自己是Exchange遭受HRS攻擊的受害者，請主動重置Exchange客戶端的配置和密碼。
