游戏文件夹内launcher_profiles.json内accessToken为明文储存，可以通过token上号器登录

[cucumbertw]

检查项

• [X] 我已在 Issues 页面 和 常见&难检反馈及问题列表 中搜索，确认了这一 Bug 未被提交过。

描述

游戏文件夹内launcher_profiles.json内accessToken为明文储存，可以通过token上号器登录

重现步骤

1 .minecraft文件夹 2.launcher_profiles.json

日志与附件

游戏文件夹内launcher_profiles.json内accessToken为明文储存，可以通过token上号器登录

[JingHai-Lingyun]

按照 Wiki 中的记载 在 launcher_profiles.json 中不应当（用于）存储账户相关信息 截至本信息最后一次 Edit 时：本人仅发现 PCL 会有此行为

[cucumbertw]

[WorldHim]

已确认 HMCL、BakaXL 不存在该行为 附 Wiki 说明： https://zh.minecraft.wiki/w/Launcher_profiles.json

[Hi-Kite]

已确认 HMCL、BakaXL 不存在该行为 附 Wiki 说明： https://zh.minecraft.wiki/w/Launcher_profiles.json

你好，据我观察，HMCL默认（除非转为“便携账户”会存储在HMCL同目录的配置文件中）会将用户信息明文存储在C:\Users\你的用户名\AppData\Roaming\.hmcl中的accounts.json文件，虽然不是在游戏文件夹内。BakaXL未观察。

[allMagicNB]

这不应该交 Security 里吗？（

[JingHai-Lingyun]

肯定会有一种形式在本地缓存。但是 PCL 直接存储在客户端目录下容易在打包（HMCL 制作整合包/直接压缩 .minecraft 文件夹）的时候被带出去，造成账户泄露

[RimacC2-EV]

不能存储在程序本体里，开启PCL2之后直接加载账号信息到内存里吗

[sulingjiang]

不能存储在程序本体里，开启PCL2之后直接加载账号信息到内存里吗

估计写完就变成无效程序了

[pnpn111]

不能存储在程序本体里，开启PCL2之后直接加载账号信息到内存里吗

这样似乎无法解决

但是 PCL 直接存储在客户端目录下容易在打包（HMCL 制作整合包/直接压缩 .minecraft 文件夹）的时候被带出去，造成账户泄露

的问题。（因为你打包也带着启动器的嘛）

所以最简单的解决方案就是像别家的一样存在别处。

在某些情况下（例如不同文件夹不同配置/账号？）似乎也可以用Windows API中的加密函数System.Security.Cryptography.ProtectedData加密后再存在文件夹路径内。

补充： 如果想要更安全的话，可以将encrypt过后的识别码的部分内容作为optionalEntropy，这样只要PCL2自身不被反编译，那么别的程序就没机会解密内容了。

[RimacC2-EV]

~不能存储在程序本体里，开启PCL2之后直接加载账号信息到内存里吗~

这样似乎无法解决

但是 PCL 直接存储在客户端目录下容易在打包（HMCL 制作整合包/直接压缩 .minecraft 文件夹）的时候被带出去，造成账户泄露

的问题。（因为你打包也带着启动器的嘛）

所以最简单的解决方案就是像别家的一样存在别处。

在某些情况下（例如不同文件夹不同配置/账号？）似乎也可以用Windows API中的加密函数System.Security.Cryptography.ProtectedData加密后再存在文件夹路径内。

可以绑定识别码

[pnpn111]

~不能存储在程序本体里，开启PCL2之后直接加载账号信息到内存里吗~

这样似乎无法解决

但是 PCL 直接存储在客户端目录下容易在打包（HMCL 制作整合包/直接压缩 .minecraft 文件夹）的时候被带出去，造成账户泄露

的问题。（因为你打包也带着启动器的嘛）

所以最简单的解决方案就是像别家的一样存在别处。

在某些情况下（例如不同文件夹不同配置/账号？）似乎也可以用Windows API中的加密函数System.Security.Cryptography.ProtectedData加密后再存在文件夹路径内。

可以绑定识别码

System.Security.Cryptography.ProtectedData可能更好一些，可以绑定到用户。识别码的话不同用户应该也一样的吧？

[Pigeon0v0]

BakaXL 会把账户档案设备端加密存储在 %appdata%\BakaXL\Profiles 文件夹下

