黑进斯巴鲁——只需车牌号，10秒接管车辆

引言

2024年11月20日，我和Shubham Shah 发现了斯巴鲁（Subaru）旗下 STARLINK 车联网服务中的一个严重安全漏洞。该漏洞可让攻击者在毫无限制的前提下，远程访问和控制美国、加拿大和日本所有车主的车辆和账户。

利用该漏洞，攻击者只需掌握受害者的姓氏和邮编，或者邮箱地址、手机号、车牌号中的任意一项，就可以实现以下操作：

• 远程启动或熄火、锁车或解锁，并获取车辆的实时位置；
• 获取任意车辆过去一年的完整轨迹记录，精度可达5米，并在每次点火时更新；
• 查询并提取任意车主的个人身份信息（PII），包括紧急联系人、授权用户、住址、账单信息（如信用卡后四位）以及车辆PIN码；
• 访问与用户相关的其他信息，例如客服通话记录、历史车主信息、里程数、销售记录等。

我们在第一时间将该漏洞报告给斯巴鲁，厂商在24小时内完成了修复，且该漏洞从未被恶意利用。

下图展示的是一辆2023款斯巴鲁Impreza泄露的1,600个定位点，任何联网的斯巴鲁车型都可能被拉取出类似的行驶数据：

正文

大约一年前，我给我妈买了一辆 2023 款斯巴鲁 Impreza，前提是她得答应我，之后我可以借来做一次“白帽渗透测试”。过去几年我一直在研究其他车企的安全问题，但一直没有机会仔细看看斯巴鲁的系统。

今年感恩节回家的时候，我抓住机会，向我妈要来了她的 MySubaru 账号登录信息，看看有没有可以切入的点。

我首先盯上的是 MySubaru 手机 App，这个应用可以远程发送各种车辆控制指令。我用 Burp Suite 对 App 进行代理抓包，拦截了车辆控制相关的 HTTP 请求，希望能找到某种未授权指令执行的漏洞。

当用户通过 App 解锁车辆时，App 会发送如下请求：

