瀏覽器驅動的異步攻擊：HTTP 請求走私（下） - 網安 - 專業的網絡安全產業、社區、知識平臺

示例探究

通過自動檢測 CSD 漏洞，我確定了一系列真正的易受攻擊的網站。在這一節中，我將研究其中四個更有趣的方法，并看看這種方法是如何發揮作用的。

Akamai——堆棧化HEAD

在第一個案例中，我們將利用一個簡單的漏洞影響許多基于 Akamai 構建的網站。作為示例目標，我將使用 www.capitalone.ca。

當 Akamai 發出重定向時，它會忽略請求的 Content-Length 標頭，并將任何消息正文留在 TCP/TLS 套接字上。Capitalone.ca 使用 Akamai 將對 /assets 的請求重定向到 /assets/，因此我們可以通過向該端點發出 POST 請求來觸發 CSD：

為了構建一個漏洞利用，我們將使用 HEAD 方法將一組 HTTP 標頭與 text/html 的 Content-Type 和一個由反映 Location 標頭中的查詢字符串的標頭組成的'body'組合起來：

如果這是服務器端異步攻擊，我們可以在就此打住。然而，要想成功實現客戶端異步，我們需要解決兩個復雜問題。

第一個問題是初始重定向響應。為了執行注入的JavaScript，我們需要受害者的瀏覽器將響應呈現為 HTML，但是 301 重定向會被瀏覽器自動跟蹤，從而阻止攻擊。一個簡單的解決方案是指定模式：'cors'，它會故意觸發 CORS 漏洞。這可以防止瀏覽器跟隨重定向并使我們能夠通過調用 catch() 而不是 then() 來恢復攻擊序列。在 catch block中，我們將使用 location = 'https://www.capitalone.ca/' 觸發瀏覽器導航。我們可能傾向于使用iframe來進行導航，但可以使用跨網站攻擊緩解措施，例如同網站 cookie。

第二個復雜的問題是所謂的“堆棧響應問題”。瀏覽器有一種機制，如果接收到的響應數據多于預期，則刪除連接。這極大地影響了對多個響應進行排隊的技術的可靠性，例如我們在這里使用的HEAD方法。為了解決這個問題，我們需要延遲對 HEAD 請求的 404 響應。幸運的是，在這個目標上，我們可以很容易地實現這一點，方法是添加一個具有隨機值的參數來充當緩存攻擊器，觸發緩存未命中并產生約 500 毫秒的延遲。利用結果如下所示：

已向 Akamai 報告了此漏洞，但我不確定何時修復。

Cisco Web VPN——客戶端緩存攻擊

我們的下一個目標是 Cisco ASA WebVPN，它可以忽略幾乎所有端點上的 Content-Length，因此我們只需向主頁發出 POST 請求即可觸發異步。為了利用它，我們將使用 Host-header 重定向小工具：

最簡單的攻擊是使用此重定向感染套接字，將受害者導航到 /+CSCOE+/logon.html，并希望瀏覽器嘗試使用感染的套接字導入/+CSCOE+/win.js，然后被重定向，最終從我們的網站導入惡意 JS。不幸的是，這是非常不可靠的，因為瀏覽器很可能會使用被感染的套接字進行初始導航。為了避免這個問題，我們將執行客戶端緩存攻擊。

首先，我們使用重定向感染套接字，然后將瀏覽器直接導航到 /+CSCOE+/win.js：

請注意，此頂級導航對于繞過緩存分區至關重要 - 嘗試使用 fetch() 將攻擊漏洞的緩存。

瀏覽器將使用被感染的套接字，接收惡意重定向，并將其保存在本地緩存中以供 https:/redacted/+CSCOE+/win.js 使用。然后，它將遵循重定向并返回我們的網站 https://psres.net/+webvpn+/index.html。我們將瀏覽器重定向到登錄頁面 https://redacted/+CSCOE+/logon.html，當瀏覽器開始出現登錄頁面時，它會嘗試導入 /+CSCOE+/win.js 并發現它已經將其保存在其緩存中。資源加載將遵循緩存的重定向并向 https://psres.net/+webvpn+/index.html 發出第二個請求。此時，我們的服務器可以使用一些惡意 JavaScript 進行響應，這些 JavaScript 將在目標網站的上下文中執行。

