前記

• 今天是學習小迪安全的第八十一天，今天主要是了解PHP和Java的框架漏洞，包括PHP的ThinkPHP、Laravel，Java的Struts2、SpringBoot
• 因為是復現其CVE漏洞，所以內容比較多，然后也介紹了很多工具，下去可以歸個類，自己也好好復現一下

服務攻防——第八十一天

開發框架安全&SpringBoot&Struts2&Laravel&ThinkPHP&CVE復現

開發框架 - 常見語言開發框架

• PHP：
  • ThinkPHP：國內常用的PHP框架，目前主流的版本為TP8，也有很多企業使用TP6
  • Laravel：國內外都比較常用的框架，安全性比TP高，目前主流版本為Laravel11
  • YII / YII2：國外常用開發框架，目前主流版本為YII2
  • CodeIgniter
  • CakePHP
  • Zend
  • Symfony
• JAVA：
  • Struts / Struts2：早些年最流行的JAVA框架，目前可能只有一些老項目能夠見到
  • Spring：15年左右Spring MVC逐漸成熟，成為主推的開發框架
  • SpringBoot：20年左右SpingBoot以 “零配置” 的優點引爆市場；并且隨著SpringBoot3.0正式到來，其整體滲透率達到了驚人的68%，是目前最常見的JAVA開發框架
  • MyBatis：是國內常用的JAVA數據庫訪問控制組件
  • Hibernate：國外常用的JAVA數據庫訪問控制組件
• Python：
  • Django：是目前國內外主流的Python開發框架，主流版本為5.1 LTS
  • Flask / FlaskAPI：Flask和FlaskAPI也是比較常見的框架
  • Bottle
  • Turbobars
  • Tornado
  • Web2py
• JavaScript：
  • React：UI組件層框架，目前主流版本為18.3，國內外都比較常用
  • Vue.js：比較常用的JS前端框架，主流版本為3.5，國內比較常用
  • Node.js：JS運行時框架，主流版本為22 LTS，JS全棧開發離不開
  • Angular
  • Svelte
  • Bootstrap
  • JQuer：主流版本為3.7.1，老項目仍在使用

PHP - 框架安全-Thinkphp&Laravel

Laravel

漏洞介紹

• Laravel 是一套簡潔、優雅的 PHP Web 開發框架(PHP Web Framework)
• CVE-2021-3129：
  • 漏洞描述：當 APP_DEBUG=true 時，內置調試組件 Ignition 的「解決方案」接口未過濾用戶輸入，可通過 Phar 反序列化實現遠程代碼執行。
  • 影響版本：
    • Laravel ≤ 8.4.2
    • facade/ignition < 2.5.2
  • 利用條件：
    • 開啟Debug模式（APP_DEBUG = true）
    • igniton組件版本低于2.5.2
• CVE-2022-31279：
  • 漏洞描述：Laravel 9.1.8 之前未對「廣播隊列」負載做簽名校驗，攻擊者可投遞惡意序列化對象，觸發 POP 鏈 RCE
  • 影響版本：
    • Laravel < 9.1.8
  • 利用條件：
    • 使用 redis/database 等廣播驅動
    • 隊列 worker 消費攻擊者可控的廣播數據
• CVE-2024-47823：
  • 漏洞描述：Livewire 上傳組件只看 MIME 類型，未校驗真實后綴，導致可上傳 .php 文件。
  • 影響版本：
    • Livewire 2 ≥ 2.12.7 且 < 3.5.2
    • Livewire 3 < 3.5.2
  • 說明：Livewire 是 Laravel 的“全棧動態界面”框架，屬于其第三方組件，并非框架漏洞
• CVE-2025-53833：
  • 漏洞描述：文檔工具 LaRecipe 的 renderBlade() 直接把 Markdown 里的 {{ }}、{!! !!} 交給 Blade 編譯，造成 SSTI → RCE
  • 影響版本：
    • LaRecipe < 2.8.1
  • 說明：LaRecipe 是 Laravel 的專用文檔生成器，同樣也屬于其第三方組件，并非框架本身漏洞