[Silverteal]

……这问题竟然才有人发现 目前已经存在“安全地”保存token的方法。launcher_profiles.json中的应该是遗留的问题。

[pnpn111]

System.Security.Cryptography.ProtectedData可能更好一些，可以绑定到用户。识别码的话不同用户应该也一样的吧？

不同电脑上的 PCL 识别码一定不相同，调用 ModSecret 中的 Friend Function SecretEncrypt(SourceString As String, Optional Key As String = "") As String 时，往 Key 参数传入 PCL 识别码，即可保证 只有这台电脑 可以通过相同的识别码解密密文。

我说的是同电脑不同用户，不是不同电脑呀

[Silverteal]

区分电脑不同用户账户在大部分场景下没有意义，且System.Security.Cryptography.ProtectedData依赖于一个（至少对我而言）很陌生且几乎不可移植的操作系统接口。我认为它不太可能被考虑。

[pnpn111]

区分电脑不同用户账户在大部分场景下没有意义，且System.Security.Cryptography.ProtectedData依赖于一个（至少对我而言）很陌生且几乎不可移植的操作系统接口。我认为它不太可能被考虑。

但确实会比识别码更符合要求，毕竟在一些情况下确实应该区分用户。在不需要区分用户的情况下按照用户级别保护也没啥问题。

使用的DPAPI实际上浏览器也在用，chromium内核浏览器大多都使用该API加密保存的密码。（不排除有浏览器额外修改，但至少chrome，edge都用）

而且这个类在net framework 2.0就有了，除非龙猫打算做非Windows版本，否则单这个API应该不会有什么问题

[Silverteal]

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N Severity: Moderate 5.6 Related CWE: CWE-522: Insufficiently Protected Credentials CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory

[LTCatt]

我记得之前是有个啥玩意儿需要这个信息才能跑的，PCL 实际的存储是加密存注册表的，我把这个文件里的直接删了就行

[RimacC2-EV]

System.Security.Cryptography.ProtectedData可能更好一些，可以绑定到用户。识别码的话不同用户应该也一样的吧？

不同电脑上的 PCL 识别码一定不相同，调用 ModSecret 中的 Friend Function SecretEncrypt(SourceString As String, Optional Key As String = "") As String 时，往 Key 参数传入 PCL 识别码，即可保证 只有这台电脑 可以通过相同的识别码解密密文。

我说的是同电脑不同用户，不是不同电脑呀

可以根据不同用户切换配置文件 实在不行就给PCL2搞个多用户功能罢（喜

[LTCatt]

这并不是严格意义上的 Security Vulnerability，因为实施所谓“攻击”的前提是 黑客已经可以访问电脑上的文件了，那么这个情况下攻击者把你电脑所有 cookie 刮走都 OK 了…… 启动器在导出整合包时也理应排除 launcher_profiles.json，所以唯一可能的泄露就是：玩家没有用启动器的导出功能，而是自行把游戏版本打了个压缩包，并且没有清理不必要的文件，还把它传给了不受信任的第三方。 实际上这个情况远比之前启动器 log 里包含 Access Token 的问题还要罕见。 总之，下个版本会修的，但没必要丢个 Security Vulnerability 评级夸大威胁 =。=

[LTCatt]

如果确实图一乐，想要一个评级的话……

若是假设攻击者可以通过访问电脑上的这个文件来获得 Access Token，那攻击者都已经可以访问文件系统了，没有讨论价值了……（这种情况下评漏洞分级，也是应该评导致攻击者能访问文件的漏洞吧……）

若是假定攻击者诱骗用户把他的 MC 客户端打包传给他，这个情况下 CVSS 评估是：

---

Attack vector: Local。这个没问题。 Attack Complexity: High，攻击者不能确保可重复的成功。楼上错误评估成了 Low。 Privileges Required: None，诱骗并不需要任何对系统的权限。楼上错误评估成了 Low。 User Interaction: Required。这当然需要用户交互，文件不会自己跑到攻击者手上。楼上错误评估成了不需要。 Scope: Unchanged，只影响了 MC，范围并未扩大。楼上错误评估成了扩大。 Confidentiality: Low。楼上错误评估成了 High，但 High 实际代表所有密钥的丢失。 Integrity: None，这个指标描述的是能否修改数据，这个情况下啥都不能改。没问题。 Availability: None。没问题。