為了使這種攻擊起作用，攻擊者的網站需要在同一端點上同時提供重定向和惡意 JS。我采取了一種懶惰的方法，并使用 JS/HTML 多語言解決了這個問題——Chrome 似乎并不介意不正確的 Content-Type：

我在 2021 年 11 月 10 日向思科報告了這個問題，他們最終在 2022 年 3 月 2 日宣布棄用該產品，他們不會修復它，但仍會為其標記為 CVE-2022-20713。

Verisign——碎片化的chunk

在尋找不同步矢量時，最好不要超出探測有效端點的范圍，而是鼓勵服務器使用不同尋常的代碼路徑。在嘗試使用像 /..%2f 這樣的半格式漏洞的 URL 時，我發現我可以通過 POST 到 /%2f 來觸發 verisign.com 上的 CSD。

我最初嘗試使用基于 HEAD 的方法，類似于之前在 Akamai 上使用的方法。不幸的是，這種方法依賴于基于 Content-Length 的響應，并且服務器向所有沒有正文的請求發送分塊響應。此外，它拒絕了包含 Content-Length 的 HEAD 請求。最終，經過測試，我發現服務器會對 HEAD 請求發出基于 CL 的響應，前提是它們使用了 Transfer-Encoding: chunked。

這在服務器端異步中幾乎沒有用，但是由于受害者的瀏覽器在我的控制之下，我可以準確地預測下一個請求的大小，并在單個 chunk中使用它：

此攻擊是使用以下 JavaScript 觸發的：

此漏洞于 2022 年 7 月 21 日被成功修復。

Pulse Secure VPN

Pulse Secure VPN會忽略對靜態文件（如 /robots.txt）的 POST 請求的Content-Length。就像 Cisco Web VPN 一樣，這個目標有一個主機標頭重定向小工具，我將使用它來劫持 JavaScript 導入。但是，這次的重定向是不可緩存的。因此客戶端緩存攻擊是不可用的。

由于我們的目標是資源負載并且沒有攻擊客戶端緩存的預期，因此攻擊時機至關重要。我們需要受害者的瀏覽器成功加載目標網站上的頁面，然后使用攻擊連接加載 JavaScript 子資源。

固有的競爭條件使這種攻擊不可靠，所以如果我們只有一次嘗試，它注定會失敗——我們需要設計一個環境，可以進行多次嘗試。為了實現這一點，我將創建一個單獨的窗口，并在攻擊者頁面上保留一個句柄。

在大多數目標頁面上，如果試圖劫持JS導入失敗，將導致瀏覽器緩存真正的JavaScript文件，在緩存的JS過期之前，該頁面不會受到此類攻擊。我能夠通過定位 /dana-na/meeting/meeting_testjs.cgi來避免這個問題，它從/dana-na/meeting/url_meeting/appletRedirect.js加載JavaScript，這實際上并不存在，所以它返回一個404，并沒有保存在瀏覽器的緩存中。我還用一個冗長的標頭填充了注入的請求，以緩解堆棧響應漏洞。

這導致以下攻擊流程：

1.打開一個新窗口。

2.向目標發出無害的請求以建立新的連接，從而使計時更加一致。

3.將窗口導航到位于 /meeting_testjs.cgi 的目標頁面。

4.120 毫秒后，使用重定向小工具創建三個攻擊連接。

5.5 毫秒后，在渲染 /meeting_testjs.cgi 時，受害者可能會嘗試導入 /appletRedirect.js 并被重定向到提供惡意JS的x.psres.net。

6.如果沒有，請重試攻擊。

最終的攻擊腳本如下：

基于暫停的異步

如上所述，在 HTTP 請求中間暫停并觀察服務器的反應可以揭示通過篡改請求的實際內容無法獲得的有用信息。事實證明，暫停還可以通過觸發漏洞的請求超時實現來創建新的異步漏洞。

這個漏洞類是不可見的，除非你的工具有比目標服務器更高的超時時間。我非常幸運地發現了它，因為我的工具應該有2秒的超時，但由于一個漏洞，它恢復到10秒的超時。我的管道還碰巧包含一個運行Varnish的單獨網站，該網站配置了自定義的 5 秒超時。

