文章总结： 文章分析了契约锁pdfverifier接口的漏洞及多次补丁绕过方法。漏洞源于OFD文件解压时的目录穿越问题，允许写入任意文件。作者发现可通过覆盖补丁jar文件实现RCE，并详细构造了恶意类注入内存马。文章还分析了从1.3.2到1.3.8版本的多次补丁绕过技术，包括URL编码、路径处理和压缩文件头部处理等方法。作者建议安全研究人员应多分析历史漏洞，可能发现新的绕过方法。
综合评分： 91
文章分类： 漏洞分析,渗透测试,代码审计,应急响应,WEB安全
契约锁pdfverifier RCE攻防绕过史
原创
killer
漫漫安全路
2025年7月21日 14:00
江西
前言
之前比较懒一直没安装契约锁进行审计最近正好爆出挺多这个产品的漏洞，于是抽空分析一下近期的漏洞为后续挖掘打基础。这篇文章主要写pdfverifier接口的漏洞以及这个地方补丁被多次绕过的分析。
pdfverifier漏洞分析利用
下面分析使用的版本为Linux下的4.3.4版本，契约锁启动后会开启三个端口分别对应下面三个服务
- 电子签约签署平台：9180
- 电子签约管理控制台：9181
- 电子签约开放平台：9182
官方建议只对外开放9180端口pdfverifier接口的漏洞便是在这个端口，对应的jar包为privapp.jar。将这个jar包拿出来分析发现无法解压使用
010Editor打开发现前面一大段为
bash脚本直接将前面的字符删除即可成功解压。解压以后发现BOOT-INF\lib\下只有少数的jar包，简单查看目录结构确定其他依赖应该在/opt/qiyuesuo/libs目录下于是直接将/opt/qiyuesuo/libs全部复制到BOOT-INF\lib\然后idea打开即可。这里有个需要注意的问题当我们没把spring的依赖放入lib时idea的两下shift查看接口是没有用的，必须存在spring的依赖他才会扫描得到接口。根据classes目录结构很快可以注意到com.qiyuesuo.config.PrivappConfigurer定义了过滤器和白名单接口。pdfverifier接口正好在里面直接两下shift定位到接口的实现方法获取扩展名以后传入
com.qiyuesuo.api.PdfVerifierController#doVerify当扩展名为
ofd时进入net.qiyuesuo.common.ofd.verify.GjzwOfdVerifyHandler#verify最后对文件进行了解压操作
这里没有判断目录穿越的情况，所以可以解压文件目录穿越写入任意文件到任意目录。但是这个服务是
springboot不能通过写webshell来RCE，可以想到的几种比较通用的办法如写模版文件、往JDK的某些的地方写文件然后初始化类、写计划任务。写模板文件的话好像没有配置了视图模板解析，往JDK的某些的地方写文件可能不太通用，写计划任务只针对Linux且没有权限因为他这里是用qiyuesuo账号起的服务。如果以前下载过qys的补丁的话就会想到他的补丁是热加载的。所以我们可以通过覆盖
/opt/qiyuesuo/security/private-security-patch.jar文件进行代码执行，虽然知道了可以通过覆盖这个文件来RCE但是我们还需要知道怎么构造这个jar包才会执行到我们的恶意代码。根据补丁安装说明可以知道主要逻辑应该在private-security-loader-1.0.0.jar点开这个jar第一个类就是com.qiyuesuo.security.patch.loader.SecurityLibManager这里很明显就是触发热加载的地方，检测到
hash值发生变化就会进行reload以及registerQVDLogic这里加载jar包
加载class
当全类名前缀为
com.qiyuesuo.security.patch.filter.logic时会实例化这个类此时可以执行到类的静态代码块，所以我们只需要往正常的private-security-patch.jar里加入com.qiyuesuo.security.patch.filter.logic.xxx 然后在静态代码块里执行恶意代码即可。于是我使用jmg生成了一个这样的内存马注入器类名为com.qiyuesuo.security.patch.filter.logic.ofdrce进行漏洞利用发现没有成功，经过调试发现我本地的private-security-loader-1.0.0.jar可能和我上传的private-security-patch.jar版本不对应实例化
com.qiyuesuo.security.patch.filter.logic包里某个类调用com.qiyuesuo.security.patch.common.util.SecurityResourceOperator类里的方法时因为其还没有实例化导致空指针异常退出，解决办法是将恶意类命名为com.qiyuesuo.security.patch.filter.logic.AAAA这样的话安装字母排序最开始实例化的就是我们的恶意类。 生成恶意类将恶意类加入正常的
private-security-patch.jar中(注意有的压缩软件直接拉文件进jar包会导致错误)制作恶意压缩文件
LINUX也可使用/proc/self/cwd/security/目录更加靠谱，windows可尝试/qiyuesuo/security/目录构造数据包上传
等待几秒钟成功实例化我们的恶意类
成功打入内存马
1.3.2补丁绕过
这个漏洞最初由1.3.2版本补丁修复,补丁关键代码如下先获取URL然后判断是否等于
PDFVERIFIER_URL_LIST里的某个值ENABLE默认为true且请求方法为POST则使用PdfverifierPreventWrapper包装request我们这里按照补丁绕过顺序来分析所以直接对比1.3.2和1.3.3补丁即可发现绕过点绕过点位于包装类的
getParts方法，当spring解析上传格式时会调用getParts方法此时会调用到com.qiyuesuo.security.patch.filter.wrapper.PdfverifierPreventWrapper#getParts而这个方法里面获取文件名和spring获取文件名存在差异。spring支持将整个文件名URL编码org.springframework.web.multipart.support.StandardMultipartHttpServletRequest#parseRequest这个地方会对整个
filename进行URL解码而
1.3.2版本补丁使用的org.apache.catalina.core.ApplicationPart#getSubmittedFileName不支持将整个文件名URL解码从而在
filename.toLowerCase().endsWith(REGEX)时判断失败所以可以直接使用URL编码的文件名绕过补丁 直接上传ofd被拦截使用
URL编码绕过补丁其实这个地方也修复了
MIME编码加URL编码双重编码的绕过
1.3.3-1.3.5补丁绕过
我下载了1.3.3之后的所以补丁，1.3.4-1.3.5补丁和pdfverifier相关的改动感觉不是在修复绕过或者说是其他接口的zip slip漏洞修复。所以这里我们直接对比1.3.5和1.3.6补丁增加了一个
removeEndSlash方法用于移除末尾的斜杠，其实这个绕过我感觉比上面的绕过更容易想到。我们先看他是如何获取uri的通过
getRequestURI获取将双斜杆替换为单斜杠
这里使用的等于来判断
虽然用了
getRequestURI获取uri但是不能使用下面这类绕过
- /api/;/pdfverifier
- /api/./pdfverifier
- ///api/pdfverifier
因为他前面有个补丁com.qiyuesuo.security.patch.filter.logic.DangerUrlPreventLogic#doQvdLogic是专门判断这类uri的，这里就需要使用spring的一个特性在路由后面添加斜杠一样可以访问到，所以使用以下POC成功绕过补丁
1.3.6补丁绕过
直接对比1.3.6和1.3.7补丁这里修改了
removeDuplicateSlash方法移除双斜杆改为了移除所有且将/+都替换为/，所以这里的绕过应该是三斜杠绕过，不过按道理三斜杠会被com.qiyuesuo.security.patch.filter.logic.DangerUrlPreventLogic#doQvdLogic检测到，为什么可以绕过呢，因为正好末尾的///先经过一次removeDuplicateSlash变为//再经过一次removeEndSlash变为了/正好可以过com.qiyuesuo.security.patch.filter.logic.DangerUrlPreventLogic#doQvdLogic检测，所以绕过POC如下
1.3.7补丁绕过
直接对比1.3.7和1.3.8补丁这里改动比较大的地方在
hasPathTraversal方法里，但是乍一看看不出什么问题。 这里移除了(entry = zis.getNextEntry()) == null的判断，改为了使用和后面pdfverifier接口解压相同的代码，于是猜测有一种办法可以导致zis.getNextEntry()== null而后面的解压代码依然可以解压。跟入getNextEntry发现会对文件头做判断如果不是zip文件头则返回NULL而后面解压代码没有使用
getNextEntry于是直接在压缩文件头部添加\r\n发现此时zis.getNextEntry()== null而解压代码依然可以解压这个压缩文件，所以这个补丁的bypass即为在压缩文件头部添加\r\n我这里测试绕过成功但是内存马没打上后面看了下又是之前的原因实例化
com.qiyuesuo.security.patch.config.logic.SecurityPropertiesConfigLogic的时候报错了而这个类的顺序是在我们之前内存马顺序之前所以还是建议内存马使用com.qiyuesuo.security.patch.config.logic.AAAAA最为靠谱，替换内存马类名后成功注入内存马。
总结
这个漏洞本身其实比较简单，覆盖补丁热加载来RCE值得学习，后续的多次补丁绕过也挺有意思。所以说挖洞的话还是需要多分析历史漏洞说不定就绕过了挖个新的RCE。
本文仅供安全研究和学习使用，由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：漫漫安全路 killer《契约锁pdfverifier RCE攻防绕过史》