• CVE-2024-55556：
  • 漏洞描述：Laravel 的 decrypt() 會自動反序列化解密數據；一旦 APP_KEY 泄露，攻擊者可構造惡意 payload 觸發 RCE
  • 影響版本：
    • Laravel 10.x（含10.x）之前的所有版本
  • 利用條件（滿足其一即可）：
    • SESSION_DRIVER=cookie 且 KEY 泄露
    • 業務把用戶輸入直接丟進 decrypt()

漏洞復現

CVE-2021-3129

• 首先開啟靶機：
  

• 然后我們就直接使用工具一把梭就好了，項目地址：https://github.com/zhzyker/CVE-2021-3129

• 下載文件夾之后我們使用命令：

python exp.py http://123.58.224.8:20094

• 可以看到第二個，還有其他下面的很多都能夠成功返回whoami的執行結果，說明存在該漏洞
• 其實這個exp.py本身是基于phpggc這個工具的，為什么是上面特定的exp執行成功就是因為這幾個exp滿足當前的Laravel版本：
  

ThinkPHP

漏洞介紹

• ThinkPHP 是一套開源的、基于 PHP 的輕量級 Web 應用開發框架。
• CVE-2018-1002015：
  • 漏洞描述：在解析控制器名時，直接把用戶輸入拼接到類名字符串，且僅做簡單正則過濾，允許插入反斜杠 \\ 穿越命名空間，從而可調用任意公共方法。
  • 影響版本：
    • TP 5.0.x（≤ 5.0.23）
    • TP 5.1.x（< 5.1.31）
  • 利用條件：
    • url_route_must 保持默認（false，未開啟強制路由）
• CVE-2019-9082：
  • 漏洞描述：框架把 PATHINFO 直接當控制器類名，導致可調用任意 public 方法
  • 影響版本：
    • TP 5.0.0~5.0.23
  • 利用條件：
    • url_route_must 未開啟（默認）
• CVE-2018-20062：
  • 漏洞描述：5.1 重寫路由后，對控制器名正則過濾不完整，可插入 \ 穿越
  • 影響版本：
    • TP 5.1.0~5.1.31
  • 利用條件：
    • url_route_must 未開啟（默認）
• CNVD-2021-44350：
  • 漏洞描述：Builder::parseData() 把數組鍵名當字段名拼接，未過濾導致SQL注入
  • 影響版本：
    • TP 5.0.13~5.0.15
    • TP 5.1.0~5.1.5
  • 利用條件：
    • 把 $_POST 直接當數組鍵名寫進 insert()
• CVE-2022-45982：
  • 漏洞描述：默認文件/Redis 緩存對數據 unserialize()，可被寫入惡意對象
  • 影響版本：
    • TP 6.0.0~6.0.13
    • TP 6.1.0~6.1.1
  • 利用條件：
    • 使用默認緩存驅動
• QVD-2022-46174：
  • 漏洞描述：lang=../../../path 可穿越包含任意 PHP 文件
  • 影響版本：
    • TP 5.0/5.1 全分支
    • TP 6.0.1~6.0.13
  • 利用條件：
    • 開啟多語言（lang_switch_on=true）
  • 文件上傳：在開啟register_argc_argv且安裝了pcel/pear的情況下，可以包含/usr/local/lib/php/pearcmd.php并寫入任意文件
• CVE-2024-48112：
  • 漏洞描述：think\exception 模板渲染鏈可被反序列化，導致任意代碼執行
  • 影響版本：
    • TP 6.1.3~8.0.4
  • 利用條件：
    • 開啟異常模板調試（默認關閉）
• 我看了一下，在8月5號的時候TP5又爆出來一個RCE，但是這里就不多寫了，具體可以自查CVE官網：CVE: Common Vulnerabilities and Exposures

漏洞復現

