背景介绍

2022 年秋天，国外一群白帽小哥从伊利诺伊州芝加哥到华盛顿特区进行了一次公路旅行，参加一场网络安全会议，同时从平时的工作中放松一下。

当他们参观马里兰大学时，发现校园里摆放着一堆电动踏板车，于是他们忍不住‘戳’了一下踏板车的APP。于是乎，所有车上的喇叭和车头灯打开并连续亮起了 15 分钟。

随后他们向电动踏板车制造商发送了漏洞报告，并尝试了更多的攻击方法。

经过头脑风暴，这群白帽小哥意识到过去 5 年制造的几乎每辆汽车都具有几乎相同的功能。

如果攻击者能够发现车辆远程信息处理系统使用的 API 端点中的漏洞，他们就可以远程按喇叭、闪灯、跟踪、锁定/解锁以及启动/停止车辆。

于是他们开始以寻找影响汽车行业的漏洞为目标，在接下来的几个月中，发现了尽可能多的与车企相关的漏洞。

让我们来看看他们都发现了哪些有趣的漏洞吧～

漏洞记录

通过错误配置的 SSO 接管宝马和劳斯莱斯的完整帐户

在测试 BMW 资产时，他们发现了一个面向 BMW 员工和承包商的自定义 SSO 门户。

这让他们非常兴奋，因为在这里发现的任何漏洞都有可能让攻击者入侵连接到宝马所有资产的任何账户。

例如，如果经销商想要访问宝马实体经销商的经销商门户，他们必须通过该门户进行身份验证。此外，该 SSO 门户还用于访问内部工具和相关的 DevOps 基础设施。

白帽团队做的第一件事是使用 gau 和 ffuf 等工具对主机进行指纹识别。

经过几个小时的Fuzz测试后，我们发现了一个 WADL 文件，该文件通过发送以下 HTTP 请求公开了主机上的 API 端点：

GET /rest/api/application.wadl HTTP/1.1 Host: xpita.bmwgroup.com

HTTP 响应包含 xpita 主机上的所有可用 REST 端点，于是开始枚举端点并发送模拟 HTTP 请求以查看可用的功能。

通过在user字段 API 端点中发送星号即可查询所有 BMW 用户帐户。

输入类似“sam*”的内容便可检索名为“sam.curry”的用户信息，而无需猜测实际的用户名。

GET /reset/api/users/example* HTTP/1.1 Host: xpita.bmwgroup.com

响应包：

HTTP/1.1 200 OK Content-type: application/json {"id":"redacted","firstName":"Example","lastName":"User","userName":"example.user"}

发现该漏洞后，白帽团队继续测试其它可访问的 API 端点，一个特别有趣的端点是“/rest/api/chains/accounts/:user_id/totp”端点。

他们注意到“totp”一词通常代表一次性密码生成。

当使用与 TOTP 端点配对的通配符查询中获得的 SSO 用户 ID 向此端点发送请求时，它会返回一个随机的 7 位数字。以下 HTTP 请求和响应：

请求：
GET /rest/api/chains/accounts/unique_account_id/totp HTTP/1.1 Host: xpita.bmwgroup.com

响应：

HTTP/1.1 200 OK Content-type: text/plain 9373958

HTTP 请求似乎都会为用户帐户生成 TOTP。

白帽团队猜测该交互可能与“忘记密码”功能有关，于是他们通过使用原始通配符查找和检索受害者用户 ID 查询example*来寻找示例帐户。

检索到 ID 后，他们尝试为用户帐户重置密码，直到系统从用户的 2FA 设备（例如电子邮件或电话）请求 TOTP 代码。

检索从 API 端点生成的 TOTP 代码，并将其输入到重置密码确认字段中，bingo！成功重置了用户帐户，获得了对任意宝马员工和承包商用户的完全帐户接管。

至此，攻击者可以完全接管任何宝马或劳斯莱斯员工帐户以及这些员工的访问工具。

