文章总结： 本文详细披露了2024年11月发现的斯巴鲁STARLINK车联网服务严重安全漏洞。攻击者可通过获取车主的姓氏和邮编、邮箱、手机号或车牌号等信息，入侵其后台管理系统，进而远程控制车辆（如启动/熄火、锁车/解锁）、获取车辆实时位置及过去一年的完整行驶轨迹，并能提取车主的个人身份信息（PII），包括紧急联系人、住址及信用卡后四位等敏感数据。该漏洞在报告后24小时内被厂商修复，且未发现被恶意利用的情况。 综合评分： 95 文章分类： 车联网安全,渗透测试,漏洞分析,安全大事件
黑进斯巴鲁——只需车牌号，10秒接管车辆
原创
玲珑安全 玲珑安全
玲珑安全
2025年4月8日 15:02 福建
玲珑安全第六期SRC培训迎来周年庆特惠
点击下方卡片查看招生细则
欢迎广大朋友咨询参加
引言
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#53
Non-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 相关的后台管理面板。
起初看这个后台登录页的时候，并没有觉得有太大希望——就是一个普通的登录界面，而且我们也没有任何员工的账号密码。
我尝试查看网页源码，看看有没有隐藏的线索。果然，有一段代码引起了我的注意：
<script type="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 接口里测试，直到第四个请求时，接口返回了这样的内容：
<label for="securityQuestionId"> <span class="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');
通过移除客户端的覆盖层后，我点击页面上的各个按钮，发现整个应用似乎恢复了正常。所有按钮都能正常使用，并且服务器返回了正确的数据。
左侧导航栏有很多不同的功能，但最吸引人的是“最后已知位置”。我输入了我妈妈的姓氏和邮政编码。她的车出现在搜索结果中。我点击了它，看到过去一年我妈妈去过的所有地方：
| 日期 | 里程表 | 位置 | | — | — | — | | 2024年11月21日 6:18:56 PM | 14472.6 | 41.30136,-96.161142 | | 2024年11月21日 4:59:51 AM | 14472.6 | 41.301402,-96.161134 | | 2024年11月21日 4:49:02 AM | 14472.6 | 41.301286,-96.161145 | | … | … | … | | 2023年11月2日 1:44:24 PM | 6440.6 | 41.256003,-96.080627 | | 2023年11月1日 9:52:47 PM | 6432.5 | 41.301248,-96.159951 | | 2023年11月1日 12:16:02 PM | 6425.2 | 41.259397,-96.078775 |
“最后已知位置”端点不仅提供了最后的位置，它还给出了过去一年她每次启动引擎或使用远程指令时的精确坐标。我没意识到这些数据被收集，但看起来我们在购买时已经同意了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岁员工，可以查询到加州某辆车的账单信息，而这并不会引起任何警觉，这是他们的日常工作内容之一。员工们有权访问大量个人数据，而整个系统的运作依赖于信任。
当系统默认设置如此广泛的访问权限时，想确保这些系统的安全性，并不容易。
培训咨询v
bc52013
linglongsec
SRC漏洞挖掘培训
玲珑安全第一期SRC漏洞挖掘培训
玲珑安全第二期SRC漏洞挖掘培训
玲珑安全第三期SRC漏洞挖掘培训
玲珑安全第四期SRC漏洞挖掘培训
玲珑安全第五期SRC漏洞挖掘培训
玲珑安全第六期SRC漏洞挖掘培训
往期漏洞分享
要挂科了？那就黑一下教务处系统吧…
价值10w的Google点击劫持漏洞
我是怎么挖到NASA上的P1漏洞的？
在Google漏洞追踪系统中获得15600$赏金
账户接管+PII+原漏洞绕过
Zoho帐户接管
玲珑安全B站公开课
https://space.bilibili.com/602205041
玲珑安全QQ群
191400300
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：玲珑安全 玲珑安全 玲珑安全《黑进斯巴鲁——只需车牌号，10秒接管车辆》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论