本環(huán)境是蛇矛實(shí)驗(yàn)室基于"火天網(wǎng)演攻防演訓(xùn)靶場(chǎng)"進(jìn)行搭建，通過(guò)火天網(wǎng)演中的環(huán)境構(gòu)建模塊，可以靈活的對(duì)目標(biāo)網(wǎng)絡(luò)進(jìn)行設(shè)計(jì)和配置，并且可以快速進(jìn)行場(chǎng)景搭建和復(fù)現(xiàn)驗(yàn)證工作。火天網(wǎng)演中，內(nèi)置大量固件設(shè)備，包含大型網(wǎng)絡(luò)設(shè)備及物聯(lián)網(wǎng)設(shè)備，可以靈活選取進(jìn)行測(cè)試驗(yàn)證。

背景

2022年11月16日，F(xiàn)5官方公布了F5 BIG-IP和BIG-IQ設(shè)備中的多個(gè)安全漏洞。其中高危漏洞（CVE-2022-41622，CVSS評(píng)分8.8）是iControl SOAP跨站點(diǎn)請(qǐng)求偽造，可允許未經(jīng)身份驗(yàn)證的遠(yuǎn)程代碼執(zhí)行攻擊。高危漏洞（CVE-2022-41800，CVSS評(píng)分8.7）為iControl REST遠(yuǎn)程代碼執(zhí)行漏洞，允許經(jīng)過(guò)身份驗(yàn)證的管理員用戶通過(guò)RPM注入執(zhí)行任意代碼。

受CVE-2022-41622影響的版本為：

BIG-IP:17.0.0
BIG-IP:16.1.0-16.1.3
BIG-IP:15.1.0-15.1.8
BIG-IP:14.1.0-14.1.5
BIG-IP:13.1.0-13.1.5
BIG-IQ:8.0.0-8.2.0
BIG-IQ:7.1.0

受CVE-2022-41800影響的版本為：

BIG-IP:17.0.0
BIG-IP:16.1.0-16.1.3
BIG-IP:15.1.0-15.1.8
BIG-IP:14.1.0-14.1.5
BIG-IP:13.1.0-13.1.5

BIG-IP 設(shè)備默認(rèn)有倆個(gè)用戶(終端用戶和web用戶)，在配置設(shè)備信息時(shí)由于系統(tǒng)對(duì)web端用戶的密碼沒(méi)有什么嚴(yán)格要求(如必須數(shù)字、字母組合、特殊符號(hào)等等)，可能會(huì)導(dǎo)致攻擊者可以爆破出web端用戶密碼，加上今年5月剛爆出的CVE-2022-1388未授權(quán)繞過(guò)漏洞幾乎為同型號(hào)設(shè)備，這就使得倆個(gè)web用戶導(dǎo)致的pre-auth漏洞很容易被利用。

環(huán)境搭建

本小節(jié)使用的漏洞環(huán)境固件為BIG-IP，漏洞版本號(hào)為16.1.0。在靶場(chǎng)中調(diào)用BIG-IP后，BIG-IP會(huì)自動(dòng)分配出mgmt口的IP地址。

在瀏覽器端使用(admin/admin)登錄后，如下圖所示：

漏洞分析

BIG-IP的管理模式有多種，包括web頁(yè)面，tmsh命令行，rest api，以及soap api。soap api數(shù)據(jù)交換格式為soap/xml。rest api數(shù)據(jù)交換格式使用http/json。soap api為比較舊的技術(shù)，在版本11.6中已經(jīng)放棄維護(hù)，目前支持正常使用，rest api目前官方一直在推薦用戶使用和開(kāi)發(fā)。cve-2022-41622為csrf漏洞，漏洞本身危害不大，但是由于在漏洞利用過(guò)程中可以使用soap api接口進(jìn)行操作從而rce。cve-2022-41800為iControl rest容易受到rpm注入攻擊導(dǎo)致rce。

明白了漏洞利用的方法，下面我們開(kāi)始分析。進(jìn)入BIG-IP終端，BIG-IP默認(rèn)開(kāi)啟ssh服務(wù)，我們可以使用"scp -r root@ip:/* ./"命令將BIG-IP的所有文件拷貝到本地進(jìn)行分析。BIG-IP中程序運(yùn)行的httpd服務(wù)為apache

CVE-2022-41800

我們?cè)?etc"目錄簡(jiǎn)單查看一下，在"init.d"目錄下發(fā)現(xiàn)了httpd啟動(dòng)服務(wù)的httpd腳本，腳本注明為apache server并且配置文件的位置為"/etc/httpd/conf/httpd.conf"。

查看一下配置文件，我們發(fā)現(xiàn)httpd接受請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)到不同端口的服務(wù)上完成對(duì)應(yīng)的處理。下圖中AuthPAM開(kāi)啟，說(shuō)明調(diào)用了httpd的某個(gè)".so" 文件進(jìn)行預(yù)先的認(rèn)證，并且將所有向 /mgmt 發(fā)送的請(qǐng)求都轉(zhuǎn)發(fā)到了 "http://localhost:8100/mgmt/"。

