漏洞概要 关注数(24) 关注此漏洞
缺陷编号:wooyun-2015-0113648
漏洞标题:我是如何通过三个绕过拿下盛大全部游戏官网及内网十几台服务器
相关厂商:盛大游戏
漏洞作者: 3King
提交时间:2015-05-12 14:18
修复时间:2015-06-26 14:30
公开时间:2015-06-26 14:30
漏洞类型:未授权访问/权限绕过
危害等级:高
自评Rank:20
漏洞状态:厂商已经确认
漏洞来源: http://www.wooyun.org,如有疑问或需要帮助请联系 [email protected]
Tags标签: 无
漏洞详情
披露状态:
2015-05-12: 细节已通知厂商并且等待厂商处理中
2015-05-12: 厂商已经确认,细节仅向厂商公开
2015-05-22: 细节向核心白帽子及相关领域专家公开
2015-06-01: 细节向普通白帽子公开
2015-06-11: 细节向实习白帽子公开
2015-06-26: 细节向公众公开
简要描述:
无意中看到某漏洞,然后手贱。
先声明一下:
1.本次测试,事前已与盛大安全人员进行沟通。
2.网站服务器和用户数据服务器、数据库都是隔离的,所以不会涉及任何用户数据安全。
3.本报告仅作为漏洞思路交流,挑事、造谣的朋友请绕道。
详细说明:
某天逛乌云,无意中看到了 WooYun: 盛大某站文件远程包含任意文件下载目录读取 ,进来一点,发现SSRF仍在。
然后手贱,进一步看了下,于是就出现了第一层绕过:
如图我们可以看到,任意文件下载问题已经修复,输出URL Error。
首先想到的是协议问题。我们访问有SSL的
也提示URL Error。这里就有疑惑,难道是根据URL前缀进行匹配判断的吗?
接下来访问
依然提示URL Error。这里就可以确定,本次修复是通过text的内容进行校验。如果不在url参数优先出现"http://",则输出 URL Error,否则webrequest.getresponse。
这么一来,似乎没法绕过了。因为你没法在http协议后面跟file协议,因为无法解析,像这样:
跳转呢? 这里做了一个302测试:
结果表明不能从一种格式跳往另一种格式。
但是这里我们猜想了下,是不是一定限制了"http://"放在参数头部?
访问url
可以看到,回显的是"无法连接远程服务器",似乎是绕过成功了..?
换成文件协议试试:
路径中有非法字符。 对呀,虽说是绕过了,但是后面的http://怎么办,又不能去掉。
这里曾经想到过很多方法,截断、ascii80-99等,都没用。。
最后成功用以前经典的#号,成功绕过。
在这里,我们注意了一下绝对路径。
这里有个想法,根据以前的测试经验,或许盛大的所有的官方网站全运行在同一台服务器上,然后再进行分流?
比如这个星辰变2:http://x2.sdo.com/对应绝对路径==>d:\Website\x2\x2\
根据运行规则:http://mxd.sdo.com/是不是对应绝对路径==>d:\Website\mxd\mxd\ ?
尝试访问:
成功。
尝试访问:
成功。
基本上证明我们的猜测是正确的。
但是现在问题来了:如何获取权限呢?
盛大所有公网生产后台基本上都是走UAM的,且无法通过x-forward和refer等绕过,登录需要动态密保,而且都是站库分离,想了想只有上传了。
上传点在哪儿呢?前台?由于盛大所有活动都有统一上传机制,所以没可能实现,那就只有后台才有可能了。
说道后台,可能是盛大自信自家UAM的原因,/admin 很好找。关键是如何绕过UAM。
还是得进行后台的白盒。
刚访问配置文件,我们就发现了一个亮点:
fckeditor? 不要这么好吧。。。
但是文件模块有session验证
看看源码:
所以思路大致确定了,只要获取带有user的session,即可访问fckeditor的文件模块,再想办法找上传漏洞。
可是在哪找呢? 只有后台。 后台有UAM登录限制啊。。。且无法绕过。。
或许我们可以找到一些未授权页面然后取得session("user")?
很遗憾。。没有。。
或者我们可以下载全盘文件逐个分析? 但是无法遍历目录,这个想法也放弃了。
到这里思路似乎断了。
最后我觉得,是否可能存在一些旧版本的后台代码,可能会由于代码不严等问题找到一些突破点?
首先搜集盛大所有游戏的官网。。 然后一个个翻。。。。
终于在一些后台看到了几个亮点。
例如:
可以看到,部分后台将后台用户名和密码直接定义了出来,而不是进入数据库查询。这就给我们进入后台减少了一道门槛。
再翻,终于在这些直接定义密码的后台中找到了一个有亮点的:
可以看到,此后台登录是先检查ticket,如果ticket参数为空,则跳转到UAM登录地址(uam.sdo.com)
否则,就校验ticket,然后定义user从uam_callback中域账户取。
然后,第二层绕过来了。
如果ticket为空,则跳转UAM登录地址,那么ticket参数不为空呢?
也就是说,无论ticket是否有效,程序都会向下执行,并不会退出。
然后就到了后台帐户校验块,由于后台帐户信息已在配置文件中定义,我们可以直接拿来登录了。
直接访问,跳转uam
加ticket,未退出,继续执行。
登录后台成功。
由于session(user)已有值,fckeditor文件模块访问成功。
但由于服务器iis版本为7.5,不能用6.0方法执行解析漏洞。
这里注意到了一个细节,文件模块显示的是修改日期。
那么我们知道,fckeditor的较新版本都是显示文件大小的,显示修改日期的话,应该是旧版本的fckeditor。
回头一看,果然。
这样的话,可以通过00截断,成功上传webshell。第三层绕过成功。
转到website目录一看,下线的上线的,一共两百个官网目录。
随后与盛大安全人员沟通时,他们无法复现,清空cookie后发现我们也无法复现了。这里想到可能启用了负载均衡。这么一想也合理,毕竟日均pv非常大,全挤在一个服务器早炸了。
我们重复上面提权动作重新拿到webshell后查看ip,发现ip由原来的10.**.18.11变成了10.**.18.16
最后确认,这个段内有十几台均载服务器。
如果我们无限清空cookie,然后一直随机分配均载服务器的话,这十几台服务器全部可以被提权。
但是也是没意义的。因为均载服务器里面内容都一样:-)
漏洞证明:
修复方案:
·既然这么信任UAM,那么就应该后台所有程序全局include。
·很多后台程序有点老啦,应该升级啦。还有很多网站存在相同漏洞,不再点出,请自行检查。
·前台上传、后台上传全走了统一上传,就fckeditor没走,也是比较醉:-)。
版权声明:转载请注明来源 3King@乌云
漏洞回应
厂商回应:
危害等级:高
漏洞Rank:20
确认时间:2015-05-12 14:28
厂商回复:
感谢关注,欢迎继续关注
最新状态:
2015-05-12:标题太惊悚了。。。本次渗透我们提前知晓,渗透进展也知晓。。。