• 同樣，直接工具一把梭即可，這里工具可以直接使用ONE-FOX自帶的thinkphp檢測工具，也可以使用藍鯨這個工具
• 下載地址：https://github.com/bewhale/thinkphp_gui_tools/

CVE-2018-1002015

• 啟動靶場，然后訪問目標網站：
  

• 這里從圖標可以看出來網站是Thinkphp搭建，但是沒有具體版本號，但是可以嘗試讓他報錯，看看是否暴漏版本號：
  

• 這里確實可以拿到版本號為TP 5.1.30，符合上面好幾個的漏洞版本，那這里我們就可以一個一個試了

• 假設我們知道這里就是關于CVE-2018-1002015的漏洞利用，所以我們就也是直接使用Payload：

/index.php?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=whoami

• 成功執行任意命令，接下來就可以嘗試上傳WebShell了
• 當然，這里使用工具一把梭也是能夠RCE的：
  

QVD-2022-46174

• 啟動靶機，訪問地址/public/index.php：
  

• 直接給出了TP版本號為6.0.12，那可以利用的也就那幾個漏洞，一個一個試就完了

• 當然這里我們查看網絡數據包發現Set-Cookie的值有個think_lang=zh-cn，可以猜測存在多語言的漏洞：
  

• 直接抓包，轉到Repeater模塊，寫入如下Payload看看是否有回顯：

/public/index.php?+config-create+/&lang=../../../../../../../../../../../usr/local/lib/php/pearcmd&/<?=phpinfo()?>+/var/www/html/shell.php

• 然后我們訪問shell.php看看是否創建了phpinfo()的頁面：
  

• 說明存在RCE漏洞，同樣我們也可以嘗試使用工具一把梭：
  

• 也可以掃出來可能存在這個漏洞，手動驗證一下即可

J2EE - 框架漏洞-Struts2&SpringBoot

Struts2

漏洞介紹

• Apache Struts2框架是一個使用JavaEE網絡應用程序的Web框架，可能存在OGNL表達式注入擴展，從而造成RCE，風險極大
• CVE-2020-17530（S2-061）：
  • 漏洞描述：標簽屬性二次 OGNL 解析
  • 影響版本：
    • Struts2 2.0.0 ~ 2.5.25
  • 利用條件：
    • 目標應用使用受影響標簽
    • 標簽的“id”或其他可二次解析屬性被賦值為用戶可控數據
    • 服務器未升級到 2.5.30/6.0.0 以上
• CVE-2021-31805（S2-062）：
  • 漏洞描述：這是對 2020 年 CVE-2020-17530（S2-061）補丁的“二次繞過”。當 JSP 標簽屬性使用 %{...} 強制 OGNL 評估且屬性值來自用戶輸入時，攻擊者仍可注入 OGNL 表達式，導致任意代碼執行。
  • 影響版本：
    • Struts 2.0.0 ~ 2.5.29（含）
  • 利用條件：
    • 同CVE-2020-17530
• CVE-2023-50164（S2-066）：
  • 漏洞描述：文件上傳攔截器對“上傳路徑+文件名”的校驗存在缺陷，允許攻擊者通過構造 ../ 序列將任意文件寫入 Web 容器可執行目錄，進而導致遠程代碼執行。
  • 影響版本：
    • Struts2 2.5.0 ~ 2.5.32
    • Struts2 6.0.0 ~ 6.3.0
  • 利用條件：
    • 應用使用了 <s:file> 上傳功能并且保存路徑由后端自動拼接
    • 未對上傳后綴或路徑做額外白名單限制
    • 具備文件上傳權限（多數場景無需管理員身份）
• 其他漏洞，看到比較全的文章是這篇：Struts2框架漏洞總結與復現 - FreeBuf網絡安全行業門戶

漏洞復現

• 同樣，直接工具一把梭即可，工具可以使用ONE-FOX自帶的struts2全版本檢測工具
• 該工具目前仍在更新，下載地址：https://github.com/abc123info/Struts2VulsScanTools/releases

CVE-2016-0785（S2-029）

