【网络安全】系统0day分析
前言
起因看见通告，描述是通过/lfw/core/rpc接口访问到PortalSpecServiceImpl类中的createSkinFile方法。
补丁名称：patch_portal65_lfw任意文件上传漏洞
补丁编码：NCM_NC6.5_000_109902_20240301_GP_281362040
搜了下网上没有相关描述
接口和关键类和函数描述中都给出来了，直接定位如下
调用handleRequest
继续跟进getControlPlugin
然后调用RpcControlPlugin.handle
RpcHelper.processJsonRequest如下，获取rpcdata参数，用json存储，并传递给call函数
在call()中，获取json中的rpcname和methond和params，通过paramList存储params参数，params参数最多不超过10个
然后一顿字符串处理，直接拉到call函数最后，instance、getMethod、method.invoke获取实例、获取类方法、反射调用，并且通过上面可以知道，所以参数都可控。
看起来是直接代码执行。
0x01
直接传递如下
rpcname为bsh.Interpreter
method为eval
params为ping o3n9.callback.red
直接发包，返回500，没这么简单。。。
先把命令改成whoami，再次发送，还是500，参数这么简单，中间代码是处理字符串和获取参数对应的class应该不会出什么问题
然后详细看了下获取实例的函数ServiceLocator.getService(className);
调用getInstance().doGetService(name);
doGetService函数如下，NCLocator.getInstance()看起来好熟悉，在哪个漏洞接口见过。
rpcname直接设置为ldap://xxx，method和params随便设置即可，因为反射调用找不到方法导致报错是后面的事了。
直接发，获取到请求，接着打jndi就行。
0x02
由于描述说的是文件上传，查了下ServiceLocator.getService，叫做服务定位器模式，这看起来像JNDI的样子
服务定位模式（Service Locator Pattern）是一种设计模式，用于解耦客户端和服务的依赖关系。在服务定位模式中，一个中心的服务定位器（Service Locator）负责管理和提供服务的实例，客户端通过服务定位器来获取所需的服务，即能够在不知道抽象类的具体类型的情况下定位到服务。
例子如下图所示
然后ServiceLocator这样调用service1、2
也就是说通过ServiceLocator.getService(className)去获取实例，className要先被加入到ServiceCache才能通过getService获取到。
上面用的bsh.Interpreter这个类是获取不到的，描述里的这个类PortalSpecServiceImpl应该能获取到的，并且有createSkinFile方法可以写文件
一共6个参数，分别拼接到filePath里
直接构造
rpcname为nc.uap.portal.service.impl.PortalSpecServiceImpl
method为createSkinFile
params为String1、2、3等
再次直接打，服务器还是返回500，正常来说，应该没啥问题的，有点难受。
0x03
下面两个思路
找ServiceCache里有哪些类，然后找有可以执行命令或者写文件public方法的类。
继续看下为什么PortalSpecServiceImpl调不了
下面继续看了，跟着上面的NCLocator.getInstance().lookup(name)
doGetService
-->ServerNCLocator#lookup
-->BusinessAppServer#lookup
-->AbstractContext#lookup
大概有三种方式加载
name以->开头通过findMeta()和findComponent()获取实例。
name不以->开头，直接通过服务定位模式this.getServiceCache().get(name)在Cache中取，如果有的话直接返回实例
name以java:comp/env/开头，进入jndiCtx.lookup。最后如果meta和retObject还是未获取到，则调用jndi(jndiName)
大概率PortalSpecServiceImpl这个应该不是在ServiceCache里，不然就成功获取到对象然后反射调用方法了，或者可以通过某种方式先添加PortalSpecServiceImpl到ServiceCache，再获取。
重点看下第一种方式，获取Meta如下。
进行实例化
查看实例化过程，通过this.getImplementationClass()获取对象
PortalSpecServiceImpl是实现的这个接口nc.uap.portal.service.itf.IPortalSpecService。
那类就应该为IPortalSpecService，重新构造发包
服务器返回200，exp没问题了，但是发现文件上传到目录不对，应该是filePath拼接的目录有问题。
0x04
回到上面的在call()中的处理参数字符串那段
会用fromJsObject进行处理
最后到JSONTokener的nextValue函数，会把传进去的字符串进行一个字符一个字符的判断。
如跳转目录的../../../被处理会变成了..
window环境下可以直接..\..\即可。为了通用的话还是需要处理一下
这里注意到在fromJsObject处理之后会调用如一次decode
这里传递两层url编码即可
当发送..%252f..%252f这个字符串后，服务器进行第一次解码，到fromJsObject处理时，此时的路径为..%2f..%2f，绕过/检测，接着经过JsURLDecoder.decode()，变成了../../，最后拼接到filePath。
到这里就可以web根目录上传文件了
最后，这里就是一个代码执行，也可以调用其他类方法，只是类有点限制，如读文件win.ini。
