泛微ecology9 FormAction SQL注入漏洞分析
type
status
date
slug
summary
tags
category
icon
password
AI summary
注入点分析
入口点在于/mobilemode/mobile/server.jsp和/mobilemode/Action.jsp
这里反射获取invoker类，然后判断是否为BaseMobileAction的子类，然后实例化并调用execute_proxy()
遍历获取带有@ActionMapping 注解的方法，如果找到的注解中的 name 属性值与当前请求的 action 名称相匹配，就会调用该方法。
在BaseMobileAction的子类中，有一个FormAction，在它的parseDefaultValueAction中，获取了content参数的值
在经过AES解密后
最终执行了SQL，在这个过程中content的值是可控的。只需要知道AES的密钥即可构造恶意请求。
AES密钥分析
解密过程入口
密钥获取流程
首先从数据库中加载配置获取所有键值对，然后加载到内存缓存和Redis缓存。然后再调用getSecurityKey()取security.key
如果内存缓存和Redis缓存都为空时，才会从配置文件中获取security.key，并更新数据库，然后调用setConfig()同步更新内存和Redis缓存。
数据库中的security.key从何而来？
在SecurityRuleInitMobileConfig中，对于security.key进行了初始化
- 首先查询数据库中是否存在security.key
- 如果存在且有效，则标记数据库初始化成功
- 如果不存在或为空：
- 生成新的随机UUID的前16位作为密钥
- 更新数据库中的值
- 记录初始化结果
- 然后检查配置文件中是否已有密钥
- 如果配置文件中没有密钥：
- 将生成的随机密钥写入配置文件
- 记录配置文件初始化结果
这其实有概率导致数据库和配置文件的密钥不一致
漏洞复现
读取数据库中的密钥：
然后使用以下脚本构造加密content，脚本来自于@lipuhua
感觉是有点鸡肋在的....security.key不是硬编码，需要结合文件读取才能利用。
Loading...