Tabby 2.0 自动化代码静态审计：CVE-2024-53675&53676 HPE IRS XXE&RCE 漏洞

新年伊始 Tabby v2.0 正式发布了，过节正好有时间体验下实际效果。ZDI 去年底公开了 HPE Insight Remote Support 存在漏洞 CVE-2024-53675 和 CVE-2024-53676 。从描述来看，主要是由于对 XML 外部实体引用的限制不当导致出现了 XXE 漏洞，以及存在路径穿越漏洞可导致任意文件写，漏洞都比较简单，正好适合用来体验新版本的 Tabby 。

下载 v7.12.0 版本进行安装。启动后注册 HPRSMAIN 和 HPRSRECEIVERS 服务：

"C:Program FilesHPRSBINhprsmain.exe" //RS//HPRSMAIN"C:Program FilesHPRSBINhprsreceivers.exe" //RS//HPRSRECEIVERS

HPRSMAIN 服务会启动 HPRS_EXECUTION 、 JETTY 、 KCT 、 HPRS_INTEGRATION 等 Java 进程，对应服务端口为：

KCT -> 7901Jetty -> 7904/7906...

HPRSRECEIVERS 服务启动了 HPRS_LISTENER 这个 Java 进程，绑定的服务端口包括 7903/7905 。此外，其他启动的端口还有 8110/8120/7909/49734 ，为了加快分析速度，进行简单的服务指纹识别：

PORT      STATE  SERVICE     VERSION7901/tcp  open   java-object Java Object Serialization7903/tcp  open   http        JBoss Enterprise Application Platform7904/tcp  open   http7905/tcp  open   ssl/http    JBoss Enterprise Application Platform7906/tcp  open   ssl/httpPORT     STATE SERVICE  VERSION7909/tcp open  java-rmi Java RMI| rmi-dumpregistry:|   hprsMain|      implements java.rmi.Remote, com.hp.uca.hprsmain.IHPRSMainRemote,|     extends|       java.lang.reflect.Proxy|       fields|           Ljava/lang/reflect/InvocationHandler; h|             java.rmi.server.RemoteObjectInvocationHandler|             extends|_              java.rmi.server.RemoteObject8110/tcp  closed unknown8120/tcp  closed unknown49734/tcp open   java-rmi    Java RMI

存在 http 服务（比如 7905/7906 端口 ），以及 RMI 服务（比如 7909 端口等 ）。简单分析 RMI 服务接口，没有找到明显可利用的点。接下来将注意力主要放在 Jetty Web 服务上。

查看配置文件可知，定义了一些 Servlet 、 Filter 、Listener 对象，并且集成了 com.sun.jersey.spi.container.servlet.ServletContainer 的 Jersey REST framework 框架：

此外，还定义了几个 SOAP 接口：

提取引入的 Jar 和 class 文件进行分析（为了减少第三方库的干扰，可以过滤掉一些文件，比如只提取 com.hp.* 包下的类 ）。待分析的 jar 文件列表如下（ 将 class 文件打包成了 jar 包）：

利用 tabby.jar 生成代码属性图，并通过 tabby-vul-finder.jar 将结果导入 Neo4j 数据库。完成这些初始化工作之后，下面就开始通过 Cyber 查询语法进行静态审计。

在分析之前，首先收集潜在的 Web 访问接口集合。从前面分析来看，存在的潜在 Source 点如下：

• HttpServlet 类的 doGet 、 doPost 函数；

• Filter 类的 doFilter 函数；

• ServletContainer 类的 service 函数；

• 存在 @WebService 和 @WebMethod 注解的类和函数；

• ...

寻找常见 XXE 漏洞的 Sink 触发点，还好数量不多：

接着寻找 Source 到 Sink 之间潜在的 Chain 路径。通过反复尝试，没有找到从 Servlet 、 Filter 等出发的可用 Chain 。当设置路径长度为 6 时，通过 SOAP 接口找到了 2 个潜在的 Chain ：

这 2 个利用链的 Source 点均为 registerDevice 接口函数，对应 Registration 这个 SOAP 接口：

2 个 Sink 触发点分别为 javax.xml.parsers.DocumentBuilder#parse 和 javax.xml.validation.Validator#validate ，Sink 点没有进行 XXE 限制，如果输入参数可控，那么就可以触发 XXE 漏洞：