• 這個是老漏洞了，像這種就純是用工具一把梭了，基本實戰已經碰不到了

• 啟動靶場，是這個樣子的：
  

• 怎么判斷是否為Struts2框架呢，首先是看看指紋識別工具是否能夠識別出，然后可以看看有沒有.action這種后綴的頁面，最后實在沒有就看這個網站它是不是哪種看起來就特別老的網站，并且是Java語言開發的

• 這里并沒有，也不用管，反正就盲掃就盲掃就完了：
  

• 也是能夠成功掃到漏洞并利用成功

CVE-2020-17530（S2-061）

• 啟動靶機，也是不管，就掃：
  

• 這里又是掃到了，然后他提示并沒有利用功能，但是我們選擇執行命令，仍然是可以執行成功的：
  

• 當然，如果確定漏洞，但這里也利用不了的話，我們就使用具體的利用工具：yaunsky/s2-061-rce: s2-061批量掃描兼命令執行exp
  

• 成功利用

CVE-2021-31805（S2-062）

• 啟動靶機，然后訪問網站，還是用工具掃：
  

• 不過很可惜的是這里并沒有掃出來，當然也可以使用其他的工具掃描，比如Tscan、Yakit等等帶PoC的工具慢慢嘗試

• 這里也假設知道了就是這個漏洞，我們就使用網上的exp進行利用即可，下載地址：pyroxenites/s2-062: 遠程代碼執行S2-062 CVE-2021-31805驗證POC

• 這里使用有回顯的那個腳本都是利用失敗的，原因是因為這里傳入的參數為name，但腳本中的默認參數為id

• emmm，雖然改完之后也沒用，可能他是不回顯的，那我們嘗試他的第二個dnslog帶外的腳本：

python exp.py --url http://192.168.0.143:58503/s2_062/index.action --par name

• 可以看到，是存在漏洞的，那么我們就嘗試利用，這里抓包然后嘗試反彈Shell

• 怎么抓到python的包呢，我們就可以利用之前學到的Proxifier聯動BP抓包：
  

• 抓到包之后轉到Repeater模塊：
  

• 這里先在kali上開啟監聽，比如監聽9999端口：
  

• 然后我們將這個name的值轉到Decode模塊，URL解碼之后，將命令改成反彈Shell的命令，然后URL編碼：
  

• 替換參數之后發包，我還是不明白為什么這里老是連不上，真沒辦法理解是環境的問題還是我的問題

SpringBoot

漏洞介紹

• CVE-2021-21234：
  • 漏洞描述：spring-boot-actuator-logview（第三方日志查看器）在 0.2.13 之前版本未對 base 參數做校驗，僅校驗 filename 參數。攻擊者可將 base 設為任意路徑穿越串，拼接后讀取日志根目錄之外的任意文件，造成目錄遍歷/任意文件讀取。
  • 影響版本：
    • spring-boot-actuator-logview < 0.2.13
  • 利用條件：
    • 應用顯式引入上述依賴
    • /log/view 或 /manage/log/view 端點可訪問且未鑒權
    • 運行用戶對目標文件具有讀權限
  • 說明：該漏洞是第三方組件的漏洞，并非SpringBoot本身的框架漏洞，因此如果對方未引用該組件，便無法形成危害
• CVE-2022-22947：
  • 漏洞描述：Spring Cloud Gateway 在啟用并暴露 Gateway Actuator 端點（/actuator/gateway/routes 與 /actuator/gateway/refresh）時，允許遠程攻擊者通過 POST 創建惡意路由。路由中的 filter 字段會被 Gateway 內部 ShortcutConfigurable#getValue() 方法以 SpEL 表達式形式解析，且使用 StandardEvaluationContext，從而可執行任意系統命令，造成 未經身份驗證的 RCE。
  • 影響版本：
    • Spring Cloud Gateway 3.1.x < 3.1.1
    • Spring Cloud Gateway 3.0.x < 3.0.7
    • 其他舊版本分支同樣受此影響
  • 利用條件：
    • 應用引入 spring-cloud-gateway-server 并啟用 Actuator（management.endpoints.web.exposure.include=gateway 或 *）
    • 端點 未做認證保護（默認無鑒權）
    • 攻擊者可發送 HTTP POST 請求到 /actuator/gateway/routes/{id} 與 /actuator/gateway/refresh
    • 網關版本在受影響范圍內。
  • 說明：和上面一樣，這個漏洞本質是 Spring Cloud Gateway 的缺陷，不屬于 Spring Boot 框架本身的漏洞