POST /g2v30/service/g2/unlock/execute.json;jsessionid=AE6E4482F5C4493A79C8F3BD656F8BBA HTTP/1.1Host: mobileapi.prod.subarucs.comContent-Type: application/jsonConnection: keep-aliveAccept: */*User-Agent: MySubaru-PROD-SOA/2024110100 CFNetwork/1568.300.101 Darwin/24.2.0Content-Length: 83Accept-Language: en-US,en;q=0.9Accept-Encoding: gzip, deflate, br{  "delay": 0,  "unlockDoorType": "ALL_DOORS_CMD",  "vin": "4S3GTAV64P3701234",  "pin": "1234"}

我尝试绕过授权机制，直接伪造请求来远程控制车辆，但没有成功。整个 App 的接口数量不多，安全机制做得还挺到位，权限校验也很严谨。

看来，单纯盯着用户端 App 的方向并不奏效。

结合我以前在其他车企挖洞的经验，我知道很多时候员工端系统的权限远比用户端大得多，而且这些系统有时会暴露在公网，或存在配置不当的问题。

于是我开始转向搜集和分析斯巴鲁旗下的其他相关网站，重点寻找那些员工内部使用的后台系统，看看能不能找到新的突破口。

我在 Discord 上给我朋友 Shubs 发了条消息，问他有没有兴趣一起帮我找找斯巴鲁内部使用的员工端系统。他很爽快地答应了，接着马上发来了一条消息：

shubs — 2024/11/19你见过这个域名吗？subarucs.com

他注意到，MySubaru App 使用的域名 my.subaru.com 实际上是一个 CNAME，最终指向的是我之前没见过的一个子域名：mys.prod.subarucs.com

我通过 nslookup 验证了一下这个域名解析链：

nslookup my.subaru.comServer:         127.0.0.53Address:        127.0.0.53#53Non-authoritative answer:my.subaru.com   canonical name = www.mysubaru.com.www.mysubaru.com        canonical name = mys.prod.subarucs.com.Name:   mys.prod.subarucs.com

随后我们对 subarucs.com 域名下的子域进行了扫描，并分析了扫描结果，发现了一个非常有意思的页面：

STARLINK® Admin Portal - https://portal.prod.subarucs.com/login.html

这个看上去就像是员工用的后台系统。从简单的 Google 搜索来看，“STARLINK” 是斯巴鲁旗下的车载信息娱乐系统名称，提供包括远程控制在内的各种联网功能。

而这个“Admin Portal”，很明显就是与 STARLINK 相关的后台管理面板。

起初看这个后台登录页的时候，并没有觉得有太大希望——就是一个普通的登录界面，而且我们也没有任何员工的账号密码。

我尝试查看网页源码，看看有没有隐藏的线索。果然，有一段代码引起了我的注意：

<scripttype="text/javascript"src="/assets/_js/starlinkEnroll.js"></script>

登录页面加载了位于 /assets/_js/ 路径下的多个 JavaScript 脚本文件，看起来里面可能藏着有用的信息。于是我用目录扫描工具 FFuF 对这个路径进行了爆破，试图找出更多未公开的 JS 文件。

几分钟后，FFuF 命中了一个名为 login.js 的文件，其中包含如下这段非常有意思的代码：

$('#new_password_submit').on('click', function(e) {e.preventDefault();if($('#forgot-password-step4-form').valid()) {disableBtns();$.ajax({            url: "/forgotPassword/resetPassword.json",type: "POST",            contentType: "application/json",            data: JSON.stringify({                email: email,                password: $('#new_password').val(),                passwordConfirmation: $('#confirm_new_password').val()            }),async: false}).done(function (response) {

从代码来看，这个系统提供了一个 /forgotPassword/resetPassword.json 接口，用于重置密码，而且不需要任何验证令牌（token）。

换句话说，如果这个接口确实按这段 JavaScript 的逻辑运行，那攻击者只需要知道某位员工的邮箱地址，就可以重置其密码，直接接管账号。

为了验证这个接口是否真的对外开放，我构造了如下 POST 请求，以测试这个功能是否可用：

POST /forgotPassword/resetPassword.json HTTP/1.1Host: portal.prod.subarucs.com{  "email": "[email protected]",  "password": "Example123!",  "passwordConfirmation": "Example123!"}

响应包如下：

HTTP/1.1 200Content-type: application/jsonContent-length: 7“error”

从测试结果来看，接口在正常工作。我们只需要找到一个有效的员工邮箱地址，就能实际验证能否接管账户。

考虑到这是一个大型后台系统，平台上应该存在不少员工账号。我们只需要找出一个可以用于枚举邮箱是否存在的接口即可。

我继续分析前面提到的 JS 文件，直到发现了这样一个 API 请求：

GET /adminProfile/[email protected] HTTP/1.1Host: portal.prod.subarucs.com

响应如下：

HTTP/1.1 200Content-type: application/jsonContent-length: 7{  "error": "Invalid email"}

这个接口对我们很有用：如果传入的邮箱地址是有效的，就会返回该用户设置的安全问题；如果无效，就返回 “Invalid email”。

我们可以利用这个接口进行邮箱爆破，枚举出哪些员工邮箱是真实存在的，从而进一步用于密码重置操作。

我打开 LinkedIn 搜索关键词 “Subaru STARLINK”，很快就找到了几位自称是 Subaru STARLINK 团队的软件工程师。

通过他们在公开页面上的姓名，我们结合 Google 搜索，很快确认了 Subaru 的邮箱格式是：

[名字首字母][姓氏]@subaru.com

我将整理出的几个候选邮箱地址逐个丢进 /getSecurityQuestion.json 接口里测试，直到第四个请求时，接口返回了这样的内容：

<labelfor="securityQuestionId">  <spanclass="securityQuestionText">What city were you born in?</span></label>

说明这个邮箱地址（如 [email protected]，已脱敏）是有效的员工账号。

接下来，我立即返回到之前的 /forgotPassword/resetPassword.json 接口，对这个邮箱执行密码重置请求：

POST /forgotPassword/resetPassword.json HTTP/1.1Host: portal.prod.subarucs.com{  "email": "[email protected]",  "password": "Example123!",  "passwordConfirmation": "Example123!"}

响应如下：

HTTP/1.1 200Date: Wed, 20 Nov 2024 03:02:31 GMTContent-Type: application/jsonConnection: closeX-Frame-Options: SAMEORIGINContent-Length: 9"success"

返回包显示我们成功修改了密码，于是我使用新设置的密码成功登录了后台系统：

但在尝试使用后台系统时，遇到了2FA（双因素认证）的提示。这个 2FA 是自定义实现的，因此我开始尝试各种方法来绕过它。

我首先尝试了一个非常简单的思路：直接移除客户端的2FA覆盖层，即隐藏前端的弹窗界面。

原始代码：

$('#securityQuestionModal').modal('show');

替换后的代码：

//$('#securityQuestionModal').modal('show');

通过移除客户端的覆盖层后，我点击页面上的各个按钮，发现整个应用似乎恢复了正常。所有按钮都能正常使用，并且服务器返回了正确的数据。

左侧导航栏有很多不同的功能，但最吸引人的是“最后已知位置”。我输入了我妈妈的姓氏和邮政编码。她的车出现在搜索结果中。我点击了它，看到过去一年我妈妈去过的所有地方：

“最后已知位置”端点不仅提供了最后的位置，它还给出了过去一年她每次启动引擎或使用远程指令时的精确坐标。我没意识到这些数据被收集，但看起来我们在购买时已经同意了STARLINK注册。

为了更好地理解这些数据，我导出了我妈妈2023年Impreza的一整年位置历史，并将其导入到下面的Google地图页面中。

这张地图展示了从2023年斯巴鲁Impreza中泄露的1,600个坐标，显示了车辆过去一年的行驶位置。

类似的数据，任何连接互联网的斯巴鲁车辆都可以被检索到，甚至可能包括其他车主的行驶数据。

在管理员面板中，能访问到我们的STARLINK购买协议历史记录：

除了这些，还有许多其他的端点。其中一个是车辆搜索功能，允许你查询客户的姓氏和邮政编码、电话号码、电子邮件地址或车辆识别号码（VIN，通常可以通过车牌号码获取），并授予或修改对其车辆的访问权限。这个功能让用户能够非常方便地访问和控制目标车辆的详细信息：

在仪表板上搜索并找到自己的车辆后，我确认了STARLINK管理员仪表板应该能够访问几乎所有美国、加拿大和日本的斯巴鲁车辆。为了确保我没有遗漏什么，我联系了一位朋友，问她是否可以“黑”掉她的车，以证明我们可以完全接管车辆。

她给了我她的车牌号码，我在管理员面板中调出了她的车辆，将自己添加为她的斯巴鲁的授权用户：

如图：

现在我具有访问权限，我让她看一下房子外面，看看她的车是否有什么变化。

接着我发送了“解锁”命令，然后她给我们发来了这段视频：

后来，她确认在我将自己添加为授权用户并解锁她的车后，她并没有收到任何通知、短信或电子邮件。

时间线

• 2024年11月20日 11:54 PM CST：初步报告已发送至安全运营（SecOps）邮箱
• 2024年11月21日 7:40 AM CST：斯巴鲁团队的初步回应
• 2024年11月21日 4:00 PM CST：漏洞已修复，无法重现
• 2025年1月23日 6:00 AM CST：博客文章发布

写这篇文章时，我发现很难再写一篇关于汽车黑客的博客。大多数读者都从事安全工作，所以我认为密码重置或二次验证绕过的技术对他们来说并不陌生。真正值得分享的，是这个漏洞的影响，以及联网汽车系统如何运作。

汽车行业的特殊性在于，一个来自德州的18岁员工，可以查询到加州某辆车的账单信息，而这并不会引起任何警觉，这是他们的日常工作内容之一。员工们有权访问大量个人数据，而整个系统的运作依赖于信任。

当系统默认设置如此广泛的访问权限时，想确保这些系统的安全性，并不容易。