翻译：WisFree
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
在这篇文章中，我们将对Argus研究团队在博世Drivelog Connect BOD-II适配器中发现的漏洞进行详细讨论。需要注意的是，这个漏洞将允许攻击者通过Drivelog平台停止一台正在行驶的汽车引擎。
根据Argus的漏洞披露政策，我们发现该漏洞之后便于2017年2月20日将漏洞信息上报给了博世公司。2017年2月21日，博世的产品安全事件响应团队（PSIRT）与Argus的研究人员取得了联系，并开始着手解决相应的安全问题。
下面即为Argus在博世Drivelog Connect中发现的两个漏洞：
1. 一个信息披露漏洞，存在于Drivelog Connector适配器与Drivelog Connect智能手机应用之间的验证过程中。
2. 一个存在于Drivelog Connector适配器的信息过滤器中的安全漏洞。
信息披露漏洞将允许我们快速离线爆破PIN码，并通过蓝牙连接Drivelog Connect适配器。连接成功之后，适配器信息过滤器中的安全漏洞将允许我们向汽车的CAN总线注入恶意指令。
在我们的研究过程中，我们可以在蓝牙可连接的范围内关闭一辆正在运行的汽车引擎。但更让我们担心的是，由于我们能够通过适配器向CAN总线注入恶意信息，这也意味着我们也许能够控制网络中其他的电子控制单元（ECU）。如果攻击者能够在现实生活中实现这种攻击，我们估计他们将能够对道路上正在行驶的汽车造成物理影响。
联网设备-攻击者的圣杯
近些年，网络安全研究专家已经演示了大量针对物联网设备的攻击方法。比如说，Mirai恶意软件利用了全球各地的路由器和远程摄像头构建了一个范围非常大的僵尸网络，攻击者将能够利用这种僵尸网络来发动垃圾邮件攻击。而且随着汽车智能化的延伸，针对智能汽车的黑客攻击技术也逐渐得到了大家的关注。需要注意的是，之前泄漏的CIA攻击工具中也包括很多针对汽车的恶意工具。除此之外，针对汽车的网络攻击事件也成为了近几年各大安全媒体的头版头条，而且几乎目前所有主流的智能产品都已经成为了黑客手中的牺牲品。
博世Drivelog Connector适配器
博世的Drivelog Connect是一个提供有关车辆状态信息的服务，与其他的物联网设备一样，这项服务可以给汽车驾驶员提供大量的便捷功能以及车辆的健康状态信息，例如汽车潜在的问题、服务期限、燃料消耗数据和驾驶情况等等。这个连接器可以通过CAN车载总线与车辆进行连接，实时监控车辆的运行数据，并根据数据提供诊断信息和维修保养建议。产品包括一个名叫Drivelog Connector的适配器，Drivelog适配器总共有两种型号，分别适用于私家车和商务车，其主要区别就在于适配器上的CAN总线接口的数量上。
为了与适配器进行通信，我们下载了Drivelog Connect应用程序，这款应用可以通过蓝牙与适配器连接，并对汽车的健康状况和驾驶信息进行检查。Drivelog Connect应用有Android和iPhone两个版本，考虑到Android系统天然的开源特性，我们决定从Android版本着手开始我们的研究。
研究开始-在实验室中模拟汽车
我们首先要做的，就是在实验室中让Drivelog适配器和移动端App在没有实际接入汽车（行驶状态）的情况下运行起来。因此，我们首先要模拟出一个汽车环境。为了实现这一点，我们需要对连接了适配器的真实车辆CAN总线的传输数据进行记录和分析，并观察适配器所需要的数据。
基本思路比较简单：首先，将适配器与一台正在行驶的汽车连接，识别适配器所发送的PID请求，并记录汽车返回的响应信息；接下来，我们需要在实验环境中模拟一台正在行驶的汽车，当适配器发送请求时，我们会将之前记录下的汽车响应数据返回给适配器，这样就可以让适配器正常运行了。
在对CAN总线所发送的PID信息进行观察之后，我们创建了一个字典来保存请求-响应信息，这个字典将允许我们模拟出一台正常状态的汽车。适配器配置完成之后，我们将注意力转移到了Android应用的身上，在对Java代码进行了反编译之后，我们就可以开始检查应用程序的源代码了。
适配器和移动App
在对反编译后的Java源码进行了分析之后，我们了解到了以下几点信息。虽然源码中绝大部分函数和变量都用字母代替了（例如a()、b()、c()），但是我们仍然通过大量的调试日志了解到了代码的基本运行逻辑。由于函数日志对于逆向工程来说是非常有用的信息，因此我们将应用反汇编成Smali代码，并进一步观察调试日志的内容。
我们发现，Drivelog应用还可以更新适配器的固件。实际上，有可用的固件更新时，在固件更新过程完成之前Drivelog应用是不允许我们与适配器相连接的，这也是保证更新能够迅速完成的一种方法。如果我们能够拿到适配器的固件程序，那么我们就可以审查其源码并有可能找出远程代码执行漏洞了。但不幸的是，在对应用程序的行为以及它与适配器的通信方式进行了观察之后，我们发现固件更新补丁在传输过程中是经过了加密的，而且只有适配器才能对其进行解密。这也就意味着，即使我们拿到了固件程序，我们仍然要进行大量的解密工作，但是如果我们能够拿到固件源码，我们就可以找出潜在的攻击向量了。
消息过滤器中的安全漏洞
既然固件采用了加密保护，因此我们决定将注意力转移到时间成本更低的攻击向量上，比如说一台被入侵的智能手机。那么问题来了，攻击者如果得到了车主手机的root权限，那么他们就能够通过Drivelog应用来与适配器进行通信，那么他们会给汽车带来多大的威胁呢？
为了充分理解适配器所使用的协议，我们对蓝牙通信数据进行了监听。我们发现，App与适配器之间的传输数据同样是经过加密的，因此我们对Android端App进行了修改，并收集到了所有的蓝牙通信数据（UDP）。
UDP输出数据如下所示：
在上图中，App所发送的信息标记为TX，适配器发送给App的信息标记为RX。通过对比蓝牙和CAN总线的数据，我们可以看到App发送CAN总线信息是通过REQ命令实现的。REQ命令后面紧接着的就是通过CAN总线所发送的数据（后面的aa是填充数据，填充至CAN总线数据的最大长度-8个字节）。
认证过程中的信息披露漏洞
首先，我们假设攻击者可以访问目标用户的受感染手机。现在，我们就要找出一个可以向适配器发送控制指令并生成CAN消息的简单方法。为了能够复制攻击者对目标手机的这种读写访问权限，我们还需要分析Drivelog适配器和Android端应用之间的认证处理过程。
从用户体验度方面考虑，适配器与App之间的配对过程比较简单-用户从蓝牙列表中选择适配器，然后输出连接密码就可以完成连接了。但是，在对反编译后的源码进行了分析之后，我们发现整个认证处理过程比我们想象中要复杂得多。
完整的配对步骤如下：
1. Android端应用通过蓝牙与适配器相连，并请求适配器证书（适配器的公钥和已签名的二进制字符串）。
2. Android应用发送适配器证书以及PIN码（用户向后台服务器发送的）。
3. 服务器通过App返回适配器的配对证书。
4. 适配器验证配对证书中的配对PIN码，验证成功之后，适配器会将证书和随机数发送给Android应用。
5. 接收到适配器证书之后，Android应用会检查其中的配对PIN码。
6. PIN码验证完成之后，Android App会对适配器的随机数进行签名。
7. 随机数签名完成之后，App会将适配器的随机数以及手机端的随机数发送给适配器，适配器会将已签名的手机随机数发送回给App。
8. 适配器和Android端App会对各自的随机数签名进行验证，并且还会建立一条加密信道来交换随机数。
在第一步中，适配器会发送其证书，其中包含有公钥和已签名的二进制字符串，签名使用的是SHA256哈希算法计算得出，计算参数如下：
1. 适配器的MAC地址；
2. 适配器PIN码；
3. 适配器公钥；
如果攻击者想要确定猜测出来的PIN码是否正确，他们还需要结合适配器的MAC地址、PIN码、以及适配器的公钥进行分析，并计算整个字符串的SHA256哈希，最后再对加密字符串的签名进行验证。如果攻击者能够与适配器进行连接，那么他们就可以获取足够的信息来对PIN码进行爆破。由于Drivelog适配器的PIN码由八位数字组成，因此总共有一亿种可能的PIN码组合。验证过程需要进行一次SHA256哈希计算以及公钥的加密操作。需要注意的是，只要使用合适的软件，一台普通的笔记本电脑就可以在三十分钟内进行一亿次SHA256哈希计算，如果使用多台爆破服务器进行并行计算的话，破解时间还会更短。
完整的攻击流程
现在，我们准备结合这两个漏洞来设计出一种可行的攻击方法：首先，通过认证过程中存在的信息披露漏洞实现对PIN码的爆破，然后使用通信信道发送恶意CAN总线消息。
结合以上信息，我们设计出的完整攻击流程如下：
1. 攻击者与Drivelog适配器进行配对，并接收适配器证书。
2. 攻击者在离线环境下爆破适配器PIN码。
3. 攻击者与适配器进行连接。
4. 完成了上面的1-3步之后，攻击者就可以发送恶意CAN总线数据了。
如果攻击者想要进行破坏，那么他就可以发送随机的CAN总线数据，并对汽车造成物理影响。
总结
此次发现的漏洞足以证明，Drivelog平台中存在严重的安全隐患，其中包括Drivelog适配器、移动端App以及后台通信服务器等设备都会受到影响。
除此之外，此次研究的结果也说明了以下几个问题：
1. 在产品的研发过程中，即使我们将信息安全放在首位，但最终的产品仍然有可能包含漏洞。就过去的经验来看，很多智能汽车组件中的漏洞都是产品功能实现的过程中出现的，但本文所描述的两个漏洞纯粹是设计缺陷所导致的。
2. 智能汽车的网络安全问题需要多层解决方案。很明显，在智能汽车的安全方面，虽然加密技术将扮演主要角色，但我们也不能仅仅依靠加密手段来抵御网络攻击。
3. 一旦攻击出现，用户需要安全工具来保护自身的安全，因此这个重任将落在汽车制造商和安全社区的身上。
4. 汽车制造商以及供应商需要对产品进行定期的安全审查和渗透测试，而这些测试应该有汽车安全专家来负责进行。
还没有评论，来说两句吧...