漏洞详情

披露状态:

2014-02-24: 细节已通知厂商并且等待厂商处理中
2014-02-24: 厂商已经确认,细节仅向厂商公开
2014-03-06: 细节向核心白帽子及相关领域专家公开
2014-03-16: 细节向普通白帽子公开
2014-03-26: 细节向实习白帽子公开
2014-04-10: 细节向公众公开

简要描述:

本专题发布到乌云的目的第一是为了交流基本思路(本人也是菜鸟 ╮(╯▽╰)╭),第二是获取rank以作为回报,第三是就大企业整体的安全防御进行讨论。不足之处,还望指正。

※ 本次渗透是基于乐视官方授权许可的基础上进行的,这些漏洞在上报乌云前均已得到了修复。建议各位做持续或内部渗透前,先和官方联系,取得相应许可,以免出现不必要的误会和麻烦。

※ 本报告中部分信息涉及的隐私部分,将做屏蔽或替换处理。

※ 应厂商意向,本专题希望各位基友仅在乌云讨论,不要外发,谢谢!

详细说明:

乐视有个“V”系统,出现过strtus2框架漏洞,曾经上报过,乐视受理了漏洞。这次渗透前的例行扫描中,找到了这个“V”系统的几个测试系统。

123.B25.C9.D22-123.B25.C9.D33



而这几个测试系统均已打strtus2补丁,也不存在什么弱口令,便暂时放在了一边。



渗透到这里,可以说已经提高了本次渗透的主动权。有内外网服务器权限,有管理员、IP段信息,接下来的渗透的难度将有所降低。



于是,便抽了个时间重新关注这个“V”系统。



ping一下这个“V”系统的IP,10.B5.C22.D122,看来已经解析到了内网。不过没关系,从三四章的渗透中,已经获得了足够的内网访问权限,可以直接通过域名访问了它。一测试,发现strtus2框架漏洞还在!乐视这懒偷得.. 有时间转移到内网,没时间打补丁..



于是balabala拿到了这个服务器的权限,随后进入数据库的管理员表获取管理员信息。



很奇怪的是,试了几个管理员信息,均提示用户名或密码错误。



难道还有别的数据源?



通过查看代码和服务器连接信息,确定只有这一个数据库。



那这是怎么回事呢?



一百来个管理员信息,试了几十个之后才有一个有效管理员,于是进入了系统。



右上角的修改密码引起了注意

1.jpg





点开修改密码链接后,发现并不是在本服务器修改的密码,而是跳转到了另一个站点

http://128.B66.C131.D169:8090



2.jpg





嗯..这应该是一些站的权限系统..



java架构...



于是下意识地测了一下strtus2命令执行...



我勒个去! 还真有!

3.jpg





拿到这个权限系统的服务器权限后,登录了这个数据库,获取到超级管理员MD5并解密,返回“V”系统登录,登录成功。

4.jpg



5.jpg





这时想起,前面不是有过“V”系统测试系统的地址吗?是不是它们的登录全是由这个权限系统控制的呢?



于是用权限系统的超级管理员密码登录已打strtus2补丁的外网“V”系统测试系统,成功!

6.jpg





通过挖掘,发现“V”系统存在上传限制绕过漏洞。虽然在上传Flash处限制了文件类型,但是可以通过上传框处改名绕过。虽然很多上传点会对图片进行裁剪,但在“新增专辑”的不裁剪处能成功将任意文件上传到“V”系统中,导致可以获取Shell。



在“V”系统测试系统中,发现了几个“V”系统本身没有的数据源。

7.jpg





其中一个用“V”系统测试系统登录,竟然提示Host 'V@localhost' is not allowed to connect to this MySQL server



这就未免有点奇怪。



既然not allowed,那这个数据源还放在系统里干嘛?



这时,便产生了好奇,想要登录这个数据库试试。说不定是重要数据库呢~(后来证实是对的)



那么怎么才能登录进去呢?



一般来说,有这两种方法:

1.

本机→数据库机终端→数据库





2.

本机→允许访问该数据库的机器→数据库





第一种,密码爆破失败,况且linux出弱口令的可能性小多了,而且是数据库机,怎么可能允许弱口令。。



看来能用第二种方法了。。



但是,到哪里去找允许访问该数据库的机器呢。。 现在手里这几个“V”系统机器都不行啊。。



想来想去,只有从我手里现在有的机器一个个去试了。。



于是拿第一章、第二章的服务器去试。。。



RP真好!第二章的乐视客服服务中心服务器可以访问该数据库!



进去之后,感觉有点不对劲。。。



每章表数据都是几十万。。 每次的请求返回都卡到超时。。 而且一些内容都非常新。。这难道是进了乐视主库?



USER表更是次次不能返回。。。



费了九牛二虎之力,执行SELECT COUNT(*) AS CNT FROM USER成功了。。



返回信息,一千多万。。。。。。。。。。



选取其中5条进行登录验证,100%成功。



(由于较敏感,这部分就不给截图了)

漏洞证明:

1.jpg



2.jpg



3.jpg



4.jpg



5.jpg



6.jpg



7.jpg

修复方案:

·修补“V”系统的上传绕过



·修改相关数据库密码



·全面检查全网其它系统是否还存在strtus2框架漏洞

版权声明:转载请注明来源 3King@乌云


漏洞回应

厂商回应:

危害等级:高

漏洞Rank:20

确认时间:2014-02-24 10:33

厂商回复:

辛苦了,做了不少工作,感谢。

最新状态:

暂无


漏洞评价: