Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863574016

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

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漏洞影響。

8.png

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

9.png

圖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 進行分塊傳輸。

10.png

圖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所示。

11.png

圖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而不需要進行身份驗證。

12.png

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

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

13.png

圖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所示。

14.png

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

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

15.png

圖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