標題：從F5 BIG-IP RCE漏洞（CVE-2023-46747）來看請求走私的利用價值

0x01 前言F5 BIG-IP廣域流量管理器是一種網絡流量管理設備，用於提升鏈路性能與可用性。 F5在金融行業具有特別廣泛的使用量，做過各大銀行攻防演練的小伙伴對這個系統應該不會陌生。

最近爆出的CVE-2023-46747漏洞能達到遠程RCE的效果，屬於嚴重級別的安全漏洞。有意思的是這個漏洞和“AJP請求走私”有關。本文將對請求走私漏洞和CVE-2023-46747做一個詳細介紹和分析。

0x02 AJP請求走私介紹較早出現的AJP請求走私漏洞是CVE-2022-26377，關於該漏洞的詳細信息已經有作者進行過分析，感興趣的讀者可以查看原文https://www.ctfiot.com/44809.html，這裡我們關注的是AJP請求走私漏洞的危害。

AJP請求走私漏洞影響Apache Httpd 2.4.54，注意這裡直接受影響的並不是tomcat，所以並不是所有的java網站都受請求走私漏洞的影響，而是只有啟用了httpd服務的網站才受此漏洞影響，類似於現在前後端分離中nginx服務的作用。在F5 BIG-IP中啟動的WEB服務的架構如圖2.1所示，並且在F5-BIG-IP中的httpd版本2.2.15，受CVE-2022-26377漏洞影響。

圖2.1 F5 BIG-IP中的WEB服務架構

圖2.2 F5 BIG-IP中的httpd版本

AJP請求走私漏洞並不是一個高危漏洞，在各個CVSS評分在6.5-7.5之間，所以一直沒有受到我的關注，只是覺得這是一個僅供研究沒有實際意義的理論漏洞。在這次F5 BIG-IP的RCE漏洞爆出之後，我才重新對這個漏洞進行研究。關於此漏洞的詳細理論可以參考上面的文章，這裡主要總結下面的幾個關鍵點：

1） 瀏覽器並不能直接發送AJP協議的數據包，需要依賴於Apache的proxy_ajp 模塊進行反向代理，暴露成HTTP 協議給客戶端訪問。

2） AJP協議對於POST類型的HTTP請求會分成header 和body 兩個數據包發送，由於處理body數據時，其中前面四位固定格式與Forward Request 數據包完全一樣，導致本來應該是一個數據包body部分的數據，可能在進行AJP轉發時被識別為另一個數據包。這也是AJP請求走私的本質原理和危害，如圖2.3所示。

3） AJP請求走私時需要使用Transfer-Encoding: a, chunked 進行分塊傳輸。

圖2.3 AJP請求走私流程

從圖2.3可以看出，整個AJP請求走私的流程是可以把一個HTTP請求經過AJP代理轉化之後轉化為兩個AJP請求，這也是請求走私名字的來源。

0x03 CVE-2023-46747漏洞分析經過0x02的分析已經對AJP請求走私有了初步的了解，但是實際上還是很難看出這樣的漏洞能導致RCE效果。

從官方對這個漏洞的描述中可以看出，此漏洞僅影響開放了TNUI接口的系統（F5 BIG-IP默認啟用），這是因為在/config/httpd/conf.d/proxy_ajp.conf文件中定義了AJP代理的配置，其中只會對tmui相關接口進行代理，如圖3.1所示。

圖3.1 TMUI接口中的AJP代理配置

如圖2.1所示，httpd服務監聽的IP是0.0.0.0，所以是可以被外網用戶直接訪問到的，httpd提供反向代理的功能，把請求轉發到tomcat java監聽的80端口。最初看到這個漏洞的時候，我一直在java代碼中尋找鑑權的邏輯，以圖找到通過AJP請求走私繞過鑑權的方式，但是找了很久都沒有找到，甚至我在F5的JAVA代碼中沒有找到任何的Filter。後來在翻閱F5的歷史漏洞分析文章中才看到原來F5的鑑權並不在JAVA代碼中，而是在httpd模塊中。

F5實現了自己的pam進行認證，模塊路徑為/usr/lib/httpd/modules/，其中，涉及到login.jsp授權的是mod_f5_auth_cookie.so文件。反彙編之後，大概是這樣的。我們能夠請求/tmui/login.jsp而不需要進行身份驗證。

圖3.2 訪問/tmui/login.jsp不需要授權

如果直接訪問其他jsp文件，在沒有通過身份驗證的情況下，會被重定向到/tmui/login.jsp

圖3.3訪問其它頁面需要授權

這也就說明在CVE-2023-46747漏洞的POC利用腳本中通過訪問/tmui/login.jsp（這個頁面是不需要授權，又可以進行AJP請求轉化的頁面），在body中添加AJP請求走私的內容，就可以達到繞過鑑權的效果。

poc地址：

https://www.ddpoc.com/poc/DVB-2023-5391.html

在使用的時候注意，部分BurpSuite會去掉Transfer-Encoding頭，自動從分塊傳輸轉化為普通傳輸導致檢測失敗，所以在使用的過程中盡量不要使用Burp代理，如果非要抓包可以使用Charles，如圖3.4所示。

圖3.4 使用Burp代碼導致檢測失敗

去掉Burp代理之後，在Charles中可以看到正常的Chunked請求體和請求頭，並且運行成功之後可以執行命令，如圖3.5所示。

圖3.5 通過POC可以正常繞過權限添加用戶並執行命令

關於繞過權限之後F5 BIG-IP執行命令的邏輯在F5歷史漏洞CVE-2022-1388中已經使用過，其實F5 BIG-IP本身就提供了接口/mgmt/tm/util/bash為後台用戶執行系統命令的，有興趣的讀者也可以看https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg了解詳細的創建用戶和後台命令執行的邏輯。

0x4 結論CVE-2023-46747算是請求走私漏洞的典型應用場景，把一個中低危的漏洞放在特定的場景中放大危害造成RCE效果，整個利用過程就像是為AJP請求走私量身定制一樣。

首先，F5 BIG-IP使用httpd來轉發前端用戶請求，並且對特定接口/tmui/*開啟AJP請求轉發功能。

其次，F5 BIG-IP的用戶鑑權邏輯在httpd的so文件中實現，而不是在java代碼中是實現。甚至在後端的java代碼中沒有任何鑑權邏輯，導致只要請求轉發到後端java代碼則可以訪問到。通過AJP請求走私可以把一個隱私的添加用戶的請求隱藏在未授權接口/tmui/login.jsp請求中，導致繞過了F5鑑權的邏輯把添加用戶的請求轉發到後端java代碼。

最後，添加的用戶在後台可以直接命令執行導致RCE效果。

參考：https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg

https://github.com/W01fh4cker/CVE-2023-46747-RCE

https://www.ctfiot.com/44809.html

https://blog.csdn.net/weixin_39541693/article/details/111112257