---

结论上……严重程度为低 (2.5)，远低于楼上的中等 (6.5)。

Severity: Low (2.5) CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N

[Silverteal]

咱没人实际用过CVSS，所以不用太认真，我也没交Security Vulnerability。CVSS的这种表达形式也没几个人看得懂，不太会造成什么“恐慌”之类的。

稍微认真点扯的话

社交工程学手段应该不算在漏洞中。 攻击复杂度是High而非Low，这个确实，昨晚睡迷糊了。 特权Low至少是需要的，攻击者至少需要获取相关文件夹的读取权限，像Guest一样完全没有权限是啥也干不了的。 用户交互方面，获取读取权限后，就不需要任何用户交互了。 Scope应该还是Changed，因为受影响的组件是Minecraft账号，而脆弱的组件是计算机应用程序/启动器。 Confidentiality 选择为 High 参考了 FIRST介绍文章的这一段

把上面的攻击复杂度从Low改成High的话，就是5.6分

社交工程学手段应该不算在漏洞中。但是因为实施所谓“攻击”的前提是 黑客已经可以访问电脑上的文件了，那么这个情况下攻击者把你电脑所有 cookie 刮走都 OK 了……这个表态的合理性我是存疑的。首先不说，Cookie在本地存储是加密的，导致盗取Cookie并没有“那么”容易。其次，并不是说能单独导致利用的才算漏洞，和其他漏洞组合起来能造成/加大数据保密性、完整性和服务可用性造成损失的，就可以算漏洞，就这一点而言，应该不存在夸大。有些漏洞专精“渗透”，而另一些是“渗透”之后的“泄密”，组合起来才会导致严重的利用，不能因为“要渗透后才能泄密”就认为“泄密”的漏洞就不是漏洞。侧重点不同的漏洞使用同一套CVSS评估系统，每个单独漏洞的评分不一定高。同样，CVSS分数高的漏洞，也可能因为难以形成有效的利用链，或者环境中经常存在威胁更大的漏洞而没有那么大的威胁，因此，CVSS威胁分数的高低，并不直接代表威胁的高低，所以CVSS评分可以图一乐，这没关系。

至于存在Log里面，那几天我没看Github，等我看到的时候已经修好了。所以我也不好再说什么。

[wuliaodexiaoluo]

Cookie在本地存储是加密的

抵不住 Google 直接把密码和加密密钥明文保存在文件里面，还特别好找.....

[LTCatt]

我会郑重指出来是因为 Minecraft 社区对于 “漏洞” 过度敏感，有很多人会盯着这些事情博流量，而 MC 的主要玩家群体又不懂这些，所以说啥信啥，这使得这些 “小道消息” 传播地异常快，很快就被传得乱七八糟。 就像爱发电，才半天就已经被传得洗钱进局子了，而消息源却是八竿子打不着的 2023/1 的一个网站包含黄色内容的处罚信息……

所以至少我个人非常不建议在公开场合讨论这些，很容易被断章取义然后一觉睡醒你都猜不到传成啥样了……

---

技术上，CVSS 确实纯图一乐。 Silverteal 的引文中的 Any system that stores login credentials 我觉得应该理解成 “储存了登录凭据的系统”，也就是说 “包含了登录凭据的 Windows 系统遭到了入侵，就应该评为 High”，而不是 “任何登录凭据丢了就是 High”，这样理解和字段定义中的 Some loss 是冲突的（既然丢了任何凭据都该是 High，那 “Some loss 评定 Low” 就没意义了）。 不过 Confidentiality 选 Low 就是 2.7，选 High 就是 5.5，这能直接差出一倍，评定还很主观，就真图一乐。

[Silverteal]

理解理解，哎……

[allMagicNB]

于 https://github.com/Hex-Dragon/PCL2/blob/main/Plain%20Craft%20Launcher%202%2FModules%2FMinecraft%2FModLaunch.vb#L1778-L1843

[cucumbertw]

7C6D-06E5-5489-043A谢谢

[LTCatt]

你的解锁码：urYx6LWXVO24sP6hM91R2EtVTLrw5lB0 在 更多 → 关于与鸣谢 → 输入解锁码 中使用，谢谢支持～