利用解析差异复活某凌OA前台RCE

前言

23年底网上公开了一个某凌OA前台RCE,接口为/sys/ui/sys_ui_component/sysUiComponent.do这个漏洞是文件解压以后复制到WEB目录导致的任意文件写入，接口是直接能前台访问。我印象中能前台直接访问的接口里没有这个，后来发现是V16的某些版本才存在，于是分析了一下漏洞出现的原因以及是如何修复的。

鉴权分析

蓝凌为了给不同role的用户做权限校验，自写了一种xml配置方式。

和/sys/ui/有关的配置xml在WEB-INF/KmssConfig/sys/ui/design.xml定义

<?xml version="1.0" encoding="UTF-8"?>
<configs
	xmlns="http://www.example.org/design-config"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.example.org/design-config ../../design.xsd ">
	<module
		messageKey="sys-ui:module.sys.ui"
		urlPrefix="/sys/ui/"
		defaultValidator="true">
		<request
			path="index.jsp*"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)" />
		<request
			path="tools.jsp*"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)" />
		<request
			path="tree.jsp*"
			defaultValidator="roleValidator(role=SYSROLE_USER)" />
		<request
			path="help/font/**"
			defaultValidator="roleValidator(role=SYSROLE_USER)" />
		<request
			path="help/component/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;ROLE_SYSPORTAL_BASE_SETTING)" />
		<request
			path="help/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;ROLE_SYSPORTAL_EXT_SETTING)" />
		<request
			path="demo/**"
			defaultValidator="roleValidator(role=SYSROLE_USER)" />
		<request
			path="jsp/**"
			defaultValidator="roleValidator(role=SYSROLE_USER)" />
		<request
			path="sys_ui_logo/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)" />
		<request
			path="sys_ui_extend/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;ROLE_SYSPORTAL_EXT_SETTING)" />
		<request
			path="sys_ui_tool/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)" />
		<request
			path="sys_ui_config/**"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)" />
		<request
			path="sys_ui_qrcode/**"
			defaultValidator="roleValidator(role=SYSROLE_USER)" />
		<request
			path="/sys_ui_compress/sysUiCompress.do*"
			defaultValidator="roleValidator(role=SYSROLE_ADMIN;SYSROLE_SYSADMIN)"/>
	</module>
</configs>

/sys/ui/模块defaultValidator为ture即无需鉴权，如果匹配到下面path里的路径则需要对应的defaultValidator权限。漏洞路径为/sys/ui/sys_ui_component/sysUiComponent.do匹配不到path里的路径所以也就无需鉴权了。具体的鉴权代码在com.landray.kmss.sys.authentication.intercept.AuthenticationValidateCoreImp#checkAuthentication(com.landray.kmss.sys.authentication.intercept.ValidatorRequestContext)

com.landray.kmss.sys.config.design.SysConfigs#loadAuthValidator

通过路径获取对应的模块

根据模块对应的授权配置匹配路径

com.landray.kmss.sys.config.design.SysCfgQuery#match

此处为参数级权限校验

这个漏洞出现的原因其实就是/sys/ui/模块默认无需鉴权，开发在这个模块新增了一个路由这个路由的命名正好也没匹配到其他的path，开发也忘记在xml里添加相应的鉴权配置，导致这个路由可以直接前台访问。

解析差异

在2023-06-09官方就已经修复了这个漏洞，修复方法为在xml里配置了鉴权。

WEB-INF/KmssConfig/sys/ui/design.xml



我们注意到这个地方使用的参数级鉴权，只有method等于某些特定值的时候才需要鉴权。

我们重新回到对于参数级权限校验处理的方法

com.landray.kmss.sys.config.design.SysCfgQuery#match

这个地方会获取method参数的值然后和配置里的比较



跟入com.landray.kmss.common.actions.RequestContext#getParameter



他这里就是用的tomcat的getParameterMap获取参数map然后获取值。

我们看后面调用方法的时候，他是怎么获取的。com.landray.kmss.common.actions.BaseAction#getMethodName



这里传入的request可以由我们在org.springframework.web.servlet.DispatcherServlet#doDispatch里改变





当请求为POST且Content-Type以multipart/开头request即为DefaultMultipartHttpServletRequest

所以当我们以上传格式传入method



验证权限的时候获取不到method参数的值，而查找调用方法时可以找到。

所以只需使用form-data格式传入method即可绕过权限校验复活这个漏洞。

漏洞利用

/sys/ui/sys_ui_component/sysUiComponent.do路由在WEB-INF/KmssConfig/sys/ui/spring-mvc.xml处定义

找到对应存在漏洞的方法

com.landray.kmss.sys.ui.actions.SysUiComponentAction#getThemeInfo

如果上传文件的后缀为zip的话会进行解压



解压的方法里判断目录穿越的情况



判断解压的文件里是否包含component.ini，如果包含的话加载ini从中获取id和name最后将一些需要的参数返回



然后把刚才解压的内容复制到this.getAppFolder(extendId)



extendId是我们刚才解压文件里面component.ini里的值。相当于将我们压缩包的文件解压然后全部复制到web目录的/resource/ui-component/+extendId目录下面

我们将component.ini文件内容填写如下

id=dasdasdas
name=test
thumb=/thumb.jpg

压缩包的文件解压后将会被复制的/resource/ui-component/dasdasdas/

我们制作一个如下压缩包



构造数据包使用上传格式传入method的值绕过权限校验，同时上传我们制作好的压缩包即可实现前台RCE

修复

官方于2024-07-26修复了漏洞。



修复访问为对/sys/ui/sys_ui_component/sysUiComponent.do添加了默认鉴权

以及在进入鉴权参数判断前对上传格式的数据包进行解析

com.landray.kmss.sys.authentication.intercept.FilterInvocationDefinitionSourceImp#getAttributes

总结

通过分析某凌OA鉴权机制发现其鉴权和最终获取method时存在差异。可以利用spring获取参数时会对form-data格式进行解析获取，而正常使用getParameter获取参数时获取不到form-data里参数的值从而实现鉴权绕过。这种绕过鉴权的方式在smartbi中也出现过，其实在某远OA里也存在。这种解析差异不止可以用来绕过鉴权，在java里很多时候会使用全局过滤器做sql注入、xss检测。过滤器里使用getParameter获取参数值实际上是获取不到form-data格式里的值的，这种情况可能会被直接绕过全局过滤器检测，所以进行黑盒测试的如果碰到sql注入有代码检测可以直接转为form-data格式进行测试有可能会有惊喜。