HTTP 標頭走私：通過反向代理攻擊 AWS

現代 Web 應用程序通常依賴于多臺服務器鏈，它們相互轉發HTTP請求。這種轉發創建的攻擊面越來越受到關注，包括最近流行的緩存攻擊和請求走私漏洞。最近的請求走私研究，已經開發出新的方法來隱藏鏈中某些服務器的 HTTP 請求標頭，同時讓其他服務器看到它們——這種技術被稱為“標頭走私”。本文提出了一種新的識別標題走私的技術，并演示了標題走私如何導致緩存攻擊、IP限制繞過和請求走私。

Web 應用程序使用的 HTTP 服務器鏈通常可以建模為由兩個組件組成：

• 直接處理來自用戶請求的“前端”服務器，這些服務器通常會處理緩存和載荷平衡，或充當 Web 應用程序防火墻 (WAF)；
• 前端服務器將請求轉發到的“后端”服務器，這是應用程序的服務器端代碼運行的地方；

上述模型僅是一個簡化，可能有多個前后端服務器，現實中可能有多個前端和后端服務器，而前端和后端服務器本身通常是多個服務器鏈。

后端服務器通常依賴前端服務器在 HTTP 請求標頭中提供的準確信息，例如“X-Forwarded-For”標頭中的客戶端 IP 地址或“Content-Length”標頭中的請求正文長度。為了準確地提供這些信息，前端服務器必須過濾掉客戶端提供的這些標頭的值，這些值是不可信的。

使用標頭走私，可以繞過此過濾并將信息發送到它視為受信任的后端服務器。我將展示這如何導致繞過 AWS API Gateway 中的 IP 限制，以及一個易于利用的緩存攻擊問題。然后，我將討論如何調整用于發現這些漏洞的方法，以基于多個“Content-Length”標頭(CL)安全地檢測請求走私。

本研究開發的用于識別標頭走私漏洞的方法決定了是否可以對標頭應用“突變”，使其能夠在不被前端服務器識別或處理的情況下潛入后端服務器。突變只是對標頭的混淆。以下示例是“Content-Length”標頭的變體版本：

這個方法依賴于這樣一個事實：當發送一個帶有無效的“Content-Length”標頭的請求時，大多數web服務器都會返回一個漏洞：

請求

響應

該方法還依賴于在“Content-Length”標頭的常規形式和變異形式發送有效值和無效值時對響應的比較。我們首先將常規“Content-Length”標頭中的有效和無效值發送到目標：

請求

響應

請求

響應

由于在“Content-Length”標頭中包含垃圾值會導致響應不同，我們可以推斷鏈中至少有一個服務器正在解析這個標頭。

此服務器鏈允許通過在標頭名稱中的空格后附加字符將標頭走私到后端。因此，當我們將請求中的“Content-Length”替換為“Content-Length abcd”并再次發送請求時，我們得到以下結果：

請求

響應

請求

響應

在比較來自常規和變異的“Content-Length”標頭的響應時，有三件重要的事情需要注意。第一個是每個標頭中的無效值與有效值引起的響應不同。這表明鏈中至少有一個服務器將這些標頭中的每一個解析為“Content-Length”標頭。

其次，當每個標頭文件中包含一個有效值時，會返回相同的響應：

請求

響應

請求

響應

這表明變異標頭的存在并沒有阻止任一服務器正常解析請求，這種檢查對于確保突變不會使請求完全無效非常重要。

最后要注意的重要一點是，與常規標頭相比，每個標頭中的無效值會導致變異標頭中的不同響應：

請求

響應

請求

響應

這表明，這些漏洞很可能源自鏈中的不同服務器。換句話說，前端服務器不會像解析常規的“Content-Length” 標頭一樣解析變體后的“Content-Length”標頭，而后端服務器由于存在標頭走私，則可以。

示例

繞過限制

• AWS API 網關 IP 限制

在跨漏洞賞金計劃掃描時，我注意到使用 AWS API Gateway 創建的 API 允許通過在空格后將字符附加到標頭名稱來進行標頭走私，例如，將“X-My-Header: test”變異為“X-My-Header abcd: test”。我還注意到前端服務器正在重寫“X-Forwarded-For”標頭。