• CVE-2022-22963：
  • 漏洞描述：Spring Cloud Function 的 RoutingFunction 在收到 functionRouter 請求時，會把 HTTP 頭 spring.cloud.function.routing-expression 的值直接交給 SpEL 解析器。攻擊者可在該頭寫入任意 SpEL，從而遠程執行系統命令。
  • 影響版本：
    • 3.0.0.RELEASE ≤ Spring Cloud Function ≤ 3.2.2（含 3.1.6、3.2.2 等全部維護分支）
  • 利用條件：
    • 應用引入 spring-cloud-function-context 并暴露 functionRouter 端點（默認即存在）
    • 路由功能開啟（spring.cloud.function.routing.enabled=true，默認開啟）
    • 攻擊者可發送 HTTP POST 請求
  • 說明：同樣，這個漏洞本質是 Spring Cloud Function 的 SpEL 解析缺陷，不屬于 Spring Boot 框架本身的漏洞
• CVE-2022-22965：
  • 漏洞描述：Spring Framework 5.3.17/5.2.19 及更早版本在 JDK 9+ 環境下，對 Java Bean 屬性綁定過濾不完整，允許攻擊者通過嵌套屬性鏈訪問 class.module.classLoader 等內部對象。結合 Tomcat 的 AccessLogValve 可在 Web 根目錄寫入任意文件，實現遠程代碼執行。
  • 影響版本：
    • Spring Framework 5.3.0 ~ 5.3.17
    • Spring Framework 5.2.0 ~ 5.2.19
    • 其他舊分支同樣受影響
  • 利用條件：
    • JDK ≥ 9（模塊系統繞過關鍵）
    • 使用 Spring MVC/WebFlux 且存在 POJO 參數綁定
    • 部署方式為 WAR 包運行在 Apache Tomcat（jar 包無法寫入 webapps）
    • 未對 class.*、Class.* 等字段做全局黑名單過濾
  • 說明：本質是 Spring Framework 核心缺陷，并非 Spring Boot 自身代碼漏洞，但是基本上的項目都會將該組件拉進來，所以也算是其框架漏洞了
• CVE-2022-27772：
  • 漏洞描述：Spring Boot 自帶的 Unix 啟動腳本（spring-boot-loader-tools 生成的 init.d 服務）在創建臨時目錄時未校驗符號鏈接，導致本地攻擊者通過目錄劫持實現任意文件寫入/覆蓋，最終可獲取代碼執行權限。
  • 影響版本：
    • SpringBoot 2.2.0 ~ 2.2.10 RELEASE
    • SpringBoot 1.5.x
  • 利用條件：
    • 應用以 systemd / init.d 方式安裝并啟用 Spring Boot 自帶啟動腳本
    • 攻擊者已擁有本地普通用戶 shell
    • 可預測或控制 /tmp/spring-boot-* 臨時目錄路徑（默認權限 755，重啟后清空）
• CVE-2023-34055：
  • 漏洞描述：Spring Boot 對外部配置源（環境變量、JNDI、spring.application.json、spring.config.import）的信任鏈校驗不足，攻擊者可在容器/云平臺注入惡意屬性，導致敏感配置泄露或間接遠程代碼執行。
  • 影響版本：
    • SpringBoot 2.6.x 全系列
    • SpringBoot 2.7.0 ~ 2.7.18
    • SpringBoot 3.0.0 ~ 3.0.11
  • 利用條件：
    • 應用使用 spring-boot-starter-actuator 或 spring-cloud-kubernetes 等動態配置能力
    • 攻擊者可控制 Pod/容器環境變量或 ConfigMap（例如擁有 patch 權限）
    • 應用將 Environment 屬性直接拼接到命令行、JVM 參數或日志輸出

