H3C-iMC智能管理中心autoDeploy.xhtml页面代码执行漏洞分析

H3C-iMC智能管理中心存在远程代码执行漏洞,攻击者利用该漏洞可以在服务器执行远程命令。

一、漏洞简介

H3C-iMC智能管理中心存在远程代码执行漏洞,攻击者利用该漏洞可以在服务器执行远程命令。

二、影响版本

**产品名称:**H3C iMC产品

受影响的版本:EIA E0632H06及之前的版本

修复的版本:EIA E0632H07及之后的版本

三、漏洞原理分析

这个漏洞其实是一个组合漏洞,先是利用;.js的方式绕过权限限制。之后可以访问到后台功能点,利用后台功能点的反序列化漏洞执行系统命令。

先来跟踪一下漏洞过程:

漏洞入口在org.apache.myfaces.renderkit.html.HtmlResponseStateManager#getSavedState处。

是 MyFaces 框架中的一个方法,用于在 JavaServer Faces (JSF) 应用中管理视图状态。这个方法的作用是从请求中获取保存的视图状态。

在 JSF 中,视图状态(ViewState)是一个重要的概念,它用于维护用户界面组件的状态以及应用程序的行为。这个状态通常在多个请求之间持久化,因此在一个请求中产生的状态可以在后续的请求中使用。JSF 使用一个隐藏字段来传递视图状态,通常命名为 javax.faces.ViewState

这里通过Faces上下文的请求参数中获取该值。根据命名encodedState可以看出来,后去的状态是加密的。

image-20240813175838608.png

跟进函数org.apache.myfaces.shared.util.StateUtils#reconstruct,该函数主要对出入的数据进行一些列的解码、解密。

image-20240813180457189.png

之后传递给org.apache.myfaces.shared.util.StateUtils#getAsObject,从字符转换成对象,在Java中通常称为反序列化。

image-20240813180848768.png

虽然说这是一个反序列化,但是不能直接利用,还需要对payload进行加密。

解密

发送的post请求体是加密的,所以需要分析一下加解密。

第一层:org.apache.myfaces.shared.util.StateUtils#decode解码,这是一个base64解码。一般byte[]格式的数据,都会进行base64加密,更好保存和传输,以避免过程中报错。

image-20240813181649267.png

第二层:org.apache.myfaces.shared.util.StateUtils#decrypt,这是一个AES解密函数。

先通过上下文保存的ivkey对解密器进行初始化

image-20240813181819945.png

然后对数据进行解密并返回

image-20240813181905784.png

第三层:org.apache.myfaces.shared.util.StateUtils#decompress,这是一个解压缩函数,系统采用的GZIP压缩

image-20240813182202626.png

加密

我们在生成payload的时候,并不需要根据解密函数反推出加密函数,只需要对已有加密函数进行微调即可

加密:org.apache.myfaces.shared.util.StateUtils#encrypt

image-20240813182325338.png

先来看一下加密逻辑,跟解密逻辑类似,先根据上下文对加密器进行初始化,之后再对数据进行加密

image-20240813185026411.png

image-20240813185106439.png

看一下初始化时的值是从哪里来的,拿org.apache.myfaces.shared.util.StateUtils#getSecret举例

从各种地方查找键为org.apache.myfaces.SECRET.CACHE的值

image-20240813185413489.png

全局查找,实在配置中写死的

client/web/apps/imc/WEB-INF/assembly/web.xml

image-20240813185912217.png

生成Payload

我们生成payload的时候,肯定没办法调用应用的上下文,这时候就需要重写加密函数,把从上下文中获取的值,直接写入到函数中。

image-20240813192516514.png

还需要构造序列化的对象,直接用ysoserial工具的Myfaces2生成可以,也可以自定义

image-20240813201511321.png

四、漏洞复现

这里的payload修改成从请求头中直接获取命令的方式,更方便一些。

image-20240813201540884.png

输入payload后,几个阶段中的数据变化

接收

image-20240813202625772.png

解密后

image-20240813202853999.png

反序列化

image-20240813203106588.png

五、总结

该漏洞主要因为没有对反序列化的数据进行验证,导致任意命令执行。针对反序列化,通常有如下几条修复方法

  1. 避免反序列化不可信数据
  • 原则: 尽量避免反序列化来自不可信来源的数据。如果反序列化的输入可能来自用户或外部系统,应特别小心。
  • 解决方案: 使用可信的数据源,并确保数据在受信任的环境中处理。
  1. 使用安全的替代方案
  • 原则: 使用更安全的数据格式(如JSON、XML)代替Java的原生序列化机制。
  • 解决方案: 如果必须使用反序列化,考虑使用安全框架来限制可反序列化的类。
  1. 限制可反序列化的类
  • 原则: 通过白名单策略,限制可反序列化的类。

  • 解决方案

    • Java: 可以使用ObjectInputFilter来控制允许哪些类被反序列化。Java 9及更高版本支持这一特性。
    • 第三方库: 使用第三方库如 Apache Commons SerializationUtils 提供的反序列化工具,这些工具通常有更严格的安全控制。
  1. 验证和过滤反序列化的数据
  • 原则: 在反序列化前验证数据,确保其符合预期格式和内容。
  • 解决方案: 在反序列化前,使用签名验证、数据校验等手段来验证数据的完整性和可信度。
  1. 使用自定义的readObjectreadResolve方法
  • 原则: 在可控的类中,通过自定义的readObjectreadResolve方法来验证数据或防止不安全的反序列化行为。

  • 解决方案

    • readObject: 允许你在反序列化过程中执行额外的安全检查。
    • readResolve: 确保反序列化后的对象处于安全的状态。
  1. 安全的类加载器
  • 原则: 限制类加载器在反序列化时加载任意类,防止加载恶意类。
  • 解决方案: 配置安全的类加载器,限制可加载的类的范围。

官方已经针对该漏洞进行修复,升级新版本即可修复漏洞

https://www.h3c.com/cn/Service/Online_Help/psirt/security-notice/detail_2021.htm?Id=134

  • 发表于 2024-08-14 10:24:19
  • 阅读 ( 4090 )
  • 分类:Web应用

1 条评论

zch
您好,师傅,可以分享一下加解密的代码吗
请先 登录 后评论
请先 登录 后评论
Harper Scott
Harper Scott

6 篇文章

站长统计