API Gateway 允許你使用以下資源策略來限制 API 訪問某些 IP 地址：

此策略將訪問限制為僅接受來自 IP 地址 1.2.3.4和私有范圍 10.0.0.0/8 的請求。來自其他 IP 地址的請求遇到漏洞：

請求

響應

不出所料，簡單地向請求添加“X-Forwarded-For”標頭與 AWS 的安全控制不匹配：

要求

回復

然而，當應用一個允許標頭信息走私到這個標頭信息的突變時，就會授予訪問權限：

請求

響應

這允許繞過 IP 限制，但在實際情況下可能很難實現。來自私有范圍的地址是顯而易見的猜測，但如果這些不被允許，那么就很難猜測一個已被授予訪問權限的IP地址。

請求

響應

事實證明，在請求中添加標頭“x - forward - for abcd: z”可以在API網關中繞過AWS資源策略的IP限制。

AWS Cognito速率限制

在滲透測試期間，我在 AWS Cognito 中發現了一個類似但非常小的漏洞。Cognito 是一個身份驗證提供程序，你可以將其集成到你的應用程序中以幫助處理身份驗證。

在短時間內向“ConfirmForgotPassword”或“ForgotPassword”目標發出五次請求后，我的IP地址被暫時封鎖。但是，在請求中添加“X-Forwarded-For:[0x0b]z”允許再發出 5 個請求。不幸的是，不可能在此標頭中循環不同的值或有效的 IP 地址繼續獲得五次嘗試，這意味著此漏洞的影響很小。然而，它仍然是一個很好的例子，說明如何使用頭部走私來繞過速率限制。

緩存攻擊

在我向AWS報告后，他們立即修復了IP限制繞過。當重新測試時，我注意到我仍然可以使用相同的變體將標頭走私到后端服務器，這讓我想知道是否還有其他有趣的標頭值得嘗試。

API 網關可能在內部使用了一些很有趣的標頭，但我無法識別其中的任何一個。真正引人注目的是”Host”標頭，如果我試圖將這個標頭偷偷傳遞到后端服務器會發生什么。

我使用 API Gateway 設置了兩個 API：一個“受害者”API 和一個“攻擊者”API：

請求

響應

請求

響應

當在常規“Host”標頭旁邊包含一個變異的“Host”標頭時，就會出現有趣的行為：

請求

響應

API 網關正在從變異的“Host”標頭中指定的 API 返回響應。這與大多數 Web 服務器的行為形成對比，后者不會將變異的“Host”標頭視為“Host”標頭，而是從常規“Host”標頭中獲取主機。當這樣的服務器充當 API 網關前的緩存時，這會變得很有趣，因為它會緩存上述請求的結果，就好像它是對“victim.i.long.lat”的請求一樣，即使響應是來自“attacker.i.long.lat”API。

為了演示這一點，我使用“AllViewer”請求策略在 API 網關前面設置了 CloudFront，這會導致所有標頭都被轉發。發送上述請求，然后請求“https://victim.i.long.lat/a”，顯示攻擊者API的響應已經存儲在受害者API的緩存中：

請求

響應

請求

響應

這種緩存攻擊很容易被利用，因為攻擊者可以設置自己的API并返回任意路徑的任意內容。這允許他們完全覆蓋受害者緩存中的任何條目，有效地允許他們完全控制受害者API的內容。

請求走私

在 Black Hat USA 2020 上，Amit Klein 提出了一個基于 2 個“Content-Length”標頭的請求走私（“CL.CL”請求走私）。當使用在同一連接中發送的以下請求將 Squid 用作 Abyss Web 服務器前的反向代理時，可能會觸發該漏洞：

第一個請求以綠色顯示，包含兩個“Content-Length”標頭，一個是變異的，另一個是未變異的。Squid 只會解析未變異的標頭文件，并將第一個請求的主體長度取為 33 字節，以藍色顯示。Squid 然后將第二個請求作為紅色顯示的請求——對“/doesntexist”的“GET”請求。

