小说阅读网站,完美世界有声小说,盗墓笔记小说

本環境是蛇矛實驗室基于"火天網演攻防演訓靶場"進行搭建，通過火天網演中的環境構建模塊，可以靈活的對目標網絡進行設計和配置，并且可以快速進行場景搭建和復現驗證工作。火天網演中，內置大量固件設備，包含大型網絡設備及物聯網設備，可以靈活選取進行測試驗證。

背景

2022年11月16日，F5官方公布了F5 BIG-IP和BIG-IQ設備中的多個安全漏洞。其中高危漏洞（CVE-2022-41622，CVSS評分8.8）是iControl SOAP跨站點請求偽造，可允許未經身份驗證的遠程代碼執行攻擊。高危漏洞（CVE-2022-41800，CVSS評分8.7）為iControl REST遠程代碼執行漏洞，允許經過身份驗證的管理員用戶通過RPM注入執行任意代碼。

受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 設備默認有倆個用戶(終端用戶和web用戶)，在配置設備信息時由于系統對web端用戶的密碼沒有什么嚴格要求(如必須數字、字母組合、特殊符號等等)，可能會導致攻擊者可以爆破出web端用戶密碼，加上今年5月剛爆出的CVE-2022-1388未授權繞過漏洞幾乎為同型號設備，這就使得倆個web用戶導致的pre-auth漏洞很容易被利用。

環境搭建

本小節使用的漏洞環境固件為BIG-IP，漏洞版本號為16.1.0。在靶場中調用BIG-IP后，BIG-IP會自動分配出mgmt口的IP地址。

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

漏洞分析

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

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

CVE-2022-41800

我們在"etc"目錄簡單查看一下，在"init.d"目錄下發現了httpd啟動服務的httpd腳本，腳本注明為apache server并且配置文件的位置為"/etc/httpd/conf/httpd.conf"。

查看一下配置文件，我們發現httpd接受請求，并將請求轉發到不同端口的服務上完成對應的處理。下圖中AuthPAM開啟，說明調用了httpd的某個".so" 文件進行預先的認證，并且將所有向 /mgmt 發送的請求都轉發到了 "http://localhost:8100/mgmt/"。

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

查看一下8100端口的服務，發現有java服務在監聽

查看一下pid信息，發現java的"-classpath"參數后為"usr/share/java/rest"和"usr/share/java/rest/libs"目錄下的所有jar包，且"--port"參數為8100。

如果要動態調試java程序，我們可以修改"etc/bigstart/scripts/restjavad"，在jvm_options后附加"-agentlib:jdwp=transport=dt_socket,address=1043,server=y,suspend=n"選項，并且使用Idea配置好ip、port后進行遠程調試。

注意：防火墻默認策略為禁止，動態調試需要放行調試端口

RestServerServlet 是整個 iControle REST 的入口，在其"service"方法中"RestServerServlet" 異步執行，注冊了一個 "ReadListener"。而且會在處理請求時，為每一個請求創建了一個 "RestOperation"，并且后續處理將以回調的方式執行。

這里會檢測請求中是否包含相關認證，并將其設置到 "RestOperation" 中。

調用setIdentityFromBasicAuth方法后，并且basic認證的value不為空便會進入setIdentityData，在比較userName和userReference都不為空時，最后在completeEvaluatePermission中比較完成后完成身份認證過程。

隨后"trySendInProcess" 中會根據請求端口來尋找相關的 "RestWorker" 。在 findWorker() 方法中，將以請求路徑為查詢條件，匹配 RestServer 的 pathToWarkerMap 。之后便會執行 worker.onRequest() 方法，將worker添加到 RestServer.readyWorkerSet 中。后面會以該 Set 為消費者隊列，并執行各個worker。

"RestServer" 中主要工作是維護隊列，并執行相關的worker。入口點為其構造方法：

processQueueRequests后面運行到 "callDerivedRestMethod" 方法，這里便會調用對應worker的處理方法并完成對應的鏈調用。

在官方文檔中，有開發編寫worker的例子，流程如下，在worker中我們發現WORKER_URI_PATH為uri中/mgmt/"后面的的地址。

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

打開"iAppRpmSpecFileCreatorWorker.js"worker的文件，發現加載了"../infrastructure/specFileCreator"模塊，并使用SpecWriter變量調用，隨后new了一個specWriter

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

生成spec文件的名字如下。

_validate對傳進來的內容進行判斷，如判斷body是否為空，header是否存在"application/json"，取出specFileData的json內容并進行判斷，判斷是否有name、summary、version、release、description、srcBasePath字符等等。這里便是漏洞點，漏洞成因便是沒有對用戶傳來的json數據進行判斷，導致攻擊者可以通過" "特殊字符進行繞過。

在進行格式化時，使用specFileCreator.js模塊。這里使用了doT.js模板，模板path為"./resources"。doT.js 靈感來源于搜尋基于 V8 和 Node.js ，強調性能，最快速最簡潔的 JavaScript 模板函數。它在 Node.js 和瀏覽器兩端都彰顯出卓越的性能。下圖中specFileData調用specTemplate格式化json數據

doT.js模板如下，當攻擊者傳來的數據"description"后面跟著" "是，spec文件就變得攻擊者可控，可隨意添加惡意數據，如調用"%check 'command'"執行系統命令。

當我們再次通過rest api進行build-package 時，就會執行spec文件中的惡意命令

CVE-2022-41622

CVE-2022-41622為CSRF漏洞，CSRF漏洞的成因是網站的已認證通過信息在瀏覽器中一段時間內不會過期，以后只要是訪問這個網站，會默認用你已經通過的認證信息來進行，所以不用再次登錄。如果攻擊者發送了構造好的CSRF腳本或包含CSRF腳本的鏈接，管理者點擊后可能會執行惡意操作（比如是添加賬號、獲取信息等）。

漏洞程序為 "/iControl/iControlPortal.cgi"，并且該程序為suid權限。

csrf漏洞本身的成因比較簡單，沒有對Content-Type以及Referer進行驗證，以及Token機制不完善。

下面說一下漏洞利用。在前面我們已經分析了CVE-2022-41800漏洞，這里的CVE-2022-41622與前面的利用過程類似，這里只不過是利用soap api進行發送soap請求。當我們在http中用soap方式發送xml數據去調用一個服務時，我們只知道通用的http協議的傳參方式還是不夠的，我們仍然需要知道目標服務的接口文檔。在soap中每個服務都有的接口文檔就是一個用wsdl規范編寫的wsdl文檔，當程序接收到soap請求后根據wsdl文檔進行解析執行。