?入职公司已经一年了，工作的主要内容是针对车场的联网汽车进行安全测试以及车联网相关（或不相关）的安全技术研究。入职的这一年主要还是学习和摸索的过程，针对于汽车安全有了一些自己的理解。
汽车安全测试
??近些年来，很多车厂都对于车辆安全测试有了一些需求，造成这种需求上升的原因主要有两个：1、车载终端有了更强大的更丰富的功能。2、大量的车辆都具有了联网的功能。车厂最关心的漏洞类型，还是传统服务端的漏洞，包括APP、TBox、HU所访问的服务端。这些服务端与非车联网的服务端并无不同，因此往往不太需要与汽车安全有关的知识就可以进行漏洞的挖掘；其次就是一些非接触式的攻击纬度，如蓝牙、NFC、WiFi、4G、GPS，这类漏洞挖掘难度和攻击难度都较高，厂商也相对关心，但是在测试时间有限的情况下一般不会有什么产出；而接触式层面的测试，如调试口、USB、CAN总线（OBD）、后门等则是相对优先级低一些的测试项目。除此之外，安全测试不仅需要对于外部可直接使用的功能进行测试，同时还要对系统内部的一些存在的安全风险（漏洞）进行分析。因为内部有些系统或组件的漏洞并不能直接通过外部直接访问，但是在系统被攻破后会造成进一步的风险。所以在对于汽车进行安全测试的过程中，可以大致将测试的内容分为以下三个部分：1、已知公开漏洞扫描；2、未知漏洞挖掘；3、安全风险发现。下面分别针对这三个方面进行探讨。
已知公开漏洞检测
??已知公开漏洞：已知公开漏洞可以说是车联网安全测试过程中比较重要的环节之一，不论是云端、车载终端中都存在了大量第三方应用、代码和库。对于云端来说使用的Web引擎、Web框架、Web插件等都是第三方的成分。就车载终端来说，使用的操作系统、SDK、开源库都属于第三方的范畴。发现已知的公开漏洞，所使用的主要方法就是准确的识别出所使用的相关项目及其项目的版本号，再结合漏洞库的漏洞信息，发现待测目标中存在的已知公开漏洞。大致的工作流程可以如下图所示：
??
在整个已知公开漏洞的发现过程中，最重要的部分就是组件版本识别，准确地识别了组件的版本就可以发现存在于该组件中的漏洞。进行组件版本识别的方法有很多种。首先可以基于交互时的Banner信息，也可以基于交互时特定功能的差异性，也可以根据固件中的相关信息识别出组件及其版本信息进行识别。所以识别已知公开漏洞中最重要的部分是进行特征数据库的建立，选取车载系统中常见的且易受攻击的组件作为目标，收集这类组件的特征及其漏洞信息，并选取合适的方法作为组件发现以及版本识别的方法，可以做到每一个组件一个单独的测试脚本。并将这些脚本汇总成一个集成化的已知公开漏洞扫描工具。
未知漏洞挖掘
??已知漏洞的扫描几乎可以基于工具的自动化实现，而未知漏洞的挖掘则大部分需要测试人员人工测试与少量的自动化Fuzz。人工测试的目标主要是Web服务端、OTA、网络服务、蓝牙服务等。Web服务端的主要测试方式就是传统的Web测试，根据OWASP中的相关内容以及测试人员的经验对于服务端的安全性进行测试。OTA服务、网络服务、蓝牙服务、USB服务、UDS服务主要是通过对于二进制文件逆向分析进行漏洞挖掘，常见的漏洞类型为内存破坏、逻辑漏洞、命令注入等。除此之外，针对一些在车内比较常出现且容易出现漏洞的服务，可以采取Fuzz的方式对于其进行更深层次的安全测试。在此要特别区分开车载系统开发所使用的语言，如果使用的是Java（Android）语言开发，如安卓车机，则几乎不存在内存型漏洞。针对该类车机，只需对于逻辑漏洞以及命令注入类漏洞进行分析。不论是Web的漏洞还是二进制的漏洞，此类未知漏洞的挖掘的测试效果主要取决于测试人员的水平以及测试所花费的时间。
安全风险发现
??安全风险发现主要根据经验所提出的一些风险点，此类风险点并不算是漏洞，往往是由于一些配置错误或者安全意识缺失产生的问题。安全风险带来的危害可大可小，如调试口开放、没有安全启动机制等问题在安全风险问题中属于危害较大的。而调试信息未去除、权限设置不当等问题则属于安全风险问题中相对比较小的。由于目前车载终端安全还没有明确的规范和标准，安全风险的定义完全是根据各个安全团队自己定义的，所以此类安全风险基本基于个人以及团队的经验积累，测试难度小，但是点相对分散。
??以我目前的经验来说就把安全测试的内容大体的总结就是上面的三个方面。有机会的话会在后面的博客里针对每一方面的内容展开进行详细的介绍 。
汽车安全研究
??我的另一项工作内容就是进行汽车相关的安全研究。我们花费了几个月的时间在某款豪华车的研究之上。安全研究与安全测试最大的不同就是，汽车的安全研究主要的目标是搞一些别人没搞过或者搞不定的事出来。漏洞影响面广、漏洞影响程度深、攻击方式新颖，都是在进行汽车安全研究时的目标。而测试时的全面性则是在进行安全测试事的目标。
大批量车控
??目前看来，具有车联网功能的汽车，影响面相对最广的攻击方式，还是针对云端的服务进行攻击。大部分车厂对于互联网这一套东西并不是十分熟悉，也没有相应比较成熟的应急响应机制，所以出现严重漏洞的可能性一般较大，尤其是运行在内网中的服务。而如果想实现大规模的车辆控制，还需要进行进一步的分析服务端的架构，继续进行渗透，找到实际进行车辆控制的服务器才可以完成大规模的车控。这种方式车控范围大，但是对于车辆的控制还是局限于车厂设定的范围之内，一般只能开门开窗等车身舒适的操作，少数可以完成远程点火等涉及动力的操作。如果想要实现超出车厂设定的车辆控制，只能通过寻找OTA服务推送恶意的升级固件或进行汽车破解。
深入汽车破解
??汽车破解目前没有一个准确的定义，我的看法就是攻击者利用车载电子系统中的漏洞，不断地提升自身控制权，知道实现整车的控制。从科恩多次破解特斯拉以及作为汽车安全开端事件的大切诺基破解来看，可以分为以下四部分：1.HU、TBox控制权。2.直连CAN总线报文权。3.Gateway控制权。4.全部CAN总线报文权。就目前的阶段来说，虽然CAN总线有其自身的局限性，但是大部分车厂还是使用CAN总线作为车内大部分ECU的通信总线。所以获得了整车CAN总线的报文权，就可以向车内绝大部分ECU发送CAN报文。也就意味着可以通过UDS服务对于ECU进行刷写，从而实现超越车辆本身的限制的车控行为。而车载以太网则是未来的发展趋势，未来车内的总线可能由以太网逐步替换掉CAN，不过考虑到成本问题可能尚需时日。总体来说2、3、4这三项的难度不大，因为一般车辆对于这三项基本没有什么防护，只是需要大量的时间对于MCU进行分析。目前看来难度最大，也是大家比较争相去研究的还是如何攻破第一道防线，获取到HU（TBox）的最高权限。从之前的很多破解案例，如2019年pwn2own中对于特斯拉HU的破解，攻击者都选择的是浏览器作为突破口。特斯拉的浏览器内核从之前的Webkit转移到了现在的v8，还是难逃被攻破的命运。除浏览器外，HU（TBox）的网络服务、USB、OTA也都出现过RCE的案例。理论上，蓝牙和WiFi也存在被攻击的可能，PJ0的人曾经实现过对于WiFi芯片的攻击，在WiFi芯片中实现了RCE并进一步转化为到AP芯片RCE的攻击路径。在真正的对于HU（TBox）中的应用、驱动、系统进行分析之前，对于它们的硬件进行硬件分析、固件提取、固件分析等步骤都是都是必不可少的，这里面同样有很大的学问。
新型攻击方式
??新型的攻击方式则是汽车安全研究的另一个方向。在前些年，新型的攻击方式主要是针对汽车的无线攻击，包括针对无钥匙进入的无线中继攻击、GPS欺骗、伪基站劫持、TPMS攻击等。其中见过的比较优秀的案例就是对于汽车钥匙进行无线中继攻击无钥匙进入系统的案例。而最近很多车厂又将运用于其他领域的技术搬到了车上，如蓝牙钥匙、手机NFC钥匙、指纹解锁等功能。这些功能的出现，又为汽车的攻击带了一些新的攻击面。针对自动驾驶系统的攻击是这两年最火热的研究点，但是说实在的，目前进行汽车安全研究的人还没有自动驾驶的场景里面找到合适的切入点和攻击场景。通过激光逼停自动驾驶模式中特斯拉，通过异常图像激活特斯拉的感应雨刷，通过地面设置的标志点迫使特斯拉做出异常动作，是这两年比较出色的研究案例了。但是我感觉上述这些案例属于鸡肋型案例，真正有意义的针对自动驾驶的实际攻击场景以及攻击方式还需要进一步的研究。
小结
??汽车安全是一个传统安全的大杂烩，需要多各种各样的知识才能支撑起针对汽车安全的各种研究。入行一年的我现在处于这座大山脚下，对于汽车安全的一些方面有一点粗浅的认识，希望对于想要了解一些汽车安全的朋友有一定的帮助。
---------------------
版权声明：本文为CSDN博主「ltdzzzz」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dominatex/article/details/96144403