# 改掉车主的云端账号密码，再绕过二次验证，就能打开连网汽车的车门 **Summary:** Shubham Shah 与 Sam Curry 通过接管车主的云端账号打开了连网汽车的车门：管理后台暴露的管理员凭据、绕过防火墙的请求路径，再加上一条跳过二次验证的登录方式，串起了从车牌号到解锁指令的完整链路。两家车厂未被点名，完整的账号到车辆链路也只用美国的账号和车辆验证过。 - Canonical: https://markhuang.ai/zh/news/connected-car-cloud-account-unlock - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-11-09 - Section: News - Tags: 连网汽车, 网络安全, 账号接管, ForgeRock, 车联网安全 - Source: [Shubham Shah](https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一朵造型如雕塑的云托着黄铜钥匙，停在蓝色 SUV 驾驶座车门旁](https://cdn.markhuang.ai/news/connected-car-cloud-account-unlock/hero.webp) *概念示意图：连网汽车的云端账号可以为车辆上的操作授权。这张图不是研究者的测试现场。* Shubham Shah 和 Sam Curry 给一辆获准测试的车发了一条解锁指令，车门真的开了。他们的突破口不在车上，而在车厂背后的在线账号系统。在 [Shah 2026 年 11 月 7 日的文章](https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/)里，澳大利亚这条链路从一个车牌号开始，最终换来一份登录凭据，而车辆正常的远程控制服务真的认它。 远程解锁这种车主早已习惯的便利，这次靠一次账号接管就到手了。研究者拿到的，正是车主 App 发指令时所用的那份数字权限。所以车门安不安全，有一部分取决于谁能改掉一个在线账号，谁能拿到一份可用的登录凭据。 这里有几条边界得说清楚。两人都写明这是授权测试。厂商没有点名，能做什么也取决于具体车型和服务。[另一份配套报告](https://samcurry.net/forgerock)称，涉及的两家匿名车厂在收到通报后约两小时内修好了所报漏洞，并轮换了受影响的凭据。Shah 这篇讲澳大利亚的文章，没有单独给出修复时间线。 ## 一次查询，把车和车主连了起来 Shah 先从车厂 Android App 背后的服务查起，顺着这条线摸到一个在线管理后台。它对外下发的 JavaScript 里直接带着 API 密钥。研究者称，其中几个 API（软件用来请求数据或发起操作的接口）只要用上这些已经暴露的密钥，就不再需要别的认证。 顺着这些接口，他们能从车辆识别码（VIN）查到对应的订阅用户记录，再查到这个人的邮箱。Shah 说，澳大利亚的车辆登记查询可以用车牌号换到 VIN。VIN 本身有正当用途，比如查一辆二手车的来历。出问题的地方在于：这些在线服务允许别人凭它查到什么。 查到这些，仍然开不了车门。这个管理后台的账号管理功能相当全，但 Shah 明确说，靠它们拿不到远程控制。知道车主是谁，和拿到以车主身份行动的权限，是两件不同的事。 真正把两件事接上的是下一步。另一个 JavaScript 打包文件里存着 ForgeRock OpenIDM 的管理员凭据，这套软件负责管理客户身份。据 Shah 说，本该只用于测试环境的凭据，在生产环境里也能用。 ## 第二条登录路径，绕开了那道额外检查 身份系统前面挡着一道 Web 应用防火墙。这类过滤器会检查进来的请求，把指定流量拦掉。两人确实撞上了障碍，最后才找到一个请求路径的变体，能访问到受保护的账号管理功能。配合手里的管理员凭据，他们就能改掉客户的密码。 App 的多因素认证，本来就是在密码之外多加的一道检查。Shah 说，澳大利亚这套部署还开放了另一条认证路径，直接跳过这道检查。这条路走的是 OAuth 的 Resource Owner Password Credentials 授权方式，之后经过几轮交换，才拿到移动 App 使用的访问 Token。访问 Token 就是服务在 App 后续请求时认可的那份数字凭据。 这是一次部署层面的失误，后果很具体：改完账号密码，不用走 App 正常的二次验证流程就能拿到 Token，再拿它发出解锁指令。 [RFC 9700 里的 OAuth 安全指南](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.4)写明，密码凭据授权“不得使用”（MUST NOT），并解释它本来就不是为双因素认证、或涉及多轮用户交互的认证设计的。这也解释了，为什么登录页上那道让人安心的检查，不能用来断定通往 App Token 的每条路径都安全。 按 Shah 的报告简化一下，澳大利亚这条链路是这样的： ```mermaid flowchart TD A["车牌号与 VIN 查询"] --> B["暴露的 API 查出关联的客户账号"] C["暴露的管理员凭据加上防火墙绕过"] --> D["替换账号密码"] B --> D D --> E["另一条登录路径跳过额外的认证检查"] E --> F["取得移动 App 的访问 Token"] F --> G["通过正常的远程服务发送解锁指令"] ``` ## “任何一辆车”漏掉了什么 Shah 的标题说得很大，他文末点明的范围却是澳大利亚、美国、加拿大。配套报告在证据上写得更细：研究者访问过多个区域的生产身份目录，但完整的“账号到车辆”链路，只用美国的账号和车辆测过。报告还提到，哪些远程功能可用，取决于车型和订阅。 我的理解是，这证明受影响的连网服务存在严重缺陷，但不能说明两家车厂卖过的每一辆车都能被打开。[Hacker News 的讨论](https://news.ycombinator.com/item?id=50419215)里就有人质疑，“任何一辆车”用在老车上是否成立。这个区分配套报告里本来就写了，它把范围限定在连网服务上。评论区对车厂身份的猜测，提供不了任何验证。 已经演示的结果也有边界。配套报告描述的是车主站在车旁的实地确认：解锁、启动发动机，再熄火、落锁。这些报告没有演示对转向或刹车的控制，也没有说明车可以被开走。 ## 账号该放进车辆的安全评估里 2024 年 9 月，[WIRED 报道过另一桩 Kia 网页门户的漏洞](https://www.wired.com/story/kia-web-vulnerability-vehicle-hack-track/)，研究者能借此重新分配连网汽车功能的访问权限，WIRED 现场看过演示。那桩旧事能给这类漏洞提供背景，却指认不出这次报告里匿名的车厂。 如果让我向连网服务提供方提一个问题，那就是：改账号、发 App Token 的每一种方式，是不是都落实了本该有的防护？只看 App 正常的登录流程，就会漏掉 Shah 描述的这条澳大利亚路径。他们能成功，是因为管理后台、身份管理和认证环节同时出了问题。 对车主来说，厂商匿名、车型清单缺失，这些限制了任何针对具体车型的建议。一个在线账号就可能握着打开车门的权限。做安全评估时，除了看那个显示解锁按钮的 App，还得查清楚谁能改这个账号、谁能签发它的登录 Token。