在16.1.0的官方文檔中，簡(jiǎn)單翻閱我們得知所有REST API的uri中都是含有 "mgmt" 的。

查看一下8100端口的服務(wù)，發(fā)現(xiàn)有java服務(wù)在監(jiān)聽(tīng)

查看一下pid信息，發(fā)現(xiàn)java的"-classpath"參數(shù)后為"usr/share/java/rest"和"usr/share/java/rest/libs"目錄下的所有jar包，且"--port"參數(shù)為8100。

如果要?jiǎng)討B(tài)調(diào)試java程序，我們可以修改"etc/bigstart/scripts/restjavad"，在jvm_options后附加"-agentlib:jdwp=transport=dt_socket,address=1043,server=y,suspend=n"選項(xiàng)，并且使用Idea配置好ip、port后進(jìn)行遠(yuǎn)程調(diào)試。

注意：防火墻默認(rèn)策略為禁止，動(dòng)態(tài)調(diào)試需要放行調(diào)試端口

RestServerServlet 是整個(gè) iControle REST 的入口，在其"service"方法中"RestServerServlet" 異步執(zhí)行，注冊(cè)了一個(gè) "ReadListener"。而且會(huì)在處理請(qǐng)求時(shí)，為每一個(gè)請(qǐng)求創(chuàng)建了一個(gè) "RestOperation"，并且后續(xù)處理將以回調(diào)的方式執(zhí)行。

這里會(huì)檢測(cè)請(qǐng)求中是否包含相關(guān)認(rèn)證，并將其設(shè)置到 "RestOperation" 中。

調(diào)用setIdentityFromBasicAuth方法后，并且basic認(rèn)證的value不為空便會(huì)進(jìn)入setIdentityData，在比較userName和userReference都不為空時(shí)，最后在completeEvaluatePermission中比較完成后完成身份認(rèn)證過(guò)程。

隨后"trySendInProcess" 中會(huì)根據(jù)請(qǐng)求端口來(lái)尋找相關(guān)的 "RestWorker" 。在 findWorker() 方法中，將以請(qǐng)求路徑為查詢條件，匹配 RestServer 的 pathToWarkerMap 。之后便會(huì)執(zhí)行 worker.onRequest() 方法，將worker添加到 RestServer.readyWorkerSet 中。后面會(huì)以該 Set 為消費(fèi)者隊(duì)列，并執(zhí)行各個(gè)worker。

"RestServer" 中主要工作是維護(hù)隊(duì)列，并執(zhí)行相關(guān)的worker。入口點(diǎn)為其構(gòu)造方法：

processQueueRequests后面運(yùn)行到 "callDerivedRestMethod" 方法，這里便會(huì)調(diào)用對(duì)應(yīng)worker的處理方法并完成對(duì)應(yīng)的鏈調(diào)用。

在官方文檔中，有開(kāi)發(fā)編寫worker的例子，流程如下，在worker中我們發(fā)現(xiàn)WORKER_URI_PATH為uri中/mgmt/"后面的的地址。

根據(jù)"WORKER_URI_PATH"字符串，我們可以簡(jiǎn)單搜索一下系統(tǒng)中的worker，結(jié)果如下圖所示。這里WORKER_URI_PATH為"shared/iapp/rpm-spec-creator"就是生成spec文件的worker

打開(kāi)"iAppRpmSpecFileCreatorWorker.js"worker的文件，發(fā)現(xiàn)加載了"../infrastructure/specFileCreator"模塊，并使用SpecWriter變量調(diào)用，隨后new了一個(gè)specWriter

java中的onPost方法傳進(jìn)來(lái)的restOperation，先getBody獲取內(nèi)容，并且調(diào)用_validate進(jìn)行判斷，隨后使用specWriter.render進(jìn)行格式化，最后調(diào)用getFs().writeFile生成".spec"文件

生成spec文件的名字如下。

_validate對(duì)傳進(jìn)來(lái)的內(nèi)容進(jìn)行判斷，如判斷body是否為空，header是否存在"application/json"，取出specFileData的json內(nèi)容并進(jìn)行判斷，判斷是否有name、summary、version、release、description、srcBasePath字符等等。這里便是漏洞點(diǎn)，漏洞成因便是沒(méi)有對(duì)用戶傳來(lái)的json數(shù)據(jù)進(jìn)行判斷，導(dǎo)致攻擊者可以通過(guò)" "特殊字符進(jìn)行繞過(guò)。

在進(jìn)行格式化時(shí)，使用specFileCreator.js模塊。這里使用了doT.js模板，模板path為"./resources"。doT.js 靈感來(lái)源于搜尋基于 V8 和 Node.js ，強(qiáng)調(diào)性能，最快速最簡(jiǎn)潔的 JavaScript 模板函數(shù)。它在 Node.js 和瀏覽器兩端都彰顯出卓越的性能。下圖中specFileData調(diào)用specTemplate格式化json數(shù)據(jù)

