.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
利用面向公眾的服務是在網絡中獲得初步立足點的方法之一，這種情況在野外會經常看到。眾所周知，各種攻擊者都會濫用諸如緩衝區溢出(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客戶端的配置和密碼。