Varnish

Varnish 緩存有一個稱為 synth() 的特性，它可以讓你在不將請求轉發到后端的情況下發出響應。下面是一個用來阻止訪問文件夾的規則示例：

當處理匹配synth規則的部分請求時，如果Varnish在15秒內沒有收到數據，它將超時。當這種情況發生時，即使它只從套接字讀取了一半的請求，它也會讓連接保持打開狀態以便重用。這意味著，如果客戶機繼續處理HTTP請求的后半部分，它將被解釋為一個新的請求。

要在易受攻擊的前端觸發基于暫停的異步，首先發送你的標頭，承諾正文，然后等待。最終你會收到一個響應，當你最終發送你的請求正文時，它會被解釋為一個新的請求：

Apache

在這個發現之后，我碰到了 Turbo Intruder 的請求超時，發現同樣的技術也適用于 Apache。與Varnish一樣，它在服務器自己生成響應而不是讓應用程序處理請求的端點上很容易受到攻擊。發生這種情況的一種方法是使用服務器級重定向：

如果你發現一個服務器容易受到基于暫停的異步的影響，你有兩個利用它的選項，具體取決于它是前端還是后端。

服務器端

如果易受攻擊的服務器在后端運行，你可能會觸發服務器端異步。為此，你需要一個將請求流傳輸到后端的前端。特別是，它需要在不緩沖整個請求正文的情況下以HTTP 標頭轉發。

這里有一個小問題。前端不會讀取超時響應并將其傳遞給我們，直到看到我們發送完整的請求。因此，我們需要發送我們的標頭，暫停一段時間，然后在沒有提示的情況下繼續其余的攻擊序列。我不知道有任何安全測試工具支持像這樣部分延遲請求，所以我在 Turbo Intruder 中實現了支持。隊列接口現在有三個新參數：

pause before指定一個Turbo應該暫停的偏移量。

pauseMarker 是一種替代方案，它采用 Turbo 在發出后應暫停的字符串列表。

pauseTime 指定暫停多長時間，以微秒為單位；

那么，哪些前端實際上具有這種請求流？一個著名的前端是 Amazon 的 Application Load Balancer (ALB)，但還有一個額外的障礙。如果 ALB 收到對部分請求的響應，它將拒絕重用連接。

幸運的是，這種機制中有一個固有的競爭條件。你可以通過延遲請求的后半部分來充分利用 ALB 后面的 Varnish，使其在后端超時的同時到達前端。

匹配超時

在利用 ALB 背后的 Apache 時還有一個額外的復雜性，兩臺服務器的默認超時時間都是 60 秒。這就為發送請求的第二部分留下了極短的時間窗口。

我試圖通過發送一些被前端規范化的數據來解決這個問題，以便在不影響后端計時器的情況下重置前端的計時器。不幸的是，塊大小填充、塊擴展或 TCP 重復/無序數據包都沒有達到這個目標。

最后，為了證明這個概念，我使用 Turbo Intruder 發起了一次緩慢但持續的攻擊。66個小時后，這個實驗最終成功了。

MITM 攻擊

由于基于暫停的異步攻擊使用合法的 HTTP 請求，人們很自然地想知道它們是否可以用來觸發客戶端異步。我探索了使瀏覽器在發出請求的中途暫停的選項，但盡管 Streaming Fetch 聽起來很有希望，但它還沒有實現，最終測試失敗。

然而，有一種方法絕對可以延遲瀏覽器請求——主動 MITM 攻擊。TLS 旨在防止數據在傳輸過程中被解密或修改，但它是通過 TCP 捆綁的，沒有什么可以阻止攻擊者延遲整個數據包。這可以稱為盲目 MITM 攻擊，因為它不依賴于解密任何流量。

攻擊流程與常規的客戶端異步攻擊非常相似。用戶訪問攻擊者控制的頁面，該頁面向目標應用程序發出一系列跨域請求。第一個 HTTP 請求被故意填充到非常大，以至于操作系統將其拆分為多個 TCP 數據包，從而使活動的 MITM 能夠延遲最終數據包，從而觸發基于暫停的異步。由于存在填充，攻擊者只需根據數據包的大小就能識別出需要暫停的數據包。