doT.js模板如下，當(dāng)攻擊者傳來(lái)的數(shù)據(jù)"description"后面跟著" "是，spec文件就變得攻擊者可控，可隨意添加惡意數(shù)據(jù)，如調(diào)用"%check 'command'"執(zhí)行系統(tǒng)命令。

當(dāng)我們?cè)俅瓮ㄟ^(guò)rest api進(jìn)行build-package 時(shí)，就會(huì)執(zhí)行spec文件中的惡意命令

CVE-2022-41622

CVE-2022-41622為CSRF漏洞，CSRF漏洞的成因是網(wǎng)站的已認(rèn)證通過(guò)信息在瀏覽器中一段時(shí)間內(nèi)不會(huì)過(guò)期，以后只要是訪問(wèn)這個(gè)網(wǎng)站，會(huì)默認(rèn)用你已經(jīng)通過(guò)的認(rèn)證信息來(lái)進(jìn)行，所以不用再次登錄。如果攻擊者發(fā)送了構(gòu)造好的CSRF腳本或包含CSRF腳本的鏈接，管理者點(diǎn)擊后可能會(huì)執(zhí)行惡意操作（比如是添加賬號(hào)、獲取信息等）。

漏洞程序?yàn)?"/iControl/iControlPortal.cgi"，并且該程序?yàn)閟uid權(quán)限。

csrf漏洞本身的成因比較簡(jiǎn)單，沒(méi)有對(duì)Content-Type以及Referer進(jìn)行驗(yàn)證，以及Token機(jī)制不完善。

下面說(shuō)一下漏洞利用。在前面我們已經(jīng)分析了CVE-2022-41800漏洞，這里的CVE-2022-41622與前面的利用過(guò)程類似，這里只不過(guò)是利用soap api進(jìn)行發(fā)送soap請(qǐng)求。當(dāng)我們?cè)趆ttp中用soap方式發(fā)送xml數(shù)據(jù)去調(diào)用一個(gè)服務(wù)時(shí)，我們只知道通用的http協(xié)議的傳參方式還是不夠的，我們?nèi)匀恍枰滥繕?biāo)服務(wù)的接口文檔。在soap中每個(gè)服務(wù)都有的接口文檔就是一個(gè)用wsdl規(guī)范編寫的wsdl文檔，當(dāng)程序接收到soap請(qǐng)求后根據(jù)wsdl文檔進(jìn)行解析執(zhí)行。

下圖為添加用戶請(qǐng)求的wsdl文件為"Management.UserManagement.wsdl"

這樣我們?cè)趐re-auth的情況下就可以發(fā)送創(chuàng)建用戶的請(qǐng)求來(lái)創(chuàng)建用戶，當(dāng)然我們也可以構(gòu)造其他的請(qǐng)求（如上傳文件）

漏洞復(fù)現(xiàn)

CVE-2022-41800

使用rest api調(diào)用rpm-spec-creator創(chuàng)建spec文件并查看。

使用"nc -lvp 4444"命令監(jiān)聽(tīng)4444端口

使用rest api調(diào)用build-package 構(gòu)建package包裹。

此時(shí)已經(jīng)獲到shell，并且是root權(quán)限。

CVE-2022-41622

將csrf.html目錄使用python啟動(dòng)http服務(wù)

假設(shè)管理員使用賬號(hào)密碼登錄BIG-IP web管理頁(yè)面，此時(shí)點(diǎn)擊了我們啟動(dòng)http服務(wù)的鏈接，鏈接自動(dòng)跳轉(zhuǎn)到"https://192.168.141.152/iControl/iControlportal.cgi"并提交soap請(qǐng)求

用戶已經(jīng)添加成功

使用我們?cè)O(shè)置好的用戶名和密碼進(jìn)行登錄。

總結(jié)

這一小節(jié)，我們簡(jiǎn)單分析了F5設(shè)備的倆個(gè)pre-auth漏洞，了解了rpm注入和csrf漏洞產(chǎn)生原因。并且在此過(guò)程中我們簡(jiǎn)單學(xué)習(xí)F5設(shè)備中 soap接口和rest接口的區(qū)別以及利用。

蛇矛實(shí)驗(yàn)室成立于2020年，致力于安全研究、攻防解決方案、靶場(chǎng)對(duì)標(biāo)場(chǎng)景仿真復(fù)現(xiàn)及技戰(zhàn)法設(shè)計(jì)與輸出等相關(guān)方向。團(tuán)隊(duì)核心成員均由從事安全行業(yè)10余年經(jīng)驗(yàn)的安全專家組成，團(tuán)隊(duì)目前成員涉及紅藍(lán)對(duì)抗、滲透測(cè)試、逆向破解、病毒分析、工控安全以及免殺等相關(guān)領(lǐng)域。

審核編輯：湯梓紅