另一方面，Abyss 將解析變異和未變異的“Content-Length”標頭，并從變異標頭中獲取 0 字節的值。因此，它認為第二個請求是以藍色開頭的請求——對“/a.html”的“GET”請求。

這樣做的總結果是，Abyss 以“/a.html”的內容響應，而 Squid 將此響應緩存到路徑“/doesntexist”，從而導致緩存攻擊。

Klein 的研究特別有趣，因為它表明 CL.CL 請求走私存在于現代系統中，他提出了一種使用超時安全檢測請求走私的簡單方法，該方法基于“內容長度”和“傳輸編碼”標頭（“CL.TE”和“TE.CL”請求走私）。此方法試圖使后端期待比前端轉發更多的內容，從而觸發后端超時。通過首先掃描 CL.TE 請求走私，可以在測試易受攻擊的系統時將影響其他用戶請求的風險降至最低。

對 CL.CL 請求走私執行相同操作的嘗試可能類似于以下情況：

對于前端讀取未變異的“Content-Length”標頭而后端讀取變異版本的易受攻擊的系統，這通常會導致超時。盡管在 Squid 和 Abyss 設置的情況下，不會導致超時，因為 Abyss 不會在回復“POST”請求之前等待正文發送。

當這個請求被發送到一個易受攻擊的系統時，危險就來了，其中前端讀取變異的標頭，后端讀取未變異的版本。前端服務器將轉發“z”正文，后端服務器將其視為下一個請求的開始。然后套接字就被攻擊了，并且由于后端服務器將請求方法視為例如“zGET”，因此另一個用戶的請求失敗的可能性很高。

如果我們不知道前端服務器將解析哪個“Content-Length”標頭，我們既有可能會在易受攻擊的系統中導致超時，也有可能發生套接字攻擊，可能導致另一個用戶的請求失敗。

可以稍微修改用于檢測標頭走私的方法，以創建安全的 CL.CL 請求走私檢測方法。以下示例展示了如何使用這種修改后的方法來檢測 Squid 和 Abyss 中的 Klein 漏洞。

首先，使用正在測試的“Content-Length”標頭對向目標系統發送 "baseline" 請求：

請求

響應

下一步是再發送兩次相同的請求，在每個“Content-Length”標頭中都有一個垃圾值：

請求

響應

請求

響應

比較 3 個響應，我們注意到：

包含垃圾值的請求都觸發了與"baseline"響應不同的響應，這表明至少有 1 個服務器正在解析每個標頭的值。

對包含垃圾值的請求的響應是不同的。這表明漏洞來自不同的服務器，因此鏈中的不同服務器正在解析不同版本的“Content-Length”標頭。

這些情況表明潛在的 CL.CL 請求走私，當調查超出這一點時，重要的是要知道前端服務器正在解析哪個標頭，以最大限度地減少使套接字攻擊和影響其他用戶的機會。

這可以通過發送帶有單個未變異的“Content-Length”標頭的請求并觀察產生的漏洞來實現：

請求

響應

由于前端服務器幾乎肯定會解析此請求中的“Content-Length”標頭，因此產生的漏洞很可能是由前端服務器生成的。通過將此漏洞與該過程中早期生成的漏洞進行比較，我們看到它與在同一請求中發送標頭“Content-Length: z”和“Content-Length abcd: 0”時生成的漏洞相同。因此，前端服務器解析未變異的“Content-Length”標頭，后端服務器解析變異的1。

這些請求僅表明存在潛在的請求走私漏洞，盡管還遠未確定。例如，許多服務器會處理兩種形式的“Content-Length”標頭，但是當它們具有不同的值時就會出現漏洞，從而無法進行請求走私。

緩解措施

防御這些類型的漏洞可能有些復雜，因為它們依賴于 Web 服務器之間實現的差異，而不是 1 個 Web 服務器中的特定漏洞。

前端服務器應避免轉發格式奇怪的標頭，這是 AWS 通過 API 網關采用的方法，包括編寫測試來驗證這種行為。這也阻止了 Cloudflare 在緩存攻擊示例中使用，因為它們不會轉發名稱中帶有空格的任何標頭。