https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/
这篇文章挺有意思，而且是一个非常典型的汽车联网平台被攻破的案例。
它不是传统意义上的汽车硬件破解，也不是通过蓝牙、车钥匙信号复制来开车门，而是从一个非常普通的入口开始：
研究人员通过汽车 App 的 API 和后台身份认证系统，最终获得了远程控制大量真实车辆的能力。
更值得关注的是，这不是单个漏洞，而是一条由多个安全缺陷串联起来的完整攻击链。即使其中某些漏洞单独看起来影响不大，组合起来却可以直接威胁车主的人身和财产安全。
文章作者是 Assetnote 联合创始人 Shubs，与安全研究员 Sam Curry 合作完成，发表于 2026 年 11 月 7 日。
一、他们究竟攻破了什么？
先看最终成果：
- 仅知道汽车的车牌号，就可以逐步找到对应车主的联网汽车账户。
- 可以绕过账户的多因素认证（MFA）。
- 可以伪造车主的 App 登录身份。
- 可以调用汽车厂商的远程控制 API。
- 最终实现远程解锁车门，甚至启动发动机等操作。
作者明确表示，测试只针对自己拥有或获得授权的车辆。
这里有一个容易误解的地方：他们并没有攻破汽车本身的 ECU、CAN 总线或者无线钥匙系统。
他们攻破的是汽车厂商的云端联网服务（Connected Car Platform）。
整个架构可以简单理解为：
手机 App（车主登录、远程控制）
|
v
身份认证系统（OpenIDM / OpenAM / OAuth / MFA）
|
v
汽车厂商 API（REST / GraphQL / 远程指令）
|
v
汽车 T-Box / 车联网模块（接收远程指令，执行开锁等操作）只要云端能够代表车主发送合法指令，那么攻破云端身份认证，就可能获得汽车控制权。
这也是这篇文章最值得注意的地方：汽车已经不只是一个机械和电子设备，它同时也是一个连接互联网的云端服务终端。
二、攻击过程：六个关键步骤
1. 反编译 Android App，寻找后台 API
研究人员首先下载汽车厂商的 Android APK，然后反编译。
他们从代码中找到了大量后台域名，例如：
api.redacted-telematics.com.au
admintool.redacted-telematics.com.au
login.redacted-identity.com.au这一步其实并不复杂。
Android APK 本质上是一个可以被分析的应用包，里面包含：
- API 地址
- 请求参数
- 部分客户端配置
- API Key
- 业务接口调用逻辑
即使 App 本身经过混淆，很多运行时使用的接口信息仍然可以被研究人员还原。
这里第一个安全问题就出现了：客户端代码里包含了本不应该暴露的后台管理凭证。
2. 发现暴露在公网的 Admin Tool
严重安全问题
研究人员发现了一个公开可访问的管理工具：
admintool.redacted-telematics.com.au它原本应该是供汽车厂商内部员工使用的工具。
通过分析它的 JavaScript Bundle，研究人员发现了大量管理 API，而且部分 API 只需要 JavaScript 中硬编码的 API Key 就能调用。
这意味着：
- 可以根据邮箱查询用户。
- 可以根据 VIN 查询对应用户。
- 可以获取用户账户信息。
- 可以把自己添加为用户的二级账户。
- 可以生成远程访问码。
这里有两个值得区分的问题：
第一，管理后台暴露在公网。
公网可访问不必然意味着存在漏洞，但内部管理系统如果没有严格认证和访问控制，就非常危险。
第二，前端 JavaScript 中包含管理凭证。
这属于典型的凭证泄露问题。
前端代码默认是公开的，任何用户都可以下载和分析，不能把前端硬编码的 Key 当作秘密。
3. 通过车牌号找到车主账户
这是攻击链中很巧妙的一环。
在澳大利亚，研究人员可以利用公开的车辆登记查询服务，从车牌号获得 VIN。
VIN 是 Vehicle Identification Number，也就是车辆识别代码，通常为 17 位。
随后，他们利用汽车厂商后台 API，完成了这样的关联：
车牌号（Number Plate）
|
v
VIN
|
v
Subscriber GUID
|
v
车主账户、邮箱等个人信息这里需要注意：
VIN 本身不是秘密信息，车辆识别码在很多国家都存在合法查询渠道。
真正的问题是，厂商后台居然允许通过 VIN 找到对应的 Subscriber GUID，进而查询用户个人信息。
这涉及一个非常重要的安全概念：IDOR（Insecure Direct Object Reference，不安全的直接对象引用）以及对象级授权缺失。
假设一个 API 是：
GET /v1/vehicle/{VIN}/subscriber如果服务端只检查调用者是否拥有一个有效 API Key，却不检查调用者是否有权查询这辆车，就可能出现越权访问。
当然，文章并没有把每个接口都简单归类为 IDOR。核心问题是接口缺少足够的对象级访问控制。
4. 找到 ForgeRock 身份认证系统的管理员凭证
攻击链的关键突破口
这里开始进入真正危险的部分。
厂商使用了 ForgeRock 管理用户身份认证。
涉及两个核心组件：
| 组件 | 主要作用 |
|---|---|
| OpenAM | 身份认证、登录流程、SSO |
| OpenIDM | 用户身份数据管理、账户管理 |
研究人员在前面发现的 JavaScript Bundle 中，找到了一组 OpenIDM 管理员凭证。
更糟糕的是：
这些凭证原本属于 Staging 测试环境，但竟然在生产环境也能使用。
这暴露出几个问题：
- 管理员凭证被写入客户端代码。
- 测试环境和生产环境的凭证隔离不充分。
- 生产环境的管理接口暴露在公网。
这几个问题叠加，意味着研究人员已经拿到了生产环境的管理员身份。
不过，他们还遇到了一道阻碍：WAF。
5. 绕过 WAF，直接操作 OpenIDM
厂商并不是完全没有安全防护。
他们在 Nginx 前面部署了 WAF，对 /openidm/ 等敏感路径进行拦截。
直接访问：
/openidm/managed/user会返回 403。
研究人员发现，问题出在不同组件对 URL 的解析方式不一致。
这涉及一个经典漏洞类别：
Path Traversal + URL Normalization / Parser Differential。
简单说：
同一个 URL，可能被不同层以不同方式理解。
例如：
- WAF 看到的是一个看似普通的静态资源路径。
- Web Server 对 URL 进行解码和规范化。
- 后端 Servlet 又进行一次路径解析。
- 最终请求实际进入了本来应该被禁止的管理接口。
这就是所谓的 WAF Bypass。
值得注意的是，作者专门研究了 ForgeRock、Jetty 和相关路由实现，最终找到了能够通过前端过滤、又能被后端正确识别的路径形式。
这里不是 WAF 本身失效那么简单，而是安全设备和后端应用对请求的解释不一致。
这类问题在 Web 安全领域非常值得重视。
6. 修改用户密码，绕过 MFA，获得汽车控制权
最终影响：远程控制车辆
拿到 OpenIDM 管理权限后，研究人员可以修改任意用户的密码。
但还有一个问题：MFA。
正常情况下，即使攻击者知道用户密码，还需要通过手机验证码等第二因素验证。
然而，厂商的澳大利亚环境还存在一个认证配置问题。
他们使用了 OAuth 的 ROPC（Resource Owner Password Credentials）授权模式。
这种模式允许客户端直接使用用户名和密码获取 Token。
它本身并不是 MFA 绕过漏洞，但如果认证服务器错误地允许这条授权流程跳过原本必须执行的 MFA，就会产生严重问题。
于是整个过程变成：
- 修改目标车主密码。
- 使用 ROPC 流程获取身份 Token。
- 利用 Token 换取 App 所需的认证 Session。
- 再通过 OAuth Authorization Code + PKCE 流程获取移动 App 的 Access Token。
- 使用这个 Token 调用车辆控制 API。
最后调用的就是厂商的远程控制接口。
POST /v1/remote/route/command
Authorization: Bearer <app_access_token>
{
"command": "door-unlock"
}汽车解锁成功。
这里最重要的技术细节是：
攻击者不需要破解汽车的密码，也不需要伪造汽车钥匙。他们让厂商的云端系统相信，自己就是合法车主。
三、这实际上是一条什么样的漏洞链？
把上面过程放在一起，就能看出问题的严重程度。
完整攻击链
- 客户端信息泄露：反编译 APK，发现后台 API、管理凭证
- 管理后台暴露：调用管理 API，查询车辆与用户信息
- 身份关联：车牌 → VIN → 用户 GUID → 车主账户
- 管理员权限泄露：获得生产环境 OpenIDM 管理员凭证
- WAF 绕过：利用 URL 解析差异访问敏感接口
- 账户接管：修改任意车主密码，绕过 MFA
- Token 伪造 / 获取：获得合法的汽车 App Access Token
- 车辆远程控制（最终影响）：解锁车门、发动机启动等远程操作
这也解释了为什么不能只看单个漏洞的严重程度。
例如：
- 一个前端 API Key 泄露，可能被认为是中低危。
- 一个 WAF 路径绕过，可能被认为只是防护绕过。
- 一个 ROPC 配置问题，也可能被认为是认证策略问题。
但把它们串起来，最终就能从一个公开的车牌号获得车辆控制权。
安全漏洞的实际风险，往往取决于攻击链的最终能力，而不是某一个漏洞的 CVSS 分数。
四、还有一个更严重的版本：不仅仅是汽车解锁
如果只看 Shubs 的文章，可能会以为这只是澳大利亚某个汽车品牌的后台配置问题。
但实际上，两位研究人员还有一篇联合技术报告：
Hacking Two Automakers: ForgeRock Path Confusion, RCE, and Remote Vehicle Access
这篇报告揭示了更严重的情况。
1. 涉及两家汽车制造商
研究人员发现，两家汽车厂商使用的 ForgeRock 身份认证基础设施存在相似的安全问题。
厂商名称没有公开披露。
而且不是只有澳大利亚环境受到影响，相关生产身份系统服务多个地区的用户。
2. 他们甚至获得了生产服务器的 RCE
RCE = Remote Code Execution，远程代码执行。
这比普通的 API 越权严重得多。
研究人员利用 ForgeRock 的路径解析问题，进入了 Apache Felix Web Console。
这里有一个非常有意思的技术细节：
- ForgeRock 使用 OSGi 架构。
- Apache Felix 是 OSGi 的运行时实现。
- Felix 提供 Web Console 管理界面。
- 管理界面支持 ConfigMgr 配置。
- OpenIDM Scheduler 可以执行 Groovy 脚本。
- 研究人员最终通过这条路径，在生产身份认证服务器上执行代码。
也就是说，他们不再只是通过某个 API 查询用户，而是获得了生产服务器内部的代码执行能力。
这意味着攻击者可以进一步访问服务器进程权限范围内的数据和服务。
3. 影响范围比单纯开锁大得多
研究人员拿到的权限不仅可以控制汽车，还可以获取：
- 车主账户信息。
- 车辆 VIN。
- 车辆实时位置。
- 车辆遥测数据。
- 车辆状态信息。
- 远程解锁和发动机启动等能力。
甚至还有一个很容易被忽略的细节：
他们能够修改车主的邮箱，并将 App 的推送通知注册到自己控制的设备上。
这意味着，攻击者不仅可能获得车辆控制权，还可能干扰车主对账户异常的感知。
4. 厂商修复速度倒是很快
约 2 小时完成修复
根据 Sam Curry 的披露时间线：
- 2026 年初：研究人员验证漏洞并联系厂商。
- 厂商安全团队收到报告。
- 当天：两家厂商在约两小时内完成修复。
- 移除用于验证的代码，并轮换受影响的凭证。
需要注意，报告称他们在美国账户和车辆上验证了完整攻击链；澳大利亚文章则展示了另一条针对澳大利亚环境的攻击路径。不能简单地把所有地区都理解成使用完全相同的漏洞链。
五、从技术角度看，哪些地方最值得学习？
1. 前端 API Key 不等于安全凭证
这是最基础、但也是最常见的错误。
很多开发者会在前端代码中写：
const API_KEY = "xxxxxxxx";然后认为：
只要不是放在 HTML 里面，或者经过了代码混淆，就不容易被发现。
实际上，前端代码中的所有内容都应该视为公开信息。
需要区分两种 Key：
| 类型 | 是否可以暴露 |
|---|---|
| 客户端公开标识、Public API Key | 可以，但必须限制权限 |
| 后端管理员凭证、数据库密码、Secret Key | 绝对不可以 |
即使某个 Key 的设计目的是客户端使用，也必须在服务端做好权限约束。
2. 测试环境和生产环境必须彻底隔离
这篇文章最离谱的地方之一，就是 Staging 环境的管理员凭证可以用于生产环境。
这在企业系统中是一个非常危险的问题。
我会建议：
- 测试、预发布、生产使用不同的身份认证实例。
- 使用不同的管理员账户。
- 使用不同的密钥和数据库。
- 不允许测试凭证在生产环境生效。
- 定期轮换管理员凭证。
- 使用 Secret Manager 管理敏感信息。
尤其是多租户 SaaS，不能因为开发方便，就让测试环境和生产环境共用管理员账户。
3. WAF 不能代替应用层权限控制
这个案例很好地说明了 WAF 的局限性。
WAF 能做什么？
- 拦截恶意请求。
- 过滤常见攻击模式。
- 检测 SQL Injection。
- 检测 XSS。
- 限制某些敏感路径。
但 WAF 不应该成为后台 API 的最后一道权限防线。
如果一个管理接口本身缺少认证、授权，或者存在管理员凭证泄露，那么 WAF 就算部署得再复杂，也可能被绕过。
更合理的设计是：
纵深防御（Defense in Depth）
- 网络层：管理接口不直接暴露公网
- 网关层：WAF、IP 白名单、请求限制
- 身份层：强认证、MFA、短期 Token
- 授权层：RBAC、ABAC、对象级权限校验
- 数据层：敏感数据隔离、最小权限
- 审计层：操作日志、异常行为检测、告警
每一层都应该有独立的安全价值，而不是把所有安全责任交给 WAF。
4. OAuth 的认证流程不等于业务授权
这是我认为最值得仔细理解的部分。
文章中涉及：
- OAuth 2.0
- OpenID Connect（OIDC）
- Authorization Code Flow
- PKCE
- ROPC
- Access Token
- Refresh Token
- MFA
这些东西经常被混在一起讨论，但它们解决的问题并不一样。
| 技术 | 主要解决的问题 |
|---|---|
| OAuth 2.0 | 授权访问资源 |
| OIDC | 在 OAuth 基础上提供身份认证 |
| MFA | 增加身份验证因素 |
| PKCE | 保护授权码交换过程 |
| Access Token | 携带访问授权 |
| Refresh Token | 获取新的访问令牌 |
这里特别强调一点：
拿到合法 Token，不代表就应该拥有所有业务权限。
汽车控制 API 还应该检查：
- 这个 Token 对应哪个用户？
- 用户是否拥有这辆车？
- 是否拥有远程控制权限？
- 车辆是否支持该操作？
- 是否存在异常设备或异常登录？
- 是否需要额外验证？
如果服务端只检查 Token 是否有效，却不检查用户和车辆之间的授权关系，就会出现严重的越权问题。
5. 一个身份认证系统，可能成为整个业务的单点故障
这篇文章给我的最大感受就是：
汽车厂商可能花了大量时间保护车辆通信、车载网络和硬件安全，却忽略了整个系统最重要的信任入口：身份认证服务器。
这其实不只是汽车行业的问题。
想象一下：
- 电商系统的 SSO 被攻破，攻击者可以控制商家账户。
- 企业 SaaS 的身份管理系统被攻破，攻击者可以访问所有租户。
- 云平台的 IAM 被攻破，攻击者可以操作大量云资源。
- 智能家居平台被攻破，攻击者可以远程控制门锁、摄像头和家电。
本质上都是同一个问题：
当一个中心化身份系统掌握了大量业务资源的访问权，它本身就成为整个系统最重要的安全边界。
六、如果让我给这次事件做一个安全评级
| 维度 | 我的判断 |
|---|---|
| 漏洞入口 | 客户端凭证泄露、管理接口暴露 |
| 核心突破 | ForgeRock 路径解析差异、管理权限滥用 |
| 权限提升 | 生产服务器 RCE |
| 身份认证 | 任意用户账户接管、MFA 流程缺陷 |
| 最终影响 | 车辆位置、遥测、解锁、远程启动 |
| 影响范围 | 两家汽车厂商、多个地区 |
| 修复响应 | 厂商报告后约 2 小时修复 |
七、我的总结
我觉得这篇文章最值得记住的不是汽车解锁，而是它揭示了现代软件系统的一个安全规律：
攻击者不一定需要攻破你最重要的系统，只要攻破一个能够代表你访问重要系统的组件，就足够了。
这次攻击非常典型：
- 从 Android APK 入手，获得基础设施信息。
- 从管理后台入手，获得用户与车辆的关联信息。
- 从身份认证系统入手，获得管理员权限。
- 从 WAF 和 URL 解析差异入手，获得生产服务器代码执行。
- 从账户管理入手，获得合法用户身份。
- 最后通过正常业务 API 控制车辆。
整个过程中，汽车厂商的车辆控制 API 甚至不一定存在传统意义上的漏洞。
因为攻击者拿到的是一个合法的车主 Access Token。
这比单纯的 API 漏洞更值得警惕。
另外，我很喜欢这篇研究的另一个地方：它展示了安全研究如何利用源码分析、逆向工程、协议分析和 AI 辅助审计，逐步解决复杂问题。
作者提到，他们曾让 GPT-5.6 Sol Ultra 分析 OpenIDM 的源码约六个小时，最终找到了此前人工没有尝试到的路径组合。
这也说明 AI 在安全研究中的价值，不只是生成漏洞利用代码，还可以帮助研究人员理解大型代码库、分析不同组件的实现差异，寻找人类容易遗漏的边界条件。
如果要给这篇文章一个评价：
这不是一次汽车破解，而是一次从客户端到生产身份认证基础设施，再到真实物理世界的完整供应链式攻击。
原文值得收藏：
后者尤其值得读，它把 ForgeRock、Apache Felix、OSGi、WAF、RCE 和 OAuth 认证流程串成了一次完整的实战研究。