漏洞概要
关注数(24)
关注此漏洞
漏洞标题:普通应用下的暗涌-几款通用型应用的SSRF漏洞利用及分析以及某大厂坑到自己记录
提交时间:2015-08-12 18:53
修复时间:2015-11-12 15:46
公开时间:2015-11-12 15:46
漏洞类型:设计缺陷/逻辑错误
危害等级:高
自评Rank:20
漏洞状态:已交由第三方合作机构(cncert国家互联网应急中心)处理
Tags标签:
无
漏洞详情
披露状态:
2015-08-12: 细节已通知厂商并且等待厂商处理中
2015-08-14: cncert国家互联网应急中心暂未能联系到相关单位,细节仅向通报机构公开
2015-08-17: 细节向第三方安全合作伙伴开放
2015-10-08: 细节向核心白帽子及相关领域专家公开
2015-10-18: 细节向普通白帽子公开
2015-10-28: 细节向实习白帽子公开
2015-11-12: 细节向公众公开
简要描述:
验证到半夜,求加精
为什么敢自评20,因为我觉得影响确实很广
而且要么不影响要么就是内网
你觉得SSRF的问题有多大?
自从乌云上大牛们提了不少SSRF进内网的实例以后,让我明白:
不要以为有缺陷的应用在内网就能高枕无忧!!!
内部应用的安全同样需要做好,无需一个WEBSHELL,一个你没想到的SSRF的点就能让你崩溃,而且很多人都在用的应用~
本报告记录几款没什么人注意,用户量多,比较隐蔽的且通用SSRF漏洞,以及某大厂商内网执行命令的故事
如果你看懂了,恭喜你,情商跟我一样为负数了~
详细说明:
首先,此处的主角为几款流行的编辑器:
Ueditor、ewebeditr、xheditor
以前在用这些编辑器的时候,往往最容易出现问题的就是,直接GETSHELL,欺骗绕过,上传改名等。但是在印象中,还有一个功能,就是远程文件上传,功能一直存在。聪明的你,应该想到了吧,虽然以前远程上传文件也能够直接GETSHELL,但是后面修复过以后,这功能也就渐渐被人遗忘了。SSRF最近也火起来了,我就拿出来写下这几款编辑器的缺陷吧,以及是怎样拿其中一款在某厂商内部执行命令的
其实我是分析了不少编辑器的,如下:
网络上面容易搜到,且下载多的都找了下。
暂时就发现了开头说的那三个存在SSRF问题。
注:因为很多编辑器都只有前端处理程序,SSRF漏洞需要后端的脚本提供支持~
一款编辑器一般都有不同语言开发的版本,要实现的功能也是一样的。
在此报告中,就主要分析下PHP写的,以及后面在某厂中用到的JSP版本的,来证明无关语言,反正通杀~
比如百度出品的ueditor(文章的猪脚)
Ueditor有三个版本,ubuilder、ueditor开发版、ueditorMINI版本
漏洞文件:
老版本:
/php/getRemoteImage.php
比较新版本以及最新版本以及未发布的1.4.4测试版本:
1.4.4版本又在1.4.3的上面修改了一处代码,导致一处可回显的SSRF变成了BOLL型的SSRF,可能百度内部也没引起重视,自己的产品的版本升级到最新的未发布的版本,或者更新个安全通过,导致自己被坑倒了~
1.4.4现在在官网并没有下载,只有github存在,而且是测试版本,为什么这样说,请看下面写的测试百度的内容。
/php/action_crawler.php
首先分析下getRemoteImage.php文件所产生的问题:
此文件存在于V1.4.2以下版本,不影响V1.4.2
此漏洞在最新发布的ueditor1.4.3依旧存在
ueditor1.4.4暂时值存在于github,虽然已经不能获取到返回的内容了(非图片资源),但是还是可以用于盲打SSRF,或者用户WEB指纹判断应用类型(比如请求/tomcat.jpg)这类的
因为漏洞是通用,代码差不多,这里就不啰嗦,直接对比下最新未发布的跟最新已经发布的版本,看看哪里修改了代码,给我们造成了困扰吧。
主要看:
\php\ Uploader.class.php
188行到192行
跟以前老版本的没区别对吧,所以漏洞依旧是可以利用获取到任意请求资源内容的。
我们来看看baiduGithub中还没发布的V1.4.4的代码:
核心就是多了个”!”,这里就限制住请求任意资源文件了。
为什么最新的未发布的修改了呢?因为是百度的发现了这个问题,但是却没认为非常重要,不是一个安全问题,这就会导致百度内网出问题。
在找百度用的这种编辑器的时候,发现的最新版。
http://**.**.**.**/static/lib/ueditor/php/controller.php?action=catchimage&source[]=
还有一处JSP版本,JSP版本在低版本也比PHP的安全,比如
http://**.**.**.**/thirdparty/ueditor/jsp/imageUp.jsp
最新版本跟非PHP版本(没有研究ASP,.NET以及其他版本),虽然不能获取到请求的数据,但是这些版本都是可以进行内网探测,盲打SSRF的。(以下有个彩蛋对于这个)
我们看看为什么低版本的JSP编辑器也不能够获取到返回来的数据吧:
\jsp\getRemoteImage.jsp
到此分析ueditor完毕。
小结:
php版本的ueditor<=1.4.3可以通过SSRF获取内容
jsp,php的所有版本(暂时值看了这两个),都可以盲打内网SSRF,以及进行端口扫描。
在进行探测的时候,注意端口打开的时候以及关机的时候的延时。
如果存在错误信息泄漏的话,更加方便。
ueditor验证:
老版本:
**.**.**.**/ueditor/php/getRemoteImage.php
POST:
upfile=**.**.**.**:80/%23.jpg
新版本:
**.**.**.**/ueditor/php/controller.php?action=catchimage
POST:
source[]=**.**.**.**:80/%23.jpg
ewebeditor这款肯定不会陌生了。
这里来说说利用,漏洞成因都是一样的,就不分析了:
**.**.**.**/ts/ewebeditor/editor/php/upload.php?action=REMOTE&style=toby57&language=en
POST:
eWebEditor_UploadText=http://**.**.**.**/img/bd_logo1.jpg
证明一下,可以获取到任意资源。
xheditor这个用的人也是不少,这个只能用来盲打SSRF之类的了。
因为,它获取到资源以后会对文件进行检查,不是图片文件会进行删除操作。
利用POC:
**.**.**.**/xheditor/demos/saveremoteimg.php
POST:
urls=https://**.**.**.**:80/img/bd_logo1.png
另外附带一个openwysiwyg_v1.4.7编辑器的列目录漏洞:
/addons/imagelibrary/select_image.php?dir=..\..\..\..\..
漏洞证明:
ueditor是百度的产品就找下百度的问题吧~
在详细说明中已经给了两处了,都不能获取返回的内容,只能盲扫,等下还说下我盲扫的结果。
http://**.**.**.**/static/lib/ueditor/php/controller.php?action=catchimage&source[]=
http://**.**.**.**/thirdparty/ueditor/jsp/imageUp.jsp
给出扫描的验证脚本一部分:
通过类似上面的脚本我扫描了百度内网不少网段,筛选了一些开着8080,80端口的机器。
类似这样:
很多,就不一一列出了了~
给出暂时找到的一处,可以获取返回资源的:
http://**.**.**.**/editor/php/getRemoteImage.php
下面给出结果吧:
一开始的想法其实就是想通过struts2的代码执行漏洞,盲SSRF一个回显到外网的WEB日志去,但是可能由于之前有大牛打过一回,那有问题的IP端口也关了,所以没有一个成功,这个是在后面一个一个找URL看源码,找出来的。。
漏洞证明:
如下图有我用JSP版本盲打SSRF的日志记录(可惜没成功一个),请求回来的,
然后有很多内网的真实IP了。
PY源码:
还有一些截图,在这里没必要再给出来了,下面给个可以执行代码的问题应用(寻找的过程略掉,不然太啰嗦):
Jenkins
参考资料:
http://**.**.**.**/archives/2166.html
Jenkins我在本地测试的时候是不接收GET参数的,很奇怪百度里面的那个接收。。
如图:
这里说下两个问题:
在请求的时候提交单引号或者双引号。。
比如"whoami".execute().text,去执行任意代码。
会被转移掉,然后报错,就是前面添加了一个反斜杠,如图:
然后我就想到了用
/代替单双引号,没想到行得通,简单绕过了这个,就可以执行任意命令了。
空格提交的时候需要编码为%2520..
如图:
现在可以在内网执行任意命令了
然后就停止了验证。
没有做任何破坏性操作,没有写WEBSHELL文件,只是检测。
扫描的时候只是扫描了80,8080端口,只为寻找WEB应用。
通过延时判断端口请求的小补充:
修复方案:
远程文件上传功能不必要就删除
这些问题其实相当于代理,直接通往内网
限制好请求的主机
版权声明:转载请注明来源 Tea@乌云
漏洞回应
厂商回应:
危害等级:高
漏洞Rank:10
确认时间:2015-08-14 15:44
厂商回复:
CNVD确认所述情况,已由CNVD通过软件生产厂商(或网站管理方)公开联系渠道向其邮件(和电话)通报,由其后续提供解决方案并协调相关用户单位处置。
最新状态:
暂无