奇安信攻防社区-H3C-iMC智能管理中心autoDeploy.xhtml页面代码执行漏洞分析

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](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-43ed10bd4e460f0efb5b01103a9510155ef655f7.png)

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

![image-20240813180457189.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-ad68ea0da0b212655e50956f0b131b634ff18740.png)

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

![image-20240813180848768.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-23a0440949881ec63c79734b9b1aacb9be2a5eab.png)

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

### 解密

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

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

![image-20240813181649267.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-27f935dfc9e61127323cbf3c5244e6485ab13094.png)

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

先通过上下文保存的`iv`和`key`对解密器进行初始化

![image-20240813181819945.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-ace8bbf601ee88d05010dfe859852a9f5d9bd0f3.png)

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

![image-20240813181905784.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-b6738a16e551f04a7bc8bae75fd156c8c3e0ba34.png)

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

![image-20240813182202626.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-02de79f549480073a3d950fece023a9d3315a793.png)

### 加密

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

加密：`org.apache.myfaces.shared.util.StateUtils#encrypt`

![image-20240813182325338.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-de227298f6e80e23b627d105ea1ca7785ac15b37.png)

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

![image-20240813185026411.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-e8aa865e5dc1b833eda779baecc1851d757e298b.png)

![image-20240813185106439.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-0ce3348f59d9552fcbbbd71158ed8e317c45e5c6.png)

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

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

![image-20240813185413489.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-ae37dc6ed586888a23be1373752ce620cdafeae2.png)

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

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

![image-20240813185912217.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-06db727edb4f384190bc3bb6a3c889127330e0d7.png)

### 生成Payload

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

![image-20240813192516514.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-b014fab4a163df6b5fdc3bbe2794e8c0f90c47a7.png)

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

![image-20240813201511321.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-1969bdfc6a8d813d8a7266cd632958da1f9bcaad.png)

四、漏洞复现
------

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

![image-20240813201540884.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-17c38b877af8aaceec8859862ac6d95668f40208.png)

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

接收

![image-20240813202625772.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-26a9cee4f743ecdae57d4cda3fae083d1cccbb15.png)

解密后

![image-20240813202853999.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-ea6e5cca026070f6377a5d753e7f9b8a93a118a2.png)

反序列化

![image-20240813203106588.png](https://shs3.b.qianxin.com/attack_forum/2024/08/attach-f42ccd1c84998f64e519665476af642e7ad5abeb.png)

五、总结
----

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

1. **避免反序列化不可信数据**

- **原则**: 尽量避免反序列化来自不可信来源的数据。如果反序列化的输入可能来自用户或外部系统，应特别小心。
- **解决方案**: 使用可信的数据源，并确保数据在受信任的环境中处理。

2. **使用安全的替代方案**

- **原则**: 使用更安全的数据格式（如JSON、XML）代替Java的原生序列化机制。
- **解决方案**: 如果必须使用反序列化，考虑使用安全框架来限制可反序列化的类。

3. **限制可反序列化的类**

- **原则**: 通过白名单策略，限制可反序列化的类。
- 解决方案
    
    
    - **Java**: 可以使用`ObjectInputFilter`来控制允许哪些类被反序列化。Java 9及更高版本支持这一特性。
    - **第三方库**: 使用第三方库如 Apache Commons `SerializationUtils` 提供的反序列化工具，这些工具通常有更严格的安全控制。

4. **验证和过滤反序列化的数据**

- **原则**: 在反序列化前验证数据，确保其符合预期格式和内容。
- **解决方案**: 在反序列化前，使用签名验证、数据校验等手段来验证数据的完整性和可信度。

5. **使用自定义的`readObject`或`readResolve`方法**

- **原则**: 在可控的类中，通过自定义的`readObject`或`readResolve`方法来验证数据或防止不安全的反序列化行为。
- 解决方案
    
    
    - **`readObject`**: 允许你在反序列化过程中执行额外的安全检查。
    - **`readResolve`**: 确保反序列化后的对象处于安全的状态。

6. **安全的类加载器**

- **原则**: 限制类加载器在反序列化时加载任意类，防止加载恶意类。
- **解决方案**: 配置安全的类加载器，限制可加载的类的范围。

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

[https://www.h3c.com/cn/Service/Online\_Help/psirt/security-notice/detail\_2021.htm?Id=134](https://www.h3c.com/cn/Service/Online_Help/psirt/security-notice/detail_2021.htm?Id=134)

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

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

0 条评论