一、概述
在过去的几周中，Check Point Research与CyberInt共同确认了一系列漏洞，这些漏洞一旦被攻击者利用，可能会导致全球第二大游戏公司EA Games的数百万玩家帐户被接管。同时，这些漏洞可能还会导致攻击者非法获取用户的信用卡信息，也可能导致攻击者以用户的身份购买游戏。
CyberInt和Check Point在第一时间将这些安全漏洞通知EA Games，同时利用我们的专业能力帮助EA修复这些漏洞，以保护其游戏玩家的利益。
二、关于Origin：EA游戏平台
EA Games拥有超过3亿客户，公司市值目前在50亿美元左右，是全球第二大游戏公司，拥有一系列家庭游戏，例如FIFA、Maden NFL、NBA Live、UFC、The Sims、Battlefield、Command and Conquer、Medal of Honor等。所有这些游戏都依赖于其自行开发的Origin游戏平台，该平台允许用户在计算机和移动设备上购买EA游戏并运行。
除了游戏功能之外，Origin还包含社交功能，例如个人资料管理、与朋友联网聊天或直接加入游戏、与Facebook、Xbox Live、PlayStation Network、Nintendo Network等网络站点的社区集成。
三、漏洞发现过程
与Check Point Research团队之前在另一个非常流行的游戏平台Fornite上发现的漏洞类似，在EA平台上发现的漏洞不需要用户提交任何详细信息。相反，该漏洞利用了EA Games将身份验证令牌与EA Games用户登录过程中内置的oAuth单点登录（SSO）和TRUST机制结合使用的弱点。
我们发现，EA Games大量使用了云平台，该公司在Microsoft Azure托管多个域名，包括ea.com和origin.com，以便为其遍布全球的玩家提供各种服务，例如创建新的游戏帐户、连接进入Origin社交网络、在EA的在线商店中购买更多游戏等。
视频：EA Games漏洞导致帐号泄露和身份信息窃取
四、技术细节
4.1 eaplayinvite.ea.com子域名劫持
EA Games运营多个域名，包括ea.com和origin.com，以便为其遍布全球的玩家提供各种服务，包括创建新的Apex Legend帐户、连接到Origin社交网络、在EA的在线商店购买新的游戏等。
通常，像EA Games这样依赖于云服务的公司所提供的每项服务，都会在一个唯一的子域名地址上注册，例如eaplayinvite.ea.com，并且具有指向特定云服务商主机的DNS指针（A记录或CNAME记录）。在我们的示例中，ea-invite-reg.azurewebsites.net是一个Web应用程序服务器，会在后台运行所需的服务。
eaplayinvite.ea.com的DNS指针指向CNAME记录，即ea-invite-reg.azurewebsites.net：
Azure是由Microsoft提供支持的云服务提供商解决方案，允许公司注册新的服务（例如：Web应用程序、REST API、虚拟机、数据库等），以便向全球的在线客户提供这些服务。
每个Azure用户帐户都可以请求注册特定服务名称（服务名称.azurewebsites.net），该名称将在Azure子域名验证过程中验证其CNAME记录，并连接到组织特定的域名或子域名。
然而，根据CyberInt进行的研究，他们发现ea-invite-reg.azurewebsites.net服务在Azure云服务中不再使用，但唯一的子域名eaplayinvite.ea.com仍然使用CNAME配置重定向到该域名。
eaplayinvite.ea.com的CNAME重定向允许我们在自己的Azure帐户中创建新的成功注册请求，并将ea-invite-reg.azurewebsites.net注册为我们新的Web应用程序服务。这样一来，我们基本上就劫持了eaplayinvite.ea.com的子域名，并且能够监控EA合法用户的请求。
将“eaplayinvite.ea.com”的CNAME重定向更改为我们自己的Azure帐户中托管的“ea-invite-reg.azurewebsites.net”：
如下图所示，在劫持之后的DNS记录状态显示，eaplayinvite.ea.com已经重定向到我们的新Azure云Web服务：
4.2 oAuth无效重定向导致帐户接管
在控制了eaplayinvite.ea.com子域名之后，我们的团队找到了一个新的目标，即研究如何滥用TRUST机制。TRUST机制存在于ea.com和Origin.com域名及其子域名之间。如果能成功滥用该机制，那么我们就能够操纵oAuth协议的实施方式，并利用该漏洞实现完全的帐户接管。
我们首先需要确定EA Games是如何配置oAuth协议并为其用户提供单点登录（SSO）机制。SSO机制通过唯一的SSO令牌（SSO Token）交换用户凭据（用户名和密码），然后使用该令牌对EA网络的任何平台（例如：accounts.origin.com）进行身份验证，而无需再次输入其凭据。
在分析EA Games的oAuth SSO在几个EA服务（例如：answers.ea.com、help.ea.com、accounts.ea.com）中具体实现的过程中，我们对EA的身份验证流程进行了研究，并掌握了有关目前实施的TURST机制的更多信息。
作为使用EA全局服务通过answers.ea.com成功进行身份验证过程的一部分，oAuth HTTP请求将发送到accounts.ea.com以获取新的用户SSO令牌，然后应用程序应通过signin.ea.com将其重定向到名为answers.ea.com的最终EA服务以识别用户。
使用answers.ea.com进行身份验证的oAuth SSO请求：
oAuth身份验证SSO令牌通过signin.ea.com重定向到EA的answers.ea.com服务器：
但是，我们发现，实际上可以通过修改被我们劫持的EA子域名eaplayinvite.ea.com的HTTP请求中的returnURI参数，来确定生成oAuth令牌的EA服务地址。
oAuth请求为eaplayinvite.ea.com生成新的用户令牌：
服务器生成有效令牌，而不会验证假的EA服务：
但是，由于EA的服务器端还具有一些限制，所以仅仅生成上述请求，将生成的SSO令牌重定向到我们这边还并不足够。
下面，我们将分析EA引入的限制，并逐一说明我们如何成功绕过这些限制，从而使我们的攻击过程武器化。
五、突破EA最后的防线
5.1 限制1：缺少有效的引用
为了攻陷EA帐户，研究团队需要将上文提到的请求发送到accounts.ea.com，其中也包括修改后的参数，该参数将伪装成受害用户的身份。
但是，accounts.ea.com的后端服务器会通过检查HTTP Referer头部的方式来验证请求是否最初是来自受信任的Origin域名。
为了突破此限制，我们需要以受害用户的身份，从EA受信任的域名或子域名发出请求。因此，我们将新的iframe编码到被我们劫持的子域名的索引页面上，以便从iframe启动请求，并绕过服务器验证。
eaplayinvite.ea.com恶意索引页面：
攻击者在eaplayinvite.ea.com上生成iframe以绕过HTTP Referer验证：
5.2 限制2：请求来源问题
在我们向signin.ea.com发送请求以完成恶意身份验证过程，并将受害者的令牌发送到eaplayinvite.ea.com上的被劫持子域名后，会生成一个新的jQuery函数，并返回至客户端以重定向令牌。
但是，由于目标服务器（eaplayinvite.ea.com）不是当前Origin（signin.ea.com）的组成部分，因此jQuery $.postMessage函数此时将无法执行。因此，该函数将向浏览器控制台发送错误，并停止向我们发送令牌。
为了解决这个问题，我们必须要在signin.ea.com上寻找一个新的令牌重定向的方式，因为jQuery函数阻止它们将受害用户的令牌作为恶意流量的一部分传输出去。
经过多次尝试，我们终于捕获了一个包含redirectback参数的signin.ea.com的不同请求。该参数将指示服务器使用returnuri值，并直接将页面重定向到该页面，而不将受害者的访问令牌附加到其上。
发送redirectback参数，以绕过jQuery来源问题：
服务器通过简单的重定向到目标服务器来进行响应：
此时，我们设法将经过身份验证的EA玩家重定向到我们的服务器。我们在访问oAuth SSO身份验证的iframe之后就可以执行此项操作，所以也就能够在我们的服务器中记录传入的请求。
由于使用我们的恶意iframe通过severaloAuth SSO URL对玩家进行了重定向，所以现在令牌就会被发送到HTTP Referer标头中体现的服务器上。signin.ea.com上最后一次重定向使用window.location JavaScript函数将玩家重定向到我们的服务器。它包含玩家的SSO令牌，并允许我们对其进行控制。
记录传入的Referer值，并搜索受害用户的Access-Token：
使用受害用户oAuth SSO令牌登录攻击者的PC：
还没有评论，来说两句吧...