为了演示该漏洞的影响，白帽团队简单地在 Google 上搜索了“宝马经销商门户”，并使用他们的帐户访问了在宝马和劳斯莱斯实体经销商的门户。

登录后，可以看到接管的模拟账户与实际经销商绑定，攻击者可以访问经销商本身有权访问的所有功能。

包括查询特定 VIN 号码和检索车辆销售文件的能力。

凭借访问级别，攻击者可以针对宝马和劳斯莱斯客户帐户和客户车辆执行大量功能。

通过错误配置的 SSO 远程执行代码并访问奔驰和劳斯莱斯上的数百个内部工具

测试早期，白帽团队中的某位白帽小哥购买了一辆梅赛德斯-奔驰汽车，因此他们开始审查梅赛德斯-奔驰的基础设施。

我们采取了与宝马相同的方法，开始测试梅赛德斯-奔驰员工的 SSO。

遗憾的是，团队无法找到影响 SSO 门户本身的任何漏洞，但通过探索 SSO 网站，他们发现奔驰正在为员工帐户运行某种形式的 LDAP。

基于对其基础设施的高度了解，他们猜测各个员工应用程序使用集中式 LDAP 系统来验证用户身份。

于是他们开始探索这些网站，试图找到公共注册，以便可以获得 SSO 凭证来访问员工应用程序，哪怕是极其有限的权限。

在对随机站点进行一段时间的模糊测试后，他们最终找到了“umas.mercedes-benz.com”网站，该网站是为汽车维修店请求访问梅赛德斯-奔驰的特定工具而建立的。

该网站启用了公共注册，因为它是为维修店构建的，并且似乎写入了与核心员工 LDAP 系统相同的数据库。

于是白帽团队填写了注册所需的所有字段，成功创建了一个用户帐户，然后使用侦察到的数据来识别重定向到 Mercedes-Benz SSO 的网站。

我们第一个尝试的是一个非常明显的员工工具，它是“git.mercedes-benz.com”，Github 的缩写。

尝试使用用户凭据登录 Mercedes-Benz Github，结果成功登录！

梅赛德斯-奔驰 Github 在经过身份验证后，要求在帐户上设置 2FA，以便继续访问该应用程序。

白帽团队安装了 2FA 应用程序并将其添加到帐户中，输入2FA代码后，成功进入，并完全访问“git.mercedes-benz.com”。

几分钟后，他们看到 Github 中拥有了各种梅赛德斯-奔驰项目的内部文档和源代码，包括客户用来远程连接到他们的车辆的 Mercedes Me Connect 应用程序。

内部文档为员工提供了详细的说明，如何为自己构建一个与客户车辆对话的应用程序，以及与客户车辆对话必须采取的具体步骤。

白帽团队报告了该漏洞，但随后安全团队要求他们证明进一步的漏洞影响。

于是白帽团队使用员工帐户登录了许多包含敏感信息的应用程序，并通过暴露的actuators、Spring Boot 控制台以及梅赛德斯-奔驰员工使用的数十个敏感内部应用程序实现了远程代码执行。

这些应用程序之一是 Mercedes-Benz Mattermost（基本上就是一个 Slack）。

攻击者有权加入任何渠道，包括安全渠道，并且可以冒充梅赛德斯-奔驰员工：

简单概述起来就是：

• 多个仅限员工使用的 Github 账户，包含了敏感信息，其中包含梅赛德斯-奔驰基础设施中多个应用程序的文档和配置文件
• Spring Boot actuators 可导致敏感员工和客户应用程序上的远程代码执行、信息泄露、Jenkins instances
• AWS 和云计算控制面板，可以在其中请求、管理和访问各种内部系统
• 用于与客户车辆通信的 XENTRY 系统
• 用于配置和管理内部应用程序的内部 OAuth 和应用程序管理相关功能
• 数百个内部其它服务

未完待续……