漏洞復現

• 對于大部分的SpringBoot漏洞，我們同樣可以采用現成的工具，比如SpringBoot_Scan和YYBaby
• 下載地址：
  • AabyssZG/SpringBoot-Scan: 針對SpringBoot的開源滲透框架，以及Spring相關高危漏洞利用工具
  • YYBaby Spring Scan —— 強大的 Spring & SpringBoot 漏洞掃描工具_禿兔安全

CVE-2021-21234

• 啟動靶機，先看看是不是SpringBoot框架：
  

• 顯示為Spring框架，都差不多，那我們就直接用工具先掃一遍，看看能不能掃出東西：

python .\SpringBoot-Scan.py -v http://192.168.0.143:55190/

• 那可以看到就掃出來了，直接利用即可，抓包然后逐個嘗試其Payload：
  

CVE-2022-22963

• 這個漏洞的靶機我們使用vulhub，因為vulfocus上好像沒有，啟動起來之后訪問網站：
  

• 打開就是熟悉的報錯頁面，確定為SpringBoot，然后工具啟動：
  

• 成功掃到了存在漏洞CVE-2022-22963，于是我們就在網上找找有沒有直接利用的exp，下載地址：brinhosa/CVE-2022-22963-Spring-cloud-function-SpEL-RCE: Spring-cloud-function-SpEL-RCE 批量檢測腳本，反彈shell_EXP,歡迎師傅們試用

• 先在本地進行監聽：

.\nc.exe -lvvp 9999

• 然后運行這個腳本：
  

• 成功反彈Shell：
  

• 這里我們可以看看exp是怎么寫的：
  

• 其實就很簡單了，就是將反彈Shell的命令通過Runtiome.getRuntime().exec()去執行，然后放到請求頭中發送給目標網站的/functionRouter路徑

• 當然我們也就可以直接嘗試用BP抓包去利用，這里就不再嘗試了

CVE-2022-22965

• 這個漏洞我們也用vulhub，啟動靶機之后訪問網站：
  

• 可以看到指紋識別到為Spring，還是直接工具開掃：
  

• 這里讓我們自己嘗試，那直接訪問提供的地址：
  

• 成功利用，那這里我們還是先搜一下有沒有利用腳本，下載地址：likewhite/CVE-2022-22965: CVE-2022-22965 EXP

• 我們就不利用了，直接看他的exp是怎么寫的：
  

• 首先對請求頭進行加工，這里添加一些數據，然后對請求的data數據，寫入我們的payload，比如寫入參數為cmd，寫入的文件后綴為.jsp，文件名和文件路徑都由用戶指定，最后使用post提交

• 那我們可以嘗試抓包自己利用一下看看能不能成功：
  

• 比如這里寫入文件名為tomcatwar.jsp，用post提交提示405方法不允許，改為get提交提示200成功，但是訪問這個文件仍然顯示不存在

• 這個就不知道是什么原因了，我重新用那個SpringBoot_Scan利用了一遍抓包，換個文件名也不行，不懂

CVE-2022-22947

• 這里我們又換回vulfocus靶場，啟動起來，然后訪問網站：
  

• 同樣Spring框架，同樣工具先掃描一遍：
  

• 這里就直接掃到了，我們還是再了解一下利用過程，這里也不用搜了，我感覺網上的exp好多都利用不了，直接看SpringBoot_Scan的數據包吧
  

• 他的邏輯就是首先創建一個路由，路徑為/actuator/gateway/routes/路由名稱，讓他的值為命令執行的語句，執行id命令

• 再訪問這個路徑，就可以看到命令執行的結果了：
  

• 之后再通過/static/uploadify/uploadFile.jsp?uploadPath=/static/uploadify路徑上傳一句話木馬getshell