前些时间测试的时候遇到了一个系统采用了UEditor编辑器,版本为1.4.3。已知该编辑器v1.4.3版本存在SSRF漏洞,虽然是Bool型的SSRF,除了可以进行内网探测外,也可以根据web应用指纹信息,之后进行进一步的测试。
查看官方的更新日志可以发现UEditor编辑器在版本1.4.3.1修复了SSRF漏洞。
那版本1.4.3应该存在SSRF漏洞,本着能搜索就不动手的原则搜了一下,发现wooyun-2015-0133125中提到过这类的漏洞。但我这里是jsp版本的,里面提到jsp版本不一样,只好去分析一下漏洞产生的位置。
那我们需要查看版本1.4.3与1.4.3.1有什么不同,从而找到存在问题的地方。
可以发现在该版本有一次commit,commitId 为a1820147cfc3fbe2960a7d99f8dfbe338c02f0b6
。根据字面意思应该是增加了修复SSRF的代码。
发现在v1.4.3.1中修改了jsp/src/com/baidu/ueditor/hunter/ImageHunter.java的validHost方法。
新增了对ip地址是否为内部地址的判断。而在v1.4.3中仅仅是做了是否为过滤的ip地址。
isSiteLocalAddress方法作用是当IP地址是地区本地地址(SiteLocalAddress)时返回true,否则返回false。
IPv4的地址本地地址分为三段:10.0.0.0~ 10.255.255.255、172.16.0.0 ~ 172.31.255.255、192.168.0.0 ~192.168.255.255。
搜索后发现在captureRemoteData中调用了validHost方法。
根据代码可以分析:首先使用validHost对url进行判断,如果不合法,就提示“被阻止的远程主机”;当满足条件后会使用validContentState方法查看返回的状态是否为200,若不为200,则提示“远程连接出错”;进而对后缀、文件大小进行判断,都符合之后才进行图片的保存。如果url无法访问,则提示“抓取远程图片失败”。
所以可以根据返回的内容,来推断该url对应的主机是否可以访问。由于在版本v1.4.3中没有对请求的主机进行验证,从而造成了SSRF漏洞。
继续查看在capture方法中调用了captureRemoteData。
当调用capture需要满足条件为actionCode为ActionMap.CATCH_IMAGE,在ActionMap中value为ActionMap.CATCH_IMAGE对应的key为catchimage。所以当actionType值为catchimage,即action参数对应为catchimage时,才可能触发SSRF漏洞。下面对漏洞进行验证。
功能实现的入口文件是jsp/controller.jsp。由上述分析可知需要满足action参数为catchimage。
在case ActionMap.CATCH_IMAGE中下断点,然后进行调试。
访问链接
继续运行发现list为空,然后就抛出了异常。
再次运行,查看list数据从何而来。
可以看出list的数据从浏览器source[]参数而来。这里source[]需要后缀为图片格式,具体可以查看config.js中的catcherAllowFiles。
已知192.168.135.133开启了tomcat服务,且端口为8080。我们这里访问一张不存在的图片,例如用UUID生成一张图片的名称。
构造请求链接:
当进入validHost方法时,由于被访问的主机地址不在过滤的范围,所以返回true。
这里可以发现,仅仅对127.0.0.1、localhost和img.baidu.com进行了限制,当ip为本地地址时并没有限制,从而可以进行内网探测。
由于UEditor在v1.4.3之前没有加入对内部IP的限制,所以在使用抓取图片的功能时,造成SSRF漏洞。可以进行内网服务器的探测。然后根据内网服务器的特征(如/jmx-console/images/logo.gif, /tomcat.png),判断其使用的组件,并猜测可能存在的漏洞,然后进行进一步的渗透。