从两个案例看APP端的智能汽车入侵风险

汽车安全 2年前 (2022) admin
667 0 0


本文仅供参考分析学习


批量控车越来越容易了么?

近日木卫四汽车威胁情报系统收录到国外有两名安全研究人员发现了两个远程控车漏洞。

从两个案例看APP端的智能汽车入侵风险

其一,互联网车辆服务商Sirius XM 的一个授权漏洞,攻击者仅需知道车辆识别码(VIN)即可远程解锁、启动、定位、闪烁和鸣笛,该漏洞影响本田、英菲尼迪、讴歌和日产等多款汽车;

其二,现代汽车API身份认证的漏洞,研究人员通过对现代汽车APP产生的流量进行分析,发现了API身份认证的漏洞,该漏洞影响现代和捷尼赛斯汽车的车辆远程信息处理服务,通过该漏洞可实现对车辆的远程控制;

上述两个新型漏洞的攻击场景与今年极棒大会上的多个汽车类攻击比赛类似,瞄准远程控车场景,对此类场景漏洞挖掘,寻找链路上存在的每一个可能“解锁”的姿势。

从两个案例看APP端的智能汽车入侵风险

控车漏洞一

漏洞研究过程

先抓个包

安全研究员通过Burpsuite对日产手机APP的流量进行抓包分析,发现某个HTTP的API请求”exchangeToken” 可以返回一个授权的 BEARER token,其中BEARER Token 是一种Access Token ,云端Server在身份验证通过之后下发给Client。

从两个案例看APP端的智能汽车入侵风险

再改个参数

通过对各个字段的参数篡改,安全研究员最终发现“exchangeToken”请求的json字段只与”customerId”相关,只要发送请求中包含”customerId”字段,服务端即可返回响应。

逮到关键参数

继续对 customerId进行深度分析,研究customerId参数的值与鉴权过程的关系,发现 customerId 是鉴权过程不可缺少的参数。

从两个案例看APP端的智能汽车入侵风险

参数“变态”的神奇效果

经过近一步深入的研究,决定采用一种“变态”的方式,将VIN作为customerId的值传入,令人惊讶的是,居然可以获取BEARER。

从两个案例看APP端的智能汽车入侵风险

为了确保此流程与会话 JWT 无关,完全删除Authorization 参数之后重新请求,结果仍然有效!!!

这个漏洞能干什么?

隐私泄漏:获取用户配置文件

在HTTP请求中使用这个授权的Bearer,可以获取用户配置文件,其中包含受害者的姓名、电话号码、地址和汽车详细信息。

从两个案例看APP端的智能汽车入侵风险

远程控车:解锁、启动、鸣笛、闪灯

利用这个授权的Bearer发送控车的http请求,可实现对车辆的远程控制。

从两个案例看APP端的智能汽车入侵风险

漏洞影响

此远程控制服务的提供商为SiriusXM,该服务商为多家车企提供服务,通过对使用此服务商的其他车型进行测试验证,发现除了日产之外,还可以在本田、英菲尼迪和讴歌车辆上访问客户信息并执行车辆远控命令。

从两个案例看APP端的智能汽车入侵风险

控车漏洞二

漏洞研究过程

现代和捷尼赛斯的应用程序允许经过身份验证的用户远程控制他们的车辆。通过 Burp Suite 代理抓取应用程序的流量,并查看实际使用的 API 。

从两个案例看APP端的智能汽车入侵风险

抓个包

通过分析捕获的流量包,可知正常解锁的简化版HTTP请求如下:

`POST /ac/v2/rcs/rdo/unlock HTTP/1.1
Access_token: token
{"userName":"EMAIL","vin":"VIN"}`

其中“Access_token”是JWT 通过电子邮件/密码对移动应用程序进行身份验证而生成的。

再改个参数

安全研究员尝试将电子邮件参数修改为 JWT 电子邮件以外的任何其他内容,服务器均将返回“未授权”。

这一操作表明服务器正在将请求的JSON正文中发送的电子邮件与Json Web Token(JWT)中存储的解析电子邮件进行比较。这意味着无法通过抓包直接修改邮箱进行攻击。

如果可以绕过对邮件的字符串检查,理论上是可以解锁汽车并执行所有的控车操作。

继续改一改

通过对用户帐户注册进行近一步研究,发现现代汽车的服务器不要求用户在帐户注册期间验证其电子邮件地址,并且允许在电子邮件地址中使用控制字符的正则表达式。

从两个案例看APP端的智能汽车入侵风险

魔法打败魔法?

安全研究员并未就此止步,为实现最终的远程控车,又开启新的“骚操作”,在注册过程中,通过在已经存在的车主用户电子邮件地址末尾添加CRLF字符来注册新帐户。利用这种方式创建了一个可绕过 JWT 和电子邮件参数校验的帐户。

`被攻击车主电子邮件:[email protected]`
`攻击者的电子邮件:[email protected]%0d`

在发送HTTP请求的过程中JWT使用攻击者新注册的账户,参数使用被攻击车主的账户,通过%0d 干扰服务端,将攻击者的请求误认为是被攻击车主的请求,最终将成功返回被攻击车主的车辆VIN信息。

从两个案例看APP端的智能汽车入侵风险

如上图所示,安全研究员成功获取被攻击车主车辆的 VIN信息之后 ,继续使用附加了 CRLF 的被攻击车主帐户发送远程控车的 HTTP 请求,尝试远程解锁被攻击者车主的车辆,意料之中,成功返回200 OK,车辆成功解锁。

漏洞利用及影响

此漏洞可实现对现代和捷尼赛斯车辆的任意远程解锁、启动等控车操作。

如何应对此类新型汽车漏洞

上述两个远程控车漏洞从攻击场景上属于利用车主应用APP及云端指令中心的漏洞对车辆发起远程控制,通过破解车主应用APP与后端服务API的远程业务协议漏洞,窃取或滥用车辆访问凭据、TOKEN等,从而获取到单车或者多车的控制权。(这类手法在木卫四之前技术博客中也有类似的分析

如何应对呢?木卫四安全工程师给出以下三点建议:

  1. 方案设计阶段,需要针对车辆远控、数字钥匙等业务进行安全风险评估;

  2. 功能开发阶段,需遵守代码安全规范,并进行渗透评估;

  3. 车辆运营阶段,需进行实时监控,及时发现黑客正在研究破解的行为,并通过OTA等方式处置潜在的风险;


本文作者


博文、Mickey 木卫四工程师 情报分析师、白帽子工程师



本文转载自:

两个控车漏洞的攻击手法解读 (wolai.com)

原文始发于微信公众号(Th0r安全):从两个案例看APP端的智能汽车入侵风险

版权声明:admin 发表于 2022年12月2日 下午2:56。
转载请注明:从两个案例看APP端的智能汽车入侵风险 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...