完整调用链如下：

# chain 1- XMLValidator.validateAgainstXSD (com.hp.uca.xmlutil)- RegisterDeviceHelper.validateDeviceIDsXML (com.hp.it.sa.helpers)- RegisterDeviceHelper.registerDevice_common (com.hp.it.sa.helpers)- RegisterDeviceHelper.registerDevice (com.hp.it.sa.helpers)- RegistrationImpl.registerDevice (com.hp.it.sa.reg)# chain 2- RegisterDeviceHelper.processDevicePropertyNVPairs (com.hp.it.sa.helpers)- RegisterDeviceHelper.registerDevice_common (com.hp.it.sa.helpers)- RegisterDeviceHelper.registerDevice (com.hp.it.sa.helpers)- RegistrationImpl.registerDevice (com.hp.it.sa.reg)

接下来验证传递参数是否可控。可以利用 SoapUI 辅助生成请求数据包：

直接访问会提示缺少了 MessageID 头：

加入 messageID 头标签后即可触发 XXE 。此外，通过人工审计发现从另外 2 个 SOAP 接口也可以到达 XXE 的触发点，只不过需要存在一个合法的 device ，调用栈如下：

# chain 3- XMLValidator.validateAgainstXSD (com.hp.uca.xmlutil)- DirectConnectUtil.validateXMLagainstXsd (com.hp.it.sa.helpers)- DataPackageReceiverWebSvcHelper.processRequest (com.hp.it.sa.helpers)- DataPackageReceiverWebSvcHelper.processRequestForAttachment(com.hp.it.sa.helpers)- DataPackageReceiverServiceImpl.dataPackageReceiver(com.hp.it.sa.dpra)# chain 4- XMLValidator.validateAgainstXSD (com.hp.uca.xmlutil)- DirectConnectUtil.validateXMLagainstXsd (com.hp.it.sa.helpers)- DataPackageReceiverWebSvcHelper.processRequest (com.hp.it.sa.helpers)- DataPackageReceiverWebSvcHelper.processRequest (com.hp.it.sa.helpers)- DataPackageXmlReceiverServiceImpl.dataPackageXmlReceiver (com.hp.it.sa.dpr)

从公开通报信息来看，这是一个路径穿越漏洞，触发点位于 DataPackageReceiverSOAPHandler 类的 processAtatchmentDataStream 函数，其中写文件操作的文件名称和内容均来自于输入参数 attachment ：

搜索调用点找到 DataPackageReceiverSOAPHandler#handleMessage 函数，并且 attachment 对象均来自于输入参数 messagecontext ：

DataPackageReceiverSOAPHandler 继承于 SOAPHandler 接口，这是一个 SOAP message 的拦截器，可以拦截输入和输出的 message 对象，分析发现在 handlers-dataPackageReceiver.xml 配置文件中定义了 handler 链：

而 DataPackageXmlReceiverServiceImpl 接口绑定了该 handler 配置：

访问 DataPackageXmlReceiverServiceImpl 对应的 soap 请求，将触发 DataPackageReceiverSOAPHandler#handleMessage ，整个过程中没有对参数进行任何过滤检查，因此存在非常明显的路径穿越漏洞，可导致任意文件写入。完整调用栈如下：

DataHandler.writeTo (javax.activation)AttachmentsHelper.processAtatchmentDataStream (com.hp.it.sa.helpers)AttachmentsHelper.processAtatchment (com.hp.it.sa.helpers)AttachmentsHelper.processAttachments(com.hp.it.sa.helpers)DataPackageReceiverWebSvcHelper.processRequestForAttachment (com.hp.it.sa.helpers)DataPackageReceiverServiceImpl.dataPackageReceiver (com.hp.it.sa.dpra)

但是 Tabby 没有找到这个 Chain 链，有兴趣的师傅可以找找原因：

说一下使用体验吧。从测试情况来看，Tabby v2.0 在功能上有不少新的拓展，比如增加了一些常见漏洞类型的检测，对一些简单的漏洞通过配置合理的规则，可以自动化完成挖掘过程。虽然还有一些需要完善的地方，但是作为一款辅助分析工具，整体表现还是相当不错的。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。

原文始发于微信公众号（自在安全）：Tabby 2.0 自动化代码静态审计：CVE-2024-53675&53676 HPE IRS XXE&RCE 漏洞