当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(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标签： 无

4人收藏 收藏
分享漏洞：

漏洞详情

披露状态：

2015-05-12： 细节已通知厂商并且等待厂商处理中
2015-05-12： 厂商已经确认，细节仅向厂商公开
2015-05-22： 细节向核心白帽子及相关领域专家公开
2015-06-01： 细节向普通白帽子公开
2015-06-11： 细节向实习白帽子公开
2015-06-26： 细节向公众公开

简要描述：

无意中看到某漏洞，然后手贱。
先声明一下：
1.本次测试，事前已与盛大安全人员进行沟通。
2.网站服务器和用户数据服务器、数据库都是隔离的，所以不会涉及任何用户数据安全。
3.本报告仅作为漏洞思路交流，挑事、造谣的朋友请绕道。

详细说明：

某天逛乌云，无意中看到了 WooYun: 盛大某站文件远程包含任意文件下载目录读取 ，进来一点，发现SSRF仍在。

01.png


然后手贱，进一步看了下，于是就出现了第一层绕过：

02.png


如图我们可以看到，任意文件下载问题已经修复，输出URL Error。
首先想到的是协议问题。我们访问有SSL的

http://x2.sdo.com/handler/ShowHTML.ashx?url=https://www.baidu.com


03.png


也提示URL Error。这里就有疑惑，难道是根据URL前缀进行匹配判断的吗?
接下来访问

http://x2.sdo.com/handler/ShowHTML.ashx?url=www.baidu.com（这里不加http）


04.png


依然提示URL Error。这里就可以确定，本次修复是通过text的内容进行校验。如果不在url参数优先出现"http://"，则输出 URL Error，否则webrequest.getresponse。
这么一来，似乎没法绕过了。因为你没法在http协议后面跟file协议，因为无法解析，像这样：

05.png


跳转呢? 这里做了一个302测试：

<?php
header('Location: file:///c:/tmp.vbs');
?>


结果表明不能从一种格式跳往另一种格式。

06.png


但是这里我们猜想了下，是不是一定限制了"http://"放在参数头部?
访问url

http://x2.sdo.com/handler/ShowHTML.ashx?url=ftp://127.0.0.1/http://


07.png


可以看到，回显的是"无法连接远程服务器"，似乎是绕过成功了..？
换成文件协议试试：

http://x2.sdo.com/handler/ShowHTML.ashx?url=file:///c:/windows/system32/cmd.exe?http://


08.png


路径中有非法字符。 对呀，虽说是绕过了，但是后面的http://怎么办，又不能去掉。
这里曾经想到过很多方法，截断、ascii80-99等，都没用。。
最后成功用以前经典的#号，成功绕过。

09.png


在这里，我们注意了一下绝对路径。

d:\Website\x2\x2\Handler\ShowHtml.ashx


这里有个想法，根据以前的测试经验，或许盛大的所有的官方网站全运行在同一台服务器上，然后再进行分流？
比如这个星辰变2：http://x2.sdo.com/对应绝对路径==>d:\Website\x2\x2\
根据运行规则：http://mxd.sdo.com/是不是对应绝对路径==>d:\Website\mxd\mxd\ ?
尝试访问：

http://x2.sdo.com/handler/ShowHTML.ashx?url=file:///d:\Website\mxd\mxd\web5\home\home.asp%23http://


10.png


成功。
尝试访问：

http://x2.sdo.com/handler/ShowHTML.ashx?url=file:///d:\Website\ff\ff\web6\index\index.html%23http://


11.png


成功。
基本上证明我们的猜测是正确的。
但是现在问题来了：如何获取权限呢？
盛大所有公网生产后台基本上都是走UAM的，且无法通过x-forward和refer等绕过，登录需要动态密保，而且都是站库分离，想了想只有上传了。
上传点在哪儿呢？前台？由于盛大所有活动都有统一上传机制，所以没可能实现，那就只有后台才有可能了。
说道后台，可能是盛大自信自家UAM的原因，/admin 很好找。关键是如何绕过UAM。
还是得进行后台的白盒。
刚访问配置文件，我们就发现了一个亮点：

12.png


fckeditor? 不要这么好吧。。。
但是文件模块有session验证

13.png


看看源码：

14.png


所以思路大致确定了，只要获取带有user的session，即可访问fckeditor的文件模块，再想办法找上传漏洞。
可是在哪找呢？ 只有后台。 后台有UAM登录限制啊。。。且无法绕过。。
或许我们可以找到一些未授权页面然后取得session("user")?
很遗憾。。没有。。
或者我们可以下载全盘文件逐个分析？ 但是无法遍历目录，这个想法也放弃了。
到这里思路似乎断了。
最后我觉得，是否可能存在一些旧版本的后台代码，可能会由于代码不严等问题找到一些突破点？
首先搜集盛大所有游戏的官网。。 然后一个个翻。。。。
终于在一些后台看到了几个亮点。
例如：

d:\Website\1000y\1000y\admin\config.inc.asp
d:\Website\xcb\xcb\admin\config.inc.asp


15.png


16.png


可以看到，部分后台将后台用户名和密码直接定义了出来，而不是进入数据库查询。这就给我们进入后台减少了一道门槛。
再翻，终于在这些直接定义密码的后台中找到了一个有亮点的：

<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>
<%
	NoValidate = True
%>
<!--#include file="config.inc.asp" -->
<!--#include file="UPMconfig.asp" -->
<!--#include virtual="include/UPMInterface.asp" -->
<%	
  IF trim(request.QueryString("Ticket")) = "" THEN
      RedirectUPMLoginUrl
  ELSE
      Ticket = request.QueryString("Ticket")
      SET dummy = ValidateByUserID( Ticket )
      IF SUCCEEDED( dummy.ExecuteStatu ) THEN
          Session( "user" ) = dummy.Data.DomainAccount
          Response.Redirect( "ArenaManage.asp" )
      ELSE
          response.Write dummy.Message 
      END IF
  END IF
	dim check
	
	if request.ServerVariables("REQUEST_METHOD")="POST" then
		
		if request.Form("LoginUser")=PAdminUserName and request.Form("LoginPwd")=PAdminUserPassword then
			session("user")=PAdminUserName
			response.Redirect("news.asp")
			response.end
		else
			alertRedirect "ticket error!",ScriptName
		end if
	end if
	
	
	dim act
	
	act = request.QueryString("act")
	
	select case act
		case "logout"
			session("User")=""
			session("UserType")=""			
	end select
%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
下略...


可以看到，此后台登录是先检查ticket，如果ticket参数为空，则跳转到UAM登录地址(uam.sdo.com)
否则，就校验ticket，然后定义user从uam_callback中域账户取。
然后，第二层绕过来了。
如果ticket为空，则跳转UAM登录地址，那么ticket参数不为空呢?
也就是说，无论ticket是否有效，程序都会向下执行，并不会退出。
然后就到了后台帐户校验块，由于后台帐户信息已在配置文件中定义，我们可以直接拿来登录了。
直接访问，跳转uam

18.png


加ticket，未退出，继续执行。

19.png


登录后台成功。

20.png


由于session(user)已有值，fckeditor文件模块访问成功。

21.png


但由于服务器iis版本为7.5，不能用6.0方法执行解析漏洞。
这里注意到了一个细节，文件模块显示的是修改日期。

22.png


那么我们知道，fckeditor的较新版本都是显示文件大小的，显示修改日期的话，应该是旧版本的fckeditor。
回头一看，果然。

23.png


这样的话，可以通过00截断，成功上传webshell。第三层绕过成功。

24.png


25.png


26.png


转到website目录一看，下线的上线的，一共两百个官网目录。

27.png


随后与盛大安全人员沟通时，他们无法复现，清空cookie后发现我们也无法复现了。这里想到可能启用了负载均衡。这么一想也合理，毕竟日均pv非常大，全挤在一个服务器早炸了。
我们重复上面提权动作重新拿到webshell后查看ip，发现ip由原来的10.**.18.11变成了10.**.18.16

28.png


最后确认，这个段内有十几台均载服务器。
如果我们无限清空cookie，然后一直随机分配均载服务器的话，这十几台服务器全部可以被提权。
但是也是没意义的。因为均载服务器里面内容都一样:-)

漏洞证明：

30.png

修复方案：

·既然这么信任UAM，那么就应该后台所有程序全局include。
·很多后台程序有点老啦，应该升级啦。还有很多网站存在相同漏洞，不再点出，请自行检查。
·前台上传、后台上传全走了统一上传，就fckeditor没走，也是比较醉:-)。

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

漏洞回应

厂商回应：

危害等级：高

漏洞Rank：20

确认时间：2015-05-12 14:28

厂商回复：

感谢关注，欢迎继续关注

最新状态：

2015-05-12：标题太惊悚了。。。本次渗透我们提前知晓，渗透进展也知晓。。。